[Anthony Baxter]
> Regardless of whether we consider gcc's behaviour to be correct or not,
It is correct, but more to the point it's, umm, /there/ ;-)
> I do agree we need a fix for this in 2.5 final. That should also be
> backported to
> release24-maint for the 2.4.4 release, and maybe release2
Brett,
>> I think this is less accurate. Patches languish because of limited time
>> *and* because newbies don't have any social capital w/in the Python
>> community. New patch contributors are volunteers too, so they understand
>> that constraint. Their big problem is their outsider status, to wh
On Sunday 27 August 2006 05:06, Jack Howarth wrote:
>I discovered that gcc 4.2 exposes a flaw with
> signed integer overflows in python. This bug and the
> necessary fix has been discussed in detail on the gcc
> mailing list. I have filed a detailed bug report and
> the recommended patch pr
Regarding yield in the finally problem:
The current implementation throws RuntimeException after the yield
transfer the control back to the close method. If that is changed to
reporting a bad behavior and rethrowing GeneratorExit or its hidden
analog as suggested at the point of yield inside the g
On 8/23/06, Phillip J. Eby wrote:
> Our original
> assumption was that if they could implement throw() then they could clearly
> implement close(), since close() was defined in terms of throw(). An
> asynchronous return might be another matter.
Such asynchronous return can always be implemented v
On 8/23/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Simpler is in the eye of the beholder - the current close() merely uses
> throw() to raise a particular kind of exception 'asynchronously' (which is
> already a familiar concept due to KeyboardInterrupt). What you're suggesting
> is a completely
Jack Howarth wrote:
> I believe some of the others here might be interested in
> some other postings on the gcc mailing list regarding this issue
> (which weren't cross-posted here)...
>
> http://gcc.gnu.org/ml/gcc/2006-08/msg00516.html
> http://gcc.gnu.org/ml/gcc/2006-08/msg00517.html
>
> It
On 8/27/06, Chad Whitacre <[EMAIL PROTECTED]> wrote:
Brett, > When you submit your patch, the tracker notifies a mailing list that > most core Python developers subscribe to of the creation of your new > patch.Isn't "of the creation of your new patch" redundant? What else would it
be notifying the
Brett,
> When you submit your patch, the tracker notifies a mailing list that
> most core Python developers subscribe to of the creation of your new
> patch.
Isn't "of the creation of your new patch" redundant? What else would it
be notifying the list of?
> Your patch may languish for week
Brett,
>> I liked the "patch angel" term in Chad's version. Stating "a Python
>> developer will take a look at your patch" smacks of a guarantee,
>> while Chad's use of "patch angel" and "get the ball rolling" better
>> conveyed the fact that this 5-for-1 rule is simply a practice of some
>>
Title: zip -> izip; is __length_hint__ required?
Yes, please rip that
out. The patch should be a direct copy of the code in the itertools module. The use of length-hint was deliberately left-out of
izip().
Also, yes it would be fine to alter the
code in abstract.c to LBYL instead of su
I believe some of the others here might be interested in
some other postings on the gcc mailing list regarding this issue
(which weren't cross-posted here)...
http://gcc.gnu.org/ml/gcc/2006-08/msg00516.html
http://gcc.gnu.org/ml/gcc/2006-08/msg00517.html
It makes clear that the impact of this
Patch / Bug Summary
___
Patches : 407 open ( +3) / 3393 closed (+17) / 3800 total (+20)
Bugs: 888 open (+28) / 6145 closed (+14) / 7033 total (+42)
RFE : 232 open ( +3) / 236 closed ( +1) / 468 total ( +4)
New / Reopened Patches
__
most miss
13 matches
Mail list logo
