[issue11233] clarifying Availability: Unix

[Georg Brandl]

Georg Brandl  added the comment:

The "Notes on availability" bullet list at the top of 
docs.python.org/library/os should already say everything that there is to say 
here...

--
nosy: +georg.brandl
resolution:  -> works for me
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10709] Misc/AIX-NOTES needs updating

[Georg Brandl]

Georg Brandl  added the comment:

Committed as r88438.  Thanks!

Please indicate how much of this needs to be backported to 2.7 and 3.1.

--
resolution:  -> fixed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build

[Georg Brandl]

Georg Brandl  added the comment:

Committed as r88439 in py3k.

--
priority: release blocker -> critical

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11184] Broken large file support on AIX

[Georg Brandl]

Georg Brandl  added the comment:

Okay, committed to py3k in r88440.  Does this need backporting?

--
resolution:  -> fixed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11222] Python3.2rc3 fails to build on Mac OS X with a non-framework build

[Ned Deily]

Changes by Ned Deily :


--
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11184] Broken large file support on AIX

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Okay, committed to py3k in r88440.  Does this need backporting?

Certainly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant

[yeswanth]

yeswanth  added the comment:

I have gone through the source of mkcfg.py and though of implementing version 
check by calling distutils2.is_valid_version() and then if it results false , 
call suggest_normalized_version() to ask the user if he would like the 
suggested version or enter a new version ...if it returns none, prompting the 
version again . For this i need to create a new function say "check_version()" 
and call it just after version is asked for in the query_user() function call.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11247] Error sending packets to multicast IPV4 address

[Charles-Francois Natali]

Charles-Francois Natali  added the comment:

Are you using a default gateway ?
Are you sure this gateway supports multicast ?
See for example http://www.sockets.com/err_lst1.htm#WSAENETUNREACH :
"""
WSAENETUNREACH (10051) Network is unreachable. 

Berkeley description: A socket operation was attempted to an unreachable 
network. 

WinSock description: Almost same as Berkeley. For WinSock, this error is 
equivalent to Berkeley's EHOSTUNREACH error, the catch-all error for 
unreachable hosts. "You can't get there from here." 

TCP/IP scenario: The local network system could generate this error if there 
isn't a default route configured. Typically, though, WinSock generates this 
error when it receives a "host unreachable" ICMP message from a router. The 
ICMP message means that a router can't forward the IP datagram, possibly 
because it didn't get a response to the ARP request (which might mean the 
destination host is down). Note: this error may also result if you are trying 
to send a multicast packet and the default gateway does not support multicast 
(check your interface configuration). 
"""

By the way, when you submit this kind of issue, it's a lot easier to analyse if 
you provide a sample code.

--
nosy: +neologix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11224] 3.2: tarfile.getmembers causes 100% cpu usage on Windows

[Lars Gustäbel]

Lars Gustäbel  added the comment:

_FileInFile.read() does lots of unnecessary seeking and reads the same block 
again and again. The attached patch fixes that. Please try if it works for you.

--
assignee:  -> lars.gustaebel
keywords: +patch
Added file: http://bugs.python.org/file20793/tarfile.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11244] Negative tuple elements produce inefficient code.

[Mark Dickinson]

Mark Dickinson  added the comment:

Unassigning.  I don't think that r82043 is the *real* culprit here;  that 
bugfix just happened to expose a deficiency in the peepholer;  one that's 
already present in other situations:

>>> dis.dis(lambda: 2*(3*4))
  1   0 LOAD_CONST   1 (2)
  3 LOAD_CONST   4 (12)
  6 BINARY_MULTIPLY 
  7 RETURN_VALUE
>>> dis.dis(lambda: (2*3)*4)
  1   0 LOAD_CONST   5 (24)
  3 RETURN_VALUE

Antoine, does your patch take care of this case too?

--
assignee: mark.dickinson -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Greg Kochanski]

New submission from Greg Kochanski :

When you have a generator as an argument to zip(), code after the last yield 
statement may not get executed.  The problem is that zip() stops after it gets 
_one_ exception, i.e. when just one of the generators has finished.

As a result, if there were any important clean-up code at the end of a 
generator, it will not be executed.   Caches may not get flushed, et cetera.

At the least, this is a documentation bug that needs to be pointed out in both 
zip() and the definition of a generator().  More realistically, it is a severe 
wart on the language, because it violates the programmer's reasonable 
expectation that a generator executes until it falls off the end of the 
function.  It means that a generator becomes conceptually nasty: you cannot 
predict what it will do based just on an inspection of the code and the code it 
calls.

Likely, the same behavior happens in itertools, too.

--
components: None
files: bug312.py
messages: 128842
nosy: gpk-kochanski
priority: normal
severity: normal
status: open
title: Tails of generator get lost under zip()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20794/bug312.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Ezio Melotti]

Ezio Melotti  added the comment:

This behavior is documented[0]:
"""The returned list is truncated in length to the length of the shortest 
argument sequence."""

You can use izip_longest instead[1].

[0]: http://docs.python.org/library/functions.html#zip
[1]: http://docs.python.org/library/itertools.html#itertools.izip_longest

--
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11244] Negative tuple elements produce inefficient code.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le samedi 19 février 2011 à 10:45 +, Mark Dickinson a écrit :
> Mark Dickinson  added the comment:
> 
> Unassigning.  I don't think that r82043 is the *real* culprit here;  that 
> bugfix just happened to expose a deficiency in the peepholer;  one that's 
> already present in other situations:
> 
> >>> dis.dis(lambda: 2*(3*4))
>   1   0 LOAD_CONST   1 (2)
>   3 LOAD_CONST   4 (12)
>   6 BINARY_MULTIPLY 
>   7 RETURN_VALUE
> >>> dis.dis(lambda: (2*3)*4)
>   1   0 LOAD_CONST   5 (24)
>   3 RETURN_VALUE
> 
> Antoine, does your patch take care of this case too?

It should. Can you test?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Greg Kochanski]

Greg Kochanski  added the comment:

(a) It is not documented for the symmetric (4, 4) case where the two generators 
are of equal length.

(b) Even for the asymmetric case, it is not documented in such a way that 
people are likely to see the implications.

(c) Documented or not, it's still a wart.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11243] email/message.py str conversion

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso  added the comment:

I also got this now, it happens with and without the str() patch stuff.  (Note 
that message.py line numbers are off by 1-2 lines ..).  I don't know more about 
that in the moment, but the only thing that's changed is that i do:

   alln = self._msg.items()[:] # In fact -> ensure all are header.Header
   # If any converted (str->Header) header names exist ...
   if len(alln):
# Delete *all* occurrences of h (doesn't throw)
for (n, b) in alln:
del self._msg[n]
# And append in order
for (n, b) in alln:
self._msg[n] = b


  Traceback (most recent call last):
File "/Users/steffen/usr/bin/s-postman.py", line 953, in save_ticket
  mb.add(ticket.message())
File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 595, in 
add
  self._toc[self._next_key] = self._append_message(message)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 733, in 
_append_message
  offsets = self._install_message(message)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 805, in 
_install_message
  self._dump_message(message, self._file, self._mangle_from_)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 215, in 
_dump_message
  gen.flatten(message)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 
88, in flatten
  self._write(msg)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 
134, in _write
  self._dispatch(msg)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 
151, in _dispatch
  main = msg.get_content_maintype()
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 
528, in get_content_maintype
  ctype = self.get_content_type()
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 
516, in get_content_type
  ctype = _splitparam(value)[0].lower()
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 53, 
in _splitparam
  a, sep, b = param.partition(';')
  Exception: AttributeError: 'NoneType' object has no attribute 'partition'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11243] email/message.py str conversion

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso  added the comment:

The latter one was my fault, i did LIST.append(name, HEADER.append(xy)), 
assuming that HEADER.append() returns self though it doesn't.  Sorry.  However 
- shouldn't Message.__setitem__ check for valid arguments (see msg128846 code 
snippet)?  It would have saved some anger...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11243] email/message.py str conversion

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso  added the comment:

However, maybe that 5.1 message.py thing doesn't like header.Header instances.  
Also extending msg128846, this one is related to the str() issue - added an 
extended email_message.2.patch.

  Traceback (most recent call last):
File "/Users/steffen/usr/bin/s-postman.py", line 953, in save_ticket
  mb.add(ticket.message())
File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 595, in 
add
  self._toc[self._next_key] = self._append_message(message)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 733, in 
_append_message
  offsets = self._install_message(message)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 805, in 
_install_message
  self._dump_message(message, self._file, self._mangle_from_)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 215, in 
_dump_message
  gen.flatten(message)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 
88, in flatten
  self._write(msg)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 
134, in _write
  self._dispatch(msg)
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 
151, in _dispatch
  main = msg.get_content_maintype()
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 
530, in get_content_maintype
  ctype = self.get_content_type()
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 
518, in get_content_type
  ctype = _splitparam(value)[0].lower()
File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 53, 
in _splitparam
  a, sep, b = param.partition(';')
  Exception: AttributeError: 'Header' object has no attribute 'partition'

P.S.: i'm hard to take, and 'programming is an iterative task'...

--
Added file: http://bugs.python.org/file20795/email_message.2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11244] Negative tuple elements produce inefficient code.

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8300] Allow struct.pack to handle objects with an __index__ method.

[Matt Joiner]

Matt Joiner  added the comment:

Why isn't this implemented to work with __int__ as well?

--
nosy: +anacrolix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11234] Possible error in What's new Python3.2(rc3) documentation (sysconfig.get_config_var)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, it's up to Georg to decide if it goes before 3.2. But I don't see the 
hurry: the online docs are rebuilt daily anyway.

--
assignee: pitrou -> georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Ezio Melotti]

Ezio Melotti  added the comment:

a) that's true, even if the behavior makes sense (when the first generator ends 
there's no reason to see what's next in the second). Georg, do you think it 
should be documented?

b) if you want to be sure that some clean-up is executed you should use a 
try/finally in the generator. Relying on the number of elements of another 
generator used together with zip() seems very fragile to determine when/if a 
clean-up should be done (what if the other generator has a different number of 
elements? what if an exception is raised before it's fully consumed? what if 
you use the generator in for/while loop and break the loop before reaching the 
end? ...).

c) even if you consider it as a wart, changing it for zip() will break 
compatibility and it's against the language moratorium. This behavior is also 
useful if e.g. you have the generators g1 that yields 1 2 3, g2 that yields 4 5 
6, and g3 that yields a b c d e f and you want to first zip(g1, g3) and get 1a 
2b 3c and then continue with zip(g2, g3) and get 4d 5e 6f. Checking in the 
first zip() if g3 reached its end or not would mean consuming the 'd', and that 
would be a worse wart imho.

--
nosy: +eric.araujo, georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10709] Misc/AIX-NOTES needs updating

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Great!

I intend to check that branch 2.7 works fine on AIX once I will have finished 
with 3.x (which should be soon).
I will then update this file for Python 2.7 (there shouldn't be much changes 
hopefully).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11071] What's New review comments

[Éric Araujo]

Éric Araujo  added the comment:

Attached patch adds a missing attribution, a missing bug number, fixes one typo 
(“content manager”) and five grammar issues.

I haven’t had time to make a full read-through during the last weeks, but here 
are a few comments about the overall structure of the file:
- The introduction is a bit scarce (compare that of 2.6);
- “Other Language Changes” sounds strange, given that the previous sections 
(PEPs) are language as well as library changes → name it something like “Small 
Language Changes”;
- “New, Improved, and Deprecated Modules” are not sorted nor grouped;
- Ditto for the bits of advice in the Porting section;
- The small sections about Unicode and codecs could be merged;
- What Antoine said about “Code repository”.

--
keywords: +patch
Added file: http://bugs.python.org/file20796/whatsnew-fixes.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11233] clarifying Availability: Unix

[R. David Murray]

R. David Murray  added the comment:

Yes, but when you jump directly to one of the functions, you don't see that 
bullet list.  Whereas if it were a footnote on the 'avaiability: unix" 
statement, the natural thing would be to follow the footnote and thus learn the 
limitations on that statement.  Thus I think the footnote would be better than 
the bullet list at the top.

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11243] email/message.py str conversion

[Steffen Daode Nurpmeso]

Changes by Steffen Daode Nurpmeso :


Removed file: http://bugs.python.org/file20784/email_message.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11243] email/message.py str conversion

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso  added the comment:

David, i'm going down now.  I'll raise the type to 'crash', because, in fact, 
EMail 5.1 doesn't really take care of header.Header objects in message.Message 
headers, which doesn't sound pretty useful to me!  The patch is sufficient for 
my broken thing (it doesn't produce a traceback at the moment - time to go for 
a sunday!), but since i don't really have a glue of mailbox.py / email/* it may 
not cover all places where a header.Header may occur but the code in fact 
assumes a str (and implicit conversion of Header to str doesn't work).

--
type: behavior -> crash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11243] email/message.py str conversion

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso  added the comment:

... as a last though of mine, here is a header of the well known spam mail:


>From MAILER-DAEMON Sat Feb 19 15:58:47 2011
Date: =?latin1?q?Tue=2C_4_Jan_2011_17=3A37=3A26_+0100_=28CET=29?=
From: =?latin1?q?=22SAJATNAPTAR=2ECOM=22_=3Cinfo=40sajatnaptar=2Ecom=3E?=
To: =?latin1?q?source-changes=40cvs=2Eopenbsd=2Eorg?=
Subject: 
=?latin1?q?Falinapt=3Fr_ingyenes_h=3Fzhozsz=3Fll=3Ft=3Fssal=2E_M=3Fr_rendelt=3Fl=3F_Olvass_el!?=
Message-ID: =?latin1?q?=3C20110104053726system=40sajatnaptar=2Ecom=3E?=
Content-Type: =?latin1?q?text/plain=3B_charset=3Diso-8859-1?=


Shouldn't email/* be smart enough to know that Date:, Content-Type:, 
Message-ID:, plus some other well-known, RFC-documented header names need *not* 
be converted, whatever type of object is used to represent them?  This could be 
implemented with a simple {}.

Bye.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Martin v . Löwis]

New submission from Martin v. Löwis :

Currently, memory management for the Py_tp_doc slot in PyType_FromSpec is 
ill-defined. The doc string being passed is stored in the type object as-is, 
but later released with PyObject_Free. To make this consistent, PyType_FromSpec 
should copy the string, so that it's guaranteed that relasing the memory 
matches allocation.

Without this patch, users will have to hold onto the type objects they get from 
PyType_FromSpec "forever".

--
files: tp_doc.diff
keywords: patch
messages: 128857
nosy: loewis
priority: release blocker
severity: normal
status: open
title: Memory mismanagement with Py_tp_doc
Added file: http://bugs.python.org/file20797/tp_doc.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Sure it should be a blocker?

--
nosy: +georg.brandl, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Martin v . Löwis]

Martin v. Löwis  added the comment:

If this isn't added, people using the API might see crashes. If they then work 
around crashes, they will see memory leaks in future releases.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, isn't Py_tp_doc characteristically bound to a constant char *, so that 
the problem doesn't manifest itself?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7291] urllib2 cannot handle https with proxy requiring auth

[Mike Beachy]

Mike Beachy  added the comment:

I've been in contact w/ Barry Scott offline re: the monkey patch previously 
mentioned. I'm attaching a 2.7 maintenance branch patch that he has needed to 
extend, and plans to follow up on.

--
Added file: http://bugs.python.org/file20798/2_7_x.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7291] urllib2 cannot handle https with proxy requiring auth

[Mike Beachy]

Mike Beachy  added the comment:

Attached to this comment (can you attach multiple files at once?) is the 
somewhat moldy 2.6.4 monkey patch, mercilessly ripped from my own code and 
probably not good for much.

--
Added file: http://bugs.python.org/file20799/monkey_2_6_4.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Georg Brandl]

Georg Brandl  added the comment:

Sounds like a blocker to me.  Martin, will you be able to provide a patch 
before final?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11233] clarifying Availability: Unix

[Georg Brandl]

Georg Brandl  added the comment:

That's a good point, indeed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11071] What's New review comments

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Éric, go ahead an apply this patch except for the insertion of "the" in the 
codecs section.

I'm not making regrouping, reordering, merging or other stylistic changes at 
this point.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11233] clarifying Availability: Unix

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Greg Kochanski]

Greg Kochanski  added the comment:

Yes, the current behaviour makes sense from a language designer's viewpoint, 
and maybe even from the user's viewpoint (if the user thinks about it a 
carefully).

But, that's not the point of a computer language.   The whole reason we program 
in languages like python instead of asm is to match the behaviour of the 
silicon to human capabilities and expectations.   So, documentation needs to go 
beyond the minimum from which an expert could deduce the system behaviour.  It 
needs to point out unexpected things that a competent programmer might miss, 
even if they could potentially have deduced that unexpected behaviour.

The trouble here is that the syntax of a generator is so much like a function 
that it's easy to think of it as being as safe and simple as a function.  It's 
not: the "yield" statement lets a lot of external complexity leak in that's not 
relevant to a function (unless you're writing multithreaded code).  So, the 
documentation needs to help the user avoid such problems.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Greg Kochanski]

Changes by Greg Kochanski :


--
resolution: invalid -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11071] What's New review comments

[Éric Araujo]

Éric Araujo  added the comment:

Applied in r88441.

I checked again that the issue numbers were right, and discovered that
the functions in site related to PEP 370 were actually new in 2.6, not
3.2, so you may want to remove that section.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11071] What's New review comments

[Éric Araujo]

Éric Araujo  added the comment:

> I checked again that the issue numbers were right, and discovered that
> the functions in site related to PEP 370 were actually new in 2.6, not
> 3.2, so you may want to remove that section.

Sorry: The functions are indeed new in 2.7/3.2, it’s the command-line
functionality (python -m site --user-base) that was already here in
previous versions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11234] Error in What's new 3.2rc3 with sysconfig.get_config_var('SO')

[Éric Araujo]

Éric Araujo  added the comment:

The online docs are rebuilt, but people may read the version bundled with a 
tarball or installer and wonder at the discrepancy, if they notice it.

--
title: Possible error in What's new Python3.2(rc3) documentation 
(sysconfig.get_config_var) -> Error in What's new 3.2rc3 with 
sysconfig.get_config_var('SO')

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11234] Error in What's new 3.2rc3 with sysconfig.get_config_var('SO')

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy:  -pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11071] What's New review comments

[Éric Araujo]

Éric Araujo  added the comment:

It appears that Misc/NEWS in 3.2 lists the new functions under the 3.1 section, 
among other strange differences.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Well, isn't Py_tp_doc characteristically bound to a constant char *

That's exactly the problem: PyType_FromSpec puts in this string literal.
When the type is later released, PyObject_Free is called in
type_dealloc, which segfaults.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Sounds like a blocker to me.  Martin, will you be able to provide a patch 
> before final?

The attached patch works fine for me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > Sounds like a blocker to me.  Martin, will you be able to provide a patch 
> > before final?
> 
> The attached patch works fine for me.

Is there some documentation somewhere for all this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11234] Error in What's new 3.2rc3 with sysconfig.get_config_var('SO')

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Éric, go ahead and fix this please.

--
assignee: georg.brandl -> eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11234] Error in What's new 3.2rc3 with sysconfig.get_config_var('SO')

[Éric Araujo]

Éric Araujo  added the comment:

Done in r88442.  I found a missing closing quote and fixed it too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11244] Negative tuple elements produce inefficient code.

[Mark Dickinson]

Mark Dickinson  added the comment:

> It should. Can you test?

Ah, you're asking me to actually do some (minimal) work instead of just 
complaining?

Yep, the patch tests fine over here (OS X 10.6), and fixes the 2*(3*4) case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8300] Allow struct.pack to handle objects with an __index__ method.

[Mark Dickinson]

Mark Dickinson  added the comment:

Because (arguably) we don't want to be able to pack non-integral floats (or 
Decimal instances, or ...) using integer formats:

>>> import struct
[56090 refs]
>>> struct.pack('L', 2.3)
Traceback (most recent call last):
  File "", line 1, in 
struct.error: required argument is not an integer
[56125 refs]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

[Mark Dickinson]

Mark Dickinson  added the comment:

Sorry, I'm unassigning myself from this;  I'm still following the issue, but 
just don't forsee having time to work on it at all.

--
assignee: mark.dickinson -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Georg Brandl]

Changes by Georg Brandl :


--
assignee:  -> docs@python
components: +Documentation -None
nosy: +docs@python
stage: committed/rejected -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Martin v . Löwis]

Martin v. Löwis  added the comment:

>>> Sounds like a blocker to me.  Martin, will you be able to provide a patch 
>>> before final?
>>
>> The attached patch works fine for me.
> 
> Is there some documentation somewhere for all this?

Can you please be more specific? What's "all this"?

That tp_doc will be copied is currently undocumented. PyType_FromSpec
is documented in the PEP.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> >>> Sounds like a blocker to me.  Martin, will you be able to provide a patch 
> >>> before final?
> >>
> >> The attached patch works fine for me.
> > 
> > Is there some documentation somewhere for all this?
> 
> Can you please be more specific? What's "all this"?
> 
> That tp_doc will be copied is currently undocumented. PyType_FromSpec
> is documented in the PEP.

I meant all of py_tp_doc, "limited api", "restricted api" show almost
zero hits in the API docs. A PEP is nice but I'm not sure many people
spontaneously read PEPs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Martin v . Löwis]

Martin v. Löwis  added the comment:

>> That tp_doc will be copied is currently undocumented. PyType_FromSpec
>> is documented in the PEP.
> 
> I meant all of py_tp_doc, "limited api", "restricted api" show almost
> zero hits in the API docs. A PEP is nice but I'm not sure many people
> spontaneously read PEPs.

No, there is no documentation in the Doc directory. I *would* expect
that people interested in using the stable ABI do find the PEP and
read it. With the exception of this issue, I consider the PEP to be
complete and correct documentation (of course, it probably contains
errors that I'm unaware of).

However, documentation for the PEP 384 changes seems to be an
unrelated issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Daniel Urban]

Changes by Daniel Urban :


--
nosy: +durban

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11249] Memory mismanagement with Py_tp_doc

[Georg Brandl]

Georg Brandl  added the comment:

OK, committed in r88443 (with error handling made more consistent).

BTW, the return from PyType_GenericAlloc isn't NULL-checked, which looks like a 
potential crasher to me.  Not release-critical though.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11060] distutils2 sdist does not complain about version that is not PEP 386 compliant

[Éric Araujo]

Éric Araujo  added the comment:

You don’t need a new function (and certainly not in the __init__ submodule, the 
right place would be the version module), just do something like this:

try:
NormalizedVersion(text)
except IrrationalVersionError:
# version is invalid

Alternative: use suggest_normalized_version, which returns a string or None, 
then display according text to prompt the user to accept the suggested version 
or type another.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This is not a bug.  It is an implementation specific detail and is not 
guaranteed behavior.  The submitted "example bug" is horrible code that makes 
unwarranted assumptions about the implementation -- it is an anti-pattern to 
write generators that assume that their consumers will run them to exhaustion 
so that cleanup code will be executed -- a number of tools violate this 
assumption.  If you're relying on this technique for cleanup, you're doing it 
wrong.

I'll look at this again after the 3.2 release.  When it was discussed before, 
the outcome was to introduce itertools.zip_longest() and to not over-document 
non-guaranteed implementation specific details (lest people rely on them and 
write code even worse than the OP's example).

--
assignee: docs@python -> rhettinger
nosy: +rhettinger
priority: normal -> low
type: behavior -> feature request

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11250] 2to3 truncates files at formfeed character

[Christoph Gohlke]

New submission from Christoph Gohlke :

Running Tools/Scripts/2to3.py on Python 3.2rc3 or 2.7.1 for Windows on a file 
that contains a formfeed character (0x0C, ) results in a truncated file. 

E.g. a file (attached) with the content

print 1

print 2

is incorrectly refactored:

@@ -1,4 +1,1 @@
-print 1
-
-
-print 2
+print(1)


Python 2.6.6 and 3.1.3 correctly refactor the file:

-print 1
+print(1)
 
-print 2
+print(2)

--
files: formfeedbug.py
messages: 128885
nosy: cgohlke
priority: normal
severity: normal
status: open
title: 2to3 truncates files at formfeed character
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20800/formfeedbug.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11250] 2to3 truncates files at formfeed character

[Christoph Gohlke]

Changes by Christoph Gohlke :


--
components: +2to3 (2.x to 3.0 conversion tool)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11250] 2to3 truncates files at formfeed character

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11071] What's New review comments

[Nick Coghlan]

Nick Coghlan  added the comment:

On Sun, Feb 20, 2011 at 4:22 AM, Éric Araujo  wrote:
> It appears that Misc/NEWS in 3.2 lists the new functions under the 3.1 
> section, among other strange differences.

"new in 3.2" changes are relative to 3.1, while 2.7 is relative to
2.6. They're treated as separate streams of development. Since 3.1
came out well after 2.6, there are some things that were new in 2.7
that 3.1 already included.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11071] What's New review comments

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the message, but I already knew that.  What I meant is that in the 
3.2 version of Misc/NEWS, the addition of the functions is listed under the 3.1 
section instead of 3.2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11251] cmd.Cmd tab completion treats dashes as spaces

[Jon McKenzie]

New submission from Jon McKenzie :

I'm writing a cmd.Cmd module that operates on filenames. As such, I'm 
attempting to write tab completions that operate similar to bash. However, 
files that contain dashes (hyphens) appear to exhibit unexpected behavior.

It appears that somewhere along the line, dashes are converted into spaces for 
the purposes of tab completion.

So, for example..

(Cmd) edit blah-

Should print..

blah-1.0.0.txt  blah-2.0.0.txt

And..

(Cmd) edit blah-1

Should autocomplete to..

(Cmd) edit blah-1.0.0.txt

Instead, the following behavior occurs:

(Cmd) edit blah-

..becomes...

(Cmd) edit blah-blah

..and thus..

(Cmd) edit blah-blah-

..becomes, in turn..

(Cmd) edit blah-blah-blah

My completion function is absolutely standard, as far as I'm able to tell from 
looking at other examples (see attached)

--
files: completion.snip
messages: 12
nosy: Jon.McKenzie
priority: normal
severity: normal
status: open
title: cmd.Cmd tab completion treats dashes as spaces
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20801/completion.snip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Greg Kochanski]

Greg Kochanski  added the comment:

The code (bug312.py) was not submitted as a "pattern", but rather as an example 
of a trap into which it is easy to fall, at least for the 99% of programmers 
who are users of the language rather than its implementers.  


The basic difference is that while one can write a function that is guaranteed 
to execute to the end of its body[*]; one cannot do that with a generator 
function.   This point ought to be made in the documentation.
[* Neglecting SIGKILL and perhaps a few abnormal cases.]

The current documentation emphasizes the analogy to functions (which can be 
misleading) and (in section 6.8) explictly says that the normal behaviour of a 
generator function is to run all the way to completion.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11252] Handling statement OR assignment continuation '\' on Win32 platform

[Suresh Kalkunte]

New submission from Suresh Kalkunte :

Referring to URL for files used to build the Apache Portable Runtime Utilities 
library using Python 2.7.1(AMD64) or 2.6.5(Cygwin) on a Win32 system (Windows 
7), when apr/build/gen-build.py 
(http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/build/gen-build.py?revision=886996&view=markup)
 parses '\' on line 96 and 97 in apr-util/build.conf 
(http://svn.apache.org/viewvc/apr/apr-util/branches/1.4.x/build.conf?revision=886996&view=markup),
 it recognizes them as separate tokens causing the script to fail on line 168 
"assert file[-2:] == '.c'". If the line continuation notation ('\') is removed 
from build.conf, gen-build.py performs without errors. 

On a Redhat Linux, I have verified Python 2.5.5 (and trust 2.7.1 to provide the 
same behavior on Linux) handles '\' without errors leading me to believe that 
if this is a bug, it is only on Win32 platform (and instances where '\' is used 
for directory path separation).

I am new to Python, from searching the python bug database, I have not been 
able to find the above condition covered. If this bug has already been 
identified, please disregard.

--
components: Interpreter Core, Windows
messages: 128890
nosy: Suresh.Kalkunte
priority: normal
severity: normal
status: open
title: Handling statement OR assignment continuation '\' on Win32 platform
type: behavior
versions: Python 2.6, Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8300] Allow struct.pack to handle objects with an __index__ method.

[Matt Joiner]

Matt Joiner  added the comment:

Thanks Mark for clearing that up. I found this link to be useful in explaining 
the purpose of __index__: 
http://docs.python.org/release/2.5.1/whatsnew/pep-357.html

I think the choice of allowing only __index__ was the right choice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11248] Tails of generator get lost under zip()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I've looked at the docs again and think they're fine.  And in the 3.x docs, the 
iterator version of zip() specifies its implementation with a pure python 
equivalent that makes it clear that the iterator is not run to exhaustion.  

Note that zip() has existed since 2.0 and iterators/generators since 2.2.  The 
docs for them have worked just fine, so I wouldn't worry too much about their 
being a "trap for 99% of programmers who aren't implementers."

GPK, I can see that you're wound-up about this, but you seem to have a profound 
misunderstanding about iterators/generators and have incorrectly assumed an 
implied contract for consumer functions to completely consume their inputs.  
Sorry, but I'm going to close this one.  For further discussion, I recommend 
the python tutor mailing list.

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11253] autodocument first appearance of ctypes.wintypes constants

[anatoly techtonik]

New submission from anatoly techtonik :

I've just noticed that my application is incompatible with Python 2.5, because 
ctypes.wintypes is missing SHORT constants. However, I can't find the 
information when these symbols were introduced first. To prevent such confusion 
in future it would be nice to extract symbol information for each Python 
release and automatically include the version of the first appearance in 
documentation.

--
assignee: docs@python
components: Documentation
messages: 128893
nosy: docs@python, techtonik
priority: normal
severity: normal
status: open
title: autodocument first appearance of ctypes.wintypes constants
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2405] Drop w9xpopen and all dependencies

[anatoly techtonik]

anatoly techtonik  added the comment:

I still see w9xpopen.exe in my Python 3.2 installation, which is kind of 
strange to me.

--
nosy: +techtonik
versions: +Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11243] email/message.py str conversion

[R. David Murray]

R. David Murray  added the comment:

Well, it's not a crash, a crash is when the interpreter segfaults.

I'm not clear on why you are having problems, actually, since if you treat the 
messages as binary (which they are), then you shouldn't be getting Headers 
introduced into the mix.  But like I said I don't have time to look at this 
right now.

The problem with Header not being handled properly does need to be addressed, 
though.

--
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11243] email/message.py str conversion

[R. David Murray]

R. David Murray  added the comment:

Ah, I think I see what is going on.  If I'm right, then you are right, this is 
a serious problem for actually processing spam emails using email 5.1.  
Unfortunately it's too late to do anything for 3.2.0.  But email 5.1 is still 
worlds better at handling well formed binary emails.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com