[Python-Dev] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

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 missing from Windows distribution  (2006-08-16)
CLOSED http://python.org/sf/1541412  opened by  Jim Jewett

buffer overrun in repr() for unicode strings  (2006-08-16)
CLOSED http://python.org/sf/1541585  opened by  Simon Law

work around clocks with low resolution (uuid.py)  (2006-08-17)
   http://python.org/sf/1541863  opened by  Hirokazu Yamamoto

patch in bug 1542016  (2006-08-17)
CLOSED http://python.org/sf/1542019  opened by  Santiago Gala

fix crash with continue in nested try/finally  (2006-08-18)
   http://python.org/sf/1542451  opened by  Neal Norwitz

Improve dynamic linking support on AIX  (2006-08-18)
   http://python.org/sf/1542544  opened by  Göran Uddeborg

Tweak pydoc to speak about with and CONTEXTMANAGERS  (2006-08-18)
   http://python.org/sf/1542681  opened by  Santiago Gala

Fix the vc8 solution files  (2006-08-18)
   http://python.org/sf/1542946  opened by  baus

urllib2 regression  (2006-08-19)
CLOSED http://python.org/sf/1542948  opened by  John J Lee

tarfile.py: fix for bug 1543303  (2006-08-21)
CLOSED http://python.org/sf/1543897  opened by  Lars Gustäbel

Socket module is not thread-safe  (2006-08-21)
   http://python.org/sf/1544279  opened by  Maxim Sobolev

Implementation of PEP 362  (2006-08-22)
   http://python.org/sf/1544909  opened by  Brett Cannon

Fixes SocketServer Bug 1531963  (2006-08-23)
   http://python.org/sf/1545011  opened by  Damon Kohler

new splicetee module  (2006-08-23)
   http://python.org/sf/1545262  opened by  Omar AitMous

new directio module  (2006-08-23)
   http://python.org/sf/1545275  opened by  Omar AitMous

xrange that supports longs, etc  (2006-08-24)
   http://python.org/sf/1546078  opened by  Neal Norwitz

crash in dict_equal  (2006-08-24)
   http://python.org/sf/1546288  opened by  Guido van Rossum

Create a real zip iterator object; not using itertools.izip  (2006-08-24)
CLOSED http://python.org/sf/1546297  opened by  Brian Holmes

broken error reporting when filename specified by -s missing  (2006-08-25)
   http://python.org/sf/1546372  opened by  lplatypus

Patches Closed
__

most missing from Windows distribution  (2006-08-16)
   http://python.org/sf/1541412  closed by  jimjjewett

buffer overrun in repr() for unicode strings  (2006-08-16)
   http://python.org/sf/1541585  closed by  gbrandl

broken shortcut keys  (2006-08-15)
   http://python.org/sf/1540874  closed by  kbk

patch in bug 1542016  (2006-08-17)
   http://python.org/sf/1542019  closed by  gbrandl

urllib2 regression  (2006-08-19)
   http://python.org/sf/1542948  closed by  gbrandl

Backports from trunk to release24-maint  (2006-08-15)
   http://python.org/sf/1540329  closed by  gbrandl

tarfile.py: fix for bug 1543303  (2006-08-21)
   http://python.org/sf/1543897  closed by  nnorwitz

Add some explication to PEP 3100  (2006-07-13)
   http://python.org/sf/1522038  closed by  bcannon

Create a real zip iterator object; not using itertools.izip  (2006-08-24)
   http://python.org/sf/1546297  closed by  gvanrossum

Add readinto method to StringIO and cStringIO  (2006-08-12)
   http://python.org/sf/1539381  closed by  bcannon

Remove the repr()-backticks  (2006-06-04)
   http://python.org/sf/1500623  closed by  bcannon

Move reduce() to functools  (2006-06-28)
   http://python.org/sf/1513870  closed by  gvanrossum

New / Reopened Bugs
___

infinite __str__ recursion in thread causes seg fault  (2003-07-31)
   http://python.org/sf/780714  reopened by  gbrandl

tools and demo missing from windows  (2006-08-16)
   http://python.org/sf/1541420  opened by  Jim Jewett

bug in python 2.4.3 for windows?  (2006-08-16)
CLOSED http://python.org/sf/1541566  opened by  tinkiwinky

Compiler command percent-sign causes format string error  (2006-08-16)
CLOSED http://python.org/sf/1541642  opened by  Matthew Cowles

bsddb can't use unicode filenames  (2006-08-17)
   http://python.org/sf/1541671  opened by  Zooko O'Whielacronx

Incorrect example calls to PyObject_SetItem  (2006-08-17)
CLOSED http://python.org/sf/1541682  opened by  John Machin

Recently introduced sgmllib regexp bug hangs Python  (2006-08-17)
   http://python.org/sf/1541697  opened by  John J Lee

Exceptions don't call _PyObject_GC_UNTRACK(self)  (2006-08-17)
   http://python.org/sf/1542051  opened by  Žiga Seilnacht

global variable: multiple id()-addresses   (2006-08-17)
CLOSED http://python.org/sf/1542166  opened by  Frank R. Schaefer

Nested finally in generators don't follow PEP 342  (2006-08-17)
   http://python.org/sf/1542308  opened by  Bob Ippolito

httplib reads one byte per system call

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Jack Howarth]

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 change in gcc was considered
and the reasoning on their decision to follow the standard so closely.

http://gcc.gnu.org/ml/gcc/2005-06/msg01238.html

Just so other beside Guido see those.
  Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] zip -> izip; is __length_hint__ required?

[Raymond Hettinger]

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 suppressing exceptions.
 
 
Raymond


From: [EMAIL PROTECTED] on behalf of Guido 
van RossumSent: Thu 8/24/2006 4:08 PMTo: Raymond 
Hettinger; python-dev@python.org; Brian HolmesSubject: zip -> 
izip; is __length_hint__ required?

At today's sprint, Brian Holmes contributed a patch that 
implementszip as an interator, a la izip. When reviewing Brian's code, I 
noticedthat he added an implementation of __length_hint__. My gut feeling 
isthat this isn't particularly useful given that zip() is 
almostexclusively used iteratively, and rarely if ever converted to a 
listor a tuple. (The one common exception is in the test suite, but 
thereit's almost always a short list, and 3 out of 5 were actually 
testsfor zip or izip.)Should we rip it out or keep it?Also, 
the existing convention for calling __length_hint__ (e.g. 
in_PyObject_LengthHint() in abstract.c) seems to be to 
usePyObject_CallMethod() and suppress TypeError and AttributeError 
comingout of the call. It would seem to make much more sense to 
checkwhether the attribute exists without calling it, and once it 
exists,just call it and not suppress any exceptions that come out of it. 
Isthere any reason why this shouldn't work?Guido van Rossum 
(home page: http://www.python.org/~guido/)


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] draft of patch guidelines

[Chad Whitacre]

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
 >> of the volunteers.
 >
 > Eh, I still don't like the term.  Too hokey.  But I did toss in a
 > "try" to not make it sound like a guarantee.

Yeah, kind of hokey. I included it because it's succinct and accurate, 
and because I assumed there's history to the term. Putting it in quotes 
helped w/ the goofiness, I thought.

I believe Skip used the term: any comment, Skip?



chad
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] draft of patch guidelines

[Chad Whitacre]

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 weeks or more before anyone volunteers a
 > response because of limited time on the part of Python developers.

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 which 
the patch angels/5-for-1 system is an elegant solution. And that's what 
should be emphasized in this FAQ.

In other words, I still prefer my wording. But since I'm a newbie with 
little merit, I'll be content with whatever you decide. :)



chad
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] draft of patch guidelines

[Brett Cannon]

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 list of?Yep, slightly.  > Your patch may languish for weeks or more before anyone volunteers a
 > response because of limited time on the part of Python developers.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 understandthat constraint. Their big problem is their outsider status, to whichthe patch angels/5-for-1 system is an elegant solution. And that's what
should be emphasized in this FAQ.But that makes us sound elitist.
In other words, I still prefer my wording. But since I'm a newbie withlittle merit, I'll be content with whatever you decide. :)OK.  =) -Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[David Hopwood]

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 makes clear that the impact of this change in gcc was considered
> and the reasoning on their decision to follow the standard so closely.
> 
> http://gcc.gnu.org/ml/gcc/2005-06/msg01238.html
> 
> Just so other beside Guido see those.

This discussion just highlights how different the perspective of much of
the C community (especially its language committee and compiler writers)
is on error handling and language safety, relative to the perspective of
the community that uses Python and other memory-safe languages.

The C perspective is that programs have to be correct, and if they're
not correct, it basically doesn't matter what happens.

The safe language perspective is that of course we try to write correct
programs, but if a program is not correct, then it *really matters* what
the error behaviour is. Ideally, it should be something that facilitates
debugging and that doesn't silently propagate an incorrect result.
Undefined behaviour is right out.

For example, from :

# The gcc developers always face two competing constituencies: do not
# change the compiler behaviour so that existing code which relies on
# undefined behaviour continues to work, and do change the compiler
# behaviour so that new code which does not rely on undefined behaviour
# runs faster.  In general, being compiler developers, we come down on
# the side of making code which does not rely on undefined behaviour run
# faster.

... and rarely even consider whether the behaviour *should* have been
undefined or not.


(There are many people who use C but do not agree with that perspective
on error handling -- I'm one of them. These people often devise elaborate
error handling frameworks, and compile at low optimization levels when
it doesn't hurt performance.)

-- 
David Hopwood <[EMAIL PROTECTED]>


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

[Igor Bukanov]

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 new flow control concept that doesn't exist anywhere else in
> the language.

Yes, this is a new feature, but IMO the extra complexity it brings to
the implementation is worth simplifications for the user.

>
> I suggested during the PEP 352 discussions that GeneratorExit should inherit
> directly from BaseException, so that the fix to your example would be to
> replace the bare "except:" with "except Exception:"

That is, the idea was to make writing code that catches GeneratorExit
difficult, right? But then note that if the code never catches
GeneratorExit, then throwing GeneratorExit after the yield is exactly
equivalent to just returning after the yield. In either case only
finally blocks would be executed and close then would ignore
GeneratorExit or StopIteration exceptions.

So this proposal is just an extension of the idea "it should be
difficult to use catch to ignore GeneratorExit" to simpler "No catch
can catch GeneratorExit".

> (because it can swallow
> KeyboardInterrupt the version you posted is buggy regardless of how g.close()
> works).

So there are 4 kinds of exceptions now in Python:

1. Normal exceptions that are OK to catch and ignore.
2. Interrupts like KeyboardInterrupt that can be caught and ignored,
but this is not recommended and it is easy to avoid catching them
accidentally.
3. Interrupts like GeneratorExit that can be caught and ignored, but
this is not recommended and where one has to write a lot of code to
avoid catching them in a generic catch block.
4. Control transfer "exceptions" like break and continue across
finally blocks. With enough efforts one can catch and ignore them, but
then one know what he is doing:

for i in range(3):
  print "i:", i
  try:
try:
  break
finally:
  raise Exception
  except Exception:
print "Ignoring break"

print "Done"

Ideally it would be nice to merge 2-3-4 into a single class of special
exceptions where the normal catch statement never sees them and extra
efforts are necessary to ignore them, but with this proposal at least
the list would not contain the item 3.

Please also note that these comments are born after playing with
generators in JS 1.7, the next JavaScript that Firefox 2.0 would
implement. The current JS implementation tries to follow PEP 352, but
since the only catch available in JS1.7 is just catch-all as before,
the problems with accidentally catching GeneratorExit are much more
visible in JS [1]. Thus changing close in JS to just return after
yield would address the issues nicely but perhaps this can help Python
users as well.

Regards, Igor

[1]  https://bugzilla.mozilla.org/show_bug.cgi?id=349331
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

[Igor Bukanov]

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 via a special
hidden exception that is invisible to catch statements. I.e an
implementation of generators  can still use ___GeneratorExit
internally as long as it is not exposed to scripts.

Regards, Igor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GeneratorExit is unintuitive and uneccessary

[Igor Bukanov]

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 generator, that
would nicely unwind possible outer finally blocks and close the
generator in any case.

With that close-as-return proposal it does not even require to change
the interpreter as the close method can simply loop like in
generator.triggerRetrunAfterTheYield
while generatorYielding:
  reportBadYield
  generator.triggerRetrunAfterTheYield

Of cause, a bad generator can still subvert even this in the same way
as return can be canceled, but with such changes one has to put
significant non-trivial efforts in writing such code.

Regards, Igor

On 8/24/06, Guido van Rossum  wrote:
> IIUC this is how return currently works -- in some sense it's an
> exception, but it can't be caught, and it won't escape from the
> current frame. Ditto for break/continue.
>
> The generator extensions are still very young, and I'm not against
> changing them somewhat in 2.6 or py3k. Perhaps GeneratorExit can be
> replaced by a treatment similar to the treatment of return. But I'm
> not sure it helps with the original problem; you could still put a
> yield in a finally clause that intercepts a return, just as today you
> can write
>
> def f():
>   for i in range(10):
> print i
> try:
>   return
> finally:
>   break
>   print 999
>
> where the finally clause nullifies the return. In a generator, a yield
> in the finally clause still needs to be dealt with somehow.
>
>
> On 8/23/06, Igor Bukanov <[EMAIL PROTECTED]> wrote:
> > 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 via a special
> > hidden exception that is invisible to catch statements. I.e an
> > implementation of generators  can still use ___GeneratorExit
> > internally as long as it is not exposed to scripts.
> >
> > Regards, Igor
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Anthony Baxter]

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 proposed by the gcc developers.
> This problem should be addressed BEFORE python 2.5 is
> released. The bug report is...
>
> [ 1545668 ] gcc trunk (4.2) exposes a signed integer overflows
>
> in the python sourceforge bug tracker. Thanks in advance
> for attempting to fix this before Python 2.5 is released.
>  Jack

Regardless of whether we consider gcc's behaviour to be correct or not, 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 release23-maint, as Barry 
recently started talking about cutting a 2.3.6. 

Can I nominate Tim, with his terrifying knowledge of C compiler esoterica, as 
the person to pick the best fix? 

Thanks,
Anthony
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] draft of patch guidelines

[Chad Whitacre]

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 which
>> the patch angels/5-for-1 system is an elegant solution. And that's what
>> should be emphasized in this FAQ.
> 
> But that makes us sound elitist.

To be honest I took away the opposite lesson. New patch contributors 
acutely feel their outsider status; this is to be expected in any social 
system. The fact that there is a clear, established path for newcomers 
to follow -- the 5-for-1 rule -- is precisely what makes the Python 
community non-elitist in this instance. Transparent documentation on 
this point would further erode any elitism.



chad
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Tim Peters]

[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 release23-maint, as Barry
> recently started talking about cutting a 2.3.6.
>
> Can I nominate Tim, with his terrifying knowledge of C compiler esoterica, as
> the person to pick the best fix?

It's a bitch.  Changing to

if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)

is the obvious fix, but violates our "no warnings" policy:  the MS
compiler warns about applying unary minus to an unsigned operand -- it
"looks insane" to /their/ compiler writers ;-).  Elegant patch below
-- LOL.

Would be nice if someone verified it worked on a box where it matters.
 Would also be nice if people checked to see whether their compiler(s)
warn about something else now.

IIndex: Objects/intobject.c
===
--- Objects/intobject.c (revision 51618)
+++ Objects/intobject.c (working copy)
@@ -564,8 +564,14 @@
"integer division or modulo by zero");
return DIVMOD_ERROR;
}
-   /* (-sys.maxint-1)/-1 is the only overflow case. */
-   if (y == -1 && x < 0 && x == -x)
+   /* (-sys.maxint-1)/-1 is the only overflow case.  x is the most
+* negative long iff x < 0 and, on a 2's-complement box, x == -x.
+* However, -x is undefined (by C) if x /is/ the most negative long
+* (it's a signed overflow case), and some compilers care.  So we cast
+* x to unsigned long first.  However, then other compilers warn about
+* applying unary minus to an unsigned operand.  Hence the weird "0-".
+*/
+   if (y == -1 && x < 0 && (unsigned long)x == 0-(unsigned long)x)
return DIVMOD_OVERFLOW;
xdivy = x / y;
xmody = x - xdivy * y;
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com