On 19/06/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On behalf of the Python development team and the Python community, I am
> happy to announce the first beta releases of Python 2.6 and Python 3.0.
Any ETA for Windows builds? The web pages s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 19, 2008, at 4:43 AM, Paul Moore wrote:
On 19/06/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team and the Python community,
I am
happy to announce the fir
On Wed, Jun 18, 2008 at 10:55:32PM -0700, Alex Martelli wrote:
-> On Wed, Jun 18, 2008 at 9:58 PM, Cesare Di Mauro <[EMAIL PROTECTED]> wrote:
-> > Very very, interesting. Thanks. :)
-> >
-> > Somebody thinks that Python is unsuitable to implement a DSL: IMO your
example prove the contrary. :D
->
Thanks Trent, I'll apply the diff and run the tests in a tight loop
after re-enabling the client listener tests. I appreciate you tracking
this down
On Thu, Jun 19, 2008 at 2:07 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
>> Well, on my win2k machine getfqdn('127.0.0.1') returns the actual name
>>
This is a common problem. Binding to '127.0.0.1' will bind to *only*
that address; binding to "" will bind to *all* addresses the machine
is known by. If the client uses a different way of getting the
address than the literal '127.0.0.1' (like a call to getfqdn(), which
has pretty indeterminate r
On Thu, Jun 19, 2008 at 4:54 AM, C. Titus Brown <[EMAIL PROTECTED]> wrote:
>
> More generally, I've never understood why some people insist that
> certain features make Ruby better for DSLs -- are code blocks really
> that important to DSLs? Or is it just the lack of parens??
Code blocks let Ruby
At 04:54 AM 6/19/2008 -0700, C. Titus Brown wrote:
More generally, I've never understood why some people insist that
certain features make Ruby better for DSLs -- are code blocks really
that important to DSLs? Or is it just the lack of parens??
Comparison to JavaScript suggests that it's the b
On Thu, Jun 19, 2008 at 1:03 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Maciej Fijalkowski did an opcode analysis for PyPy,
>> it also shows the relative frequency of opcodes following a
>> specifc one:
>>
>> http://codespeak.net/svn/user/fijal/opcodes.txt
>>
>> Might it make sense to add
On Thu, Jun 19, 2008 at 03:04:11PM -0500, Benjamin Peterson wrote:
> I don't think the whole introduction had to go. I think it helped give
> some idea of how multiprocessing works before jumping straight to the
> API reference.
I don't think overview material like that should be buried inside the
On Thu, Jun 19, 2008 at 3:30 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> My plan is to move multiprocessing from the 'Optional OS Services'
> chapter to the 'Interprocess Communication' chapter, and then expand
> the introduction of the chapter to discuss the GIL and related issues.
> Presumably
Where would that chapter end up (source-wise) I think a few of us
might have additional things to add ;)
On Thu, Jun 19, 2008 at 4:30 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 19, 2008 at 03:04:11PM -0500, Benjamin Peterson wrote:
>> I don't think the whole introduction had to go.
On Sun, Jun 1, 2008 at 12:28 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Sat, May 31, 2008 at 10:11 PM, Alexandre Vassalotti
> <[EMAIL PROTECTED]> wrote:
>> Would anyone mind if I did add a public C API for gc.disable() and
>> gc.enable()? I would like to use it as an optimization for the pickle
On Thu, Jun 19, 2008 at 3:23 PM, Alexandre Vassalotti
<[EMAIL PROTECTED]> wrote:
> On Sun, Jun 1, 2008 at 12:28 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> On Sat, May 31, 2008 at 10:11 PM, Alexandre Vassalotti
>> <[EMAIL PROTECTED]> wrote:
>>> Would anyone mind if I did add a public C API for gc.
Hi,
I am curious if there is any news on this issue. My understanding is
that since this is a new feature, nothing will be committed until
after 2.6 comes out, but it would be *really nice* if I could use
annotations in 2.x.
[warning - mini rant]
Reason is, I am using 3.0a for now for this projec
On Thu, Jun 19, 2008 at 3:59 PM, David Pokorny <[EMAIL PROTECTED]> wrote:
> I am curious if there is any news on this issue. My understanding is
> that since this is a new feature, nothing will be committed until
> after 2.6 comes out, but it would be *really nice* if I could use
> annotations in 2
Alexandre Vassalotti wrote:
Do you have any idea how this behavior could be fixed? I am not a GC
expert, but I could try to fix this.
Perhaps after making a GC pass you could look at the
number of objects reclaimed during that pass, and if
it's less than some fraction of the objects in existen
On Jun 19, 4:16 pm, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> complex change to the syntax and code generator. Your motivation is
> also suspect: 2.6 is supposed to be a stepping stone towards 3.0, not
> a safe haven for people who don't like certain 3.0 features. Just get
Guilty as charged
David Pokorny wrote:
[warning - mini rant]
Reason is, I am using 3.0a for now for this project, but I am sorry to
say that using parentheses for raising exceptions drives me up the
wall,
[warning - a bit of a counter-rant ;-]
Does it bother you that you need ()s to make instances elsewhere?
In the comments before the implementation of sum()
in mathmodule.c, note 4 says:
Note 4: A similar implementation is in Modules/cmathmodule.c.
Be sure to update both when making changes.
I can't find a sum implementation or similar code in cmathmodule.c.
Did someone intend to port the sum f
We're still working on the implementation details for math.sum().
When it's finished, the cmath equilvalent will be added.
Raymond
- Original Message -
From: "A.M. Kuchling" <[EMAIL PROTECTED]>
To:
Sent: Thursday, June 19, 2008 7:16 PM
Subject: [Python-Dev] sum() in math module not du
At any rate, I am still interested if anyone has a working patch for
this against the trunk, or any pointers for adapting 53170, words of
experience when changing the grammar, additions to PEP 306, etc... any
help would be greatly appreciated!
David,
I can help. I don't have a patch against the
> This is a common problem. Binding to '127.0.0.1' will bind to *only*
> that address;
Indeed.
> binding to "" will bind to *all* addresses the machine
> is known by.
Agreed again. I believe what we're dealing with here though is a lack of
clarity regarding what role the 'address' attribute e
22 matches
Mail list logo
