From report at bugs.python.org  Sun Jan  1 09:22:32 2012
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sun, 01 Jan 2012 08:22:32 +0000
Subject: [New-bugs-announce] [issue13691] pydoc help (or help('help'))
	claims to run a help	utility; does nothing
Message-ID: <1325406152.03.0.315132806833.issue13691@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

What follows is a copy-paste of a shell session. Notice that at the end, rather than being inside the online help utility, I'm still in the interactive interpreter. I was able to duplicate this on python3.2, python2.7, and python2.6 (verifying it on other versions would have required installing them). Reading the source in trunk, there is nothing that looks like it actually should run this interactive help session. It's just missing.

I guess nobody used this, eh? I've attached a patch that should fix it. I'm not sure how you want to handle adding a test for this, so please advise me on that.

-----

>>> help('help')

Welcome to Python 3.2!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

>>>

----------
components: Library (Lib)
files: r74214.diff
keywords: patch
messages: 150427
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: pydoc help (or help('help')) claims to run a help utility; does nothing
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file24121/r74214.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13691>
_______________________________________

From report at bugs.python.org  Sun Jan  1 13:03:31 2012
From: report at bugs.python.org (Henrik Holmboe)
Date: Sun, 01 Jan 2012 12:03:31 +0000
Subject: [New-bugs-announce] [issue13692] 2to3 mangles from . import frobnitz
Message-ID: <1325419411.86.0.637139477325.issue13692@psf.upfronthosting.co.za>


New submission from Henrik Holmboe <henrik at holmboe.se>:

It seems that 2to3 mangles::

 from . import frobnitz

into::

 from ... import frobnitz

This was noticed in the port of ipython to py3k. See https://github.com/ipython/ipython/issues/1197

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 150430
nosy: holmbie
priority: normal
severity: normal
status: open
title: 2to3 mangles from . import frobnitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13692>
_______________________________________

From report at bugs.python.org  Sun Jan  1 18:25:00 2012
From: report at bugs.python.org (kxroberto)
Date: Sun, 01 Jan 2012 17:25:00 +0000
Subject: [New-bugs-announce] [issue13693] email.Header.Header
	incorrect/non-smart on international	charset address fields
Message-ID: <1325438700.75.0.319524788564.issue13693@psf.upfronthosting.co.za>


New submission from kxroberto <kxroberto at users.sourceforge.net>:

the email.* package seems to over-encode international charset address fields - resulting even in display errors in the receivers reader - , 
when message header composition is done as recommended in http://docs.python.org/library/email.header.html 

Python 2.7.2
>>> e=email.Parser.Parser().parsestr(getcliptext())
>>> e['From']
'=?utf-8?q?Martin_v=2E_L=C3=B6wis?= <report at bugs.python.org>'
# note the par
>>> email.Header.decode_header(_)
[('Martin v. L\xc3\xb6wis', 'utf-8'), ('<report at bugs.python.org>', None)]
# unfortunately there is no comfortable function for this:
>>> u='Martin v. L\xc3\xb6wis'.decode('utf8') + ' <report at bugs.python.org>'
>>> u
u'Martin v. L\xf6wis <report at bugs.python.org>'
>>> msg=email.Message.Message()
>>> msg['From']=u
>>> msg.as_string()
'From: =?utf-8?b?TWFydGluIHYuIEzDtndpcyA8cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZz4=?=\n\n'
>>> msg['From']=str(u)
>>> msg.as_string()
'From: =?utf-8?b?TWFydGluIHYuIEzDtndpcyA8cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZz4=?=\nFrom: Martin v. L\xf6wis <report at bugs.python.org>\n\n'
>>> msg['From']=email.Header.Header(u)
>>> msg.as_string()
'From: =?utf-8?b?TWFydGluIHYuIEzDtndpcyA8cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZz4=?=\nFrom: Martin v. L\xf6wis <report at bugs.python.org>\nFrom: =?utf-8?b?TWFydGluIHYuIEzDtndpcyA8cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZz4=?=\n\n'
>>> 

(BTW: strange is that multiple msg['From']=... _assignments_ end up as multiple additions !???   also msg renders 8bit header lines without warning/error or auto-encoding, while it does auto on unicode!??)

Whats finally arriving at the receiver is typically like:

From: "=?utf-8?b?TWFydGluIHYuIEzDtndpcyA8cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZz4=?=" <report at bugs.python.org>

because the servers seem to want the address open, they extract the address and _add_ it (duplicating) as ASCII. => error

I have not found any emails in my archives where address header fields are so over-encoded like python does. Even in non-address fields mostly only those words/groups are encoded which need it.

I assume the sophisticated/high-level looking email.* package doesn't expect that the user fiddles things together low-level? with parseaddr, re.search, make_header Header.encode , '.join ... Or is it indeed (undocumented) so? IMHO it should be auto-smart enough.

Note: there is a old deprecated function mimify.mime_encode_header which seemed to try to cautiously auto-encode correct/sparsely (but actually fails too on all examples tried).

----------
components: Library (Lib)
messages: 150434
nosy: kxroberto
priority: normal
severity: normal
status: open
title: email.Header.Header incorrect/non-smart on international charset address fields
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13693>
_______________________________________

From report at bugs.python.org  Mon Jan  2 03:15:16 2012
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 02 Jan 2012 02:15:16 +0000
Subject: [New-bugs-announce] [issue13694] asynchronous connect in
	asyncore.dispatcher does not set	addr
Message-ID: <1325470516.27.0.519900720027.issue13694@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

Patch attached

----------
components: Library (Lib)
files: dispatcher_connect_addr.patch
keywords: patch
messages: 150449
nosy: anacrolix
priority: normal
severity: normal
status: open
title: asynchronous connect in asyncore.dispatcher does not set addr
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24124/dispatcher_connect_addr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13694>
_______________________________________

From report at bugs.python.org  Mon Jan  2 06:48:10 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 02 Jan 2012 05:48:10 +0000
Subject: [New-bugs-announce] [issue13695] "type specific" to "type-specific"
Message-ID: <1325483290.25.0.872020961031.issue13695@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Please visit the following link and fix the below text:

http://docs.python.org/library/unittest.html#unittest.TestCase.assertEqual

Changed in version 2.7: Added the automatic calling of >>>type-specific<<< equality function.

Just add the hyphen. Thanks.

----------
assignee: docs at python
components: Documentation
messages: 150451
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: "type specific" to "type-specific"
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13695>
_______________________________________

From report at bugs.python.org  Mon Jan  2 19:40:30 2012
From: report at bugs.python.org (CRicky)
Date: Mon, 02 Jan 2012 18:40:30 +0000
Subject: [New-bugs-announce] [issue13696]
	[urllib.request.HTTPRedirectHandler.http_error_302]	Relative
	Redirect issue
Message-ID: <1325529630.8.0.473539706261.issue13696@psf.upfronthosting.co.za>


New submission from CRicky <cricky.kmp at gmx.fr>:

I had an HTTP redirection that worked perfectly on version 3.1.

On version 3.2, I get a HTTP error 302. In this redirection, I actually have 2 redirections. The last one does not work because it is a relative redirection, so urlparts.scheme is empty.

Some lines have been added in version 3.2 for security reason, but it also blocks relative links in 302 return.

To correct, I have added empty scheme in check:
        if not urlparts.scheme in ('http', 'https', 'ftp', ''):

With that, it works correctly.
I don't make you any for 3 new chars. ;)

Best regards,
CRicky

----------
components: Library (Lib)
messages: 150473
nosy: CRicky
priority: normal
severity: normal
status: open
title: [urllib.request.HTTPRedirectHandler.http_error_302] Relative Redirect issue
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13696>
_______________________________________

From report at bugs.python.org  Mon Jan  2 22:13:13 2012
From: report at bugs.python.org (Robert Collins)
Date: Mon, 02 Jan 2012 21:13:13 +0000
Subject: [New-bugs-announce] [issue13697] python RLock implementation unsafe
	with signals
Message-ID: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za>


New submission from Robert Collins <robertc at robertcollins.net>:

This affects the python implementation of RLock only.

If a signal occurs during RLock.acquire() or release() and then operates on the same lock to acquire() or release() it, process hangs or assertions can be triggered.

The attached test script demonstrates the issue on Python 2.6 and 3.2, and code inspection suggests this is still valid for 2.7 and 3.4.

To use it, run the script and then 'kill -SIGUSR2' the process id it prints out. Keep sending SIGUSR2 until you get bored or:
 - a traceback occurs
 - the process stops printing out '.'s

We found this debugging application server hangs during log rotation (https://bugs.launchpad.net/launchpad/+bug/861742) where if the thread that the signal is received in was about to log a message the deadlock case would crop up from time to time. Of course, this wasn't ever safe code, and we're changing it (to have the signal handler merely set a integer flag that the logging handler can consult without locking).

However, I wanted to raise this upstream, and I note per issue #3618 that the 3.x IO module apparently includes a minimal version of the Python RLock implementation (or just uses RLock itself). Either way this bug probably exists for applications simply doing IO, either when there is no C RLock implementation available, or all the time (depending on exactly what the IO module is doing nowadays).

----------
components: Library (Lib)
files: hang.py
messages: 150477
nosy: rbcollins
priority: normal
severity: normal
status: open
title: python RLock implementation unsafe with signals
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file24126/hang.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13697>
_______________________________________

From report at bugs.python.org  Mon Jan  2 22:46:27 2012
From: report at bugs.python.org (endolith)
Date: Mon, 02 Jan 2012 21:46:27 +0000
Subject: [New-bugs-announce] [issue13698] Should not use mboxo format
Message-ID: <1325540787.88.0.149207146949.issue13698@psf.upfronthosting.co.za>


New submission from endolith <endolith at gmail.com>:

The documentation states:

"Several variations of the mbox format exist to address perceived shortcomings in the original. In the interest of compatibility, mbox implements the original format, which is sometimes referred to as mboxo."

http://docs.python.org/dev/library/mailbox.html#mailbox.mbox

But this format is fundamentally broken, corrupting lines that start with ">From ", and I can't find any justification for using it in Python.  In fact, all four links included in that section argue against this format.

If only one mbox format is used, it should be mboxrd.  Otherwise, include support for all the variants, with mboxrd as the default.

----------
components: Library (Lib)
messages: 150478
nosy: endolith
priority: normal
severity: normal
status: open
title: Should not use mboxo format
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13698>
_______________________________________

From report at bugs.python.org  Tue Jan  3 00:19:01 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 02 Jan 2012 23:19:01 +0000
Subject: [New-bugs-announce] [issue13699] test_gdb has recently started
	failing
Message-ID: <1325546341.52.0.130827872784.issue13699@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

test_gdb has started failing recently on my Ubuntu Natty system:

vinay at eta-natty:~/tools/cpython$ ./python Lib/test/regrtest.py -v test_gdb
== CPython 3.3.0a0 (default:3ed5a6030c9b, Jan 2 2012, 23:04:11) [GCC 4.5.2]
==   Linux-2.6.38-13-generic-i686-with-debian-squeeze-sid little-endian
==   /home/vinay/tools/cpython/build/test_python_14449
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_gdb

[successful tests snipped]

======================================================================
FAIL: test_print_after_up (test.test_gdb.PyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vinay/tools/cpython/Lib/test/test_gdb.py", line 670, in test_print_after_up
    r".*\nlocal 'c' = 3\nlocal 'b' = 2\nlocal 'a' = 1\n.*")
  File "/home/vinay/tools/cpython/Lib/test/test_gdb.py", line 171, in assertMultilineMatches
    self.fail(msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x80ad5c6: file Python/bltinmodule.c, line 951.\n[Thread debugging using libthread_db enabled]\n\nBreakpoint 1, builtin_id (self=<module at remote 0xb7dd012c>, v=42) at Python/bltinmodule.c:951\n951\t    return PyLong_FromVoidPtr(v);\n#6 (unable to read python frame information)\nUnable to read information on python frame\nUnable to read information on python frame\nUnable to read information on python frame\n' did not match ".*\\nlocal 'c' = 3\\nlocal 'b' = 2\\nlocal 'a' = 1\\n.*"

======================================================================
FAIL: test_locals_after_up (test.test_gdb.PyLocalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vinay/tools/cpython/Lib/test/test_gdb.py", line 702, in test_locals_after_up
    r".*\na = 1\nb = 2\nc = 3\n.*")
  File "/home/vinay/tools/cpython/Lib/test/test_gdb.py", line 171, in assertMultilineMatches
    self.fail(msg='%r did not match %r' % (actual, pattern))
AssertionError: 'Breakpoint 1 at 0x80ad5c6: file Python/bltinmodule.c, line 951.\n[Thread debugging using libthread_db enabled]\n\nBreakpoint 1, builtin_id (self=<module at remote 0xb7dd012c>, v=42) at Python/bltinmodule.c:951\n951\t    return PyLong_FromVoidPtr(v);\n#6 (unable to read python frame information)\nUnable to read information on python frame\n' did not match '.*\\na = 1\\nb = 2\\nc = 3\\n.*'

----------------------------------------------------------------------
Ran 42 tests in 13.809s

FAILED (failures=2, skipped=11)
test test_gdb failed
1 test failed:
    test_gdb

vinay at eta-natty:~/tools/cpython$ ./python
Python 3.3.0a0 (default:3ed5a6030c9b, Jan  2 2012, 23:04:11) 
[GCC 4.5.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_vars()['PY_CFLAGS']
'-Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes'
>>> 

vinay at eta-natty:~/tools/cpython$ gdb --version
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

vinay at eta-natty:~/tools/cpython$ gcc --version
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

vinay at eta-natty:~/tools/cpython$ uname -a
Linux eta-natty 2.6.38-13-generic #53-Ubuntu SMP Mon Nov 28 19:23:39 UTC 2011 i686 i686 i386 GNU/Linux

Marking haypo as nosy since it might be related to recent changes for #13628.

In earlier tests (conducted on 12 Dec, before the #13628 fix was checked in) test_gdb did not fail on the same system.

----------
components: Library (Lib)
messages: 150484
nosy: haypo, vinay.sajip
priority: normal
severity: normal
status: open
title: test_gdb has recently started failing
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13699>
_______________________________________

From report at bugs.python.org  Tue Jan  3 02:11:29 2012
From: report at bugs.python.org (Erno Tukia)
Date: Tue, 03 Jan 2012 01:11:29 +0000
Subject: [New-bugs-announce] [issue13700] imaplib.IMAP4.authenticate
	authobject fails with PLAIN	mechanism
Message-ID: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za>


New submission from Erno Tukia <erno.tukia at iki.fi>:

>>> import imaplib
>>> imap = imaplib.IMAP4_SSL("imap.example.com")

>>> authcb = lambda resp: "{0}\x00{0}\x00{1}".format("username","password")
>>> imap.authenticate("PLAIN", authcb)
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    imap.authenticate("PLAIN", authcb)
  File "/usr/lib/python3.1/imaplib.py", line 361, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mech)
  File "/usr/lib/python3.1/imaplib.py", line 1075, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python3.1/imaplib.py", line 889, in _command
    literal = literator(self.continuation_response)
  File "/usr/lib/python3.1/imaplib.py", line 1238, in process
    return self.encode(ret)
  File "/usr/lib/python3.1/imaplib.py", line 1257, in encode
    e = binascii.b2a_base64(t)
TypeError: must be bytes or buffer, not str

... and ...

>>> authcb = lambda resp: "{0}\x00{0}\x00{1}".format("username","password").encode()
>>> imap.authenticate("PLAIN", authcb)
Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    imap.authenticate("PLAIN", authcb)
  File "/usr/lib/python3.1/imaplib.py", line 361, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mech)
  File "/usr/lib/python3.1/imaplib.py", line 1075, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python3.1/imaplib.py", line 889, in _command
    literal = literator(self.continuation_response)
  File "/usr/lib/python3.1/imaplib.py", line 1238, in process
    return self.encode(ret)
  File "/usr/lib/python3.1/imaplib.py", line 1259, in encode
    oup = oup + e[:-1]
TypeError: Can't convert 'bytes' object to str implicitly

----------
components: Library (Lib)
messages: 150489
nosy: etukia
priority: normal
severity: normal
status: open
title: imaplib.IMAP4.authenticate authobject fails with PLAIN mechanism
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13700>
_______________________________________

From report at bugs.python.org  Tue Jan  3 04:01:46 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 03 Jan 2012 03:01:46 +0000
Subject: [New-bugs-announce] [issue13701] Remove Decimal Python 2.3
	Compatibility
Message-ID: <1325559706.07.0.31676641509.issue13701@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

Decimal has compatibility for Python 2.3 (such as not using decorators) as mentioned in comments in the source code for it.
This compatibility should be removed in Python 3.3 and if possible, in Python 3.2.

----------
components: Library (Lib)
messages: 150495
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Remove Decimal Python 2.3 Compatibility
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13701>
_______________________________________

From report at bugs.python.org  Tue Jan  3 17:42:43 2012
From: report at bugs.python.org (Patrick von Reth)
Date: Tue, 03 Jan 2012 16:42:43 +0000
Subject: [New-bugs-announce] [issue13702] relative symlinks in
	tarfile.extract broken
Message-ID: <1325608963.69.0.695216553795.issue13702@psf.upfronthosting.co.za>


New submission from Patrick von Reth <patrick.vonreth at gmail.com>:

when extracting http://www.openssl.org/source/openssl-1.0.0d.tar.gz with python3.2 on windows 7 extraction fails with 

  File "C:\python32\lib\tarfile.py", line 2175, in extract
    set_attrs=set_attrs)
  File "C:\python32\lib\tarfile.py", line 2259, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "C:\python32\lib\tarfile.py", line 2359, in makelink
    targetpath)
  File "C:\python32\lib\tarfile.py", line 2251, in _extract_member
    self.makefile(tarinfo, targetpath)
  File "C:\python32\lib\tarfile.py", line 2292, in makefile
    target = bltn_open(targetpath, "wb")
IOError: [Errno 22] Invalid argument: 'R:\\tmp\\os\\openssl-1.0.0d\\apps\\md4.c'

the reason is that the symlink is broken

R:\>dir R:\tmp\os\openssl-1.0.0d\apps\md4.c
 Volume in drive R has no label.
 Volume Serial Number is E8F0-7223
 Directory of R:\tmp\os\openssl-1.0.0d\apps
02.01.2012  20:13    <SYMLINK>      md4.c [../crypto/md4/md4.c]

it must be backslashes instead of front slashes and that's why python cant access the file the symlink is pointing to.

----------
components: Windows
messages: 150512
nosy: Patrick.von.Reth
priority: normal
severity: normal
status: open
title: relative symlinks in tarfile.extract broken
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13702>
_______________________________________

From report at bugs.python.org  Tue Jan  3 20:36:50 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Jan 2012 19:36:50 +0000
Subject: [New-bugs-announce] [issue13703] Hash collision security issue
Message-ID: <1325619410.45.0.862265945379.issue13703@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

This is already publicly known and in deep discussion on python-dev.  The proper fix is still TBD.  Essentially, hash collisions can be exploited to DoS a web framework that automatically parses input forms into dictionaries.

Start here:

http://mail.python.org/pipermail/python-dev/2011-December/115116.html

----------
components: Interpreter Core
messages: 150522
nosy: barry, benjamin.peterson, georg.brandl
priority: release blocker
severity: normal
status: open
title: Hash collision security issue
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________

From report at bugs.python.org  Tue Jan  3 21:24:33 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 03 Jan 2012 20:24:33 +0000
Subject: [New-bugs-announce] [issue13704] Random number generator in Python
	core
Message-ID: <1325622273.87.0.90076525746.issue13704@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

All proposed fixes for a randomized hashing function raise and fall with
a good random number generator to feed the random seed. The seed must be
created very early in the startup phase of the interpreter, preferable
before the basic types are initialized. CPython already have multiple
sources for random data (win32_urandom in Modules/posixmodule.c, urandom
in Lib/os.py, Mersenne twister in Modules/_randommodule.c). However we
can't use them because they are wrapped inside Python modules which
require infrastructure like initialized base types.

Discussion at http://mail.python.org/pipermail/python-dev/2012-January/115263.html

My proposed changes are implemented in my feature fork but not yet well tested. Windows build files needs modification, too.

----------
assignee: christian.heimes
hgrepos: 98
messages: 150527
nosy: barry, benjamin.peterson, christian.heimes, georg.brandl, gvanrossum, pitrou
priority: release blocker
severity: normal
stage: patch review
status: open
title: Random number generator in Python core
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13704>
_______________________________________

From report at bugs.python.org  Tue Jan  3 23:13:08 2012
From: report at bugs.python.org (Sinisa Segvic)
Date: Tue, 03 Jan 2012 22:13:08 +0000
Subject: [New-bugs-announce] [issue13705] Raising exceptions from finally
	works better than	advertised in the documentation
Message-ID: <1325628788.79.0.655122317093.issue13705@psf.upfronthosting.co.za>


New submission from Sinisa Segvic <sinisa.segvic at fer.hr>:

Hi,

The documentation says:
"""
If the finally clause raises another exception (...) the saved exception is lost. 
"""

This does not appear to be true. 
In the example below the backtrace shows both exceptions.

>>> import math
>>> try:
...   1/0
... finally:
...   math.sqrt(-1)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
ValueError: math domain error

Cheers,

Sini?a

----------
assignee: docs at python
components: Documentation
messages: 150544
nosy: docs at python, ssegvic
priority: normal
severity: normal
status: open
title: Raising exceptions from finally works better than advertised in the documentation
type: enhancement
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13705>
_______________________________________

From report at bugs.python.org  Tue Jan  3 23:36:25 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 03 Jan 2012 22:36:25 +0000
Subject: [New-bugs-announce] [issue13706] Unicode fill characters no longer
	work in numeric	formatting
Message-ID: <1325630185.42.0.0487894537415.issue13706@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

It used to be possible to specify Unicode fill characters in numeric
formatting:

Python 3.3.0a0 (default:1dd6908df8f5, Jul 16 2011, 11:16:00) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> format(1234, "\u2007<7")
'1234\u2007\u2007\u2007'
[64682 refs]
>>> 


Now it doesn't work:

Python 3.3.0a0 (default:65ac469d30e6, Jan  3 2012, 23:23:07) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> format(1234, "\u2007<7")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: fill character too large

----------
components: Interpreter Core
messages: 150548
nosy: eric.smith, haypo, loewis, mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Unicode fill characters no longer work in numeric formatting
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13706>
_______________________________________

From report at bugs.python.org  Wed Jan  4 01:40:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 Jan 2012 00:40:53 +0000
Subject: [New-bugs-announce] [issue13707] Clarify hash() lifetime
Message-ID: <1325637653.51.0.0128051850964.issue13707@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Current 3.2.2 docs:

id(object) Return the ?identity? of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. [model]

hash(object) Return the hash value of the object (if it has one). Hash values are integers. They are used to quickly compare dictionary keys 

Suggestion: change "Hash values are integers. They ..." to
"This should be an integer which is constant for this object during its lifetime. Hash values ..."

Rationale: For builtin class instances, hash values are guaranteed to be constant that long, and only that long, as the default hash(ob) for object() instances is currently, for my win7, 64 bit, 3.2.2 CPython, id(ob) // 16 (the minimum object size). User class instance hashes (with custom __hash__) *should* have the same lifetime. But since Python cannot enforce that, I did not say 'guaranteed'.

User code should *not* depend on a longer lifetime, just as for id() output. It seems worth implying that, as for id(), because (based on recent pydev discussion) people seems to be prone to over-generalize the current longer-term stability of number and string hashes, which itself may disappear in future releases. (see #13703)

----------
assignee: docs at python
components: Documentation
messages: 150561
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify hash() lifetime
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13707>
_______________________________________

From report at bugs.python.org  Wed Jan  4 03:33:29 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 04 Jan 2012 02:33:29 +0000
Subject: [New-bugs-announce] [issue13708] Document ctypes.wintypes
Message-ID: <1325644409.99.0.366875630851.issue13708@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Document ctypes.wintypes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13708>
_______________________________________

From report at bugs.python.org  Wed Jan  4 03:46:43 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 04 Jan 2012 02:46:43 +0000
Subject: [New-bugs-announce] [issue13709] Capitalization mistakes in the
	documentation for ctypes
Message-ID: <1325645203.91.0.562347938508.issue13709@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

In section 15.17.1.17 in the ctypes documentation, the documentation says
"It is funny to see that on linux the sort function seems to work much more efficiently, it is doing less comparisons"

"It is quite interesting to see that the Windows qsort() function needs
more comparisons than the linux version!"

"linux" should be capitalized in both these sentences.

----------
assignee: docs at python
components: Documentation
messages: 150574
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Capitalization mistakes in the documentation for ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13709>
_______________________________________

From report at bugs.python.org  Wed Jan  4 05:58:50 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 04 Jan 2012 04:58:50 +0000
Subject: [New-bugs-announce] [issue13710] hash() on string containing only
	null characters returns	the length of the string
Message-ID: <1325653130.87.0.569297022599.issue13710@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

If you run hash on strings containing only null characters it returns the length of the string
>>> hash("\0")
1
>>> hash("\0\0")
2
>>> hash("\0"*1000)
1000
This behaviour is not like proper hash functions.
The hashes of these strings should exhibit the avalanche effect like in a proper hash function.

----------
components: Interpreter Core
messages: 150587
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: hash() on string containing only null characters returns the length of the string
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13710>
_______________________________________

From report at bugs.python.org  Wed Jan  4 14:26:47 2012
From: report at bugs.python.org (=?utf-8?q?Manuel_B=C3=A4renz?=)
Date: Wed, 04 Jan 2012 13:26:47 +0000
Subject: [New-bugs-announce] [issue13711] html.parser.HTMLParser doesn't
	parse tags in comments in	scripts correctly
Message-ID: <1325683607.39.0.829837031313.issue13711@psf.upfronthosting.co.za>


New submission from Manuel B?renz <manuel at enigmage.de>:

I've attached a script which demonstrates the bug.

When feeding a <script> that contains a comment tag with the actual script and the script containing tags itself (e.g. a 'document.write(<td></td>)'), the parser doesn't call handle_comment and handle_starttag.

----------
components: Library (Lib)
files: htmlparserbug.py
messages: 150603
nosy: turion
priority: normal
severity: normal
status: open
title: html.parser.HTMLParser doesn't parse tags in comments in scripts correctly
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file24137/htmlparserbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13711>
_______________________________________

From report at bugs.python.org  Wed Jan  4 15:58:04 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Jan 2012 14:58:04 +0000
Subject: [New-bugs-announce] [issue13712] test_packaging depends on hash
	order
Message-ID: <1325689084.75.0.043764224634.issue13712@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

As requested in http://bugs.python.org/issue13703#msg150609

./python Lib/test/regrtest.py test_packaging
[1/1] test_packaging
Warning -- threading._dangling was modified by test_packaging
Warning -- sysconfig._SCHEMES was modified by test_packaging
test test_packaging failed -- Traceback (most recent call last):
  File "/home/heimes/dev/python/randomhash/Lib/packaging/tests/test_create.py", line 168, in test_convert_setup_py_to_cfg
    """))
AssertionError: '[metadata]\nname = pyxfoil\nversion = 0.2\nsummary = Python bindings for the Xf [truncated]... != '[metadata]\nname = pyxfoil\nversion = 0.2\nsummary = Python bindings for the Xf [truncated]...
  [metadata]
  name = pyxfoil
  version = 0.2
  summary = Python bindings for the Xfoil engine
  download_url = UNKNOWN
  home_page = http://www.python-science.org/project/pyxfoil
  maintainer = Andr? Espaze
  maintainer_email = andre.espaze at logilab.fr
  description = My super Death-scription
         |barbar is now on the public domain,
         |ho, baby !
  
  [files]
  packages = pyxfoil
      babar
      me
  modules = my_lib
      mymodule
  scripts = my_script
      bin/run
- extra_files = setup.py
+ extra_files = Martinique/Lamentin/dady
+     Martinique/Lamentin/mumy
+     Martinique/Lamentin/sys
+     Martinique/Lamentin/bro
+     setup.py
      README
-     pyxfoil/fengine.so
      Pom
      Flora
      Alexander
+     pyxfoil/fengine.so
-     Martinique/Lamentin/dady
-     Martinique/Lamentin/mumy
-     Martinique/Lamentin/sys
-     Martinique/Lamentin/bro
  
  resources =
      README.rst = {doc}
      pyxfoil.1 = {man}
  


1 test failed:
    test_packaging

----------
assignee: eric.araujo
components: Distutils2
messages: 150610
nosy: alexis, christian.heimes, eric.araujo
priority: normal
severity: normal
status: open
title: test_packaging depends on hash order
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13712>
_______________________________________

From report at bugs.python.org  Wed Jan  4 17:38:40 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 04 Jan 2012 16:38:40 +0000
Subject: [New-bugs-announce] [issue13713] Regression for http.client read()
Message-ID: <1325695120.58.0.937190089641.issue13713@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

806cfe39f729 introduced a regression for http.client read(len).

To see this:
$ ./python test.py
$ wget http://archives.fedoraproject.org/pub/archive/fedora/linux/core/1/SRPMS/
$ diff index.html index2.html

This is a difference in the files (which there shouldn't be).

The change which introduced the problem was:
changeset:   73875:806cfe39f729
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Tue Dec 06 22:33:57 2011 +0100
summary:     Issue #13464: Add a readinto() method to http.client.HTTPResponse.

----------
components: Library (Lib)
files: test.py
messages: 150615
nosy: orsenthil, pitrou, rosslagerwall
priority: normal
severity: normal
stage: needs patch
status: open
title: Regression for http.client read()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24138/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13713>
_______________________________________

From report at bugs.python.org  Thu Jan  5 05:36:10 2012
From: report at bugs.python.org (Sworddragon)
Date: Thu, 05 Jan 2012 04:36:10 +0000
Subject: [New-bugs-announce] [issue13714] Methods of ftplib never ends if
	the ip address changes
Message-ID: <1325738170.02.0.180646245412.issue13714@psf.upfronthosting.co.za>


New submission from Sworddragon <sworddragon2 at aol.com>:

If a client gets a reconnect and a new ip from the provider the methods of ftplib can't handle this and are hanging in an infinite loop. For example if a file is transfered with storbinary() and the client gets a new ip address the script will never end. I'm using the Linux Kernel 3.2 on a 64 bit system and Python 2.7 is affected too.

----------
components: Library (Lib)
messages: 150654
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Methods of ftplib never ends if the ip address changes
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13714>
_______________________________________

From report at bugs.python.org  Thu Jan  5 17:47:21 2012
From: report at bugs.python.org (Eli Collins)
Date: Thu, 05 Jan 2012 16:47:21 +0000
Subject: [New-bugs-announce] [issue13715] typo in unicodedata documentation
Message-ID: <1325782041.56.0.783502480563.issue13715@psf.upfronthosting.co.za>


New submission from Eli Collins <elic at assurancetechnologies.com>:

I noticed a minor typo in the unicodedata.normalize() documentation...

The line reading 'U+0327 (COMBINING CEDILLA) U+0043 (LATIN CAPITAL LETTER C)' is not proper unicode, it should be in the reverse order: 'U+0043 (LATIN CAPITAL LETTER C) U+0327 (COMBINING CEDILLA)'.

attached is a small patch to fix this.

----------
assignee: docs at python
components: Documentation
files: docfix.patch
keywords: patch
messages: 150670
nosy: docs at python, eli.collins
priority: normal
severity: normal
status: open
title: typo in unicodedata documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24145/docfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13715>
_______________________________________

From report at bugs.python.org  Thu Jan  5 20:02:16 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 05 Jan 2012 19:02:16 +0000
Subject: [New-bugs-announce] [issue13716] distutils doc contains lots of XXX
Message-ID: <1325790136.17.0.881224521536.issue13716@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

http://docs.python.org/distutils/apiref.html?highlight=XXX#module-distutils.ccompiler

We find lots of "XXX" and "XXX see also." which give no information.

----------
assignee: docs at python
components: Documentation
messages: 150683
nosy: docs at python, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: distutils doc contains lots of XXX
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13716>
_______________________________________

From report at bugs.python.org  Thu Jan  5 21:12:55 2012
From: report at bugs.python.org (Atle Pedersen)
Date: Thu, 05 Jan 2012 20:12:55 +0000
Subject: [New-bugs-announce] [issue13717] print fails on unicode '\udce5'
	surrogates not allowed
Message-ID: <1325794375.32.0.250961574863.issue13717@psf.upfronthosting.co.za>


New submission from Atle Pedersen <atle.pedersen at gmail.com>:

I've made a short program to traverse file tree and print file names.

for root, dirs, files in os.walk(path):
        for f in files:
                hex = ' '.join(["%02X"%ord(x) for x in f])
                print('file is',hex,f)

This fails with the following file:

file is 67 72 DCE5 6B 61 6C 6C 65 6E 2E 6A 70 67 2E 68 74 6D 6C Traceback (most recent call last):
  File "/home/atle/bin/findpictures.py", line 16, in <module>
    print('file is',hexa,f)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udce5' in position 2: surrogates not allowed

I don't really understand the issue, but this works with Python 2, and fails using 3.1.4 (gentoo: dev-lang/python-3.1.4-r3)

Same code using Python 2.7.2 gives:
('file is', '67 72 E5 6B 61 6C 6C 65 6E 2E 6A 70 67 2E 68 74 6D 6C', 'gr\xe5kallen.jpg.html')

----------
components: Unicode
messages: 150684
nosy: Atle.Pedersen, ezio.melotti
priority: normal
severity: normal
status: open
title: print fails on unicode '\udce5' surrogates not allowed
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13717>
_______________________________________

From report at bugs.python.org  Fri Jan  6 12:24:01 2012
From: report at bugs.python.org (Michael Kesper)
Date: Fri, 06 Jan 2012 11:24:01 +0000
Subject: [New-bugs-announce] [issue13718] Format Specification Mini-Language
	does not accept comma	for percent value
Message-ID: <1325849041.09.0.966587471813.issue13718@psf.upfronthosting.co.za>


New submission from Michael Kesper <mkesper at schokokeks.org>:

http://docs.python.org/library/string.html#format-specification-mini-language mentions:
Changed in version 2.7: Added the ',' option (see also PEP 378).

PEP 378 tells me:
The ',' option is defined as shown above for types 'd', 'e', 'f', 'g', 'E', 'G', '%', 'F' and ''.

However:

Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> '{:.2,%}'.format(.537568)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid conversion specification
>>> '{:2,%}'.format(.537568)
'53.756800%'

----------
messages: 150721
nosy: mkesper
priority: normal
severity: normal
status: open
title: Format Specification Mini-Language does not accept comma for percent value
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13718>
_______________________________________

From report at bugs.python.org  Fri Jan  6 14:18:38 2012
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 06 Jan 2012 13:18:38 +0000
Subject: [New-bugs-announce] [issue13719] bdist_msi upload fails
Message-ID: <1325855918.9.0.207720990162.issue13719@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <python-bugs at systemexit.de>:

Running setup.py bdist_msi upload fails with something like:

c:\Python27\python.exe setup.py bdist_msi upload
running bdist_msi
running build
running build_ext
installing to build\bdist.win-amd64\msi
running install_lib
creating build\bdist.win-amd64
creating build\bdist.win-amd64\msi
creating build\bdist.win-amd64\msi\Lib
creating build\bdist.win-amd64\msi\Lib\site-packages
copying build\lib.win-amd64-2.7\greenlet.pyd -> build\bdist.win-amd64\msi\Lib\site-packages
running install_headers
creating build\bdist.win-amd64\msi\Include
creating build\bdist.win-amd64\msi\Include\greenlet
copying greenlet.h -> build\bdist.win-amd64\msi\Include\greenlet
running install_egg_info
Writing build\bdist.win-amd64\msi\Lib\site-packages\greenlet-0.3.3-py2.7.egg-info
creating dist
removing 'build\bdist.win-amd64\msi' (and everything under it)
running upload
Linking c:\Users\ralf\home\greenlet\build\lib.win-amd64-2.7\greenlet.pyd to c:\Users\ralf\home\greenlet\greenlet.pyd
error: greenlet-0.3.3: No such file or directory

The attached patch fixes it.

----------
assignee: tarek
components: Distutils
files: fix-bdist_msi-upload.patch
keywords: patch
messages: 150729
nosy: eric.araujo, loewis, schmir, tarek
priority: normal
severity: normal
status: open
title: bdist_msi upload fails
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file24153/fix-bdist_msi-upload.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13719>
_______________________________________

From report at bugs.python.org  Fri Jan  6 14:55:48 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Fri, 06 Jan 2012 13:55:48 +0000
Subject: [New-bugs-announce] [issue13720] argparse print_help() fails if
	COLUMNS is set to a low	value
Message-ID: <1325858148.7.0.947093232457.issue13720@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:

% cat test_argparse_narrow.py
import argparse
argparse.ArgumentParser().print_help()

% COLUMNS=15 ./python test_argparse_narrow.py
Traceback (most recent call last):
  File "test_argparse_narrow.py", line 2, in <module>
    argparse.ArgumentParser().print_help()
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 2347, in print_help
    self._print_message(self.format_help(), file)
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 2321, in format_help
    return formatter.format_help()
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 276, in format_help
    help = self._root_section.format_help()
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 206, in format_help
    func(*args)
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 206, in format_help
    func(*args)
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 514, in _format_action
    help_lines = self._split_lines(help_text, help_width)
  File "/home/zbyszek/python/cpython/Lib/argparse.py", line 615, in _split_lines
    return _textwrap.wrap(text, width)
  File "/home/zbyszek/python/cpython/Lib/textwrap.py", line 316, in wrap
    return w.wrap(text)
  File "/home/zbyszek/python/cpython/Lib/textwrap.py", line 291, in wrap
    return self._wrap_chunks(chunks)
  File "/home/zbyszek/python/cpython/Lib/textwrap.py", line 220, in _wrap_chunks
    raise ValueError("invalid width %r (must be > 0)" % self.width)
ValueError: invalid width -1 (must be > 0)

argparse should not fail if the user resizes the window to something very thin...

----------
components: Library (Lib)
files: test_argparse_narrow.py
messages: 150733
nosy: zbysz
priority: normal
severity: normal
status: open
title: argparse print_help() fails if COLUMNS is set to a low value
versions: Python 3.3
Added file: http://bugs.python.org/file24154/test_argparse_narrow.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13720>
_______________________________________

From report at bugs.python.org  Fri Jan  6 18:38:32 2012
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 06 Jan 2012 17:38:32 +0000
Subject: [New-bugs-announce] [issue13721] ssl.wrap_socket on a connected but
	failed connection	succeeds and .peer_certificate gives
	AttributeError
Message-ID: <1325871512.71.0.286774610121.issue13721@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

According to http://docs.python.org/release/2.7.2/library/ssl wrap_socket can be used either on connected sockets or on un-connected sockets which then can be .connect'ed.

In the latter case SSLSocket.connect() will (AFAIK) always raise a nice exception if the connection fails before the ssl negotiation has completed.

But when an existing connected but failing socket is wrapped then SSLSocket.__init__ will create an instance with self._sslobj = None without negotiating ssl and without raising any exception. Many SSLSocket methods (such as .cipher) checks for self._sslobj, but for example .getpeercert doesn't and will derefence None. That can lead to spurious crashes in applications.

This problem showed up with Mercurial and connections from China to code.google.com being blocked by the Chinese firewall - see for example https://bugzilla.redhat.com/show_bug.cgi?id=771691 .

In that case

  import socket, ssl, time
  s = socket.create_connection(('code.google.com', 443))
  time.sleep(1)
  ssl_sock = ssl.wrap_socket(s)
  ssl_sock.getpeercert(True)

would fail with
  ...
      ssl_sock.getpeercert(True)
    File "/usr/lib64/python2.7/ssl.py", line 172, in getpeercert
      return self._sslobj.peer_certificate(binary_form)
  AttributeError: 'NoneType' object has no attribute 'peer_certificate'

The problem occurs in the case where The Chinese Wall responds correctly to the SYN with SYN+ACK but soon after sends a RST. The sleep is necessary to reproduce it consistently; that makes sure the RST has been received and getpeername fails. Otherwise getpeername succeeds and the connection reset is only seen later on while negotiation ssl, and socket errors there are handled 'correctly'.

The problem can be reproduced on Linux with
  iptables -t filter -A FORWARD -p tcp --dport 443 ! --tcp-flags SYN SYN -j REJECT --reject-with tcp-reset

I would expect that wrap_socket / SSLSocket.__init__ raised an exception if the wrapped socket has been connected but failed. Calling getpeername is insufficient to detect that (and it is too racy to be reliable).

Alternatively all SSLSocket methods should take care not to dereference self._sslobj and they should respond properly - preferably with a socket/ssl exception.

Alternatively the documentation should describe how all applications that wraps connected sockets has to verify that it actually was connected. Checking .cipher() is apparently currently the least ugly way to do that?

One good(?) reason to wrap connected sockets is to be able to use socket.create_connection which tries all IP adresses of a fqdn before it fails. (Btw: That isn't described in the documentation! That confused me while debugging this.)

I guess applications (like Mercurial) that for that reason wants to use create_connection with 2.7.2 and older should check .cipher() as a workaround?

----------
components: Library (Lib)
messages: 150754
nosy: kiilerix
priority: normal
severity: normal
status: open
title: ssl.wrap_socket on a connected but failed connection succeeds and .peer_certificate gives AttributeError
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13721>
_______________________________________

From report at bugs.python.org  Fri Jan  6 21:32:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jan 2012 20:32:22 +0000
Subject: [New-bugs-announce] [issue13722] "distributions can disable the
	encodings package"
Message-ID: <1325881942.74.0.535921078744.issue13722@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In _PyCodecRegistry_Init() (in Python/codecs.c), it is attempted to import the encodings module (so that the default search function gets registered) and failures get ignored following the same reasoning:

            /* Ignore ImportErrors... this is done so that
               distributions can disable the encodings package. Note
               that other errors are not masked, e.g. SystemErrors
               raised to inform the user of an error in the Python
               configuration are still reported back to the user. */

However, it is unlikely for Python 3 to start up at all without an encodings package (we needs some codecs to initialize stdio). Also, I'm not sure what the point would be. Distributions can simply distribute a dummy encodings module if they really want to disable the default encodings.
Not silencing the error would probably make it easier to diagnose early import issues.

----------
components: Interpreter Core
messages: 150767
nosy: amaury.forgeotdarc, loewis, pitrou
priority: low
severity: normal
status: open
title: "distributions can disable the encodings package"
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13722>
_______________________________________

From report at bugs.python.org  Fri Jan  6 22:43:56 2012
From: report at bugs.python.org (Eric Promislow)
Date: Fri, 06 Jan 2012 21:43:56 +0000
Subject: [New-bugs-announce] [issue13723] Regular expressions: (?:X|\s+)*$
	takes a long time
Message-ID: <1325886236.37.0.0463179039095.issue13723@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

This regular expression takes a few seconds to be evaluated
against any text:

(.*?)((?:X|\s+)*)$

This reg ex is much faster:

(.*?)((?:X|\s)*)$

To be fair, Ruby's performance with the first regex is the same as Python's. PHP and JavaScript both fail to match the first regex
at all.  Only Perl evaluates both regexes nearly instantly.

----------
messages: 150770
nosy: ericp
priority: normal
severity: normal
status: open
title: Regular expressions: (?:X|\s+)*$ takes a long time
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13723>
_______________________________________

From report at bugs.python.org  Fri Jan  6 23:13:50 2012
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 06 Jan 2012 22:13:50 +0000
Subject: [New-bugs-announce] [issue13724] socket.create_connection and
	multiple IP addresses
Message-ID: <1325888030.3.0.0416342115288.issue13724@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

Forked from issue13721 where I was too lazy to report it separately:

http://docs.python.org/release/2.7.2/library/socket#socket.create_connection doesn't describe how it loops over all IP addresses. That seems to be the functions main advantage (and a gotcha) compared to creating the socket and connecting directly.

I propose to warn that it might "hang" up to n*timeout before anything happens with something like this in documentation and docstring:

... and return the socket object.
If the host resolves to multiple IP addresses then they will all be tried in turn until one of them succeeds.
Passing the optional timeout parameter will set the timeout on the socket instance before each attempt to connect.
If no ...

----------
assignee: docs at python
components: Documentation
messages: 150772
nosy: docs at python, kiilerix, pitrou
priority: normal
severity: normal
status: open
title: socket.create_connection and multiple IP addresses
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13724>
_______________________________________

From report at bugs.python.org  Sat Jan  7 12:51:48 2012
From: report at bugs.python.org (Erno Tukia)
Date: Sat, 07 Jan 2012 11:51:48 +0000
Subject: [New-bugs-announce] [issue13725] regrtest does not recognize -d flag
Message-ID: <1325937108.85.0.410316805004.issue13725@psf.upfronthosting.co.za>


New submission from Erno Tukia <erno.tukia at iki.fi>:

./python -m test --help
-d/--debug      -- print traceback for failed tests

./python -m test -d?test_imaplib
option -d not recognized
Use --help for usage

Patch included.

----------
components: Tests
files: regrtest-debug.patch
keywords: patch
messages: 150790
nosy: etukia
priority: normal
severity: normal
status: open
title: regrtest does not recognize -d flag
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24159/regrtest-debug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13725>
_______________________________________

From report at bugs.python.org  Sat Jan  7 13:14:48 2012
From: report at bugs.python.org (Erno Tukia)
Date: Sat, 07 Jan 2012 12:14:48 +0000
Subject: [New-bugs-announce] [issue13726] regrtest ambiguous -S flag
Message-ID: <1325938488.7.0.238559424001.issue13726@psf.upfronthosting.co.za>


New submission from Erno Tukia <erno.tukia at iki.fi>:

./python -m test --help
-S/--slow       -- print the slowest 10 tests

-S is used to continue running tests after an aborted run.  It will
maintain the order a standard run (ie, this assumes -r is not used).
This is useful after the tests have prematurely stopped for some external
reason and you want to start running from where you left off rather
than starting from the beginning.

in Lib/test/regrtest.py

opts, args = getopt.getopt(sys.argv[1:], '...S...',
            [..., 'slow', ... , 'start=', ...])

for o, a in opts:
    elif o in ('-S', '--start'):
        start = a
    elif o in ('-S', '--slow'):
        print_slow = True

At the moment -S (no args) and --slow (no args) are the same, not what the documentation says and not how the code executes (-S goes with --start). Help says nothing about --start.

--slow or --start needs a new short opt, and corrected documentation.

----------
assignee: docs at python
components: Documentation, Tests
messages: 150792
nosy: docs at python, etukia
priority: normal
severity: normal
status: open
title: regrtest ambiguous -S flag
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13726>
_______________________________________

From report at bugs.python.org  Sat Jan  7 14:50:36 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 07 Jan 2012 13:50:36 +0000
Subject: [New-bugs-announce] [issue13727] Accessor macros for
	PyDateTime_Delta members
Message-ID: <1325944236.57.0.0169968212645.issue13727@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

All objects of the datetime module have macros to access their properties, except timedelta.
This simple patch adds the macros PyDateTime_DELTA_GET_DAYS, PyDateTime_DELTA_GET_SECONDS, PyDateTime_DELTA_GET_MICROSECONDS; module developers are encouraged to use these instead of obj->seconds for example.

Motivation:
PyPy cannot easily expose PyDateTime_Delta fields because datetime is implemented as a pure Python module and it's difficult to rebuild a C structure from a heap type.
In PyPy these macros are actually functions, which do something similar to PyLong_AsLong(PyObject_GetAttrString(obj, "seconds")):
https://bitbucket.org/pypy/pypy/src/b67e65d709e1/pypy/module/cpyext/cdatetime.py#cl-235

----------
files: timedelta_macros.patch
keywords: patch
messages: 150796
nosy: amaury.forgeotdarc
priority: normal
severity: normal
stage: patch review
status: open
title: Accessor macros for PyDateTime_Delta members
versions: Python 3.3
Added file: http://bugs.python.org/file24160/timedelta_macros.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13727>
_______________________________________

From report at bugs.python.org  Sat Jan  7 16:36:53 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 07 Jan 2012 15:36:53 +0000
Subject: [New-bugs-announce] [issue13728] Description of -m and -c cli
	options wrong?
Message-ID: <1325950613.83.0.912226487635.issue13728@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi,
looking at http://mail.python.org/pipermail/docs/2011-December/006672.html I tried to replicate what the user said, and *it seems* that -c and -m doesn't add the current directory to the start of sys.path:

$ echo -e "import sys\nprint (sys.path)" > dummy.py ; ./python -mdummy
['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', '/home/morph/cpython/py27/Lib/plat-linux2', '/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', '/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', '/usr/local/lib/python2.7/site-packages']

and 

$ ./python -c "import dummy"
['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', '/home/morph/cpython/py27/Lib/plat-linux2', '/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', '/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', '/usr/local/lib/python2.7/site-packages']

the same sys.path as from the interactive shell:

$ ./python 
Python 2.7.2+ (2.7:f0666e56a552, Jan  7 2012, 16:31:06) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[38650 refs]
>>> sys.path
['', '/usr/local/lib/python27.zip', '/home/morph/cpython/py27/Lib', '/home/morph/cpython/py27/Lib/plat-linux2', '/home/morph/cpython/py27/Lib/lib-tk', '/home/morph/cpython/py27/Lib/lib-old', '/home/morph/cpython/py27/build/lib.linux-x86_64-2.7-pydebug', '/usr/local/lib/python2.7/site-packages']
[38657 refs]

So, is http://docs.python.org/using/cmdline.html#interface-options correct in saying "he current directory will be added to the start of sys.path (allowing modules in that directory to be imported as top level modules)."? (and so forth for -m option?) am I confused?

----------
assignee: docs at python
components: Documentation
messages: 150802
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Description of -m and -c cli options wrong?
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13728>
_______________________________________

From report at bugs.python.org  Sat Jan  7 17:05:32 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 07 Jan 2012 16:05:32 +0000
Subject: [New-bugs-announce] [issue13729] Evaluation order for dics key/value
Message-ID: <1325952332.37.0.223922022645.issue13729@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-December/006782.html , I'm opening this issue to have others confirmation of what's happening:

echo -e "def ev(r):\n    print(r)\n    return r\n\n{ev(1): ev(2), ev(3): ev(4)}" | ./python 
2
1
4
3

(this applies for 2.7/3.2/default) so it seems the value expressions are evaluated before the key expressions, so the

{expr1: expr2, expr3: expr4}

in http://docs.python.org/reference/expressions.html#evaluation-order has to be updated in

{expr2: expr1, expr4: expr3}

Is that correct/can someone confirm this is the expected behavior?

----------
assignee: docs at python
components: Documentation
messages: 150804
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Evaluation order for dics key/value
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13729>
_______________________________________

From report at bugs.python.org  Sat Jan  7 20:09:30 2012
From: report at bugs.python.org (Aaron Maenpaa)
Date: Sat, 07 Jan 2012 19:09:30 +0000
Subject: [New-bugs-announce] [issue13730] Grammar mistake in Decimal
	documentation
Message-ID: <1325963370.31.0.599534414571.issue13730@psf.upfronthosting.co.za>


New submission from Aaron Maenpaa <aaron at maenpaa.ca>:

In the sentance: "In contrast, numbers like 1.1 and 2.2 do not have an exact representations in binary floating point." there is a mismatch in number between "an" and "representations". I suggest removing "an" to make the whole thing plural.

A patch is attached.

----------
assignee: docs at python
components: Documentation
files: plural.diff
keywords: patch
messages: 150813
nosy: docs at python, zacherates
priority: normal
severity: normal
status: open
title: Grammar mistake in Decimal documentation
versions: Python 3.3
Added file: http://bugs.python.org/file24164/plural.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13730>
_______________________________________

From report at bugs.python.org  Sat Jan  7 20:16:46 2012
From: report at bugs.python.org (Aaron Maenpaa)
Date: Sat, 07 Jan 2012 19:16:46 +0000
Subject: [New-bugs-announce] [issue13731] Awkward phrasing in Decimal
	documentation
Message-ID: <1325963806.67.0.168164997308.issue13731@psf.upfronthosting.co.za>


New submission from Aaron Maenpaa <aaron at maenpaa.ca>:

The paragraph: "The exactness carries over into arithmetic. In decimal floating point, 0.1 + 0.1 + 0.1 - 0.3 is exactly equal to zero. In binary floating point, the result is 5.5511151231257827e-017. While near to zero, the differences prevent reliable equality testing and differences can accumulate. For this reason, decimal is preferred in accounting applications which have strict equality invariants."

... has some awkward phrasing to my ear. I've attached a patch with a proposed alternative.

----------
assignee: docs at python
components: Documentation
files: rephrase.diff
keywords: patch
messages: 150814
nosy: docs at python, zacherates
priority: normal
severity: normal
status: open
title: Awkward phrasing in Decimal documentation
versions: Python 3.3
Added file: http://bugs.python.org/file24165/rephrase.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13731>
_______________________________________

From report at bugs.python.org  Sat Jan  7 21:06:27 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 07 Jan 2012 20:06:27 +0000
Subject: [New-bugs-announce] [issue13732] test_logging failure on Windows
	buildbots
Message-ID: <1325966787.14.0.961413341663.issue13732@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Commit 57295c4d81ac879dd2d804190b38b2e91f934acd broke Windows buildbots:

"""
======================================================================
ERROR: test_rotator (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 3543, in tearDown
    os.unlink(fn)
PermissionError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-9ozjk9.log'

======================================================================
FAIL: test_rotator (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 3631, in test_rotator
    self.assertEqual(data.decode("ascii"), m1.msg + "\n")
AssertionError: '1\r\n' != '1\n'
- 1
?  -
+ 1


======================================================================
FAIL: test_should_not_rollover (test.test_logging.RotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 3536, in setUp
    BaseTest.setUp(self)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 114, in setUp
    raise AssertionError('Unexpected handlers: %s' % hlist)
AssertionError: Unexpected handlers: [<logging.StreamHandler object at 0x0EBAC540>]
"""

See http://python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4180/steps/test/logs/stdio and http://python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5780/steps/test/logs/stdio

----------
assignee: vinay.sajip
components: Tests
messages: 150817
nosy: neologix, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging failure on Windows buildbots
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13732>
_______________________________________

From report at bugs.python.org  Sun Jan  8 00:53:22 2012
From: report at bugs.python.org (Paul Smedley)
Date: Sat, 07 Jan 2012 23:53:22 +0000
Subject: [New-bugs-announce] [issue13733] Change required to sysconfig.py
	for Python 2.7.2 on OS/2
Message-ID: <1325980402.33.0.867781342076.issue13733@psf.upfronthosting.co.za>


New submission from Paul Smedley <paul at smedley.id.au>:

Python 2.7.2 fails during compilation on OS/2  with:
 File "./setup.py", line 1154, in detect_modules
   for arg in sysconfig.get_config_var("CONFIG_ARGS").split()]
AttributeError: 'NoneType' object has no attribute 'split'
make: *** [sharedmods] Error 1

Attached diff for sysconfig.py corrects the problem

----------
components: Build
files: sysconfig.py.diff
keywords: patch
messages: 150831
nosy: Paul.Smedley
priority: normal
severity: normal
status: open
title: Change required to sysconfig.py for Python 2.7.2 on OS/2
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file24168/sysconfig.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13733>
_______________________________________

From report at bugs.python.org  Sun Jan  8 01:14:03 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 08 Jan 2012 00:14:03 +0000
Subject: [New-bugs-announce] [issue13734] Add a generic directory walker
	method to avoid symlink	attacks
Message-ID: <1325981643.51.0.923790442233.issue13734@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

This is an offspring of #4489 (which is a security bug). The method is AFAIU intended to be private. 

As shown in the discussion of the mentioned #4489, there is a whole family of attacks that exploit the time window between gathering path names and executing a function on them. A general description of this problem can be found in: https://www.securecoding.cert.org/confluence/display/seccode/POS35-C.+Avoid+race+conditions+while+checking+for+the+existence+of+a+symbolic+link

While the consequences in rmtree() are probably most dramatic, other recursive functions could benefit too (chmodtree() and chowntree() were mentioned) so Charles-Fran?ois suggested to write a "generic walker method that would take as argument the methods to call on a directory and on a file (or link)".

Some (probably) necessary helper functions has been already implemented in #4761 (*at()) and #10755 (fdlistdir()).

Has there already been done any work? Ross mentioned he wanted to take a stab?

----------
components: Library (Lib)
messages: 150833
nosy: hynek.schlawack, neologix, pitrou, rosslagerwall, tarek
priority: normal
severity: normal
status: open
title: Add a generic directory walker method to avoid symlink attacks
type: security
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13734>
_______________________________________

From report at bugs.python.org  Sun Jan  8 04:38:30 2012
From: report at bugs.python.org (Kay Hayen)
Date: Sun, 08 Jan 2012 03:38:30 +0000
Subject: [New-bugs-announce] [issue13735] The protocol > 0 of cPickle does
	not given stable	dictionary values
Message-ID: <1325993910.77.0.693345658912.issue13735@psf.upfronthosting.co.za>


New submission from Kay Hayen <kayhayen at gmx.de>:

Hello,

I am implementing a Python compiler (Nuitka) that is testing if when it compiles itself, it gives the same output. 

I have been using "protocol = 0" ever since with "pickle" module for historic reasons (gcc bug with raw strings lead me to believe it's better) and lately, I have changed to "protocol = 2" and cPickle. But then I noticed that my compile itself test now fail to give same code from pickling of dictionary constants.

Imanaged and isolated the issue, and it's a Python2.7 regression, Python2.6 is fine:

Observe this output from "cPickle.dumps" for a constant dictionary with one element:

Protocol 0 :
Dumping read const const stream "(dp1\nS'modules'\np2\nNs."
Dumping load const const stream "(dp1\nS'modules'\np2\nNs."
Dumping load const const stream "(dp1\nS'modules'\np2\nNs."
Protocol 1 :
Dumping read const const stream '}q\x01U\x07modulesq\x02Ns.'
Dumping load const const stream '}q\x01U\x07modulesNs.'
Dumping load const const stream '}q\x01U\x07modulesNs.'
Protocol 2 :
Dumping read const const stream '\x80\x02}q\x01U\x07modulesq\x02Ns.'
Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.'
Dumping load const const stream '\x80\x02}q\x01U\x07modulesNs.'

It seems that cPickle as of CPython2.7 does give a better stream for dictionaries it itself emitted. With CPython2.6 I observe no difference.

My work-around is to "re-stream", "dumps" -> "loads" -> "dumps" with CPython2.7 for the time being.

Can you either: Fix cPickle to treat the dictionaries the same, or enhance to core to produce the same dict as cPickle does? It appears at least some kind of efficiency might be missed out for marshall as well.

----------
components: Interpreter Core, Library (Lib)
files: stream.py
messages: 150841
nosy: kayhayen
priority: normal
severity: normal
status: open
title: The protocol > 0 of cPickle does not given stable dictionary values
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24170/stream.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13735>
_______________________________________

From report at bugs.python.org  Sun Jan  8 07:22:20 2012
From: report at bugs.python.org (Jyotirmoy Bhattacharya)
Date: Sun, 08 Jan 2012 06:22:20 +0000
Subject: [New-bugs-announce] [issue13736] urllib.request.urlopen leaks
	exceptions from socket and	httplib.client
Message-ID: <1326003740.31.0.0410778534365.issue13736@psf.upfronthosting.co.za>


New submission from Jyotirmoy Bhattacharya <jyotirmoy at jyotirmoy.net>:

The documentation for urlopen says that it raises URLError on error. 
But there exist error conditions such as a socket timeout or a bad HTTP status line under which the exception from the underlying library leaks through urllib, thus breaking the promise in the documentation.

I am attaching a test program that demonstrates this bug.

----------
components: Library (Lib)
files: test_urllib_except.py
messages: 150849
nosy: jmoy, orsenthil
priority: normal
severity: normal
status: open
title: urllib.request.urlopen leaks exceptions from socket and httplib.client
versions: Python 3.3
Added file: http://bugs.python.org/file24172/test_urllib_except.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13736>
_______________________________________

From report at bugs.python.org  Sun Jan  8 08:52:07 2012
From: report at bugs.python.org (Bithin A)
Date: Sun, 08 Jan 2012 07:52:07 +0000
Subject: [New-bugs-announce] [issue13737] bugs.python.org's Django settings
	file DEBUG=True
Message-ID: <1326009127.55.0.187877288169.issue13737@psf.upfronthosting.co.za>


New submission from Bithin A <bithin2007 at gmail.com>:

I am getting an Django error when I was trying to review a patch. This error has occurred in the site as the DEBUG mode in the Django settings file is set to True. It is a security issue and should be set to false. I am attaching the screen shot of the error which I have come across.

----------
components: None
files: Screenshot at 2012-01-08 13:11:43.png
messages: 150852
nosy: Bithin.A
priority: normal
severity: normal
status: open
title: bugs.python.org's Django settings file DEBUG=True
type: security
Added file: http://bugs.python.org/file24174/Screenshot at 2012-01-08 13:11:43.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13737>
_______________________________________

From report at bugs.python.org  Sun Jan  8 15:49:18 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jan 2012 14:49:18 +0000
Subject: [New-bugs-announce] [issue13738] Optimize bytes.upper() and lower()
Message-ID: <1326034158.97.0.725746984408.issue13738@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The current implementation has useless testing and copying.

----------
components: Interpreter Core
files: bytesupper.patch
keywords: patch
messages: 150868
nosy: benjamin.peterson, flox, haypo, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Optimize bytes.upper() and lower()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24175/bytesupper.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13738>
_______________________________________

From report at bugs.python.org  Sun Jan  8 17:26:26 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Jan 2012 16:26:26 +0000
Subject: [New-bugs-announce] [issue13739] os.fdlistdir() is not idempotent
Message-ID: <1326039986.48.0.995838424483.issue13739@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

After a call to fdlistdir(), another call to fdlistdir() on the same file handle (but using a different FD, since the FD passed to fdlistdir() is closed) will return an empty list:

"""
$ cat ~/test_fdlistdir.py 
import os
import sys


fd = os.open(sys.argv[1], os.O_RDONLY)

print(os.fdlistdir(os.dup(fd)))
print(os.fdlistdir(os.dup(fd)))

os.close(fd)
$ ./python ~/test_fdlistdir.py /tmp/
['pulse-B1FebW397VI5', 'ksocket-kdm', 'etc', 'kde-cf', 'ksocket-cf', 'test_posix.py', '.X0-lock', 'kde-kdm', 'akonadi-cf.k6y52j', 'ssh-iSFleEAS1243', '.ICE-unix', '.X11-unix']
[]
"""

That's because fdopendir()/readdir doesn't reset the FD offset.
It's documented by POSIX:
"""
The file offset associated with the file descriptor at the time of the call determines which entries are returned.
"""

That's rather suprising (I got bitten while trying to write a test for #13734).
I see two options:
1. rewind the directory stream in fdlistdir()
2. document this

Here's a patch for option 1.

----------
components: None
files: fdlistdir.diff
keywords: patch
messages: 150877
nosy: neologix, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: os.fdlistdir() is not idempotent
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24178/fdlistdir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13739>
_______________________________________

From report at bugs.python.org  Sun Jan  8 22:47:45 2012
From: report at bugs.python.org (Jelle Geerts)
Date: Sun, 08 Jan 2012 21:47:45 +0000
Subject: [New-bugs-announce] [issue13740] winsound.SND_NOWAIT ignored on
	modern Windows platforms
Message-ID: <1326059265.01.0.0567556069676.issue13740@psf.upfronthosting.co.za>


New submission from Jelle Geerts <jellegeerts at gmail.com>:

As the attached example Python script explains, the winsound.SND_NOWAIT flag doesn't do anything, at least not on modern Windows platforms.

The updated MSDN documentation for PlaySound() states that SND_NOWAIT is not supported (it is ignored).
Link: http://msdn.microsoft.com/en-us/library/windows/desktop/dd743680%28v=vs.85%29.aspx

Assuming that the flag is supported on older Windows versions, I propose that the Python documentation is updated to state the same thing for SND_NOWAIT that it states for the SND_PURGE flag, which is the following:
"Note: This flag is not supported on modern Windows platforms."

Even though it might be that SND_NOWAIT was in fact never supported on any Windows version, the proposed change is at least better than not doing anything about it.

----------
components: Windows
files: example.py
messages: 150915
nosy: bughunter2
priority: normal
severity: normal
status: open
title: winsound.SND_NOWAIT ignored on modern Windows platforms
type: behavior
Added file: http://bugs.python.org/file24182/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13740>
_______________________________________

From report at bugs.python.org  Mon Jan  9 06:22:32 2012
From: report at bugs.python.org (Andrew)
Date: Mon, 09 Jan 2012 05:22:32 +0000
Subject: [New-bugs-announce] [issue13741] *** glibc detected *** python:
	double free or corruption	(!prev): 0x0000000001d53ad0 ***
Message-ID: <1326086552.75.0.47475679765.issue13741@psf.upfronthosting.co.za>


New submission from Andrew <awnystrom at gmail.com>:

Hello,
This program crashes after 12-24 hours of running.  My OS is Ubuntu 11.10, I'm using Python 2.7.2, and gcc 4.6.1.

Here's the error:

*** glibc detected *** python: double free or corruption (!prev): 0x0000000001d53ad0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x78a96)[0x7fbd28c21a96]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7fbd28c25d7c]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0xd6aa)[0x7fbd27c806aa]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0xde51)[0x7fbd27c80e51]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0x13f9b)[0x7fbd27c86f9b]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0x146c6)[0x7fbd27c876c6]
python(PyEval_EvalFrameEx+0x2f9)[0x4b6569]
python(PyEval_EvalFrameEx+0xb07)[0x4b6d77]
======= Memory map: ========
00400000-00633000 r-xp 00000000 08:06 1901460                            /usr/bin/python2.7
00832000-00833000 r--p 00232000 08:06 1901460                            /usr/bin/python2.7
00833000-0089c000 rw-p 00233000 08:06 1901460                            /usr/bin/python2.7
0089c000-008ae000 rw-p 00000000 00:00 0 
01b30000-01f26000 rw-p 00000000 00:00 0                                  [heap]
7fbd1dffc000-7fbd1dffd000 ---p 00000000 00:00 0 
7fbd1dffd000-7fbd1e7fd000 rw-p 00000000 00:00 0 
7fbd1e7fd000-7fbd1e7fe000 ---p 00000000 00:00 0 
7fbd1e7fe000-7fbd1effe000 rw-p 00000000 00:00 0 
7fbd1effe000-7fbd1efff000 ---p 00000000 00:00 0 
7fbd1efff000-7fbd1f7ff000 rw-p 00000000 00:00 0 
7fbd1f7ff000-7fbd1f800000 ---p 00000000 00:00 0 
7fbd1f800000-7fbd20000000 rw-p 00000000 00:00 0 
7fbd20000000-7fbd2011e000 rw-p 00000000 00:00 0 
7fbd2011e000-7fbd24000000 ---p 00000000 00:00 0 
7fbd24411000-7fbd24426000 r-xp 00000000 08:06 1754089                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7fbd24426000-7fbd24625000 ---p 00015000 08:06 1754089                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7fbd24625000-7fbd24626000 r--p 00014000 08:06 1754089                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7fbd24626000-7fbd24627000 rw-p 00015000 08:06 1754089                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7fbd24627000-7fbd24628000 ---p 00000000 00:00 0 
7fbd24628000-7fbd24e28000 rw-p 00000000 00:00 0 
7fbd24e28000-7fbd24e34000 r-xp 00000000 08:06 1754109                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
7fbd24e34000-7fbd25033000 ---p 0000c000 08:06 1754109                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
7fbd25033000-7fbd25034000 r--p 0000b000 08:06 1754109                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
7fbd25034000-7fbd25035000 rw-p 0000c000 08:06 1754109                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
7fbd25035000-7fbd2503f000 r-xp 00000000 08:06 1754113                    /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fbd2503f000-7fbd2523f000 ---p 0000a000 08:06 1754113                    /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fbd2523f000-7fbd25240000 r--p 0000a000 08:06 1754113                    /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fbd25240000-7fbd25241000 rw-p 0000b000 08:06 1754113                    /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7fbd25241000-7fbd25258000 r-xp 00000000 08:06 1754103                    /lib/x86_64-linux-gnu/libnsl-2.13.so
7fbd25258000-7fbd25457000 ---p 00017000 08:06 1754103                    /lib/x86_64-linux-gnu/libnsl-2.13.so
7fbd25457000-7fbd25458000 r--p 00016000 08:06 1754103                    /lib/x86_64-linux-gnu/libnsl-2.13.so
7fbd25458000-7fbd25459000 rw-p 00017000 08:06 1754103                    /lib/x86_64-linux-gnu/libnsl-2.13.so
7fbd25459000-7fbd2545b000 rw-p 00000000 00:00 0 
7fbd2545b000-7fbd25463000 r-xp 00000000 08:06 1754105                    /lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fbd25463000-7fbd25662000 ---p 00008000 08:06 1754105                    /lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fbd25662000-7fbd25663000 r--p 00007000 08:06 1754105                    /lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fbd25663000-7fbd25664000 rw-p 00008000 08:06 1754105                    /lib/x86_64-linux-gnu/libnss_compat-2.13.so
7fbd25664000-7fbd2566b000 r-xp 00000000 08:06 1754132                    /lib/x86_64-linux-gnu/librt-2.13.so
7fbd2566b000-7fbd2586a000 ---p 00007000 08:06 1754132                    /lib/x86_64-linux-gnu/librt-2.13.so
7fbd2586a000-7fbd2586b000 r--p 00006000 08:06 1754132                    /lib/x86_64-linux-gnu/librt-2.13.so
7fbd2586b000-7fbd2586c000 rw-p 00007000 08:06 1754132                    /lib/x86_64-linux-gnu/librt-2.13.so
7fbd2586c000-7fbd2587a000 r-xp 00000000 08:06 1982536                    /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
7fbd2587a000-7fbd25a7a000 ---p 0000e000 08:06 1982536                    /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
7fbd25a7a000-7fbd25a7b000 r--p 0000e000 08:06 1982536                    /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
7fbd25a7b000-7fbd25a7c000 rw-p 0000f000 08:06 1982536                    /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so
7fbd25a7c000-7fbd25b3d000 rw-p 00000000 00:00 0 
7fbd25b3d000-7fbd25b40000 r-xp 00000000 08:06 1754095                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7fbd25b40000-7fbd25d3f000 ---p 00003000 08:06 1754095                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7fbd25d3f000-7fbd25d40000 r--p 00002000 08:06 1754095                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7fbd25d40000-7fbd25d41000 rw-p 00003000 08:06 1754095                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7fbd25d41000-7fbd25d51000 r-xp 00000000 08:06 8518                       /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.11
7fbd25d51000-7fbd25f50000 ---p 00010000 08:06 8518                       /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.11
7fbd25f50000-7fbd25f51000 r--p 0000f000 08:06 8518                       /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.11
7fbd25f51000-7fbd25f52000 rw-p 00010000 08:06 8518                       /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.11
7fbd25f52000-7fbd25fcc000 r-xp 00000000 08:06 1754091                    /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0
7fbd25fcc000-7fbd261cc000 ---p 0007a000 08:06 1754091                    /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0
7fbd261cc000-7fbd261cd000 r--p 0007a000 08:06 1754091                    /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0
7fbd261cd000-7fbd261d0000 rw-p 0007b000 08:06 1754091                    /lib/x86_64-linux-gnu/libgcrypt.so.11.7.0
7fbd261d0000-7fbd26271000 r-xp 00000000 08:06 8379                       /usr/lib/x86_64-linux-gnu/libgnutls.so.26.16.14
7fbd26271000-7fbd26470000 ---p 000a1000 08:06 8379                       /usr/lib/x86_64-linux-gnu/libgnutls.so.26.16.14
7fbd26470000-7fbd26477000 r--p 000a0000 08:06 8379                       /usr/lib/x86_64-linux-gnu/libgnutls.so.26.16.14
7fbd26477000-7fbd26478000 Aborted

----------
files: server.py
messages: 150920
nosy: BlendsInWell
priority: normal
severity: normal
status: open
title: *** glibc detected *** python: double free or corruption (!prev): 0x0000000001d53ad0 ***
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file24183/server.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13741>
_______________________________________

From report at bugs.python.org  Mon Jan  9 11:35:42 2012
From: report at bugs.python.org (Simon Sapin)
Date: Mon, 09 Jan 2012 10:35:42 +0000
Subject: [New-bugs-announce] [issue13742] Add a key parameter (like sorted)
	to heapq.merge
Message-ID: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za>


New submission from Simon Sapin <simon.sapin at kozea.fr>:

Hi,

The attached patch adds a 'key' optional parameter to the heapq.merge function that behaves as in sorted().

Related discussion: http://mail.python.org/pipermail/python-ideas/2012-January/013295.html

This is my first contribution to CPython.

----------
components: Library (Lib)
files: heapq_merge_key.patch
keywords: patch
messages: 150927
nosy: SimonSapin, rhettinger
priority: normal
severity: normal
status: open
title: Add a key parameter (like sorted) to heapq.merge
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24184/heapq_merge_key.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13742>
_______________________________________

From report at bugs.python.org  Mon Jan  9 14:06:18 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 09 Jan 2012 13:06:18 +0000
Subject: [New-bugs-announce] [issue13743] xml.dom.minidom.Document class is
	not documented
Message-ID: <1326114378.06.0.424770823698.issue13743@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2012-January/007026.html I noticed the whole Document class (and relative methods) is not documented.

Maybe it is a choice to not document it, or maybe it's just a missing doc, dunno, the's why I'm opening this :)

----------
assignee: docs at python
components: Documentation
messages: 150935
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: xml.dom.minidom.Document class is not documented
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13743>
_______________________________________

From report at bugs.python.org  Mon Jan  9 14:34:22 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 09 Jan 2012 13:34:22 +0000
Subject: [New-bugs-announce] [issue13744] raw byte strings are described in
	a confusing way
Message-ID: <1326116062.09.0.84789277908.issue13744@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

The lexical analysis documentation says this:

http://docs.python.org/py3k/reference/lexical_analysis.html?highlight=raw%20bytes

"Bytes literals are always prefixed with 'b' or 'B';..."

"Both string and bytes literals may optionally be prefixed with a letter 'r' or 'R';..."

But that would lead you to believe that to get raw byte strings you should use rb"foo".  In fact, that's a SyntaxError in Python 2.6+ and Python 3.  What *does* work though is br"foo".

Either Python should accept both spellings (harder) or the documentation should make it clear that the 'b' must preceded the 'r'.

----------
assignee: docs at python
components: Documentation
messages: 150936
nosy: barry, docs at python
priority: normal
severity: normal
status: open
title: raw byte strings are described in a confusing way
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13744>
_______________________________________

From report at bugs.python.org  Mon Jan  9 16:40:10 2012
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 09 Jan 2012 15:40:10 +0000
Subject: [New-bugs-announce] [issue13745] configuring --with-dbmliborder=bdb
	doesn't build the	gdbm extension
Message-ID: <1326123610.21.0.125848045882.issue13745@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

configuring --with-dbmliborder=bdb doesn't build the gdbm extension. this option should only affect the build of the dbm extension, not the build of the gdbm extension.

----------
messages: 150943
nosy: doko
priority: low
severity: normal
status: open
title: configuring --with-dbmliborder=bdb doesn't build the gdbm extension
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13745>
_______________________________________

From report at bugs.python.org  Mon Jan  9 17:33:56 2012
From: report at bugs.python.org (Igor Bronshteyn)
Date: Mon, 09 Jan 2012 16:33:56 +0000
Subject: [New-bugs-announce] [issue13746] ast.Tuple's have an inconsistent
	"col_offset" value
Message-ID: <1326126836.81.0.857723956921.issue13746@psf.upfronthosting.co.za>


New submission from Igor Bronshteyn <igor.bronstein at gmail.com>:

Consider the following snippet (the file is attached):

==== code starts ====
a = [1, 3.14, 'abc', u'XYZ']
b = (1, 3.14, 'abc', u'XYZ')
c = {1 : 3.14, 'abc' : u'XYZ'}
===== code ends =====

The list has correct position: (1,4), the dict has correct position too: (3,4). But the position of tuple node (ast.Tuple) has wrong or inconsistent "col_offset" = 5: (2,5).

----------
files: sample01.py
messages: 150950
nosy: bronikkk
priority: normal
severity: normal
status: open
title: ast.Tuple's have an inconsistent "col_offset" value
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file24187/sample01.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13746>
_______________________________________

From report at bugs.python.org  Mon Jan  9 20:10:42 2012
From: report at bugs.python.org (Ben Darnell)
Date: Mon, 09 Jan 2012 19:10:42 +0000
Subject: [New-bugs-announce] [issue13747] ssl_version documentation error
Message-ID: <1326136242.52.0.747462245395.issue13747@psf.upfronthosting.co.za>


New submission from Ben Darnell <ben.darnell at gmail.com>:

The ssl module docs claim that the default ssl_version for client-side operation is SSLv3, but it is actually SSLv23.  The exact behavior depends on the version of openssl:  starting in 1.0 the connection is limited by default to SSLv3 or TLSv1 (as documented in the note below the compatibility table), but in older versions of openssl SSLv2 is allowed by default. 

This is just a documentation error if you've got a recent version of openssl, but it's also a security problem with older versions, since people may have been unknowingly using the weaker SSLv2 protocol.  (I don't know how widespread pre-1.0 versions of openssl are these days, but OSX Lion still ships with 0.9.8)  It would be nice if the default mode were SSLv23 with SSL_OP_NO_SSLv2 set so the defaults would be safe even with older versions of openssl (there's no way to set this configuration from python code before py3.2)

Also, the compatibility table claims that an SSLv3 client can talk to an SSLv2 server, which is incorrect.  SSLv23 clients can talk to SSLv3 and TLSv1 servers if openssl is at least version 1.0 and SSLv2 ciphers are not explicitly enabled.

----------
messages: 150963
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: ssl_version documentation error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13747>
_______________________________________

From report at bugs.python.org  Mon Jan  9 20:14:10 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Jan 2012 19:14:10 +0000
Subject: [New-bugs-announce] [issue13748] Allow rb"" literals as an
	equivalent to br""
Message-ID: <1326136450.88.0.500129181902.issue13748@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

As mentioned in issue13744, it is not easy to remember that br"" is an allowed bytes literal but not rb"". Here is a patch to allow both forms.

----------
components: Interpreter Core
files: rb.patch
keywords: patch
messages: 150964
nosy: barry, benjamin.peterson, gvanrossum, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Allow rb"" literals as an equivalent to br""
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24188/rb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13748>
_______________________________________

From report at bugs.python.org  Mon Jan  9 20:19:29 2012
From: report at bugs.python.org (K Richard Pixley)
Date: Mon, 09 Jan 2012 19:19:29 +0000
Subject: [New-bugs-announce] [issue13749] socketserver can't stop
Message-ID: <1326136769.56.0.386749729049.issue13749@psf.upfronthosting.co.za>


New submission from K Richard Pixley <rich at noir.com>:

Once I've instantiated my server class, along with a handler class, called server.serve_forever(), handler.handle() has been called, I've done my work, and I'm ready to shut the whole thing down...

How do I do that?

The doc says server.shutdown(), but if I call self.server.shutdown() from within handler.handle(), I seem to get a deadlock, which is exactly what I'd expect in a single threaded system with no way to "signal" the server.server_forever() loop which is several frames up the stack.

I've also tried sys.exit() but it seems that the server object is catching that as an exception.

How is this expected to work?  How do I terminate the server.serve_forever() loop?

Both 3.2 and 2.7 appear to behave the same way.  The documentation is confusing here as it doesn't explain what is expected to happen in this case.

----------
components: Library (Lib)
messages: 150965
nosy: teamnoir
priority: normal
severity: normal
status: open
title: socketserver can't stop
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13749>
_______________________________________

From report at bugs.python.org  Mon Jan  9 20:45:10 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 Jan 2012 19:45:10 +0000
Subject: [New-bugs-announce] [issue13750] queue broken when built
	without-thread
Message-ID: <1326138310.33.0.521077885473.issue13750@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Commit 190ad17f5a87481a006434a2a3d3a8e1e954a6db broke the fedora without-threads buildbot:
"""
./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600 
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/queue.py", line 4, in <module>
    import threading
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./Tools/scripts/run_tests.py", line 12, in <module>
    import test.support
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/support.py", line 25, in <module>
    import logging.handlers
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/logging/handlers.py", line 30, in <module>
    import queue
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/queue.py", line 6, in <module>
    import dummythreading as threading
ImportError: No module named 'dummythreading'
[76890 refs]
make: *** [buildbottest] Error 1
"""

See http://python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/1333/steps/test/logs/stdio

----------
components: Library (Lib)
messages: 150970
nosy: neologix, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: queue broken when built without-thread
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13750>
_______________________________________

From report at bugs.python.org  Mon Jan  9 21:23:58 2012
From: report at bugs.python.org (Faheem Mitha)
Date: Mon, 09 Jan 2012 20:23:58 +0000
Subject: [New-bugs-announce] [issue13751] multiprocessing.pool hangs if any
	worker raises an	Exception whose constructor requires a parameter
Message-ID: <1326140638.43.0.449072803971.issue13751@psf.upfronthosting.co.za>


New submission from Faheem Mitha <faheem at faheem.info>:

See my question at http://stackoverflow.com/questions/8785899/hang-in-python-script-using-sqlalchemy-and-multiprocessing

I can't improve on the analysis by Lorenzo Bolla,
so I reproduce his example below. This example hangs if
BadExc is thrown, but not if GoodExc is thrown.
The only difference between these is that the GoodExc does
not require an argument be passed to its constructor, while
BadExc does.

This looks like a bug to me, though I suppose it might
be some pickling limitation.

I have confirmed this behavior is present in 2.6.6, 2.7.2,
and 3.1.3, all tested on Debian squeeze.

                                       Regards, Faheem

#################################################

import multiprocessing

class BadExc(Exception):
    def __init__(self, a):
        '''Non-optional param in the constructor.'''
        self.a = a

class GoodExc(Exception):
    def __init__(self, a=None):
        '''Optional param in the constructor.'''
        self.a = a

def do(kwargs):
    i = kwargs['i']
    print i
    raise BadExc('a')
    # raise GoodExc('a')
    return i

pool = multiprocessing.Pool(processes=5)
results = []
arglist = []
for i in range(10):
    arglist.append({'i':i})
r = pool.map_async(do, arglist, callback=results.append)
try:
    # set a timeout in order to be able to catch C-c
    r.get(1e100)
except KeyboardInterrupt:
    pass
print results

----------
components: Library (Lib)
messages: 150975
nosy: fmitha
priority: normal
severity: normal
status: open
title: multiprocessing.pool hangs if any worker raises an Exception whose constructor requires a parameter
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13751>
_______________________________________

From report at bugs.python.org  Tue Jan 10 02:40:24 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 10 Jan 2012 01:40:24 +0000
Subject: [New-bugs-announce] [issue13752] add a casefold() method
Message-ID: <1326159624.07.0.383633968301.issue13752@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

See http://mail.python.org/pipermail/python-ideas/2012-January/013292.html

----------
components: Unicode
messages: 150996
nosy: benjamin.peterson, ezio.melotti
priority: low
severity: normal
status: open
title: add a casefold() method
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13752>
_______________________________________

From report at bugs.python.org  Tue Jan 10 04:52:41 2012
From: report at bugs.python.org (py.user)
Date: Tue, 10 Jan 2012 03:52:41 +0000
Subject: [New-bugs-announce] [issue13753] str.join description contains an
	incorrect reference to	argument
Message-ID: <1326167561.64.0.37328706988.issue13753@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

http://docs.python.org/py3k/library/stdtypes.html#str.join

str.join(iterable)?

    Return a string which is the concatenation of the strings in the iterable iterable. A TypeError will be raised if there are any non-string values in seq, including bytes objects. The separator between elements is the string providing this method.


"non-string values in seq" -> "non-string values in iterable"

----------
assignee: docs at python
components: Documentation
messages: 150999
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: str.join description contains an incorrect reference to argument
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13753>
_______________________________________

From report at bugs.python.org  Tue Jan 10 04:59:55 2012
From: report at bugs.python.org (py.user)
Date: Tue, 10 Jan 2012 03:59:55 +0000
Subject: [New-bugs-announce] [issue13754] str.ljust and str.rjust do not
	exactly describes	original string return
Message-ID: <1326167995.85.0.0875969790457.issue13754@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

http://docs.python.org/py3k/library/stdtypes.html#str.ljust

str.ljust(width[, fillchar])?

    Return the string left justified in a string of length width. Padding is done using the specified fillchar (default is a space). The original string is returned if width is less than len(s).

str.rjust(width[, fillchar])?

    Return the string right justified in a string of length width. Padding is done using the specified fillchar (default is a space). The original string is returned if width is less than len(s).



"less than len(s)" -> "less than or equal to len(s)"

----------
assignee: docs at python
components: Documentation
messages: 151000
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: str.ljust and str.rjust do not exactly describes original string return
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13754>
_______________________________________

From report at bugs.python.org  Tue Jan 10 05:09:29 2012
From: report at bugs.python.org (py.user)
Date: Tue, 10 Jan 2012 04:09:29 +0000
Subject: [New-bugs-announce] [issue13755] str.endswith and str.startswith do
	not take lists of	strings
Message-ID: <1326168569.6.0.720816160315.issue13755@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> 'abcd'.endswith(['a', 'b'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'list' object to str implicitly
>>>

it would be nice like in str.join
>>> ''.join(('a', 'b'))
'ab'
>>> ''.join(['a', 'b'])
'ab'
>>> ''.join({'a', 'b'})
'ab'
>>> ''.join({'a': 1, 'b': 2})
'ab'
>>>

----------
components: Interpreter Core
messages: 151002
nosy: py.user
priority: normal
severity: normal
status: open
title: str.endswith and str.startswith do not take lists of strings
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13755>
_______________________________________

From report at bugs.python.org  Tue Jan 10 13:44:19 2012
From: report at bugs.python.org (Holger)
Date: Tue, 10 Jan 2012 12:44:19 +0000
Subject: [New-bugs-announce] [issue13756] Python3.2.2 make fail on cygwin
Message-ID: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za>


New submission from Holger <holger at bille.dk>:

Downloaded Python-3.2.2.tar
cd Python-3.2.2
./configure
make
....
Fail on:
--------------------
.....
ranlib libpython3.2m.a
make: *** No rule to make target `libpython3.2m.dll.a', needed by `python.exe'.  Stop.
--------------------

libpython3.2m.a was built successfully:
--------------------
$ ls -l libpython3.2m.a
-rw-r--r--+ 1 hbille Domain Users 7182050 Jan 10 13:31 libpython3.2m.a
--------------------

I am not sure which part is incorrect. The name with or without "dll"

----------
components: Installation
messages: 151014
nosy: holgerd00d
priority: normal
severity: normal
status: open
title: Python3.2.2 make fail on cygwin
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13756>
_______________________________________

From report at bugs.python.org  Tue Jan 10 19:56:52 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 10 Jan 2012 18:56:52 +0000
Subject: [New-bugs-announce] [issue13757] os.fdlistdir() should not close
	the file descriptor	given in argument
Message-ID: <1326221812.3.0.905477293867.issue13757@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

os.fdlistdir() closes the FD passed as argument.
This is annoying, since in 99% of the cases you'd like to keep FD intact, so you end up doing os.fdlistdir(os.dup(fd)).
Here's a patch that duplicates the FD in fdlistdir(), so that the original FD is kept intact, which is much more natural (at least to me :).
That's an API change, but since fdlistdir() has been introduced in 3.3 which hasn't been released yet, I think it should be acceptable.

----------
components: Extension Modules
files: fdlistdir_noclose.diff
keywords: patch
messages: 151023
nosy: neologix, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: os.fdlistdir() should not close the file descriptor given in argument
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24194/fdlistdir_noclose.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13757>
_______________________________________

From report at bugs.python.org  Wed Jan 11 04:46:44 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Jan 2012 03:46:44 +0000
Subject: [New-bugs-announce] [issue13758] compile() should not encode
	'filename' (at least on	Windows)
Message-ID: <1326253604.11.0.305060780894.issue13758@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The 3.2.2 doc for compile() says "The filename argument should give the file from which the code was read; pass some recognizable value if it wasn?t read from a file ('<string>' is commonly used)."

I am not sure what 'recognizable' is supposed to mean, but as I understand it, it would be user-specific and any string containing a fake 'filename' should be accepted and attached to the output code object as the .co_filename attribute. (At least on Windows.)

In fact, compile() has a hidden restriction: it encodes 'filename' with the local filesystem encoding. It tosses the bytes result (at least on Windows) but lets a UnicodeEncodeError terminate compilation. The effect is to add an undocumented and spurious dependency to code that has nothing to do with real files or the local machine.

In #10114, msg118845, Victor Stinner justified this with 
"co_filename attribute is used to display the traceback: Python opens the related file, read the source code line and display it."
If the filename is fake, it cannot do that. (Perhaps the doc should warn users to make sure that fake filenames do not match any possibly real filenames ;-). The traceback mechanism could ignore UnicodeEncodeErrors just as well as it now ignores IO(?)Errors when open('fakename') does not not work.

Victor continues "On Windows, co_filename is directly used because Windows accepts unicode for filenames." This is not true in that on at least some Windows, compile tries to encode with the mbcs codec, which in turn uses the hidden local codepage. I believe that for most or all codepages, this will even raise errors for some valid Unicode filenames.

I do not know whether the stored .co_filename attribute type for *nix is str, as on Windows, or bytes. If the latter, the doc should say so.
If compile() continues to filter fake filenames, which I oppose, the doc should also say so and say what it does.

This issue came up on python-list when someone used a Chinese filename and mbcs rejected it.

----------
components: Interpreter Core
messages: 151034
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: compile() should not encode 'filename' (at least on Windows)
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13758>
_______________________________________

From report at bugs.python.org  Wed Jan 11 08:36:56 2012
From: report at bugs.python.org (Atsushi Shibata)
Date: Wed, 11 Jan 2012 07:36:56 +0000
Subject: [New-bugs-announce] [issue13759] Python 3.2.2 Mac installer version
	doesn't accept	multibyte character in interactive mode
Message-ID: <1326267416.18.0.541225422796.issue13759@psf.upfronthosting.co.za>


New submission from Atsushi Shibata <shibata at webcore.co.jp>:

I installed Python 3.2.2 on Macintosh(Snow Leopard), by using installer on python.org.
In interactive mode, it does not accept multibyte character. When I type Japanese character on it, it changes to ?.
I tried to make Python 3.2.2 by using tar ball on the same machine. I can type Japanese character in interactive mode.
I guess it's because of some minor issue, such as compile option is different etc.

Thanks in advance.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 151035
nosy: ats, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 3.2.2 Mac installer version doesn't accept multibyte character in interactive mode
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13759>
_______________________________________

From report at bugs.python.org  Wed Jan 11 08:50:12 2012
From: report at bugs.python.org (Faheem Mitha)
Date: Wed, 11 Jan 2012 07:50:12 +0000
Subject: [New-bugs-announce] [issue13760] ConfigParser exceptions are not
	pickleable
Message-ID: <1326268212.81.0.448148296094.issue13760@psf.upfronthosting.co.za>


New submission from Faheem Mitha <faheem at faheem.info>:

I have not experienced this myself, but see
http://stackoverflow.com/questions/2246384/multiprocessing-pool-hangs-when-there-is-a-exception-in-any-of-the-thread

This appears to be another case of http://bugs.python.org/issue1692335

I also recently reported a similar problem at http://bugs.python.org/issue13751

Looking at the code for `NoOptionError` (see below) in 2.6 at least it would indeed be subject to the same problem. Perhaps some attention could be paid to 
resolving 1692335, which would presumably make this vexing problem go away?

class NoOptionError(Error):
    """A requested option was not found."""

    def __init__(self, option, section):
        Error.__init__(self, "No option %r in section: %r" %
                       (option, section))
        self.option = option
        self.section = section

----------
components: Library (Lib)
messages: 151036
nosy: fmitha
priority: normal
severity: normal
status: open
title: ConfigParser exceptions are not pickleable
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13760>
_______________________________________

From report at bugs.python.org  Wed Jan 11 09:24:42 2012
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 11 Jan 2012 08:24:42 +0000
Subject: [New-bugs-announce] [issue13761] Add flush keyword to print()
Message-ID: <1326270282.71.0.886382293128.issue13761@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Add a flush keyword argument to print(), defaulting to False. If true, output will be flushed immediately.

See http://mail.python.org/pipermail/python-ideas/2012-January/013340.html

----------
assignee: georg.brandl
components: Interpreter Core
keywords: easy
messages: 151041
nosy: georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: Add flush keyword to print()
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13761>
_______________________________________

From report at bugs.python.org  Wed Jan 11 11:08:17 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 11 Jan 2012 10:08:17 +0000
Subject: [New-bugs-announce] [issue13762] missing section: how to contribute
	to devguide
Message-ID: <1326276497.12.0.812256237013.issue13762@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I struggled to find how to contribute to the devguide. I even struggled to find where the VCS is. I think it would be kool if there was a section for this info (it's not always fun to search the intertubes).

----------
components: Devguide
messages: 151049
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: missing section: how to contribute to devguide
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13762>
_______________________________________

From report at bugs.python.org  Wed Jan 11 11:41:27 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 11 Jan 2012 10:41:27 +0000
Subject: [New-bugs-announce] [issue13763] rm obsolete reference in devguide
Message-ID: <1326278487.37.0.199929224509.issue13763@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

this line:

"commonly abbreviated svn, after the program name"

was once changed to:

"commonly abbreviated hg, after the program name"

and it no longer makes sense

----------
components: Devguide
files: rm-obsolete-reference.patch
keywords: patch
messages: 151051
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: rm obsolete reference in devguide
Added file: http://bugs.python.org/file24200/rm-obsolete-reference.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13763>
_______________________________________

From report at bugs.python.org  Wed Jan 11 11:48:22 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 11 Jan 2012 10:48:22 +0000
Subject: [New-bugs-announce] [issue13764] Misc/build.sh is outdated... talks
	about svn
Message-ID: <1326278902.44.0.401175449456.issue13764@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I am wondering what else is outdated in that file. Is it still useful?

----------
components: Build
messages: 151052
nosy: tshepang
priority: normal
severity: normal
status: open
title: Misc/build.sh is outdated... talks about svn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13764>
_______________________________________

From report at bugs.python.org  Wed Jan 11 11:53:27 2012
From: report at bugs.python.org (Almar Klein)
Date: Wed, 11 Jan 2012 10:53:27 +0000
Subject: [New-bugs-announce] [issue13765] Distutils does not put quotes
	around paths that contain	spaces when compiling with MSVC
Message-ID: <1326279207.66.0.00870443648881.issue13765@psf.upfronthosting.co.za>


New submission from Almar Klein <almar.klein at gmail.com>:

I found an easy to solve bug in distutils, which is causing problems with compiling Cython code on Windows. I have reproduced this on Python 2.6 and Python 3.2 (32 bit).

The problem occurs with the native msvc compiler. Using gcc (MinGW) works fine.

The problem is that the command to link the libraries does not put double quotes around paths that have spaces in them. Unfortunately, the path where I have Python installed has spaces in it ("c:/program files/python26"). Small example of part of a link command: 

/LIBPATH:C:\Program Files (x86)\python32\libs. 

Note that the include_dirs DO have double quotes around them.

The problem is easily solved (I confirmed this) by a small change in msvc9compiler.py and msvccompiler.py (see also the patch):

def library_dir_option(self, dir):  # OLD VERSION
     return "/LIBPATH:" + dir

def library_dir_option(self, dir): # FIXED VERSION
    if ' ' in dir and not dir.startswith('"'):
        dir = '"%s"' % dir
    return "/LIBPATH:" + dir

I tried to see if it would be nicer to apply a change elsewhere, e.g. where library_dir_option() is called. However, it is called nowhere from within the distutils package. In my case I suspect numpy.distutils or a part of Cython calls it. Anyway, in my opinion you should be able to pass this function a dirname that has a space in it, and get the right (partial) command. For the record, this change is quite safe because it checks whether quotes are already present. 


===== Below follows a minimal Cython example and traceback =====

===== test_.pyx
def foo():
print('hello')


===== setup.py
import os, sys
from Cython.Distutils import build_ext
from distutils.core import setup
from distutils.extension import Extension
from numpy.distutils.misc_util import get_numpy_include_dirs

# Ugly hack so I can run setup.py in my IDE
sys.argv = ['setup.py', 'build_ext', '--inplace']

# Init include dirs
include_dirs = ['.']
include_dirs.extend(get_numpy_include_dirs())

# Creat Extensions
ext_modules = [
     Extension('test_', ['test_.pyx'],
        include_dirs=include_dirs,
        ),
     ]

# Compile
setup(
    cmdclass = {'build_ext': build_ext},
    ext_modules = ext_modules,
    )

print('Successfully compiled cython file: test_')


===== output when running setup.py
running build_ext
No module named msvccompiler in numpy.distutils; trying from distutils
cythoning test_.pyx to test_.c
building 'test_' extension
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -I. -I"C:\Program Files (x86)\python32\lib\site-packages\numpy\core\include" -I"C:\Program Files (x86)\python32\include" -I"C:\Program Files (x86)\python32\PC" /Tctest_.c /Fobuild\temp.win32-3.2\Release\test_.obj
Found executable C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Program Files (x86)\python32\libs /LIBPATH:C:\Program Files (x86)\python32\PCbuild /EXPORT:PyInit_test_ build\temp.win32-3.2\Release\test_.obj /OUT:C:\almar\projects\py\cmu1394\test_.pyd /IMPLIB:build\temp.win32-3.2\Release\test_.lib /MANIFESTFILE:build\temp.win32-3.2\Release\test_.pyd.manifest
Found executable C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe
LINK : fatal error LNK1181: cannot open input file 'Files.obj'

----------
assignee: tarek
components: Distutils
files: distutils_spaces_in_libdir.patch
keywords: patch
messages: 151054
nosy: almar, eric.araujo, mhammond, tarek
priority: normal
severity: normal
status: open
title: Distutils does not put quotes around paths that contain spaces when compiling with MSVC
type: behavior
versions: Python 2.6, Python 3.2
Added file: http://bugs.python.org/file24201/distutils_spaces_in_libdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13765>
_______________________________________

From report at bugs.python.org  Wed Jan 11 11:59:14 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 11 Jan 2012 10:59:14 +0000
Subject: [New-bugs-announce] [issue13766] explain the relationship between
	Lib/lib2to3/Grammar.txt	and Grammar/Grammar
Message-ID: <1326279554.15.0.713951578682.issue13766@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

Lib/lib2to3/Grammar.txt seems like a modified copy of Grammar/Grammar. Can you state so somewhere, maybe in the beginning of Lib/lib2to3/Grammar.txt (the Note section).

One problem with the way it is now, is that there are changes done to Grammar/Grammar that are not put into Lib/lib2to3/Grammar.txt. Maybe they are minor, but I think we don't want them diverging too much.

Another problem is that the Note on Lib/lib2to3/Grammar.txt maybe irrelevant, since this is not the authoritative Grammar file.

----------
assignee: docs at python
components: Documentation
messages: 151055
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: explain the relationship between Lib/lib2to3/Grammar.txt and Grammar/Grammar
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13766>
_______________________________________

From report at bugs.python.org  Wed Jan 11 14:24:52 2012
From: report at bugs.python.org (Zaheer Merali)
Date: Wed, 11 Jan 2012 13:24:52 +0000
Subject: [New-bugs-announce] [issue13767] Would be nice to have a future
	import that turned off	old except style
Message-ID: <1326288292.54.0.187974704865.issue13767@psf.upfronthosting.co.za>


New submission from Zaheer Merali <zaheermerali at gmail.com>:

It would be nice to have a future import to be able to prevent people in code doing:

try:
    ....
except Exception, e:
    ....

and make people do:

try:
    ....
except Exception as e:
    ....

----------
components: Interpreter Core
messages: 151058
nosy: Zaheer.Merali
priority: normal
severity: normal
status: open
title: Would be nice to have a future import that turned off old except style
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13767>
_______________________________________

From report at bugs.python.org  Wed Jan 11 16:12:50 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 11 Jan 2012 15:12:50 +0000
Subject: [New-bugs-announce] [issue13768] Doc/tools/dailybuild.py available
	only on 2.7 branch
Message-ID: <1326294770.64.0.354971567958.issue13768@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: tshepang
priority: normal
severity: normal
status: open
title: Doc/tools/dailybuild.py available only on 2.7 branch
versions: Python 2.6, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13768>
_______________________________________

From report at bugs.python.org  Wed Jan 11 17:41:19 2012
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 11 Jan 2012 16:41:19 +0000
Subject: [New-bugs-announce] [issue13769] json.dump(ensure_ascii=False)
	return str instead of	unicode
Message-ID: <1326300079.82.0.279410736545.issue13769@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

$ ipython
In [1]: type(json.dumps({'a':'b'}, ensure_ascii=False))
Out[1]: <type 'str'>

In [2]: type(json.dumps({'a':u'b'}, ensure_ascii=False))
Out[2]: <type 'unicode'>
-----------------------
Documentation:
If ensure_ascii is False, then the return value will be a unicode instance.
--------------------------------

Not applicable to python3

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 151066
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: json.dump(ensure_ascii=False) return str instead of unicode
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13769>
_______________________________________

From report at bugs.python.org  Wed Jan 11 17:42:11 2012
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 11 Jan 2012 16:42:11 +0000
Subject: [New-bugs-announce] [issue13770] python3 & json: add ensure_ascii
	documentation
Message-ID: <1326300131.17.0.750918490995.issue13770@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

Please fix documentation about ensure_ascii. Does it have any meaning in python3?

----------
assignee: docs at python
components: Documentation
messages: 151067
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: python3 & json: add ensure_ascii documentation
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13770>
_______________________________________

From report at bugs.python.org  Wed Jan 11 18:53:11 2012
From: report at bugs.python.org (Michael Mulich)
Date: Wed, 11 Jan 2012 17:53:11 +0000
Subject: [New-bugs-announce] [issue13771] HTTPSConnection __init__ super
	implementation causes	recursion error
Message-ID: <1326304391.56.0.972578337686.issue13771@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

While working on porting wsgi_intercept to Python 3 I came across a recursion issue with http.client.HTTPSConnection. The following is an lesser extraction of the traceback:


Traceback (most recent call last):
  File ".../wsgi_intercept/test/test_httplib.py", line 28, in test_success
    http = self.make_one(self.domain)
  File ".../wsgi_intercept/test/test_httplib.py", line 40, in make_one
    return http.client.HTTPSConnection(*args)
  File ".../lib/python3.2/http/client.py", line 1075, in __init__
    source_address)
  ...
  File ".../lib/python3.2/http/client.py", line 1075, in __init__
    source_address)
  File ".../lib/python3.2/http/client.py", line 1074, in __init__
    super(HTTPSConnection, self).__init__(host, port, strict, timeout,
RuntimeError: maximum recursion depth exceeded while calling a Python object

Some background information is necessary to explain what is happening here. One, this is a traceback from a test method (make_one) which makes and https connection. Two, wsgi_intercept has overridden http.client.HTTPSConnection with a class that subclasses HTTPSConnection and overrides a few methonds. For more general information, see the PyPI page (http://pypi.python.org/pypi/wsgi_intercept). 

After the wsgi_intercept behavior is invoked the __mro__ of http.client.HTTPSConnection becomes: (<class 'wsgi_intercept.WSGI_HTTPSConnection'>, <class 'http.client.HTTPSConnection'>, <class 'http.client.HTTPConnection'>, <class 'object'>). Because of this we end up recursively running the __init__.

Possible solutions:

1) Fix the issue in http/client.py:1074 by replacing "super(HTTPSConnection, self)" with "super()", which if I'm not mistaken is the recommended usage of super in Python 3.
2) Fix the issue in the wsgi_intercept package.

I was successful with both approaches, but applying the second fix would make the maintenance of wsgi_intercept slightly harder because of the code duplication and round-about-way of calling its parent classes.

----------
components: None
messages: 151072
nosy: michael.mulich
priority: normal
severity: normal
status: open
title: HTTPSConnection __init__ super implementation causes recursion error
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13771>
_______________________________________

From report at bugs.python.org  Wed Jan 11 21:01:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jan 2012 20:01:14 +0000
Subject: [New-bugs-announce] [issue13772] listdir() doesn't work with
	non-trivial symlinks
Message-ID: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Note how _getfinalpathname works and calling listdir on the final path name also works:

>>> os.symlink(".\\test", "Lib\\bar")
>>> os.listdir("Lib\\bar")[:4]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotADirectoryError: [Error 267] The directory name is invalid: 'Lib\\bar\\*.*'

>>> nt._getfinalpathname("Lib\\bar")
'\\\\?\\C:\\t\\pathlib\\Lib\\test'
>>> os.listdir(nt._getfinalpathname("Lib\\bar"))[:4]
['185test.db', 'audiotest.au', 'autotest.py', 'badcert.pem']

Calling listdir on the non-final extended path doesn't work:

>>> os.listdir('\\\\?\\C:\\t\\pathlib\\Lib\\bar')[:4]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotADirectoryError: [Error 267] The directory name is invalid: '\\\\?\\C:\\t\\pa
thlib\\Lib\\bar\\*.*'

But open() works:

>>> open('Lib\\bar\\regrtest.py')
<_io.TextIOWrapper name='Lib\\bar\\regrtest.py' mode='r' encoding='cp1252'>

----------
components: Library (Lib), Windows
messages: 151087
nosy: amaury.forgeotdarc, brian.curtin, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: listdir() doesn't work with non-trivial symlinks
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Wed Jan 11 21:33:18 2012
From: report at bugs.python.org (poq)
Date: Wed, 11 Jan 2012 20:33:18 +0000
Subject: [New-bugs-announce] [issue13773] Support sqlite3 uri filenames
Message-ID: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>


New submission from poq <poq at gmx.com>:

URIs are an extensible way to pass options to SQLite. See:
http://www.sqlite.org/uri.html

Patch adds a keyword argument "uri" to sqlite3.connect which causes the filename to be parsed as a URI if set to True.

----------
components: Extension Modules
files: sqlite-uri.patch
keywords: patch
messages: 151089
nosy: poq
priority: normal
severity: normal
status: open
title: Support sqlite3 uri filenames
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24205/sqlite-uri.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13773>
_______________________________________

From report at bugs.python.org  Thu Jan 12 01:48:10 2012
From: report at bugs.python.org (Julian Berman)
Date: Thu, 12 Jan 2012 00:48:10 +0000
Subject: [New-bugs-announce] [issue13774] json.loads raises a SystemError
	for invalid encoding on	2.7.2
Message-ID: <1326329290.58.0.508357217155.issue13774@psf.upfronthosting.co.za>


New submission from Julian Berman <Julian+Python.org at GrayVines.com>:

>>> import json
>>> json.loads("{}", [1, 2, 3])
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/usr/local/Cellar/python/2.7.2/lib/python2.7/json/__init__.py", line 339, in loads
    return cls(encoding=encoding, **kw).decode(s)
  File "/usr/local/Cellar/python/2.7.2/lib/python2.7/json/decoder.py", line 359, in __init__
    self.scan_once = scanner.make_scanner(self)
SystemError: NULL result without error in PyObject_Call

Python 3.2 and 2.6 are not affected it'd seem, so it looks to be 2.7 only.

----------
components: Library (Lib)
messages: 151100
nosy: Julian
priority: normal
severity: normal
status: open
title: json.loads raises a SystemError for invalid encoding on 2.7.2
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13774>
_______________________________________

From report at bugs.python.org  Thu Jan 12 02:06:48 2012
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 12 Jan 2012 01:06:48 +0000
Subject: [New-bugs-announce] [issue13775] Access Denied message on symlink
	creation misleading for	an existing file/directory target.
Message-ID: <1326330408.97.0.484457419227.issue13775@psf.upfronthosting.co.za>


New submission from Santoso Wijaya <santoso.wijaya at gmail.com>:

Consider:

>>> os.symlink('.\\test', 'Lib\\bar')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 5] Access is denied: '.\\test'

Where Lib\\bar is previously created. The symlink creation is rightly rejected, but with a misleading message. The failure is because 'Lib\\bar' already exists, not because of '.\\test'.

----------
components: Windows
messages: 151101
nosy: santa4nt
priority: normal
severity: normal
status: open
title: Access Denied message on symlink creation misleading for an existing file/directory target.
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13775>
_______________________________________

From report at bugs.python.org  Thu Jan 12 16:15:18 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 12 Jan 2012 15:15:18 +0000
Subject: [New-bugs-announce] [issue13776] formatter_unicode.c still assumes
	ASCII
Message-ID: <1326381318.07.0.368656319142.issue13776@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

http://docs.python.org/library/string.html#format-specification-mini-language defines

    fill        ::=  <a character other than '}'>

and the text also excludes '{'.  It does not require that the fill character be ASCII.

However, function parse_internal_render_format_spec 
http://hg.python.org/cpython/file/c2153ce1b5dd/Python/formatter_unicode.c#l277 raises a ValueError if fill_char > 127.

I'm honestly not certain which of the three is correct, but they should be consistent, and if anything but '{' is excluded, it would be best to explain why.

----------
components: Unicode
messages: 151128
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: formatter_unicode.c still assumes ASCII
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13776>
_______________________________________

From report at bugs.python.org  Thu Jan 12 19:16:32 2012
From: report at bugs.python.org (Michael Goderbauer)
Date: Thu, 12 Jan 2012 18:16:32 +0000
Subject: [New-bugs-announce] [issue13777] socket: communicating with Mac OS
	X KEXT controls
Message-ID: <1326392192.39.0.824287439397.issue13777@psf.upfronthosting.co.za>


New submission from Michael Goderbauer <contact at m-goderbauer.de>:

Mac OS X provides a socket-based API to communicate with Kernel Extensions (KEXTs) called "KEXT Controls". For this, Mac OS X defines PF_SYSTEM as a new socket domain which supports the SYSPROTO_CONTROL protocol.

Right now the PF_SYSTEM domain and the SYSPROTO_CONTROL protocol are not supported by Python's socket module. I am attaching a patch that introduces support for both.

More information on KEXT Controls can be found here:
http://developer.apple.com/library/mac/documentation/Darwin/Conceptual/NKEConceptual/control/control.html

----------
components: Extension Modules
files: kext.patch
keywords: patch
messages: 151145
nosy: goderbauer
priority: normal
severity: normal
status: open
title: socket: communicating with Mac OS X KEXT controls
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24220/kext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13777>
_______________________________________

From report at bugs.python.org  Fri Jan 13 10:24:58 2012
From: report at bugs.python.org (lesha)
Date: Fri, 13 Jan 2012 09:24:58 +0000
Subject: [New-bugs-announce] [issue13778] Python should invalidate all
	non-owned 'thread.lock'	objects when forking
Message-ID: <1326446698.28.0.760510427025.issue13778@psf.upfronthosting.co.za>


New submission from lesha <pybug.20.lesha at xoxy.net>:

Here is a great description of the issue:

http://docs.oracle.com/cd/E19683-01/806-6867/gen-1/index.html


This enhancement proposes a way to make Python more resistant to this kind of deadlock.


Consider this program:


import threading
import subprocess
import time

l = threading.Lock() 

def f():
    l.acquire()  
    time.sleep(1)
    l.release()
 
t = threading.Thread(target=f)
t.start()

def g(l):
    l.acquire()
    l.release() 
    print 'ohai'


subprocess.Popen(['ls'], preexec_fn=lambda: g(l))



g() gets called in the forked process, which means that it's waiting on a *copy* of the lock, which can never get released.


This, in turn, means that the main thread will forever wait for the Popen to finish.



The program above incorrectly assumes that a threading lock can be shared across fork() parent and child.

I suspect adding such sharing is impractical, requiring OS support or excessive complexity. If the sharing could be had cheaply, it would be great -- programs like this would work as intended, but no other programs would break. 

Crazy idea: free the locks. Sadly, that is not safe! The ones that are currently locked by other threads might be protecting some network resource, and allowing the fork child to access them would result in a logical error.

However, it is always a bad idea for a fork() child to access a lock that is held by a thread that is not its fork() parent. That lock was locked at the time of the fork(), and will stay locked, because the child process will not get updated by the lock-holding threads.

So, it is always invalid to access that type of lock. Currently, you are guaranteed a deadlock.

Proposal: trying to acquire such a lock should crash the forked child with a nice, detailed error message (including the offending lock), rather than hang the entire program.

Sample steps to implement:

1) Store the process ID on each lock instance.
2) Acquire/release should crash if the lock does not belong to the current thread AND has a different process ID from the current one.

There are other potential implementations, such as explicitly enumerating such locks at the time of fork, and invalidating them.

This crash cannot be an exception in the child, because lock methods must not throw. However, it can and should be an exception in the fork() parent.

I think this enhancement would make it much easier to debug this kind of problem. It's an easy mistake to make, because preexec_fn or fork docs do not warn you of the danger, and locks can be acquired quite implicitly by innocent-looking code.

----------
components: Library (Lib)
messages: 151165
nosy: lesha
priority: normal
severity: normal
status: open
title: Python should invalidate all non-owned 'thread.lock' objects when forking
type: enhancement
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13778>
_______________________________________

From report at bugs.python.org  Fri Jan 13 12:03:09 2012
From: report at bugs.python.org (patrick vrijlandt)
Date: Fri, 13 Jan 2012 11:03:09 +0000
Subject: [New-bugs-announce] [issue13779] os.walk: bottom-up
Message-ID: <1326452589.73.0.0617213643117.issue13779@psf.upfronthosting.co.za>


New submission from patrick vrijlandt <patrick.vrijlandt at gmail.com>:

PythonWin 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information.
>>> import os
>>> os.makedirs("g:/a/b/c")
>>> os.listdir("g:/a")
['b']
>>> for root, dirs, files in os.walk("g:/a", topdown = False):
... 	print(root, dirs, files, os.listdir(root))
... 	os.rmdir(root)
... 	
g:/a\b\c [] [] []
g:/a\b ['c'] [] []
g:/a ['b'] [] []
>>> 

>From the documentation of os.walk:
If topdown is False, the triple for a directory is generated after the triples for all of its subdirectories (directories are generated bottom-up).

As the above example shows, the directories are generated in the correct order, "generated" referring to yield from generator os.walk. However, the generated (files? and) dirs do not necessarily reflect the current situation as produced by os.listdir.

Therefore, this does not clear the entire directory tree as I would expect.

>>> os.makedirs("g:/a/b/c")
>>> for root, dirs, files in os.walk("g:/a", topdown = False):
... 	print(root, dirs, files, os.listdir(root))	
... 	if not (files + dirs):
... 	    os.rmdir(root)
... 
g:/a\b\c [] [] []
g:/a\b ['c'] [] []
g:/a ['b'] [] ['b']

I think that at least the documentation should be more clear on this issue. I would like even better, if files + dirs would match os.listdir on the moment they are generated (=yielded).

----------
assignee: docs at python
components: Documentation
messages: 151169
nosy: docs at python, patrick.vrijlandt
priority: normal
severity: normal
status: open
title: os.walk: bottom-up
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13779>
_______________________________________

From report at bugs.python.org  Fri Jan 13 14:48:28 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 13 Jan 2012 13:48:28 +0000
Subject: [New-bugs-announce] [issue13780] make YieldFrom its own node
Message-ID: <1326462508.45.0.280954945804.issue13780@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

As promised in a review a while ago of PEP 380.

----------
files: yieldfromnode.patch
keywords: patch
messages: 151172
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: make YieldFrom its own node
Added file: http://bugs.python.org/file24227/yieldfromnode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13780>
_______________________________________

From report at bugs.python.org  Fri Jan 13 23:31:56 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 13 Jan 2012 22:31:56 +0000
Subject: [New-bugs-announce] [issue13781] gzip module does the wrong thing
	with an os.fdopen()'ed	fileobj
Message-ID: <1326493916.44.0.574522946696.issue13781@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

gzip.GzipFile accepts a fileobj parameter with an open file object.

Unfortunately gzip requires a filename be embedded in the gzip file and the gzip module code uses fileobj.name to get that.

This results in the fake "<fdopen>" name from posixmodule.c being embedded in the output gzipped file when using Python 2.x.  This causes problems when ungzipping these files with gzip -d or ungzip implementations that always rely on the embedded filename when writing their output file rather than stripping a suffix from the input filename as they cannot open a file called "<fdopen>" or if they do, each successive ungzip overwrites the previous...


On Python 3.x the problem is different, the gzip module fails entirely when given an os.fdopen()'ed file object:


$ ./python gzip_fdopen_prob.py 
out_file <_io.BufferedWriter name='FOO.gz'>
out_fd 3
fd_out_file <_io.BufferedWriter name=3>
fd_out_file.name 3
Traceback (most recent call last):
  File "gzip_fdopen_prob.py", line 13, in <module>
    gz_out_file = gzip.GzipFile(fileobj=fd_out_file)
  File "/home/gps/oss/cpython/default/Lib/gzip.py", line 184, in __init__
    self._write_gzip_header()
  File "/home/gps/oss/cpython/default/Lib/gzip.py", line 221, in _write_gzip_header
    fname = os.path.basename(self.name)
  File "/home/gps/oss/cpython/default/Lib/posixpath.py", line 132, in basename
    i = p.rfind(sep) + 1
AttributeError: 'int' object has no attribute 'rfind'

(code attached)

The os.fdopen()'ed file object is kindly using the integer file descriptor as its .name attribute.  That might or might not be an issue, but regardless of that:

1) GzipFile should not fail in this case.
2) GzipFile should never embed a fake made up filename in its output.

Fixing the gzip module to catch errors and use an empty b'' filename for the gzip code in the above error is easy.

What should be done about the .name attribute on fake file objects?  I don't think it should exist at all.

(another quick test shows that gzip in python 3.x can't output to a BytesIO fileobj at all, it thinks it is readonly)

----------
files: gzip_fdopen_prob.py
messages: 151203
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: gzip module does the wrong thing with an os.fdopen()'ed fileobj
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24228/gzip_fdopen_prob.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13781>
_______________________________________

From report at bugs.python.org  Sat Jan 14 01:54:13 2012
From: report at bugs.python.org (John Machin)
Date: Sat, 14 Jan 2012 00:54:13 +0000
Subject: [New-bugs-announce] [issue13782] xml.etree.ElementTree:
	Element.append doesn't type-check	its argument
Message-ID: <1326502453.32.0.206779556991.issue13782@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at lexicon.net>:

import xml.etree.ElementTree as et
node = et.Element('x')
node.append(not_an_Element_instance)

2.7 and 3.2 produce no complaint at all.
2.6 and 3.1 produce an AssertionError.

However cElementTree in all 4 versions produces a TypeError.

Please fix 2.7 and 3.2 ElementTree to produce a TypeError.

----------
messages: 151210
nosy: sjmachin
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree: Element.append doesn't type-check its argument
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13782>
_______________________________________

From report at bugs.python.org  Sat Jan 14 07:19:47 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Jan 2012 06:19:47 +0000
Subject: [New-bugs-announce] [issue13783] Clean up PEP 380 C API additions
Message-ID: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Georg noted that the PEP 380 patch added a couple of new C interfaces without documenting them. These interfaces need to be either:
1. Documented;
2. Made private; or
3. Removed (if they're completely trivial)

PyGen_FetchStopIterationValue: probably document, explicitly noting that it also clears the StopIteration exception from the thread state

PyStopIteration_Create: probably remove

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 151235
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Clean up PEP 380 C API additions
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13783>
_______________________________________

From report at bugs.python.org  Sat Jan 14 13:02:14 2012
From: report at bugs.python.org (patrick vrijlandt)
Date: Sat, 14 Jan 2012 12:02:14 +0000
Subject: [New-bugs-announce] [issue13784] Documentation of
	xml.sax.xmlreader:	Locator.getLineNumber() and
	Locator.getColumnNumber()
Message-ID: <1326542534.95.0.205057982858.issue13784@psf.upfronthosting.co.za>


New submission from patrick vrijlandt <patrick.vrijlandt at gmail.com>:

Problem:
Locator methods return the location where the event starts, not where it ends.
Locator line numbers start at 1, Locator column numbers can be 0.

Proposal:
Adapt documentation.

>From the docs:
Instances of Locator provide these methods:

Locator.getColumnNumber() 
Return the column number where the current event ends.

Locator.getLineNumber() 
Return the line number where the current event ends

My Test:

import xml.sax

data = b"""<main>
    <sub
        attr="1"
        id="name"
        >
        <subsub />
    </sub>
</main>"""


class MyHandler(xml.sax.handler.ContentHandler):

    def startElement(self, name, attrs):
        if name == "sub":
            print("open", name, self._locator.getLineNumber(), self._locator.getColumnNumber())
            
    def endElement(self, name):
        if name == "sub":
            print("close", name, self._locator.getLineNumber(), self._locator.getColumnNumber())

xml.sax.parseString(data, MyHandler())

Output:

open sub 2 4
close sub 7 4

----------
assignee: docs at python
components: Documentation, XML
messages: 151247
nosy: docs at python, patrick.vrijlandt
priority: normal
severity: normal
status: open
title: Documentation of  xml.sax.xmlreader: Locator.getLineNumber() and Locator.getColumnNumber()
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13784>
_______________________________________

From report at bugs.python.org  Sat Jan 14 18:07:15 2012
From: report at bugs.python.org (Juan Javier)
Date: Sat, 14 Jan 2012 17:07:15 +0000
Subject: [New-bugs-announce] [issue13785] Make concurrent.futures.Future
	state public
Message-ID: <1326560835.55.0.282912980665.issue13785@psf.upfronthosting.co.za>


New submission from Juan Javier <jjdominguezm at gmail.com>:

Hello,

This is a proposal to make the state of Future objects public.

The idea is to have access to the current state of the Future using a property instead of calling several methods (done, cancelled, etc.).

Also, a history property that returns a list of Event(state, timestamp) objects is written, the list stores the timestamp every time the state of a future changes.

There is a patch attached to the issue.

Regards.

----------
components: Library (Lib)
files: concurrent.futures.Future.state_public.patch
keywords: patch
messages: 151259
nosy: bquinlan, jjdominguezm
priority: normal
severity: normal
status: open
title: Make concurrent.futures.Future state public
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24237/concurrent.futures.Future.state_public.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13785>
_______________________________________

From report at bugs.python.org  Sat Jan 14 18:42:52 2012
From: report at bugs.python.org (Meador Inge)
Date: Sat, 14 Jan 2012 17:42:52 +0000
Subject: [New-bugs-announce] [issue13786] regrtest.py does not handle --trace
Message-ID: <1326562972.28.0.512194843439.issue13786@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

While fixing issue13725 I noticed that there is a long option for 'trace', but it is not actually handled:

[meadori at motherbrain cpython]$ ./python -m test --trace
No handler for option --trace.  Please report this as a bug at http://bugs.python.org.

I will commit the attached patch shortly.

----------
assignee: meador.inge
components: Tests
files: regrtest-remove-unhandled-trace-longoption.patch
keywords: easy, patch
messages: 151260
nosy: meador.inge
priority: low
severity: normal
stage: commit review
status: open
title: regrtest.py does not handle --trace
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24238/regrtest-remove-unhandled-trace-longoption.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13786>
_______________________________________

From report at bugs.python.org  Sun Jan 15 01:33:11 2012
From: report at bugs.python.org (Mahmoud Hashemi)
Date: Sun, 15 Jan 2012 00:33:11 +0000
Subject: [New-bugs-announce] [issue13787] PyCode_New not round-trippable
	(TypeError)
Message-ID: <1326587591.5.0.14837599409.issue13787@psf.upfronthosting.co.za>


New submission from Mahmoud Hashemi <makuro at gmail.com>:

On Python 3.1.4, attempting to create a code object will apparently result in a TypeError (must be str, not tuple), even when you're creating a code object from another, working code object:

# co_what.py
def foo():
    return 'bar'

co = foo.__code__

co_copy = type(co)(co.co_argcount,
                   co.co_kwonlyargcount,
                   co.co_nlocals,
                   co.co_stacksize,
                   co.co_flags,
                   co.co_code,
                   co.co_consts,
                   co.co_names,
                   co.co_varnames,
                   co.co_freevars,
                   co.co_cellvars,
                   co.co_filename,
                   co.co_name,
                   co.co_firstlineno,
                   co.co_lnotab)
# EOF
$ python3 co_what.py
Traceback (most recent call last):
  File "co_what.py", line 20, in <module>
    co.co_lnotab)
TypeError: must be str, not tuple

Looking at the PyCode_New function, all the arguments look correctly matched up according to the signature in my Python 3.1.4 build source (looks identical to the trunk source):

# Objects/codeobject.c

PyCode_New(int argcount, int kwonlyargcount,
           int nlocals, int stacksize, int flags,
           PyObject *code, PyObject *consts, PyObject *names,
           PyObject *varnames, PyObject *freevars, PyObject *cellvars,
           PyObject *filename, PyObject *name, int firstlineno,
           PyObject *lnotab)
{
    PyCodeObject *co;
    Py_ssize_t i;

    /* Check argument types */
    if (argcount < 0 || nlocals < 0 ||
        code == NULL ||
        consts == NULL || !PyTuple_Check(consts) ||
        names == NULL || !PyTuple_Check(names) ||
        varnames == NULL || !PyTuple_Check(varnames) ||
        freevars == NULL || !PyTuple_Check(freevars) ||
        cellvars == NULL || !PyTuple_Check(cellvars) ||
        name == NULL || !PyUnicode_Check(name) ||
        filename == NULL || !PyUnicode_Check(filename) ||
        lnotab == NULL || !PyBytes_Check(lnotab) ||
        !PyObject_CheckReadBuffer(code)) {
        PyErr_BadInternalCall();
        return NULL;
    }

And, for the record, this same behavior works just fine in the equivalent Python 2.

----------
components: Interpreter Core
files: co_what.py
messages: 151270
nosy: mahmoud
priority: normal
severity: normal
status: open
title: PyCode_New not round-trippable (TypeError)
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file24239/co_what.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13787>
_______________________________________

From report at bugs.python.org  Sun Jan 15 05:29:25 2012
From: report at bugs.python.org (Ferringb)
Date: Sun, 15 Jan 2012 04:29:25 +0000
Subject: [New-bugs-announce] [issue13788] os.closerange optimization
Message-ID: <1326601765.34.0.310008166629.issue13788@psf.upfronthosting.co.za>


New submission from Ferringb <ferringb at gmail.com>:

The current implementation of closerange essentially is a bruteforce invocation of close for every integer in the range.

While this works, it's rather noisy for stracing, and for most invocations, is near a thousand close invocations more than needed.

As such it should be aware of /proc/${PID}/fd, and use that to isolate down just what is actually open, and close that.

----------
components: Extension Modules
files: closerange-optimization.patch
keywords: patch
messages: 151273
nosy: ferringb
priority: normal
severity: normal
status: open
title: os.closerange optimization
type: performance
Added file: http://bugs.python.org/file24241/closerange-optimization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13788>
_______________________________________

From report at bugs.python.org  Sun Jan 15 05:59:16 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Jan 2012 04:59:16 +0000
Subject: [New-bugs-announce] [issue13789] _tkinter does not build on Windows
	7
Message-ID: <1326603556.49.0.117233546142.issue13789@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Modules/_tkinter.py #includes Modules/tkinter.h, tcl.h, and tk.h. The latter two #include tclDecls.h, tclPlatDecls.h, and tkDecls.h. I obtained 8.5.9 versions of all 5 and added them to Include/. Although they came from Ubuntu, they appear to be cross-platform in that they look for Mac and Win defines. They make the corresponding build errors go away. However, one remains: a failure to open X11/Xlib.h.

This must come from the following in tk.h:
#ifndef RC_INVOKED
#ifndef _XLIB_H
#   if defined(MAC_OSX_TK)
#    include <X11/Xlib.h>
#    include <X11/X.h>
#   else
#    include <X11/Xlib.h>
#   endif
#endif
#ifdef __STDC__
#   include <stddef.h>
#endif

It seems this tk.h header, at least, expects RC_INVOKED to be defined on non-X11 platforms. Something here is crucially different than on the machine that builds Python for windows. The version of tk.h? the absence of X11/xlib.h? the pcbuild stuff? or the Visual Studio version?

I tried to compile PCbuild/pcbuild.sln with VC2008 Express in the 3.3, 3.2, and 2.7 repositories. For 3.3, I tried both debug and release builds.

----------
components: Build, Windows
messages: 151276
nosy: brian.curtin, loewis, terry.reedy, tim.golden
priority: normal
severity: normal
status: open
title: _tkinter does not build on Windows 7
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13789>
_______________________________________

From report at bugs.python.org  Sun Jan 15 06:31:18 2012
From: report at bugs.python.org (py.user)
Date: Sun, 15 Jan 2012 05:31:18 +0000
Subject: [New-bugs-announce] [issue13790] In str.format an incorrect error
	message for list, tuple, dict, set
Message-ID: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> '{0:d}'.format('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'd' for object of type 'str'
>>> '{0:d}'.format(1+1j)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'd' for object of type 'complex'
>>> '{0:d}'.format([])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'd' for object of type 'str'
>>>

also strange behavior:
>>> '{0:s}'.format((1, 2, 3))
'(1, 2, 3)'
>>> '{0:10.5s}'.format([1, 2, 3])
'[1, 2     '
>>>

----------
components: Interpreter Core
messages: 151277
nosy: py.user
priority: normal
severity: normal
status: open
title: In str.format an incorrect error message for list, tuple, dict, set
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13790>
_______________________________________

From report at bugs.python.org  Sun Jan 15 10:06:53 2012
From: report at bugs.python.org (Matt Joiner)
Date: Sun, 15 Jan 2012 09:06:53 +0000
Subject: [New-bugs-announce] [issue13791] Other versions
Message-ID: <1326618413.55.0.73666208075.issue13791@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

The navigation region at http://docs.python.org/dev/ should list "Other versions" instead of "Old versions" as the in development docs are also available here.

Docs for other versions
Python 2.7 (stable)
Python 3.2 (stable)
Old versions

Unreleased, development versions of the documentation. This may contain more information than the current released documentation.

http://www.python.org/doc/versions/

----------
assignee: docs at python
components: Documentation
messages: 151281
nosy: anacrolix, docs at python
priority: normal
severity: normal
status: open
title: Other versions
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13791>
_______________________________________

From report at bugs.python.org  Mon Jan 16 00:05:04 2012
From: report at bugs.python.org (Kay Hayen)
Date: Sun, 15 Jan 2012 23:05:04 +0000
Subject: [New-bugs-announce] [issue13792] The "os.execl" call doesn't give
	programs exit code
Message-ID: <1326668704.55.0.266446288638.issue13792@psf.upfronthosting.co.za>


New submission from Kay Hayen <kayhayen at gmx.de>:

Hello,

I am the author of the Python compiler Nuitka. It has the ability to immediately execute the created executable file. For that I am using "os.execl" to immediately replace the compiler and run the freshly created binary instead.

This worked well so far, but as of late, I am also checking the exit codes, and it turns out that even for failing programs, the exit code is "0" on Windows, even though the compiled binary is exiting with "1".

Investigating further, I made a simple program:

-------
import os
os.execl( "FailingProgram.exe", "lala" )
-------

And it turns out, it's giving me "0", whereas when executed directly "FailingProgram.exe" gives "1". Checking %errorlevel% manually that is, my test framework uses "subprocess" module and gets "0".

The same code works fine (preserves exit code) under Linux. I didn't find the windows specific code responsible for implementing "os.execv" under Win32. I am suspecting that somehow "cmd.exe" may not be propagating the error code, but for that to confirm I would need pointers.

Thanks in advance,
Kay

----------
components: Library (Lib)
messages: 151304
nosy: kayhayen
priority: normal
severity: normal
status: open
title: The "os.execl" call doesn't give programs exit code
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13792>
_______________________________________

From report at bugs.python.org  Mon Jan 16 06:05:25 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 16 Jan 2012 05:05:25 +0000
Subject: [New-bugs-announce] [issue13793] hasattr, delattr,
	getattr fail with unnormalized names
Message-ID: <1326690325.64.0.50515484047.issue13793@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

The documentation for hasattr, getattr, and delattr state that they are equivalent to object.attribute access; this isn't quite true, because object.attribute uses a NFKC-normalized version of the string as only the secondary location, while hasattr, getattr, and delattr (assuming an object rather than an Identifier or string) don't seem to do the normalization at all.

I think the simplest fix would be to normalize and retry when hasattr, getattr, and delattr fail with a string, but I'm not sure that normalization shouldn't be the only string tried. 

>>> o.?
Traceback (most recent call last):
  File "<pyshell#820>", line 1, in <module>
    o.?
AttributeError: 'Object' object has no attribute 'o'
>>> o.o
Traceback (most recent call last):
  File "<pyshell#821>", line 1, in <module>
    o.o
AttributeError: 'Object' object has no attribute 'o'
>>> o.?=[]
>>> hasattr(o, "?")
False
>>> getattr(o, "?")
Traceback (most recent call last):
  File "<pyshell#824>", line 1, in <module>
    getattr(o, "?")
AttributeError: 'Object' object has no attribute '?'
>>> delattr(o, "?")
Traceback (most recent call last):
  File "<pyshell#825>", line 1, in <module>
    delattr(o, "?")
AttributeError: ?
>>> o.?
[]
>>> o.? is o.o
True
>>> o.o
[]
>>> del o.?
>>> o.o
Traceback (most recent call last):
  File "<pyshell#830>", line 1, in <module>
    o.o
AttributeError: 'Object' object has no attribute 'o'

>>> o.? = 5
>>> hasattr(o, "?")
False
>>> hasattr(o, "o")
True
>>> hasattr(o, "o")
True
>>> o.?
5
>>> delattr(o, "o")
>>> o.?

----------
components: Unicode
messages: 151320
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: hasattr, delattr, getattr fail with unnormalized names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13793>
_______________________________________

From report at bugs.python.org  Mon Jan 16 06:21:44 2012
From: report at bugs.python.org (AJ)
Date: Mon, 16 Jan 2012 05:21:44 +0000
Subject: [New-bugs-announce] [issue13794] Copyright Year - Chnage it to 2012
	please
Message-ID: <1326691304.18.0.453476801273.issue13794@psf.upfronthosting.co.za>


New submission from AJ <amanjeev at gmail.com>:

Copyright in the footer on *.python.org says -2011. I believe this can be changed to 2012?

----------
components: None
messages: 151321
nosy: amanjeev
priority: normal
severity: normal
status: open
title: Copyright Year - Chnage it to 2012 please

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13794>
_______________________________________

From report at bugs.python.org  Mon Jan 16 08:16:44 2012
From: report at bugs.python.org (Pedro Andres Aranda Gutierrez)
Date: Mon, 16 Jan 2012 07:16:44 +0000
Subject: [New-bugs-announce] [issue13795] CDATA Element missing
Message-ID: <1326698204.07.0.970512725442.issue13795@psf.upfronthosting.co.za>


New submission from Pedro Andres Aranda Gutierrez <paaguti at gmail.com>:

When creating ElementTree objects that hold SVG drawings, I need a CDATA object similar to the ProcessingInstruction object. There was a circumvention of the problem for Python 2.6:

http://stackoverflow.com/questions/174890/how-to-output-cdata-using-elementtree

This workaround doesn't work in Python 2.7 and above

----------
messages: 151334
nosy: paaguti
priority: normal
severity: normal
status: open
title: CDATA Element missing
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13795>
_______________________________________

From report at bugs.python.org  Mon Jan 16 08:21:27 2012
From: report at bugs.python.org (Pedro Andres Aranda Gutierrez)
Date: Mon, 16 Jan 2012 07:21:27 +0000
Subject: [New-bugs-announce] [issue13796] use 'text=...' to define the text
	attribute of and	xml.etree.ElementTree.Element
Message-ID: <1326698487.2.0.0622950382199.issue13796@psf.upfronthosting.co.za>


New submission from Pedro Andres Aranda Gutierrez <paaguti at gmail.com>:

I have extended the xml.etree.ElementTree.Element class and pass the text attribute in the arguments. This creates much more compact code:

import xml.etree.ElementTree as xml
        
        
class Element(xml.Element):
    def __init__(self,tag,attrib={},**attrs):
        super(xml.Element,self).__init__()
        self.tag = tag
        self.attrib = attrib
        self.attrib.update(attrs)
        self.text = self.attrib.pop('text',None)
        self.tail = self.attrib.pop('tail',None)
        self._children = []

if __name__ == '__main__':
    from sys import stdout

    test = Element('Hello',)
    test2 = Element('World',{'humour':'excelent'},text = 'How do you do', tail="Fine")
    test.append(test2)    
    xml.ElementTree(test).write(stdout,encoding="utf-8",xml_declaration="yes",method="xml")

----------
messages: 151336
nosy: paaguti
priority: normal
severity: normal
status: open
title: use 'text=...' to define the text attribute of and xml.etree.ElementTree.Element
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13796>
_______________________________________

From report at bugs.python.org  Mon Jan 16 11:29:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jan 2012 10:29:11 +0000
Subject: [New-bugs-announce] [issue13797] Add a __buffer__ special method to
	retrieve a PEP 3118	object
Message-ID: <1326709751.32.0.965094376059.issue13797@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently, there's no straightforward way to create new classes in Python that delegate the PEP 3118 buffer APIs to another object that supports them (e.g. bytes, bytearray, memoryview, array.array, a NumPy array).

I see a few possible ways to go about this:

1. Add a single new special method, __buffer__. This creates an entry in the underlying getbuffer slot, but leaves releasebuffer empty.

The getbuffer wrapper then calls __buffer__ and delegates the getbuffer call to the returned object.

Any created Py_buffer instances refer directly to the underlying PEP 3118 supporting object, not the original object that defines __buffer__

The downside of this approach is that you can't implement a completely new PEP 3118 supporting object in pure Python (since you don't get access to the flags)

2. As above, but any Py_buffer structs returned are updated to refer to the original object, not the underlying one. A releasebuffer wrapper is also created, that calls back into __buffer__ to retrieve the object again. This approach has problems if __buffer__ can change to refer to different objects over time.

3. Define separate __getbuffer__ and __releasebuffer__ special methods. All C types implementing the PEP 3118 slots get these special methods automatically (as with any other slot). The flag variables are passed into __getbuffer__, and it is expected to return a memoryview object defining the view. The underlying getbuffer slot wrapper stores the current object in the Py_buffer "obj" slot, and the returned memoryview in "internal". The rest of the Py_buffer fields are populated based on the memoryview contents.

The releasebuffer wrapper then reverses this process, by passing the memoryview instance from the internal slot into the __releasebuffer__ call.

----------
components: Interpreter Core
messages: 151347
nosy: ncoghlan, pitrou, skrah
priority: normal
severity: normal
status: open
title: Add a __buffer__ special method to retrieve a PEP 3118 object
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13797>
_______________________________________

From report at bugs.python.org  Mon Jan 16 13:44:44 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 16 Jan 2012 12:44:44 +0000
Subject: [New-bugs-announce] [issue13798] Pasting and then running code
	doesn't work in the IDLE	Shell
Message-ID: <1326717884.33.0.870144380911.issue13798@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

If you paste code with multiple lines which are not in a block of code into the IDLE Shell and press enter to run the code, only the first line of the code gets executed and the rest of the code is ignored.

You can even put garbage such as "$$$$" in the lines after the first line.

----------
components: IDLE
messages: 151352
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Pasting and then running code doesn't work in the IDLE Shell
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13798>
_______________________________________

From report at bugs.python.org  Mon Jan 16 13:50:46 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 16 Jan 2012 12:50:46 +0000
Subject: [New-bugs-announce] [issue13799] Base 16 should be hexadecimal in
	Unicode HOWTO
Message-ID: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

"base 16" should be "hexadecimal" in the Unicode HOWTO in both Python 2 and 3 docs.

----------
assignee: docs at python
components: Documentation
messages: 151354
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Base 16 should be hexadecimal in Unicode HOWTO
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13799>
_______________________________________

From report at bugs.python.org  Mon Jan 16 14:28:04 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 16 Jan 2012 13:28:04 +0000
Subject: [New-bugs-announce] [issue13801] The Python 3 Docs don't highlight
	nonlocal
Message-ID: <1326720484.97.0.730349515473.issue13801@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

The Python 3 Docs don't highlight nonlocal such as in the code example in the Python 3 documentation for itertools.zip_longest() (http://docs.python.org/py3k/library/itertools.html)

----------
messages: 151362
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: The Python 3 Docs don't highlight nonlocal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13801>
_______________________________________

From report at bugs.python.org  Tue Jan 17 00:22:20 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 Jan 2012 23:22:20 +0000
Subject: [New-bugs-announce] [issue13802] IDLE Prefernces/Fonts: use
	multiple alphabets in examples
Message-ID: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In the Fonts/Tabs tab of the IDLE Preference dialog, the large box for examples of the font selected shows a small square of ascii chars. I think the box should also show 1 char for each of several alphabets so the consequence of choosing various fonts will be more evident. I am thinking of adding several line with the format
Alphabet \uXXXX <char>

----------
components: IDLE
messages: 151415
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE Prefernces/Fonts: use multiple alphabets in examples
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Tue Jan 17 05:08:39 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 17 Jan 2012 04:08:39 +0000
Subject: [New-bugs-announce] [issue13803] Under Solaris,
	distutils doesn't include bitness in the directory name
Message-ID: <1326773319.51.0.412338546649.issue13803@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

When compiling modules under Solaris, distutils generates directories like "build/lib.solaris-2.10-i86pc-3.2". The "i86pc" part is the same both in 32 and 64 bits.

So when building 32 and 64 bit C code, the binaries are mixed and the best result you can get is something like:

"""
ImportError: ld.so.1: python: fatal: /home/pybsddb/build/lib.solaris-2.10-i86pc-2.7/bsddb3/_pybsddb.so: wrong ELF class: ELFCLASS64
"""

In other platforms, bitness is correctly detected and included in the directory name.

Since Solaris is explicitly managed in the sourcecode ("distutils.util.get_platform()"), adding "platform.architecture()[0]" in the directory name seems trivial.

I think this patch should be applied to 2.6 and 3.1, unless they are open only for security fixes.

----------
assignee: tarek
components: Distutils
keywords: easy
messages: 151427
nosy: eric.araujo, jcea, tarek
priority: normal
severity: normal
status: open
title: Under Solaris, distutils doesn't include bitness in the directory name
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13803>
_______________________________________

From report at bugs.python.org  Tue Jan 17 10:48:37 2012
From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=)
Date: Tue, 17 Jan 2012 09:48:37 +0000
Subject: [New-bugs-announce] [issue13804] Python library structure creates
	hard to read code when	using higher order functions
Message-ID: <1326793717.4.0.393580852991.issue13804@psf.upfronthosting.co.za>


New submission from Martin H?cker <spamfaenger at gmx.de>:

Code that uses higher order methods is often the clearest description of what you want to do. However since the higher order methods in python (filter, map, reduce) are free functions and aren't available on collection classes as methods, using them creates really hard to read code.

For example, if I want to get an attribute out of an array of objects and concatenate the results it's two steps, get the attributes out of the object, then concatenate the results.

Without higher order methods its like this. Uses three lines, intermediate variable is quite clear, but hard to compose and hard to abstract out parts of it.

 self.questions = []
 for topic in self.topics:
   self.questions.append(topic.questions)

if I want to do it with higher order functions there's really two ways, do it in one step with reduce:
 self.questions = reduce(lambda memo, topic: memo + topic.questions, self.topics, [])

Or use two steps with the operator module
 self.questions = reduce(operator.add, map(operator.attrgetter('questions'), self.topics), [])

Of these thee first still couples two steps into one lambda, while the second one decoples everything nicely but is a total train wreck to read, as you need to constantly jump back and forth in the line to understand what it does.

Having map and reduce defined on collections would not only make it drastically shorter but also allows you to read it from front to back in one go. (Ok, there is still the caveat that the assignment is in the front instead of at the end, but hey)

 self.questions = self.topics.map(attrgetter('questions')).reduce(add, [])

That would be nicely separated into individual steps that exactly describe what each step is actually doing, is easy to abstract over and actually very succinct.

----------
messages: 151435
nosy: dwt
priority: normal
severity: normal
status: open
title: Python library structure creates hard to read code when using higher order functions
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13804>
_______________________________________

From report at bugs.python.org  Tue Jan 17 11:21:51 2012
From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=)
Date: Tue, 17 Jan 2012 10:21:51 +0000
Subject: [New-bugs-announce] [issue13805] [].sort() should return self
Message-ID: <1326795711.98.0.609923971725.issue13805@psf.upfronthosting.co.za>


New submission from Martin H?cker <spamfaenger at gmx.de>:

[].sort() returns None which means you can't chain it.

So for example someDict.keys().sort()[0] doesn't work but you have to use sorted(someDict.keys())[0] instead which is harder to read as you have to read the line not from the beginning to the end but jump back and forth in it to understand it (which gets progressively harder as the individual parts of it get longer / more complex).

----------
messages: 151439
nosy: dwt
priority: normal
severity: normal
status: open
title: [].sort() should return self
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13805>
_______________________________________

From report at bugs.python.org  Tue Jan 17 16:23:45 2012
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Tue, 17 Jan 2012 15:23:45 +0000
Subject: [New-bugs-announce] [issue13806] Audioop decompression frames size
	check fix
Message-ID: <1326813825.38.0.418557281447.issue13806@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

According to documentation (http://docs.python.org/library/audioop.html), adpcm2lin, alaw2lin and ulaw2lin are using 'width' argument to represent output frames width. However, in audioop.c module there are checks that are raising exceptions if input frames length is not multiple of 'width'. I have replaced checking of 'len' to match 'size' with checking of 'len*size' to match 'size' in order to retain only basic length validity checks.

----------
components: Library (Lib)
files: audioop_size_check.patch
keywords: patch
messages: 151459
nosy: Oleg.Plakhotnyuk, ezio.melotti, sandro.tosi
priority: normal
severity: normal
status: open
title: Audioop decompression frames size check fix
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24260/audioop_size_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13806>
_______________________________________

From report at bugs.python.org  Tue Jan 17 17:00:14 2012
From: report at bugs.python.org (Thomas Ryschawy)
Date: Tue, 17 Jan 2012 16:00:14 +0000
Subject: [New-bugs-announce] [issue13807] logging.Handler.handlerError() may
	raise AttributeError	in traceback.print_exception()
Message-ID: <1326816014.41.0.202399739958.issue13807@psf.upfronthosting.co.za>


New submission from Thomas Ryschawy <ThomasOtto.Ryschawy at Emerson.com>:

It seems to be known that in case of a Windows GUI app that isn?t connected to a console sys.stderr can be None. See the Note on http://docs.python.org/py3k/library/sys.html: Under some conditions stdin, stdout and stderr as well as the original values __stdin__, __stdout__ and __stderr__ can be None. It is usually the case for Windows GUI apps that aren?t connected to a console and Python apps started with pythonw.
In combination with logging this leads to an issue similar to issue #5971. In my case sys.stderr is None and File: lib\logging\__init__.py, Class: Handler, Method: handleError raises AttributeError: 'NoneType' object has no attribute 'write'.
A 'simple' solution would be to check if sys.stderr is not None. In case it is None handleError must not call traceback.print_exception() and not directly write to sys.stderr.

----------
components: Library (Lib)
files: traceback.txt
messages: 151462
nosy: ThomasRyschawy
priority: normal
severity: normal
status: open
title: logging.Handler.handlerError() may raise AttributeError in traceback.print_exception()
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24263/traceback.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13807>
_______________________________________

From report at bugs.python.org  Tue Jan 17 22:45:28 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 17 Jan 2012 21:45:28 +0000
Subject: [New-bugs-announce] [issue13808] url for Tutor mailing list is
	broken
Message-ID: <1326836728.79.0.892184596442.issue13808@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

faq.rst: correct url is http://mail.python.org/mailman/listinfo/tutor

----------
components: Devguide
messages: 151488
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: url for Tutor mailing list is broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13808>
_______________________________________

From report at bugs.python.org  Tue Jan 17 23:20:56 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 17 Jan 2012 22:20:56 +0000
Subject: [New-bugs-announce] [issue13809] bz2 does not work when threads are
	disabled
Message-ID: <1326838856.97.0.0714966673096.issue13809@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

In bz2.py, "import threading" prevents the bz2 module from working when threads are not enabled.  The attached patch removes the limitation and provides a fake lock object.

I don't know if this should be backported to 3.2.

----------
components: Library (Lib)
files: bz2_nothread.patch
keywords: patch
messages: 151491
nosy: amaury.forgeotdarc
priority: normal
severity: normal
stage: patch review
status: open
title: bz2 does not work when threads are disabled
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24267/bz2_nothread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13809>
_______________________________________

From report at bugs.python.org  Wed Jan 18 01:02:02 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 18 Jan 2012 00:02:02 +0000
Subject: [New-bugs-announce] [issue13810] refer people to Doc/Makefile when
	not using 'make' to	build main documentation
Message-ID: <1326844922.3.0.806900590875.issue13810@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

this is regarding "documenting.rst":

The url for checking out Sphinx from svn has been outdated for a while, so I think it would be better to refer people to Doc/Makefile for the correct urls, instead of having to keep updating this file on each change. This applies to the other modules in that section (which are currently up-to-date):

* docutils
* jinja2
* Pygments

----------
components: Devguide
messages: 151499
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: refer people to Doc/Makefile when not using 'make' to build main documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13810>
_______________________________________

From report at bugs.python.org  Wed Jan 18 01:54:04 2012
From: report at bugs.python.org (py.user)
Date: Wed, 18 Jan 2012 00:54:04 +0000
Subject: [New-bugs-announce] [issue13811] In str.format an incorrect
	alignment option doesn't make	fill char and onself absent
Message-ID: <1326848044.1.0.328293668269.issue13811@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

http://docs.python.org/py3k/library/string.html#format-specification-mini-language

"The fill character can be any character other than ?{? or ?}?. The presence of a fill character is signaled by the character following it, which must be one of the alignment options. If the second character of format_spec is not a valid alignment option, then it is assumed that both the fill character and the alignment option are absent."


>>> '{0:x>10d}'.format(1)
'xxxxxxxxx1'
>>> '{0:xx10d}'.format(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid conversion specification
>>>

----------
messages: 151505
nosy: py.user
priority: normal
severity: normal
status: open
title: In str.format an incorrect alignment option doesn't make fill char and onself absent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13811>
_______________________________________

From report at bugs.python.org  Wed Jan 18 02:15:45 2012
From: report at bugs.python.org (Jon Brandvein)
Date: Wed, 18 Jan 2012 01:15:45 +0000
Subject: [New-bugs-announce] [issue13812] multiprocessing package doesn't
	flush stderr on child	exception
Message-ID: <1326849345.92.0.83488691035.issue13812@psf.upfronthosting.co.za>


New submission from Jon Brandvein <jon.brandvein at gmail.com>:

When a child process exits due to an exception, a traceback is written, but stderr is not flushed. Thus I see a header like "Process 1:\n", but no traceback.

I don't have a development environment or any experience with Mecurial, so I'm afraid there's no patch, but it's a one-liner.

In   /Lib/multiprocess/process.py :: Process._bootstrap

    except:
        exitcode = 1
        import traceback
        sys.stderr.write('Process %s:\n' % self.name)
        sys.stderr.flush()
        traceback.print_exc()

Append a "sys.stderr.flush()" to the suite.

It surprised me that flushing was even necessary. I would've thought that the standard streams would all be closed just before the process terminated, regardless of exit status. But I observe that unless I explicitly flush stdout and stderr before terminating, the output is lost entirely, even if the exit is not abnormal. This isn't the desired behavior, is it?

----------
components: Library (Lib)
messages: 151508
nosy: brandj
priority: normal
severity: normal
status: open
title: multiprocessing package doesn't flush stderr on child exception
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13812>
_______________________________________

From report at bugs.python.org  Wed Jan 18 04:58:38 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 18 Jan 2012 03:58:38 +0000
Subject: [New-bugs-announce] [issue13813] "sysconfig.py" and
	"distutils/util.py" redundancy
Message-ID: <1326859118.01.0.584725172013.issue13813@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

During development of patch for issue #13803, I found redundancy between "sysconfig.py" and "distutils/util.py". The functions are the same, and the return values must be the same too. So programmers *MUST* remember to change both sources in sync.

This redundancy must be trimmed.

This is not strictly a bugfix, so could be not adequate for 2.7/3.2, but applying for 3.2 at least would easy future merges.

----------
assignee: tarek
components: Distutils
keywords: easy
messages: 151516
nosy: eric.araujo, jcea, tarek
priority: normal
severity: normal
status: open
title: "sysconfig.py" and "distutils/util.py" redundancy
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13813>
_______________________________________

From report at bugs.python.org  Wed Jan 18 11:43:16 2012
From: report at bugs.python.org (Arkadiusz Wahlig)
Date: Wed, 18 Jan 2012 10:43:16 +0000
Subject: [New-bugs-announce] [issue13814] Generators as context managers.
Message-ID: <1326883396.25.0.884733470267.issue13814@psf.upfronthosting.co.za>


New submission from Arkadiusz Wahlig <arkadiusz.wahlig at gmail.com>:

Generators should support the with statement with __exit__ calling self.close().

with genfunc() as g:
    for item in g:
        print(item)

----------
messages: 151530
nosy: yak
priority: normal
severity: normal
status: open
title: Generators as context managers.
type: enhancement
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13814>
_______________________________________

From report at bugs.python.org  Wed Jan 18 14:16:17 2012
From: report at bugs.python.org (Colin Watson)
Date: Wed, 18 Jan 2012 13:16:17 +0000
Subject: [New-bugs-announce] [issue13815] tarfile.ExFileObject can't be
	wrapped using	io.TextIOWrapper
Message-ID: <1326892577.13.0.456815776311.issue13815@psf.upfronthosting.co.za>


New submission from Colin Watson <cjwatson at users.sourceforge.net>:

The file-like object returned by TarFile.extractfile can't be wrapped in an io.TextIOWrapper (which would be rather convenient in some cases to get something that reads str rather than bytes).

The attached patch demonstrates the problem by way of a test case, and fixes it.  It's just a matter of adding a no-op flush method so that TextIOWrapper.close is happy with it.

----------
components: Library (Lib)
files: tarfile-exfileobject-flush.patch
keywords: patch
messages: 151536
nosy: cjwatson
priority: normal
severity: normal
status: open
title: tarfile.ExFileObject can't be wrapped using io.TextIOWrapper
versions: Python 3.3
Added file: http://bugs.python.org/file24271/tarfile-exfileobject-flush.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13815>
_______________________________________

From report at bugs.python.org  Wed Jan 18 17:23:15 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 18 Jan 2012 16:23:15 +0000
Subject: [New-bugs-announce] [issue13816] Two typos in the docs
Message-ID: <1326903795.6.0.0593092042228.issue13816@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

There's a typo in the docs for cmp_to_key() function. Fix the first sentence "Transform an old-style comparison function to a key-function." to "Transform an old-style comparison function to a key function." (delete the hyphen between words "key" and "function")

http://docs.python.org/library/functools.html#functools.cmp_to_key

------------------------------------------------------------------

There's another typo in the docs lurking in http://docs.python.org/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange

Look for the table with the columns "Operation", "Result", "Notes" (scroll down and you'll find it), and fix the text of the fifth cell under the "Result" column like this:
"i'th item of s, origin 0"  -->  "i-th item of s, origin 0".

Change that apostrophe into a hyphen, so "i'th" to "i-th". Thanks, Ezio.

----------
assignee: docs at python
components: Documentation
messages: 151547
nosy: Retro, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: Two typos in the docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13816>
_______________________________________

From report at bugs.python.org  Wed Jan 18 19:00:36 2012
From: report at bugs.python.org (Christoph Glaubitz)
Date: Wed, 18 Jan 2012 18:00:36 +0000
Subject: [New-bugs-announce] [issue13817] deadlock in subprocess while
	running several threads	using Popen
Message-ID: <1326909636.44.0.892345276723.issue13817@psf.upfronthosting.co.za>


New submission from Christoph Glaubitz <chris+lp at chrigl.de>:

Starting several threads, each just starting a subprocess.Popen and use communicate cause a deadlock in subprocess. (see attached file)

I can only reproduce this with python 2.7.2, not with any other versions. 2.6.5, 2.6.7 and 3.2.2 are working fine. Also 2.4.6 is working, with a problem fixed by http://bugs.python.org/issue1731717.

The attached script does not dead lock all the time, but at least every second call.

I am on a linux x86_64. The python's are compiled by hand, except of 2.6.5.

----------
files: subprocess_deadlock.py
messages: 151556
nosy: glaubich
priority: normal
severity: normal
status: open
title: deadlock in subprocess while running several threads using Popen
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24272/subprocess_deadlock.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13817>
_______________________________________

From report at bugs.python.org  Wed Jan 18 20:23:55 2012
From: report at bugs.python.org (Miguel Godinho)
Date: Wed, 18 Jan 2012 19:23:55 +0000
Subject: [New-bugs-announce] [issue13818] argparse: -h listening required
	options under optional	arguments
Message-ID: <1326914635.35.0.671947933448.issue13818@psf.upfronthosting.co.za>


New submission from Miguel Godinho <m at miguelgodinho.com>:

Adding a 'required optional argument' as with:
```
app.add_argument('--dbsnp', required=True)
```

will still result on having that argument listed under the optional when the app is called with the help option (-h)

Please note that the usage line is rendered ok (no square brackets around the 'required optional argument').

----------
components: Library (Lib)
messages: 151562
nosy: mgodinho
priority: normal
severity: normal
status: open
title: argparse: -h listening required options under optional arguments
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13818>
_______________________________________

From report at bugs.python.org  Wed Jan 18 21:50:17 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Jan 2012 20:50:17 +0000
Subject: [New-bugs-announce] [issue13819] _warnings settings are process-wide
Message-ID: <1326919817.29.0.252163037725.issue13819@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The settings in the C _warnings module are system-wide instead of being interpreter-wide. It seems the latter would be more desireable (and probably more compatible with the Python warnings module).

----------
components: Extension Modules, Interpreter Core
messages: 151563
nosy: brett.cannon, pitrou
priority: low
severity: normal
status: open
title: _warnings settings are process-wide
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13819>
_______________________________________

From report at bugs.python.org  Thu Jan 19 01:45:57 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 19 Jan 2012 00:45:57 +0000
Subject: [New-bugs-announce] [issue13820] 2.6 is no longer in the future
Message-ID: <1326933957.4.0.830452813069.issue13820@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

http://docs.python.org/reference/lexical_analysis.html

Changed in version 2.5: Both as and with are only recognized when the with_statement future feature has been enabled. It will always be enabled in Python 2.6. See section The with statement for details. Note that using as and with as identifiers will always issue a warning, even when the with_statement future directive is not in effect.


That was reasonable wording for 2.5 itself, but at this point, I think it would be simpler to add a Changed in version 2.6 entry.  Perhaps:

Changed in version 2.5: Using as or with as identifiers triggers a warning.  Using them as statements requires the with_statement future feature.
Changed in Python 2.6: as and with became full keywords.

----------
assignee: docs at python
components: Documentation
messages: 151595
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: 2.6 is no longer in the future
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13820>
_______________________________________

From report at bugs.python.org  Thu Jan 19 01:54:19 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 19 Jan 2012 00:54:19 +0000
Subject: [New-bugs-announce] [issue13821] misleading return from isidentifier
Message-ID: <1326934459.59.0.614334427327.issue13821@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

Python identifiers are in NFKC form; string method .isidentifier() returns true on strings that are not in that form.  In some contexts, these non-canonical strings will be replaced with their NFKC equivalent, but in other contexts (such as the builtins hasattr, getattr, delattr) they will not.


>>> cha=chr(170)
>>> cha
'?'

>>> cha.isidentifier()
True

>>> uc.normalize("NFKC", cha)
'a'

>>> obj.? = 5
>>> hasattr(obj, "?")
False
>>> obj.a
5

----------
components: Unicode
messages: 151597
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: misleading return from isidentifier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13821>
_______________________________________

From report at bugs.python.org  Thu Jan 19 05:22:55 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 19 Jan 2012 04:22:55 +0000
Subject: [New-bugs-announce] [issue13822] is(upper/lower/title) are not
	exactly correct
Message-ID: <1326946975.13.0.733756833132.issue13822@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

The isupper() and islower() methods currently use the Lowercase and Uppercase derived properties. Technically, they should use the Changes_When_(Lowercased/Uppercased/Titlecased) and Changes_When_Casemapped derived properties to compute their results.

----------
components: Unicode
messages: 151606
nosy: benjamin.peterson, ezio.melotti
priority: normal
severity: normal
status: open
title: is(upper/lower/title) are not exactly correct
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13822>
_______________________________________

From report at bugs.python.org  Thu Jan 19 09:51:47 2012
From: report at bugs.python.org (patrick vrijlandt)
Date: Thu, 19 Jan 2012 08:51:47 +0000
Subject: [New-bugs-announce] [issue13823]
	xml.etree.ElementTree.ElementTree.write - argument	checking
Message-ID: <1326963107.43.0.928827185581.issue13823@psf.upfronthosting.co.za>


New submission from patrick vrijlandt <patrick.vrijlandt at gmail.com>:

(1) The docs say:
xml_declaration controls if an XML declaration should be added to the file. Use False for never, True for always, None for only if not US-ASCII or UTF-8 or Unicode (default is None). 

The method also accepts other values, like xml_declaration = "yes". This behavior should be documented, or raise a ValueError (up to effbot, I think)

(2) The docs say (in a note):
The encoding string included in XML output should conform to the appropriate standards. For example, ?UTF-8? is valid, but ?UTF8? is not. See http://www.w3.org/

But the method accepts both values, (?UTF-8? and ?UTF8?). Since this will result in invalid xml, (but not invalid python) it should probably raise ValueError too.

(3) Open issue 9458 also refers to this method. It might be wise to raise ValueError if the encoding does not match the (mode of the) file target (binary or text).

----------
assignee: docs at python
components: Documentation, XML
messages: 151612
nosy: docs at python, patrick.vrijlandt
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.ElementTree.write - argument checking
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13823>
_______________________________________

From report at bugs.python.org  Thu Jan 19 13:25:39 2012
From: report at bugs.python.org (David Layton)
Date: Thu, 19 Jan 2012 12:25:39 +0000
Subject: [New-bugs-announce] [issue13824] argparse.FileType opens a file
	without excepting	resposibility for closing it
Message-ID: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>


New submission from David Layton <dmlayton at gmail.com>:

argparse.FileType.__call__ opens the specified file and returns it. This is well documented as an anit-idiom in http://docs.python.org/howto/doanddont.html#exceptions. 

"...a serious problem ? due to implementation details in CPython, the file would not be closed when an exception is raised until the exception handler finishes; and, worse, in other implementations (e.g., Jython) it might not be closed at all regardless of whether or not an exception is raised."

Disregarding the above, handling a file which may or may not have been opened depending the users input requires a bit of boilerplate code compared to the usual with-open idiom.  

Additionally, there is no way to prevent FileType from clobbering an existing file when used with write mode. 

Given these issues and others, it seems to me that the usefulness of FileType is outweighed by propensity to encourage bad coding. Perhaps, it would be best if FileType (or some replacement) simply checked that the file exists (when such a check is appropriate), it can be opened in the specified mode, and, curry the call to open (i.e. return lambda: open(string, self._mode, self._bufsize))

----------
components: Library (Lib)
messages: 151615
nosy: David.Layton, Paolo.Elvati, Stefan.Pfeiffer, bethard, manveru
priority: normal
severity: normal
status: open
title: argparse.FileType opens a file without excepting resposibility for closing it
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13824>
_______________________________________

From report at bugs.python.org  Thu Jan 19 15:14:17 2012
From: report at bugs.python.org (Chris Gill)
Date: Thu, 19 Jan 2012 14:14:17 +0000
Subject: [New-bugs-announce] [issue13825] Datetime failing while reading
	active directory time	attribute
Message-ID: <1326982457.08.0.645011585605.issue13825@psf.upfronthosting.co.za>


New submission from Chris Gill <chrisfgill at gmail.com>:

I believe I am having a similar issue to this: http://bugs.python.org/issue7150



I am in the middle of programming a quick script and now I cannot seem to get beyond this issue; as it is printing up the expiration times from the AD user listings (many of which print 1601 year) it finally fails after the same user account, I have compared accounts and the expiration is the same as other accounts in AD: which is set to (never)

any ideas of what's going on here and how I can bypass this error?


error report: 

Traceback (most recent call last):
... line 14, in <module>
    print user.name + ": " + str(user.accountExpires)
  File "C:\Python27\lib\site-packages\active_directory.py", line 425, in __getattr__
    self._delegate_map[name] = converter (attr)
  File "C:\Python27\lib\site-packages\active_directory.py", line 335, in convert_to_datetime
    return ad_time_to_datetime (item)
  File "C:\Python27\lib\site-packages\active_directory.py", line 319, in ad_time_to_datetime
    return BASE_TIME + delta
OverflowError: date value out of range



code:

import active_directory
from datetime import datetime,timedelta

##check AD for account expirations
users = active_directory.AD_object ("LDAP://ou=administration,dc=domain,dc=com")
for user in users.search (objectCategory='Person'):

    dn = user.distinguishedName
    dn = dn.encode("utf-8") #for the occasional apostrophe

    if "Adjuncts" in str(dn):
        print user.name + ": " + str(user.accountExpires)

print "done"


example output:

CN=John Hancock: 1601-01-01 00:00:00
CN=Jane Smith: 1601-01-01 00:00:00
...

----------
components: IDLE, Windows
messages: 151622
nosy: Chris.Gill
priority: normal
severity: normal
status: open
title: Datetime failing while reading active directory time attribute
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13825>
_______________________________________

From report at bugs.python.org  Thu Jan 19 15:25:15 2012
From: report at bugs.python.org (Julian Berman)
Date: Thu, 19 Jan 2012 14:25:15 +0000
Subject: [New-bugs-announce] [issue13826] Having a shlex example in the
	subprocess.Popen docs is	confusing
Message-ID: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>


New submission from Julian Berman <Julian+Python.org at GrayVines.com>:

The example at http://docs.python.org/dev/library/subprocess.html#popen-constructor seems a bit misplaced, as it seems to suggest that one should use the shlex module. Most of the other examples in the module seem to use a list to provide the args, so if there was a need to just point out that shlex could be used for a corner case perhaps it'd be better suited as a footnote or another subsection somewhere.

----------
assignee: docs at python
components: Documentation
messages: 151624
nosy: Julian, docs at python
priority: normal
severity: normal
status: open
title: Having a shlex example in the subprocess.Popen docs is confusing
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13826>
_______________________________________

From report at bugs.python.org  Thu Jan 19 17:02:19 2012
From: report at bugs.python.org (Michael Hipp)
Date: Thu, 19 Jan 2012 16:02:19 +0000
Subject: [New-bugs-announce] [issue13827] Unexecuted import changes namespace
Message-ID: <1326988939.6.0.324372233485.issue13827@psf.upfronthosting.co.za>


New submission from Michael Hipp <michael at redmule.com>:

A local *unexecuted* import appears to be changing the namespace. Attached files are ready to run.

# over.py
SOMETHING = "overridden"

# main.py
OVERRIDE = False
SOMETHING = "original"

def main():
    #global SOMETHING  # uncomment and it works
    if OVERRIDE:
        from over import SOMETHING  # comment out and it works
        pass
    print SOMETHING  # UnboundLocalError: local variable 'SOMETHING' referenced before assignment

The SOMETHING variable has a value from the module global namespace, but it gets lost due to an import that is never executed.

I would think an unexecuted statement shouldn't have any effect on anything.

The second file will have to be submitted in a follow-on, it appears

----------
components: None
files: main.py
messages: 151635
nosy: hippmr
priority: normal
severity: normal
status: open
title: Unexecuted import changes namespace
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24278/main.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13827>
_______________________________________

From report at bugs.python.org  Thu Jan 19 18:06:03 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 19 Jan 2012 17:06:03 +0000
Subject: [New-bugs-announce] [issue13828] Further improve casefold
	documentation
Message-ID: <1326992763.46.0.576190503242.issue13828@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

> http://hg.python.org/cpython/rev/0b5ce36a7a24
> changeset: ? 74515:0b5ce36a7a24


> + ? Casefolding is similar to lowercasing but more aggressive because it is
> + ? intended to remove all case distinctions in a string. For example, the German
> + ? lowercase letter ``'?'`` is equivalent to ``"ss"``. Since it is already
> + ? lowercase, :meth:`lower` would do nothing to ``'?'``; :meth:`casefold`
> + ? converts it to ``"ss"``.

Perhaps add the recommendation to canonicalize as well.

A complete, but possibly too long, try is below:


Casefolding is similar to lowercasing but more aggressive because it is intended to remove all case distinctions in a string. For example, the German lowercase letter ``'?'`` is equivalent to ``"ss"``. Since it is already lowercase, :meth:`lower` would do nothing to ``'?'``; :meth:`casefold` converts it to ``"ss"``.  Note that most case-insensitive matches should also match compatibility equivalent characters.  

The casefolding algorithm is described in section 3.13 of the Unicode Standard.  Per D146, a compatibility caseless match can be achieved by

    from unicodedata import normalize
    def caseless_compat(string):
        nfd_string = normalize("NFD", string)
        nfkd1_string = normalize("NFKD", nfd_string.casefold())
        return normalize("NFKD", nfkd1_string.casefold())

----------
assignee: docs at python
components: Documentation
messages: 151644
nosy: Jim.Jewett, benjamin.peterson, docs at python
priority: normal
severity: normal
status: open
title: Further improve casefold documentation
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13828>
_______________________________________

From report at bugs.python.org  Thu Jan 19 19:42:02 2012
From: report at bugs.python.org (Dan kamp)
Date: Thu, 19 Jan 2012 18:42:02 +0000
Subject: [New-bugs-announce] [issue13829] exception error
Message-ID: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za>


New submission from Dan kamp <roontoon at gmail.com>:

Get this error when trying to run Moviegrabber on a mac running v2.7. Crash report below.

Process:         Python [2444]
Path:            /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/C ontents/MacOS/Python
Identifier:      Python
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  Python [2431]
 
 
Date/Time:       2011-12-21 20:32:41.233 -0500
OS Version:      Mac OS X 10.7.2 (11C74)
Report Version:  9
 
 
Interval Since Last Report:          357638 sec
Crashes Since Last Report:           17
Per-App Crashes Since Last Report:   405
Anonymous UUID:                      3C387DB7-0AA3-4F34-A100-31D1736D2668
 
 
Crashed Thread:  0
 
 
Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000108
 
 
VM Regions Near 0x108:
-->
    __TEXT                 000000010c5c5000-000000010c5c6000 [    4K] r-x/rwx SM=COW  /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/C ontents/MacOS/Python
 
 
Application Specific Information:
objc[2429]: garbage collection is OFF
 
 
Thread 0 Crashed:
0   libdispatch.dylib                       0x00007fff8b14ace9 _dispatch_wakeup + 108
1   libdispatch.dylib                       0x00007fff8b14d876 _dispatch_resume_slow + 20
2   com.apple.CoreFoundation                0x00007fff8af8262c -[NSXPCConnection start] + 92
3   com.apple.CoreFoundation                0x00007fff8af84ca3 __CFXNotificationCenterSetupConnection + 387
4   com.apple.CoreFoundation                0x00007fff8af84b11 __CFXNotificationCenterCreate + 273
5   com.apple.CoreFoundation                0x00007fff8af849ea __CFNotificationCenterGetDistributedCenter_block_invoke_1 + 26
6   libdispatch.dylib                       0x00007fff8b14d224 dispatch_once_f + 53
7   com.apple.CoreFoundation                0x00007fff8af73e0a CFNotificationCenterGetDistributedCenter + 74
8   com.apple.CoreFoundation                0x00007fff8afb2eb8 ____CFXPreferencesGetSourceForTriplet_block_invoke_1 + 40
9   libdispatch.dylib                       0x00007fff8b14d224 dispatch_once_f + 53
10  com.apple.CoreFoundation                0x00007fff8af7fa4a __CFXPreferencesGetSourceForTriplet + 58
11  com.apple.CoreFoundation                0x00007fff8af8be67 __CFXPreferencesGetSearchListForBundleID + 215
12  com.apple.CoreFoundation                0x00007fff8af8bd48 ___CFXPreferencesCopyAppValue_block_invoke_1 + 24
13  com.apple.CoreFoundation                0x00007fff8af8bcea CFPreferencesCopyAppValue + 218
14  com.apple.SystemConfiguration           0x00007fff928f388c SCDynamicStoreCopyProxies + 43
15  _scproxy.so                             0x000000010ceae9ba 0x10ceae000 + 2490
16  org.python.python                       0x000000010c651b58 PyEval_EvalFrameEx + 13318
17  org.python.python                       0x000000010c654df7 0x10c5ca000 + 568823
18  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
19  org.python.python                       0x000000010c654df7 0x10c5ca000 + 568823
20  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
21  org.python.python                       0x000000010c654cd8 PyEval_EvalCodeEx + 1996
22  org.python.python                       0x000000010c5f2abf 0x10c5ca000 + 166591
23  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
24  org.python.python                       0x000000010c5e06e9 0x10c5ca000 + 91881
25  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
26  org.python.python                       0x000000010c64dc40 PyEval_CallObjectWithKeywords + 180
27  org.python.python                       0x000000010c5dd489 PyInstance_New + 273
28  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
29  org.python.python                       0x000000010c651f63 PyEval_EvalFrameEx + 14353
30  org.python.python                       0x000000010c654cd8 PyEval_EvalCodeEx + 1996
31  org.python.python                       0x000000010c654e6c 0x10c5ca000 + 568940
32  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
33  org.python.python                       0x000000010c654cd8 PyEval_EvalCodeEx + 1996
34  org.python.python                       0x000000010c654e6c 0x10c5ca000 + 568940
35  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
36  org.python.python                       0x000000010c654cd8 PyEval_EvalCodeEx + 1996
37  org.python.python                       0x000000010c5f2abf 0x10c5ca000 + 166591
38  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
39  org.python.python                       0x000000010c6525ec PyEval_EvalFrameEx + 16026
40  org.python.python                       0x000000010c654df7 0x10c5ca000 + 568823
41  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
42  org.python.python                       0x000000010c654df7 0x10c5ca000 + 568823
43  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
44  org.python.python                       0x000000010c654cd8 PyEval_EvalCodeEx + 1996
45  org.python.python                       0x000000010c5f2abf 0x10c5ca000 + 166591
46  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
47  org.python.python                       0x000000010c5e06e9 0x10c5ca000 + 91881
48  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
49  org.python.python                       0x000000010c61c484 0x10c5ca000 + 337028
50  org.python.python                       0x000000010c616b7a 0x10c5ca000 + 314234
51  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
52  org.python.python                       0x000000010c651f63 PyEval_EvalFrameEx + 14353
53  org.python.python                       0x000000010c654df7 0x10c5ca000 + 568823
54  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
55  org.python.python                       0x000000010c654df7 0x10c5ca000 + 568823
56  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
57  org.python.python                       0x000000010c654cd8 PyEval_EvalCodeEx + 1996
58  org.python.python                       0x000000010c5f2abf 0x10c5ca000 + 166591
59  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
60  org.python.python                       0x000000010c6525ec PyEval_EvalFrameEx + 16026
61  org.python.python                       0x000000010c654df7 0x10c5ca000 + 568823
62  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
63  org.python.python                       0x000000010c654df7 0x10c5ca000 + 568823
64  org.python.python                       0x000000010c651e0a PyEval_EvalFrameEx + 14008
65  org.python.python                       0x000000010c654cd8 PyEval_EvalCodeEx + 1996
66  org.python.python                       0x000000010c5f2abf 0x10c5ca000 + 166591
67  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
68  org.python.python                       0x000000010c5e06e9 0x10c5ca000 + 91881
69  org.python.python                       0x000000010c5d1d32 PyObject_Call + 97
70  org.python.python                       0x000000010c64dc40 PyEval_CallObjectWithKeywords + 180
71  org.python.python                       0x000000010c67f40d 0x10c5ca000 + 742413
72  libsystem_c.dylib                       0x00007fff978098bf _pthread_start + 335
73  libsystem_c.dylib                       0x00007fff9780cb75 thread_start + 13
 
 
Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000100  rbx: 0x00007ffc6a6e8610  rcx: 0x00007ffc6a6e8628  rdx: 0x0000000000000001
  rdi: 0x00007ffc6a6e8620  rsi: 0x00007fff8c3d6c40  rbp: 0x000000010d471080  rsp: 0x000000010d471070
   r8: 0x00007ffc6a6dc398   r9: 0x0000000000000596  r10: 0x0000000000000081  r11: 0x00007fff8af825d0
  r12: 0x0000000000000000  r13: 0x0000000000000000  r14: 0x00007fff7ad93180  r15: 0x00007ffc6a6bde28
  rip: 0x00007fff8b14ace9  rfl: 0x0000000000010206  cr2: 0x0000000000000108
Logical CPU: 0
 
 
Binary Images:
       0x10c5c5000 -        0x10c5c5fff  org.python.python (2.7.1 - 2.7.1) <E2C46621-158F-349B-9131-263E8958B23A> /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/C ontents/MacOS/Python
       0x10c5ca000 -        0x10c6e5ff7  org.python.python (2.7.1 - 2.7.1) <A7E34EB5-24D2-3B8F-A26B-4A5B28CD2C60> /System/Library/Frameworks/Python.framework/Versions/2.7/Python
       0x10c7eb000 -        0x10c7effff  _struct.so (??? - ???) <A871A47E-0BF6-3A21-BF66-A5438C54B237> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_struct.so
       0x10c7f5000 -        0x10c7f7ff7  binascii.so (??? - ???) <9B353DAC-B0E8-3B4B-91A1-50F6F86AA928> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/binascii.so
       0x10c7fb000 -        0x10c7fcfff  _hashlib.so (??? - ???) <C6196B8C-5451-3875-BCD9-2942C6A32FCF> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_hashlib.so
       0x10c940000 -        0x10c941fff  _locale.so (??? - ???) <FCAE62F7-D07F-3F5F-8057-18224582F344> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_locale.so
       0x10c945000 -        0x10c951fff  cPickle.so (??? - ???) <FE1D948F-998C-350E-8002-224D3DCDE8B5> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/cPickle.so
       0x10c957000 -        0x10c957fff  grp.so (??? - ???) <563EC9A6-F38F-3518-9BBB-912E9F01FDA1> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/grp.so
       0x10c95b000 -        0x10c95efff  _multiprocessing.so (??? - ???) <CFAE1A97-134D-3A6D-9646-D5109117D153> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_multiprocessing.so
       0x10c963000 -        0x10c965fff  select.so (??? - ???) <FEC6A324-8D3E-3439-9315-BC2AF15A0514> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/select.so
       0x10ce30000 -        0x10ce35fff  array.so (??? - ???) <177F1D09-ACEE-3E39-8F1E-3EE8BA8A7AC6> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/array.so
       0x10ce3b000 -        0x10ce41ff7  _socket.so (??? - ???) <CB2B2DF1-46C2-3491-A737-4522C807F5A2> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_socket.so
       0x10ce49000 -        0x10ce4afff  _functools.so (??? - ???) <D4679747-9993-34F6-B702-3946FA5BF171> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_functools.so
       0x10ce4e000 -        0x10ce52fff  _ssl.so (??? - ???) <50FC05D5-0434-3054-9C09-CA8923FED0C0> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_ssl.so
       0x10ce58000 -        0x10ce59fff  cStringIO.so (??? - ???) <AE5A2A12-8E57-3FE2-B998-C175083B27F7> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/cStringIO.so
       0x10ce5e000 -        0x10ce61fff  _collections.so (??? - ???) <62C1B5B7-654D-397A-8840-7EBB907DBCA1> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_collections.so
       0x10ce67000 -        0x10ce6afff  operator.so (??? - ???) <59A152D0-52ED-354C-9C2D-D7390E3EC216> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/operator.so
       0x10ce70000 -        0x10ce76fff  itertools.so (??? - ???) <7C8350B9-8DD3-377A-A5C1-1103A6C955A6> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/itertools.so
       0x10ce7f000 -        0x10ce7ffff  _bisect.so (??? - ???) <CD57DCA1-74B4-37F8-B338-ABDDB1750F22> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_bisect.so
       0x10ce83000 -        0x10ce84fff  _heapq.so (??? - ???) <A3448C7E-3268-32A5-B4C5-859372FFA7E6> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_heapq.so
       0x10ce89000 -        0x10ce8efff  math.so (??? - ???) <BC93F501-541B-3BA8-B1D7-2644AAD6D6CE> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/math.so
       0x10ce94000 -        0x10ce95ff7  _random.so (??? - ???) <3C7A7C17-1698-32D0-BF09-F50A19F75E4B> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_random.so
       0x10ce99000 -        0x10ce9afff  fcntl.so (??? - ???) <D2F4AAAE-3C27-3134-84AE-021647AEB1C4> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/fcntl.so
       0x10ce9e000 -        0x10ce9ffff  time.so (??? - ???) <DA274462-B33A-33EB-90F7-BB9FB8120A5D> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/time.so
       0x10cea6000 -        0x10cea9fff  strop.so (??? - ???) <A317730F-EDDF-3998-8A22-0E632B3E67A4> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/strop.so
       0x10ceae000 -        0x10ceaefff  _scproxy.so (??? - ???) <F392F576-344C-3CCB-B93C-E11205241E1D> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_scproxy.so
       0x10cf72000 -        0x10cf7dff7  datetime.so (??? - ???) <9EC1E3BD-3BD3-3B39-AE19-448CCEEA747A> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/datetime.so
       0x10cf86000 -        0x10cf8ffff  _sqlite3.so (??? - ???) <4F97C26B-1A2D-33D9-A7B4-C791FA3F645B> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_sqlite3.so
       0x10cf99000 -        0x10cf9dfff  _json.so (??? - ???) <A8E3EEA8-354B-35C6-A3C5-653928D7419D> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_json.so
       0x10cfa2000 -        0x10cfaafff  parser.so (??? - ???) <2E88032A-DFD4-38F0-BE83-03DA706702B1> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/parser.so
       0x10d1f0000 -        0x10d201fff  _io.so (??? - ???) <5451CA4B-98A0-3F70-9322-DBE6B7D93CF1> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_io.so
       0x10d210000 -        0x10d221fff  _ctypes.so (??? - ???) <2D2AE6AF-704A-3CBB-954B-33BA49B78254> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/_ctypes.so
       0x10da17000 -        0x10da19fff  zlib.so (??? - ???) <81E54FCE-EEAC-3E97-BB05-1143EB6AECA6> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynl oad/zlib.so
    0x7fff6c1c5000 -     0x7fff6c1f9ac7  dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld
    0x7fff8ace9000 -     0x7fff8ad22fe7  libssl.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <79AAEC98-1258-3DA4-B1C0-4120049D390B> /usr/lib/libssl.0.9.8.dylib
    0x7fff8ae97000 -     0x7fff8aeb7fff  libsystem_kernel.dylib (1699.22.73 - compatibility 1.0.0) <69F2F501-72D8-3B3B-8357-F4418B3E1348> /usr/lib/system/libsystem_kernel.dylib
    0x7fff8af21000 -     0x7fff8af23fff  libquarantine.dylib (36.0.0 - compatibility 1.0.0) <4C3BFBC7-E592-3939-B376-1C2E2D7C5389> /usr/lib/system/libquarantine.dylib
    0x7fff8af37000 -     0x7fff8b10bfff  com.apple.CoreFoundation (6.7.1 - 635.15) <FE4A86C2-3599-3CF8-AD1A-822F1FEA820F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff8b10c000 -     0x7fff8b147ff7  libsystem_info.dylib (??? - ???) <9C8C2DCB-96DB-3471-9DCE-ADCC26BE2DD4> /usr/lib/system/libsystem_info.dylib
    0x7fff8b148000 -     0x7fff8b156fff  libdispatch.dylib (187.7.0 - compatibility 1.0.0) <712AAEAC-AD90-37F7-B71F-293FF8AE8723> /usr/lib/system/libdispatch.dylib
    0x7fff8c79d000 -     0x7fff8c7a2fff  libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib
    0x7fff8d64a000 -     0x7fff8d64bff7  libremovefile.dylib (21.0.0 - compatibility 1.0.0) <C6C49FB7-1892-32E4-86B5-25AD165131AA> /usr/lib/system/libremovefile.dylib
    0x7fff8edae000 -     0x7fff8edf0ff7  libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib
    0x7fff8f492000 -     0x7fff8f4afff7  libxpc.dylib (77.17.0 - compatibility 1.0.0) <72A16104-2F23-3C22-B474-1953F06F9376> /usr/lib/system/libxpc.dylib
    0x7fff8f778000 -     0x7fff8f779fff  libsystem_sandbox.dylib (??? - ???) <8D14139B-B671-35F4-9E5A-023B4C523C38> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff90a8c000 -     0x7fff90b70def  libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <C5F2392D-B481-3A9D-91BE-3D039FFF4DEC> /usr/lib/libobjc.A.dylib
    0x7fff911f8000 -     0x7fff91201ff7  libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib
    0x7fff912ac000 -     0x7fff91321ff7  libc++.1.dylib (19.0.0 - compatibility 1.0.0) <C0EFFF1B-0FEB-3F99-BE54-506B35B555A9> /usr/lib/libc++.1.dylib
    0x7fff9132e000 -     0x7fff9132ffff  libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib
    0x7fff923c8000 -     0x7fff92416fff  libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib
    0x7fff928da000 -     0x7fff928defff  libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib
    0x7fff928df000 -     0x7fff9292aff7  com.apple.SystemConfiguration (1.11.1 - 1.11) <F832FE21-5509-37C6-B1F1-48928F31BE45> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfi guration
    0x7fff92a44000 -     0x7fff92ab7fff  libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib
    0x7fff92c68000 -     0x7fff92c73ff7  libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib
    0x7fff92c74000 -     0x7fff92c78fff  libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib
    0x7fff92c79000 -     0x7fff92c8bff7  libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib
    0x7fff92c8e000 -     0x7fff92c8efff  libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib
    0x7fff92c8f000 -     0x7fff92c90ff7  libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib
    0x7fff92e7c000 -     0x7fff92e82ff7  libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib
    0x7fff93681000 -     0x7fff93686ff7  libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib
    0x7fff93687000 -     0x7fff9368cfff  libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib
    0x7fff936ce000 -     0x7fff938d0fff  libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib
    0x7fff95141000 -     0x7fff95149fff  libsystem_dnssd.dylib (??? - ???) <7749128E-D0C5-3832-861C-BC9913F774FA> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff95396000 -     0x7fff95397fff  libffi.dylib (??? - ???) <DB96CC4B-0D38-3102-80AA-91DDE9AF3886> /usr/lib/libffi.dylib
    0x7fff95c12000 -     0x7fff95d1efff  libcrypto.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <3A8E1F89-5E26-3C8B-B538-81F5D61DBF8A> /usr/lib/libcrypto.0.9.8.dylib
    0x7fff95e42000 -     0x7fff95e43fff  libdnsinfo.dylib (395.6.0 - compatibility 1.0.0) <718A135F-6349-354A-85D5-430B128EFD57> /usr/lib/system/libdnsinfo.dylib
    0x7fff9653c000 -     0x7fff96543fff  libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib
    0x7fff96544000 -     0x7fff96546fff  com.apple.TrustEvaluationAgent (2.0 - 1) <1F31CAFF-C1C6-33D3-94E9-11B721761DDF> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/Tru stEvaluationAgent
    0x7fff96547000 -     0x7fff9654dfff  libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib
    0x7fff96845000 -     0x7fff96948fff  libsqlite3.dylib (9.6.0 - compatibility 9.0.0) <7F60B0FF-4946-3639-89AB-B540D318B249> /usr/lib/libsqlite3.dylib
    0x7fff96949000 -     0x7fff96976fe7  libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <095FDD3C-3961-3865-A59B-A5B0A4B8B923> /usr/lib/libSystem.B.dylib
    0x7fff977b9000 -     0x7fff977bafff  libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff977bb000 -     0x7fff97898fef  libsystem_c.dylib (763.12.0 - compatibility 1.0.0) <FF69F06E-0904-3C08-A5EF-536FAFFFDC22> /usr/lib/system/libsystem_c.dylib
    0x7fff978b6000 -     0x7fff978c0ff7  liblaunch.dylib (392.18.0 - compatibility 1.0.0) <39EF04F2-7F0C-3435-B785-BF283727FFBD> /usr/lib/system/liblaunch.dylib
 
 
External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 2200
    thread_create: 0
    thread_set_state: 0
 
 
VM Region Summary:
ReadOnly portion of Libraries: Total=60.9M resident=29.0M(48%) swapped_out_or_unallocated=31.9M(52%)
Writable regions: Total=49.5M written=2296K(5%) resident=19.6M(40%) swapped_out=0K(0%) unallocated=29.9M(60%)
 
REGION TYPE                      VIRTUAL
===========                      =======
MALLOC                             34.4M
MALLOC guard page                    48K
SQLite page cache                    96K
STACK GUARD                           4K
Stack                              70.6M
VM_ALLOCATE                           8K
__DATA                             1780K
__LINKEDIT                         48.0M
__TEXT                             12.9M
__UNICODE                           544K
shared memory                        12K
===========                      =======
TOTAL                             168.4M
 
 
Model: Macmini3,1, BootROM MM31.0081.B06, 2 processors, Intel Core 2 Duo, 2 GHz, 4 GB, SMC 1.35f0
Graphics: NVIDIA GeForce 9400, NVIDIA GeForce 9400, PCI, 256 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR3, 1067 MHz, 0x802C, 0x31364A53463235363634485A2D3147314631
Memory Module: BANK 1/DIMM0, 2 GB, DDR3, 1067 MHz, 0x802C, 0x31364A53463235363634485A2D3147314631
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x90), Broadcom BCM43xx 1.0 (5.10.131.36.11)
Bluetooth: Version 4.0.1f4, 2 service, 18 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: Hitachi HTS543212L9SA02, 120.03 GB
Serial ATA Device: PIONEER DVD-RW  DVRTS08
USB Device: Mac OS X Install Disk, apple_vendor_id, 0x1502, 0x26200000 / 2
USB Device: BRCM2046 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x06100000 / 2
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8216, 0x06110000 / 3
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x04500000 / 2
FireWire Device: Rev2, Drobo, 400mbit_speed

----------
messages: 151648
nosy: Dan.kamp
priority: normal
severity: normal
status: open
title: exception error
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13829>
_______________________________________

From report at bugs.python.org  Thu Jan 19 20:56:37 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 19 Jan 2012 19:56:37 +0000
Subject: [New-bugs-announce] [issue13830] codecs error handler is called
	with a UnicodeDecodeError	with the same args
Message-ID: <1327002997.43.0.435824061039.issue13830@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

The script below shows that the error handler is always called with the same error object.  The 'start', 'end', and 'reason' properties are correctly updated, but the 'args' is always the same and holds the values used for the first call.

It's a bit weird that error.args[2] is not equal to error.start, for example. All versions are affected: 2.7, 3.2, 3.3.
And by the way, I could not find where these are attributes documented.



def custom_handler(error):
    print(error.args,
          (error.start, error.end, error.reason))
    return b'?'.decode(), error.end

import codecs
codecs.register_error('custom', custom_handler)
b'\x80\xd0'.decode('utf-8', 'custom')

----------
components: Unicode
messages: 151650
nosy: amaury.forgeotdarc, ezio.melotti
priority: normal
severity: normal
status: open
title: codecs error handler is called with a UnicodeDecodeError with the same args
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13830>
_______________________________________

From report at bugs.python.org  Thu Jan 19 21:46:40 2012
From: report at bugs.python.org (Faheem Mitha)
Date: Thu, 19 Jan 2012 20:46:40 +0000
Subject: [New-bugs-announce] [issue13831] get method of
	multiprocessing.pool.Async should return	full traceback
Message-ID: <1327006000.05.0.152231015377.issue13831@psf.upfronthosting.co.za>


New submission from Faheem Mitha <faheem at faheem.info>:

The documentation in 
http://docs.python.org/library/multiprocessing.html#module-multiprocessing.pool

says

"""class multiprocessing.pool.AsyncResult?
The class of the result returned by Pool.apply_async() and Pool.map_async().

get([timeout])
Return the result when it arrives. If timeout is not None and the result does not arrive within timeout seconds then multiprocessing.TimeoutError is raised. If the remote call raised an exception then that exception will be reraised by get()."""

Consider the example code

################################

from multiprocessing import Pool

def go():
    print 1
    raise Exception("foobar")
    print 2

p = Pool()
x = p.apply_async(go)
x.get()
p.close()
p.join()

###########################

The traceback from this is

Traceback (most recent call last):
  File "<stdin>", line 10, in <module>
  File "/usr/lib/python2.6/multiprocessing/pool.py", line 422, in get
    raise self._value
Exception: foobar
1

As is clear in this example, this is not a full traceback - it only shows the traceback to the line where get is located and gives no further information. This is the case in all the other places I have used get. It seems to me that it *should* return the full traceback, which may contain important information missing in such a partial one. I don't know whether one would call this a feature request or a bug report. Maybe there is some technical reason why this is not possible, but I can't think of one.

----------
components: Library (Lib)
messages: 151651
nosy: fmitha
priority: normal
severity: normal
status: open
title: get method of  multiprocessing.pool.Async should return full traceback
type: enhancement
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13831>
_______________________________________

From report at bugs.python.org  Thu Jan 19 21:52:37 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 19 Jan 2012 20:52:37 +0000
Subject: [New-bugs-announce] [issue13832] tokenization assuming ASCII
	whitespace; missing multiline case
Message-ID: <1327006357.41.0.958836774052.issue13832@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

Parser/parsetok.c was recently changed (e.g. http://hg.python.org/cpython/rev/2bd7f40108b4 ) to raise an error if multiple statements were found in a single-statement compile call.  It sensibly ignores trailing whitespace and comments.  Unfortunately,

(1)  It looks only at (c == ' ' || c == '\t' || c == '\n' || c == '\014') as opposed to using Py_UNICODE_ISSPACE(ch)
(2)  It assumes that a "#" means the rest of the line is OK, instead of looking for additional linebreaks.

Not sure whether to mark this a bug or an enhancement, since it is already strictly better than the 3.2 behavior of never warning about extra text.

----------
components: Interpreter Core
messages: 151652
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: tokenization assuming ASCII whitespace; missing multiline case
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13832>
_______________________________________

From report at bugs.python.org  Thu Jan 19 22:56:14 2012
From: report at bugs.python.org (Torsten Landschoff)
Date: Thu, 19 Jan 2012 21:56:14 +0000
Subject: [New-bugs-announce] [issue13833] No documentation for
	PyStructSequence
Message-ID: <1327010174.09.0.407534369688.issue13833@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

While writing a C extension I wanted to create a namedtuple like object as os.statvfs and friends do.

I was unable to find a simple way to do this from C and was wondering how the posixmodule does it. It turned out that there is a PyStructSequence type for this.

It would be nice to have it documented. First draft for the documentation update attached.

----------
assignee: docs at python
components: Documentation
files: structseq_doc.diff
keywords: patch
messages: 151657
nosy: docs at python, torsten
priority: normal
severity: normal
status: open
title: No documentation for PyStructSequence
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24280/structseq_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13833>
_______________________________________

From report at bugs.python.org  Sat Jan 21 05:17:09 2012
From: report at bugs.python.org (py.user)
Date: Sat, 21 Jan 2012 04:17:09 +0000
Subject: [New-bugs-announce] [issue13834] In help(bytes.strip) there is no
	info about leading	ASCII whitespace
Message-ID: <1327119429.45.0.897722607985.issue13834@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

help(bytes.strip):

strip(...)
    B.strip([bytes]) -> bytes
    
    Strip leading and trailing bytes contained in the argument.
    If the argument is omitted, strip trailing ASCII whitespace.

----------
assignee: docs at python
components: Documentation
messages: 151718
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In help(bytes.strip) there is no info about leading ASCII whitespace
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13834>
_______________________________________

From report at bugs.python.org  Sun Jan 22 11:03:46 2012
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 22 Jan 2012 10:03:46 +0000
Subject: [New-bugs-announce] [issue13835] whatsnew/3.3 misspelling/mislink
Message-ID: <1327226626.95.0.153685106815.issue13835@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

1) Paragraph describing range() comparison links to issue13021.
This issue seems unrelated. It should be issue13201.

2) Paragraph describing of unicode_internal codec, mentions
"(utf-16-le or utf-16-le)"
and
"(utf-32-le or utf-32-le)".
It should be
"(utf-16-le or utf-16-be)"
and
"(utf-32-le or utf-32-be)"
respectively.

----------
assignee: docs at python
components: Documentation
files: whatsnew-3.3-misspelling.diff
keywords: patch
messages: 151765
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: whatsnew/3.3 misspelling/mislink
versions: Python 3.3
Added file: http://bugs.python.org/file24291/whatsnew-3.3-misspelling.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13835>
_______________________________________

From report at bugs.python.org  Sun Jan 22 12:45:37 2012
From: report at bugs.python.org (olivier)
Date: Sun, 22 Jan 2012 11:45:37 +0000
Subject: [New-bugs-announce] [issue13836] Define key failed
Message-ID: <1327232737.47.0.872325277438.issue13836@psf.upfronthosting.co.za>


New submission from olivier <python at noetika.com>:

Hi,

I tried to define new key in python idle and then python 2.5.1 failed to launch. 

What I did : I defined a new key, applied and changed my mind, removed my key set named 'ole'.

I launched cmd
C:\Python25\Lib\idlelib>..\..\python idle.py

got dozens of messages :

Warning: configHandler.py - IdleConf.GetOption -
problem retrieving configration option 'redo'
from section 'ole'.
returning default value: ''

Finally, this opened python idle so I went again to configure idle/keys and saw that my key set was still there. I selected again "Delete custom Key set" and now it's ok.

----------
messages: 151771
nosy: olivier57
priority: normal
severity: normal
status: open
title: Define key failed
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13836>
_______________________________________

From report at bugs.python.org  Sun Jan 22 19:10:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Jan 2012 18:10:07 +0000
Subject: [New-bugs-announce] [issue13837] test_shutil fails with symlinks
	enabled under Windows
Message-ID: <1327255807.39.0.63998442373.issue13837@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This happens when symlinks are enabled under Windows. This doesn't affect any buildbots since they don't run the tests as administrator (or they are not recent enough to have symlink support):


======================================================================
FAIL: test_copymode_follow_symlinks (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\t\cpython\lib\test\test_shutil.py", line 193, in test_copymode_follow
_symlinks
    self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
AssertionError: 33206 != 33060

======================================================================
FAIL: test_move_dangling_symlink (test.test_shutil.TestMove)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\t\cpython\lib\test\test_shutil.py", line 58, in wrap
    return func(*args, **kwargs)
  File "C:\t\cpython\lib\test\test_shutil.py", line 1136, in test_move_dangling_
symlink
    self.assertEqual(os.path.realpath(src), os.path.realpath(dst_link))
AssertionError: 'c:\\users\\antoine\\appdata\\local\\temp\\tmp8bl4eu\\baz' != 'c
:\\users\\antoine\\appdata\\local\\temp\\tmplc6h2h\\quux'
- c:\users\antoine\appdata\local\temp\tmp8bl4eu\baz
?                                        -- ^^ ^^^^
+ c:\users\antoine\appdata\local\temp\tmplc6h2h\quux
?                                         ^^^^^^^ ^^

----------
components: Library (Lib), Tests
messages: 151783
nosy: brian.curtin, hynek, pitrou, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: test_shutil fails with symlinks enabled under Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13837>
_______________________________________

From report at bugs.python.org  Sun Jan 22 23:25:30 2012
From: report at bugs.python.org (py.user)
Date: Sun, 22 Jan 2012 22:25:30 +0000
Subject: [New-bugs-announce] [issue13838] In str.format "{0:#.5g}" for
	decimal.Decimal doesn't	print trailing zeros
Message-ID: <1327271130.3.0.873784301126.issue13838@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

http://docs.python.org/py3k/library/string.html#format-specification-mini-language

The '#' option:
"For floats, complex and Decimal the alternate form causes the result of the conversion to always contain a decimal-point character, even if no digits follow it. Normally, a decimal-point character appears in the result of these conversions only if a digit follows it. In addition, for 'g' and 'G' conversions, trailing zeros are not removed from the result."

1)
>>> import decimal
>>> '{0:#.5g}'.format(1.5)
'1.5000'
>>> '{0:.5f}'.format(decimal.Decimal(1.5))
'1.50000'
>>> '{0:.5g}'.format(decimal.Decimal(1.5))
'1.5'
>>> '{0:#.5g}'.format(decimal.Decimal(1.5))
'1.5'
>>>

no zeros with "#"

2)
>>> import decimal
>>> '{0:#.5g}'.format(decimal.Decimal('1.500000000000'))
'1.5000'
>>> '{0:.5g}'.format(decimal.Decimal('1.500000000000'))
'1.5000'
>>>

zeros without "#"

----------
components: Interpreter Core, Library (Lib)
messages: 151790
nosy: py.user
priority: normal
severity: normal
status: open
title: In str.format "{0:#.5g}" for decimal.Decimal doesn't print trailing zeros
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13838>
_______________________________________

From report at bugs.python.org  Mon Jan 23 04:38:17 2012
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 23 Jan 2012 03:38:17 +0000
Subject: [New-bugs-announce] [issue13839] -m pstats should combine all the
	profiles given as	arguments
Message-ID: <1327289897.02.0.607924329906.issue13839@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

Frequently when profiling multiple threads, I need to combine several dump stat files. Currently -m pstats reads the profiling data at only the first path given. It should merge all the profiling data from all the paths given.

$ python3.3 -m pstats prof/5506-7f00f*

Minimalist patch attached.

----------
components: Library (Lib)
files: m-pstats-merge-profiles.patch
keywords: patch
messages: 151795
nosy: anacrolix
priority: normal
severity: normal
status: open
title: -m pstats should combine all the profiles given as arguments
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24294/m-pstats-merge-profiles.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13839>
_______________________________________

From report at bugs.python.org  Mon Jan 23 08:53:08 2012
From: report at bugs.python.org (Vincent Pelletier)
Date: Mon, 23 Jan 2012 07:53:08 +0000
Subject: [New-bugs-announce] [issue13840] create_string_buffer rejects str
	init_or_size parameter
Message-ID: <1327305188.04.0.956774664708.issue13840@psf.upfronthosting.co.za>


New submission from Vincent Pelletier <plr.vincent at gmail.com>:

ctypes.create_string_buffer documentation[1] says init_or_size parameter should accept a string. As of 3.2, it raises:
>>> import ctypes
>>> ctypes.create_string_buffer('foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/ctypes/__init__.py", line 59, in create_string_buffer
    buf.value = init
TypeError: str/bytes expected instead of str instance

It works fine as of 2.7 (and very probably any 2.x up to ctypes introduction):
>>> import ctypes
>>> ctypes.create_string_buffer('foo')
<ctypes.c_char_Array_4 object at 0x7fbdcb8b95f0>

[1] http://docs.python.org/py3k/library/ctypes.html#ctypes.create_string_buffer

Regards,
Vincent Pelletier

----------
components: ctypes
messages: 151800
nosy: vpelletier
priority: normal
severity: normal
status: open
title: create_string_buffer rejects str init_or_size parameter
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13840>
_______________________________________

From report at bugs.python.org  Mon Jan 23 19:58:52 2012
From: report at bugs.python.org (Jon Brandvein)
Date: Mon, 23 Jan 2012 18:58:52 +0000
Subject: [New-bugs-announce] [issue13841] multiprocessing should use
	sys.exit() where possible
Message-ID: <1327345132.43.0.775594933755.issue13841@psf.upfronthosting.co.za>


New submission from Jon Brandvein <jon.brandvein at gmail.com>:

Currently the multiprocessing library calls a hard exit function (os._exit under unix, ExitProcess under Windows) to terminate the child process.

Under unix, this is necessary because the child is forked without exec-ing. Calling sys.exit() would make it possible for the child to run code on the part of the stack inherited from the parent, via the exception handling mechanism. It might also allow the child to accidentally destroy shared state through an object destructor, even when that object was not explicitly relied on by the child.

Under Windows, I do not see any benefit besides symmetry. Processes are not forked, and the only way control can pass to user code after executing the target function, is if the process is frozen and the user puts the call to freeze_support() inside a try block. This special case can be taken care of by advising the user not to do that. (We already tell the user where freeze_support() should be located.)

Changing the multiprocessing exit routine from ExitProcess to sys.exit on Windows would ensure that all objects holding resources get properly destroyed. In particular, it would ensure that all file streams (including standard output and standard error) are flushed. This is especially important under Python 3, since the new IO system uses its own buffering which cannot be flushed by ExitProcess -- from the user's point of view, a potential regression from Python 2.x.

Related issues:
  - #13812 would not have been a problem under windows.
  - If #8713 gets adopted, unix can use sys.exit() as well.

----------
components: Library (Lib)
messages: 151835
nosy: brandj, jnoller, neologix, pitrou
priority: normal
severity: normal
status: open
title: multiprocessing should use sys.exit() where possible
type: enhancement
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13841>
_______________________________________

From report at bugs.python.org  Mon Jan 23 20:24:19 2012
From: report at bugs.python.org (James Sanders)
Date: Mon, 23 Jan 2012 19:24:19 +0000
Subject: [New-bugs-announce] [issue13842] Cannot pickle Ellipsis or
	NotImplemented
Message-ID: <1327346659.12.0.712807876778.issue13842@psf.upfronthosting.co.za>


New submission from James Sanders <bistromathic1 at gmail.com>:

At present, the built-in constants Ellipsis (...) and NotImplemented cannot be pickled.  Perhaps there is a good reason for this, but the only discussion I can find is at msg<108957>, where it is stated that these values (along with their types, and type(None)) cannot be pickled.

I ran across this in a class that keeps track of numpy-style slicing operations, and so sometimes stores references to Ellipsis.  While this is easy to work around, it does seem a little surprising that ... cannot be pickled, when slice objects can be.  I don't know if there is a likely use for pickling NotImplemented.

If this is not changed, perhaps it could be explicitly stated in the documentation that these objects cannot be pickled?

----------
messages: 151838
nosy: James.Sanders, alexandre.vassalotti, pitrou
priority: normal
severity: normal
status: open
title: Cannot pickle Ellipsis or NotImplemented
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13842>
_______________________________________

From report at bugs.python.org  Mon Jan 23 22:32:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Jan 2012 21:32:15 +0000
Subject: [New-bugs-announce] [issue13843] Python doesn't compile anymore on
	our Solaris buildbot:	undefined libintl_* symbols
Message-ID: <1327354335.3.0.0960870172041.issue13843@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

gcc    -o python Modules/python.o libpython3.3dm.a -lsocket -lnsl -lintl -lrt -ldl -lsendfile   -lm  
Undefined                       first referenced
 symbol                             in file
libintl_bind_textdomain_codeset     libpython3.3dm.a(_localemodule.o)
libintl_gettext                     libpython3.3dm.a(_localemodule.o)
libintl_textdomain                  libpython3.3dm.a(_localemodule.o)
libintl_dcgettext                   libpython3.3dm.a(_localemodule.o)
libintl_bindtextdomain              libpython3.3dm.a(_localemodule.o)
libintl_dgettext                    libpython3.3dm.a(_localemodule.o)
ld: fatal: Symbol referencing errors. No output written to python
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `python'
program finished with exit code 1

http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/4131/steps/compile/logs/stdio

----------
components: Build
messages: 151848
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Python doesn't compile anymore on our Solaris buildbot: undefined libintl_* symbols
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13843>
_______________________________________

From report at bugs.python.org  Mon Jan 23 23:56:25 2012
From: report at bugs.python.org (Robert Xiao)
Date: Mon, 23 Jan 2012 22:56:25 +0000
Subject: [New-bugs-announce] [issue13844] hg.python.org doesn't escape title
	attributes in	annotate view
Message-ID: <1327359385.01.0.222520184458.issue13844@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

On hg.python.org, the "annotate" view doesn't properly escape the title attribute of the <a> elements, resulting in breakage on the left column:

http://hg.python.org/cpython/annotate/728cfc671d15/Modules/Setup.config.in

----------
components: None
messages: 151860
nosy: nneonneo
priority: normal
severity: normal
status: open
title: hg.python.org doesn't escape title attributes in annotate view
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13844>
_______________________________________

From report at bugs.python.org  Tue Jan 24 01:02:45 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Jan 2012 00:02:45 +0000
Subject: [New-bugs-announce] [issue13845] Use GetSystemTimeAsFileTime() to
	get a resolution of 100	ns on Windows
Message-ID: <1327363365.73.0.00740710968562.issue13845@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python implements time.time() using gettimeofday() which has only a resolution of 1 microsecond because it uses the timeval structure which is only able to store microseconds.

Attached patch changes _PyTime_gettimeofday() to make it uses the timespec structure (which has a resolution has 1 nanosecond) and use GetSystemTimeAsFileTime() on Windows. So time.time() has a theorical resolution 10 times better than currently.

----------
files: timespec.patch
keywords: patch
messages: 151865
nosy: belopolsky, haypo
priority: normal
severity: normal
status: open
title: Use GetSystemTimeAsFileTime() to get a resolution of 100 ns on Windows
versions: Python 3.3
Added file: http://bugs.python.org/file24305/timespec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13845>
_______________________________________

From report at bugs.python.org  Tue Jan 24 01:22:29 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Jan 2012 00:22:29 +0000
Subject: [New-bugs-announce] [issue13846] Add time.monotonic() function
Message-ID: <1327364549.64.0.960699645726.issue13846@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

After time.wallclock() (issue #10278), let add a time.monotomic() function. It is similar to time.wallclock() (try to get the most accurate clock) but is not available if the system doesn't provide a monotonic clock. It may also fail at runtime if Python cannot find a monotonic clock, whereas time.clock() and time.wallclock() fallback on a wallclock which may go backward on NTP adjust.

The documentation of the patch should be improved :-)

wallclock() tests may be simplified or dropped because they may fail on NTP adjust.

----------
files: monotonic.patch
keywords: patch
messages: 151868
nosy: belopolsky, haypo
priority: normal
severity: normal
status: open
title: Add time.monotonic() function
versions: Python 3.3
Added file: http://bugs.python.org/file24307/monotonic.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13846>
_______________________________________

From report at bugs.python.org  Tue Jan 24 02:06:29 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Jan 2012 01:06:29 +0000
Subject: [New-bugs-announce] [issue13847] Catch time(), ftime(),
	localtime() and clock() errors
Message-ID: <1327367189.33.0.271402103517.issue13847@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attach patch catchs errors on time(), ftime(), localtime() and clock(). It changes floattime() and _Py_gettimeofday() signature: result now indicates if an error occurred or not, and these function now directly raise an exception.

Catching time() error is maybe overflow: modern version of its manual page don't mention errors.

----------
components: Library (Lib)
files: time_error.patch
keywords: patch
messages: 151871
nosy: belopolsky, haypo
priority: normal
severity: normal
status: open
title: Catch time(), ftime(), localtime() and clock() errors
versions: Python 3.3
Added file: http://bugs.python.org/file24308/time_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13847>
_______________________________________

From report at bugs.python.org  Tue Jan 24 03:03:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jan 2012 02:03:20 +0000
Subject: [New-bugs-announce] [issue13848] io.open() doesn't check for
	embedded NUL characters
Message-ID: <1327370600.14.0.389323922323.issue13848@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

>>> open("\x00abc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory: ''

Contrast with 2.x open():

>>> open("\x00abc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: file() argument 1 must be encoded string without NULL bytes, not str

----------
components: IO, Library (Lib)
keywords: easy
messages: 151876
nosy: hynek, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: io.open() doesn't check for embedded NUL characters
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13848>
_______________________________________

From report at bugs.python.org  Tue Jan 24 03:05:54 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 24 Jan 2012 02:05:54 +0000
Subject: [New-bugs-announce] [issue13849] Add tests for NUL checking in
	certain strs
Message-ID: <1327370754.29.0.66468771639.issue13849@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

ATM there's no tests (at least in 2.x, I haven't checked 3.x yet) for this behavior:

>>> os.path.exists("/tmp\x00abcds")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/genericpath.py", line 18, in exists
    os.stat(path)
TypeError: embedded NUL character

----------
components: Tests
messages: 151877
nosy: alex, amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: Add tests for NUL checking in certain strs
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13849>
_______________________________________

From report at bugs.python.org  Tue Jan 24 06:54:58 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 Jan 2012 05:54:58 +0000
Subject: [New-bugs-announce] [issue13850] Summary tables for argparse
	add_argument options
Message-ID: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

With the current argparse docs, it's very hard to get a quick reminder of how to spell the various parameters for add_argument, and just what they do. This issue suggests adding a "Quick Reference" section for add_argument, with the following elements:

1. Summary table with a one line description of each parameter
2. Summary table with a one line description of each alternative for the "action" parameter (including noting which other parameters are potentially relevant, such as 'choices' and 'metavar' for 'store' and 'const' for 'store_const')
3. Summary table with a one line description of each alternative for the "nargs" parameter

----------
assignee: docs at python
components: Documentation
messages: 151880
nosy: bethard, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Summary tables for argparse add_argument options
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13850>
_______________________________________

From report at bugs.python.org  Tue Jan 24 13:47:39 2012
From: report at bugs.python.org (Vikash Agrawal)
Date: Tue, 24 Jan 2012 12:47:39 +0000
Subject: [New-bugs-announce] [issue13851] Packaging distutils2 for Fedora
Message-ID: <1327409259.69.0.346795065424.issue13851@psf.upfronthosting.co.za>


New submission from Vikash Agrawal <vikashagrawal1990 at gmail.com>:

Packaging distutils2 for Fedora

The spec file, is attached and lack many things. I also need to add files like README, COPYING etc.

The problem is, after installtion of the generated rpm, "python -distutils2-1.0-0.1.0.a3.fc16.noarch.rpm" 
, distutils2 functionalities (such as pysetup) are still not available in the system, though I could find the distutils2 module in the interpretor

Please guide, for the necessary changes/modifications, and I hope to see this package soon in Fedora repository

this is my first packaging initiative

Regards
Vikash Agrawal

----------
assignee: tarek
components: Distutils2
files: python-distutils2.spec
messages: 151898
nosy: alexis, eric.araujo, tarek, vikash
priority: normal
severity: normal
status: open
title: Packaging distutils2 for Fedora
versions: Python 2.7
Added file: http://bugs.python.org/file24312/python-distutils2.spec

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13851>
_______________________________________

From report at bugs.python.org  Tue Jan 24 14:14:45 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 24 Jan 2012 13:14:45 +0000
Subject: [New-bugs-announce] [issue13852] Doc fixes with patch
Message-ID: <1327410885.19.0.883089570823.issue13852@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

I have collected a small amount of documentation fixes in my patch. Please review it and apply it. No pressure. ;)

----------
assignee: docs at python
components: Documentation
files: changes.diff
keywords: patch
messages: 151900
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Doc fixes with patch
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24313/changes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13852>
_______________________________________

From report at bugs.python.org  Tue Jan 24 18:42:32 2012
From: report at bugs.python.org (Jon Brandvein)
Date: Tue, 24 Jan 2012 17:42:32 +0000
Subject: [New-bugs-announce] [issue13853] SystemExit/sys.exit() doesn't
	print boolean argument
Message-ID: <1327426952.31.0.648876756339.issue13853@psf.upfronthosting.co.za>


New submission from Jon Brandvein <jon.brandvein at gmail.com>:

Raising SystemExit manually, or calling sys.exit, with an argument of "True" or "False" results in no output to the screen. According to Doc/library/exceptions.rst and Doc/library/sys.rst, any object that is not an integer or None should be printed to stderr.

Also, I'm not sure whether this is a bug, but "raise SystemExit(None)" differs from "sys.exit(None)", in that the former produces an exception with an args tuple of "(None,)", and the latter produces one with an empty args tuple.

----------
components: Interpreter Core
messages: 151920
nosy: brandj
priority: normal
severity: normal
status: open
title: SystemExit/sys.exit() doesn't print boolean argument
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13853>
_______________________________________

From report at bugs.python.org  Tue Jan 24 19:08:46 2012
From: report at bugs.python.org (Jon Brandvein)
Date: Tue, 24 Jan 2012 18:08:46 +0000
Subject: [New-bugs-announce] [issue13854] multiprocessing: SystemExit from
	child with non-int, non-str arg causes TypeError
Message-ID: <1327428526.26.0.964378708084.issue13854@psf.upfronthosting.co.za>


New submission from Jon Brandvein <jon.brandvein at gmail.com>:

In a child process, raising SystemExit or calling sys.exit with a non-integer, non-string argument value causes a TypeError at Lib/multiprocessing/process.py :: _bootstrap. This is from concatenating the argument with '\n' and writing it to stderr.

Suggested fix: replace
    sys.stderr.write(e.args[0] + '\n')
with
    sys.stderr.write(str(e.args[0]) + '\n')

This problem also occurs when the value is None, but only for raising SystemExit (not calling sys.exit()).

----------
components: Library (Lib)
messages: 151921
nosy: brandj, jnoller
priority: normal
severity: normal
status: open
title: multiprocessing: SystemExit from child with non-int, non-str arg causes TypeError
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13854>
_______________________________________

From report at bugs.python.org  Tue Jan 24 21:14:47 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 24 Jan 2012 20:14:47 +0000
Subject: [New-bugs-announce] [issue13855] Add qualname support to
	types.FunctionType
Message-ID: <1327436087.83.0.0965982153281.issue13855@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

As mentioned in issue13672 currently there is no way to specify a 
qualname on types.FunctionType:

>>> def f():
...    def g():
...       pass
...    return g
... 
>>> g = f()
>>> g
<function f.<locals>.g at 0x7f1dac4d8ba0>
>>> types.FunctionType(f.__code__, {})
<function f at 0x7f1dac4dfae0>
>>> types.FunctionType(g.__code__, {})

If issue13672 is fixed, then the qualname can be derived from the passed
in code object like name is.  We can also add an optional parameter to
the FunctionType constructor for qualname.

I am working on a patch relative to the one I just posted for 
issue13672.

----------
components: Library (Lib)
messages: 151925
nosy: meador.inge, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Add qualname support to types.FunctionType
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13855>
_______________________________________

From report at bugs.python.org  Wed Jan 25 00:02:55 2012
From: report at bugs.python.org (Nathanael Noblet)
Date: Tue, 24 Jan 2012 23:02:55 +0000
Subject: [New-bugs-announce] [issue13856] xmlrpc / httplib changes to allow
	for certificate	verification
Message-ID: <1327446175.17.0.819972733751.issue13856@psf.upfronthosting.co.za>


New submission from Nathanael Noblet <nathanaelnoblet at gmail.com>:

If I wanted to create a HTTPS connection to a xmlrpc server *and* validate its certificate, I need to override the HTTPSConnection and SafeTransport objects. However it seems like they could easily support both methods. At least it seems to work both ways for me

----------
files: xmlrpc-http-withcerts.patch
keywords: patch
messages: 151927
nosy: Nathanael.Noblet, loewis
priority: normal
severity: normal
status: open
title: xmlrpc / httplib changes to allow for certificate verification
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file24318/xmlrpc-http-withcerts.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13856>
_______________________________________

From report at bugs.python.org  Wed Jan 25 04:37:15 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Jan 2012 03:37:15 +0000
Subject: [New-bugs-announce] [issue13857] Add textwrap.indent() as
	counterpart to textwrap.dedent()
Message-ID: <1327462635.84.0.618726818638.issue13857@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As far I am aware, the simplest way to indent a multi-line string is with the following snippet:

    '\n'.join((4 * ' ') + x for x in s.splitlines())

It would be a lot simpler and clearer if I could just write that as "textwrap.indent(s, 4 * ' ')".

(i.e. indent would accept a prefix string to be inserted before each line in the supplied string, as in the original comprehension)

----------
components: Library (Lib)
messages: 151932
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add textwrap.indent() as counterpart to textwrap.dedent()
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13857>
_______________________________________

From report at bugs.python.org  Wed Jan 25 06:13:48 2012
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 25 Jan 2012 05:13:48 +0000
Subject: [New-bugs-announce] [issue13858] readline fails on nonblocking,
	unbuffered io.FileIO objects
Message-ID: <1327468428.38.0.416513768906.issue13858@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

_io._IOBase.readline doesn't seem to like _io.FileIO.read returning None, which occurs when it's unbuffered and nonblocking. (Modules/_io/fileio.c:745 in trunk). Can this be handled some other way?

$ python3.3
Python 3.3.0a0 (default:fb0f4fe8123e+, Jan 24 2012, 11:21:36) 
[GCC 4.6.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, io
>>> r, w = os.pipe2(os.O_NONBLOCK)
>>> f = io.open(r, 'rb', 0)
>>> f.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: read() should have returned a bytes object, not 'NoneType'

----------
components: IO, Library (Lib)
messages: 151933
nosy: anacrolix
priority: normal
severity: normal
status: open
title: readline fails on nonblocking, unbuffered io.FileIO objects
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13858>
_______________________________________

From report at bugs.python.org  Wed Jan 25 16:20:50 2012
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 25 Jan 2012 15:20:50 +0000
Subject: [New-bugs-announce] [issue13859] Lingering StandardError in logging
	module
Message-ID: <1327504850.36.0.736318881933.issue13859@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

There's a lingering StandardError referenced in the logging module.

StandardError was removed in Python 3, and execution across this code path generates a NameError:

  File "/home/matt/src/cpython/Lib/logging/__init__.py", line 291, in __init__
    except StandardError: #pragma: no cover
NameError: global name 'StandardError' is not defined

Patch attached.

----------
components: 2to3 (2.x to 3.x conversion tool), Library (Lib)
files: logging-uncovered-standarderror.patch
keywords: patch
messages: 151948
nosy: anacrolix
priority: normal
severity: normal
status: open
title: Lingering StandardError in logging module
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24322/logging-uncovered-standarderror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13859>
_______________________________________

From report at bugs.python.org  Wed Jan 25 18:41:19 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jan 2012 17:41:19 +0000
Subject: [New-bugs-announce] [issue13860] PyBuffer_FillInfo() return value
Message-ID: <1327513279.1.0.452976234811.issue13860@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This came up in #10419, which is already a little crowded. PyBuffer_FillInfo() returns success if the value for 'view' is NULL.

I can't really see a reason for that. Any thoughts?

----------
components: Interpreter Core
messages: 151953
nosy: ncoghlan, pitrou, skrah
priority: normal
severity: normal
status: open
title: PyBuffer_FillInfo() return value
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13860>
_______________________________________

From report at bugs.python.org  Wed Jan 25 19:43:37 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jan 2012 18:43:37 +0000
Subject: [New-bugs-announce] [issue13861] test_pydoc failure
Message-ID: <1327517017.59.0.678002352905.issue13861@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

test_pydoc fails on Ubuntu Lucid:

======================================================================
FAIL: test_apropos_with_bad_package (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_pydoc.py", line 409, in test_apropos_with_bad_package
    self.assertEqual(b'', result)
AssertionError: b'' != b'Crypto.Protocol.AllOrNothing - This file implements all-or-nothing package transformations.\nCrypto.SelfTest.Protocol.test_AllOrNothing'

======================================================================
FAIL: test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_pydoc.py", line 419, in test_apropos_with_unreadable_dir
    self.assertEqual(b'', result)
AssertionError: b'' != b'Crypto.Protocol.AllOrNothing - This file implements all-or-nothing package transformations.\nCrypto.SelfTest.Protocol.test_AllOrNothing'

----------------------------------------------------------------------

----------
components: Tests
messages: 151962
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pydoc failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13861>
_______________________________________

From report at bugs.python.org  Wed Jan 25 19:46:38 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jan 2012 18:46:38 +0000
Subject: [New-bugs-announce] [issue13862] test_zlib failure
Message-ID: <1327517198.75.0.31759393536.issue13862@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

test_zlib currently fails on Ubuntu Lucid:

======================================================================
FAIL: test_library_version (test.test_zlib.VersionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_zlib.py", line 24, in test_library_version
    self.assertEqual(zlib.ZLIB_RUNTIME_VERSION, zlib.ZLIB_VERSION)
AssertionError: '1.2.3.3' != '1.2.5'
- 1.2.3.3
+ 1.2.5

----------
components: Tests
messages: 151963
nosy: nadeem.vawda, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_zlib failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13862>
_______________________________________

From report at bugs.python.org  Wed Jan 25 20:28:01 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 25 Jan 2012 19:28:01 +0000
Subject: [New-bugs-announce] [issue13863] Using py_compile does not prevent
	recompilation due to	'bad mtime'.
Message-ID: <1327519681.79.0.252690630069.issue13863@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

(Marking this as 'Interpreter Core' because the issue really seems to come from Python/import.c rather than from the py_compile module.)

On a Windows 7 VM (64-bit, NTFS) running Python 2.7 (also reproduced on a non-VM Windows 7 installation), I'm seeing the following surprising behaviour:


C:\Python27\Lib>dir decimal.py*
 Volume in drive C is Local
 Volume Serial Number is 5083-D43D

 Directory of C:\Python27\Lib

06/10/2011  08:46 PM           219,383 decimal.py
01/25/2012  07:05 PM           165,322 decimal.pyc
01/25/2012  04:54 PM           169,386 decimal.pyo
               3 File(s)        554,091 bytes
               0 Dir(s)     966,266,880 bytes free

C:\Python27\Lib>python
Enthought Python Distribution -- www.enthought.com
Version: 7.2-2 (64-bit)

Python 2.7.2 |EPD 7.2-2 (64-bit)| (default, Sep 14 2011, 11:25:00) [MSC v.1500 64 bit (AMD64)] on win32
Type "packages", "demo" or "enthought" for more information.
>>> import py_compile; py_compile.compile('decimal.py')
>>> import os; os.stat('decimal.pyc').st_mtime
1327518430.306176
>>> import decimal
>>> os.stat('decimal.pyc').st_mtime
1327518443.9094632

Notice that in spite of calling py_compile.compile on decimal.py, the .pyc file is still regenerated on import.
Relevant details: note that the decimal.py timestamp is in the summer, and that it's currently winter time.  Also, my Windows 7 timezone setting is UTC, with 'automatically adjust for DST' set to true.

This bit me today when working with a 'post-install' script for an MSI installer for a large Python application, where the post-install script did a compileall.compile_path to make sure that all the .pyc files were up to date, and thereby avoid a *long* (> 90 second) application first startup time.  It turned out that on application startup some of the .pyc files got regenerated while others didn't, and it took me far too long to notice that it was the .py files with summer timestamps that lead to .pyc regeneration, and that those with winter timestamps were okay.

When I set my timezone to plain UTC with no DST adjustments, the above issue disappears.  Also, when I reset my timezone to that of Saudi Arabia (no DST), the issue also disappears.


The cause of the issue seems to be that:

(1) import.c uses an 'fstat' call to get mtime for a .py file.
(2) on my Windows installation, the result of fstat on a file varies (a) with time of year, and (b) with computer DST and timezone settings.  (No such problems on OS X.)
(3) in contrast, py_compile uses os.stat(...).st_mtime, which appears to be invariant under time changes.


The difference between the 'fstat' result and the os.stat result can be seen directly:

Python 2.7.2 |EPD 7.2-2 (64-bit)| (default, Sep 14 2011, 11:25:00) [MSC v.1500 64 bit (AMD64)] on win32
Type "packages", "demo" or "enthought" for more information.
>>> import decimal  # make sure .pyc file is up to date
>>> import os; os.stat('decimal.py').st_mtime  # actual mtime of .py file
1307738784.0
>>> import struct; struct.unpack('LL', open('decimal.pyc', 'rb').read(8))[1]  # stored mtime from .pyc; uses fstat
1307735184



This presumably also means that in this part of the world, .pyc files will be regenerated on import after any DST change, since the reported 'fstat' result used by import.c will no longer match the stored mtime timestamp in the .pyc file.

----------
components: Interpreter Core
messages: 151969
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Using py_compile does not prevent recompilation due to 'bad mtime'.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13863>
_______________________________________

From report at bugs.python.org  Wed Jan 25 20:52:13 2012
From: report at bugs.python.org (stephen Andel)
Date: Wed, 25 Jan 2012 19:52:13 +0000
Subject: [New-bugs-announce] [issue13864] Python 2.7.2 refuses to open
Message-ID: <1327521133.43.0.177079679673.issue13864@psf.upfronthosting.co.za>


New submission from stephen Andel <elden.andel at gmail.com>:

I recently changed one of the keybindings in python to just control. Python did not like this and, when I tried to fix this by swapping back to the default settings it closed itself and now will not open. Th program will attempt to open then stop, and the process with cancel. I have reinstalled and deleted all apparent files associated with python but this was not enough and continues to fail, badly. Sorry for the informal dialogue I'm just a bit peeved right now.

----------
components: IDLE
messages: 151971
nosy: stephen.Andel
priority: normal
severity: normal
status: open
title: Python 2.7.2 refuses to open
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13864>
_______________________________________

From report at bugs.python.org  Wed Jan 25 22:04:53 2012
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 25 Jan 2012 21:04:53 +0000
Subject: [New-bugs-announce] [issue13865] distutils documentation says
	Extension has "optional"	argument
Message-ID: <1327525493.46.0.373823292504.issue13865@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

The Extension documentation says:

--------
2.3.5. Other options
There are still some other options which can be used to handle special cases.

The optional option is a boolean; if it is true, a build failure in the extension will not abort the build process, but instead simply not install the failing extension.
---------

However there not such option, and distutils will complain:

/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension options: 'optional'

----------
messages: 151974
nosy: tebeka
priority: normal
severity: normal
status: open
title: distutils documentation says Extension has "optional" argument

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13865>
_______________________________________

From report at bugs.python.org  Wed Jan 25 23:12:02 2012
From: report at bugs.python.org (Stephen Day)
Date: Wed, 25 Jan 2012 22:12:02 +0000
Subject: [New-bugs-announce] [issue13866] {urllib,
	urllib.parse}.urlencode should not use quote_plus
Message-ID: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za>


New submission from Stephen Day <stevvooe at gmail.com>:

The current behavior of the urlencode function (2.7: urllib, 3.x: urllib.parse) encodes spaces as pluses:

>>> from urllib import urlencode
>>> urlencode({'a': 'some param'})
'a=some+param'

However, in most instances, it would be desirable to merely encode spaces using percent encoding:

>>> urlencode({'a': 'some param'})
'a=some%20param'

But there is no way to get this behavior in the standard library. 

It would probably best to change this so it defaults to use the regular quote function, but allows callers who need the legacy quote_plus behavior to pass that in as a function parameter.

An acceptable fix would be to have the quote function taken as a keyword parameter, so legacy behavior remains:

>>> urlencode({'a': 'some param'})
'a=some+param'

Then the behavior could be adjusted where needed:

>>> from urllib import quote
>>> urlencode({'a': 'some param'}, quote=quote)
'a=some%20param'

----------
components: Library (Lib)
messages: 151980
nosy: Stephen.Day
priority: normal
severity: normal
status: open
title: {urllib,urllib.parse}.urlencode should not use quote_plus
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13866>
_______________________________________

From report at bugs.python.org  Thu Jan 26 00:01:16 2012
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 25 Jan 2012 23:01:16 +0000
Subject: [New-bugs-announce] [issue13867] misleading comment in
	weakrefobject.h
Message-ID: <1327532476.25.0.872465463087.issue13867@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

http://hg.python.org/cpython/file/fec45282dc28/Include/weakrefobject.h#l54

The comment makes sense -- but doesn't appear to be true, so perhaps it is the macro that should change.


 
/* This macro calls PyWeakref_CheckRef() last since that can involve a
   function call; this makes it more likely that the function call
   will be avoided. */
#define PyWeakref_Check(op) \
        (PyWeakref_CheckRef(op) || PyWeakref_CheckProxy(op))

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 151983
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: misleading comment in weakrefobject.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13867>
_______________________________________

From report at bugs.python.org  Thu Jan 26 00:58:10 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 25 Jan 2012 23:58:10 +0000
Subject: [New-bugs-announce] [issue13868] Add hyphen doc fix
Message-ID: <1327535890.98.0.936666267948.issue13868@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

When you have time, incorporate this patch. Thanks.

----------
assignee: docs at python
components: Documentation
files: smallfix.diff
keywords: patch
messages: 151985
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Add hyphen doc fix
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24325/smallfix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13868>
_______________________________________

From report at bugs.python.org  Thu Jan 26 01:11:57 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 26 Jan 2012 00:11:57 +0000
Subject: [New-bugs-announce] [issue13869] CFLAGS="-UNDEBUG" build failure
Message-ID: <1327536717.01.0.741263593585.issue13869@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Passing -UNDEBUG as CFLAGS currently doesn't work:

./configure CFLAGS="-UNDEBUG" && make

[...]

libpython3.3m.a(object.o): In function `PyObject_Str':
/home/stefan/pydev/cpython/Objects/object.c:441: undefined reference to `_PyUnicode_CheckConsistency'
libpython3.3m.a(unicodeobject.o): In function `unicode_result_ready':
/home/stefan/pydev/cpython/Objects/unicodeobject.c:476: undefined reference to `_PyUnicode_CheckConsistency'
/home/stefan/pydev/cpython/Objects/unicodeobject.c:468: undefined reference to `_PyUnicode_CheckConsistency'
libpython3.3m.a(unicodeobject.o): In function `PyUnicode_New':
/home/stefan/pydev/cpython/Objects/unicodeobject.c:1066: undefined reference to `_PyUnicode_CheckConsistency'
libpython3.3m.a(unicodeobject.o): In function `get_latin1_char':
/home/stefan/pydev/cpython/Objects/unicodeobject.c:1647: undefined reference to `_PyUnicode_CheckConsistency'
libpython3.3m.a(unicodeobject.o):/home/stefan/pydev/cpython/Objects/unicodeobject.c:1787: more undefined references to `_PyUnicode_CheckConsistency' follow

----------
components: Build
messages: 151986
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: CFLAGS="-UNDEBUG" build failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13869>
_______________________________________

From report at bugs.python.org  Thu Jan 26 05:59:33 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 26 Jan 2012 04:59:33 +0000
Subject: [New-bugs-announce] [issue13870] false comment in
	collections/__init__.py ordered dict
Message-ID: <1327553973.99.0.0526575154681.issue13870@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

http://hg.python.org/cpython/file/tip/Lib/collections/__init__.py#l37 states that the prev/next links are weakref proxies; as of http://hg.python.org/cpython/diff/3977dc349ae7/Lib/collections.py this is no longer true of the next links.  

It could be fixed by changing

# The prev/next links are weakref proxies (to prevent circular references).

to 

# The prev links are weakref proxies (to prevent circular references).

----------
components: Library (Lib)
files: collections_init.patch
keywords: patch
messages: 151996
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: false comment in collections/__init__.py ordered dict
Added file: http://bugs.python.org/file24326/collections_init.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13870>
_______________________________________

From report at bugs.python.org  Thu Jan 26 06:47:42 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 26 Jan 2012 05:47:42 +0000
Subject: [New-bugs-announce] [issue13871] namedtuple does not normalize
	field names when sanitizing
Message-ID: <1327556862.47.0.690638642414.issue13871@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

collections.namedtuple raises a ValueError if any of the field names are not valid identifiers, or are duplicates.

It does not normalize the identifiers when checking for duplicates.

(Similar issue with the typename)

>>> namedtuple("dup_fields", ["a", "a"])
Traceback (most recent call last):
  File "<pyshell#23>", line 1, in <module>
    namedtuple("dup_fields", ["a", "a"])
  File "C:\python32\lib\collections.py", line 345, in namedtuple
    raise ValueError('Encountered duplicate field name: %r' % name)
ValueError: Encountered duplicate field name: 'a'



>>> namedtuple("nfk_tester", ["a", "?"])
Traceback (most recent call last):
  File "<pyshell#22>", line 1, in <module>
    namedtuple("nfk_tester", ["a", "?"])
  File "C:\python32\lib\collections.py", line 365, in namedtuple
    raise SyntaxError(e.msg + ':\n\n' + class_definition)
  File "<string>", line None
SyntaxError: duplicate argument 'a' in function definition:
...



and 


>>> namedtuple("just?", "?")
Traceback (most recent call last):
  File "<pyshell#24>", line 1, in <module>
    namedtuple("just?", "?")
  File "C:\python32\lib\collections.py", line 366, in namedtuple
    result = namespace[typename]
KeyError: 'just?'

----------
messages: 151997
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: namedtuple does not normalize field names when sanitizing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13871>
_______________________________________

From report at bugs.python.org  Thu Jan 26 13:57:32 2012
From: report at bugs.python.org (Matt Joiner)
Date: Thu, 26 Jan 2012 12:57:32 +0000
Subject: [New-bugs-announce] [issue13872] socket.detach doesn't mark
	socket._closed
Message-ID: <1327582652.34.0.856044764189.issue13872@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

socket.socket.detach doesn't mark the socket._closed flag. The flag is specific to the Python wrapper, so the fix is put there. Test included.

----------
components: Library (Lib)
files: socket-detach-mark-closed.patch
keywords: patch
messages: 152005
nosy: anacrolix
priority: normal
severity: normal
status: open
title: socket.detach doesn't mark socket._closed
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24327/socket-detach-mark-closed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13872>
_______________________________________

From report at bugs.python.org  Thu Jan 26 14:16:44 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 26 Jan 2012 13:16:44 +0000
Subject: [New-bugs-announce] [issue13873] SIGBUS in test_zlib on Debian
	bigmem buildbot
Message-ID: <1327583804.29.0.71599909936.issue13873@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/58/steps/test/logs/stdio

----------
assignee: nadeem.vawda
messages: 152006
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: SIGBUS in test_zlib on Debian bigmem buildbot
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13873>
_______________________________________

From report at bugs.python.org  Thu Jan 26 14:34:47 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 26 Jan 2012 13:34:47 +0000
Subject: [New-bugs-announce] [issue13874] test_faulthandler: read_null test
	fails with current	clang
Message-ID: <1327584887.45.0.833971151143.issue13874@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

In non-debug mode the read_null test fails with clang-3.0:

======================================================================
FAIL: test_disable (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/stefan/hg/cpython/Lib/test/test_faulthandler.py", line 235, in test_disable
    self.assertNotEqual(exitcode, 0)
AssertionError: 0 == 0



clang "optimizes" the undefined behavior into a simple assignment:


$ ~/usr/bin/clang --version
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-unknown-freebsd9.0
Thread model: posix
$ 
$ cat read_null.c
#include <stdio.h>

int
main(void)
{
    int *x = NULL, y;

    y = *x;
    printf("%d\n", y);

    return 0;
}
$ 
$ ~/usr/bin/clang -Wall -O0 -g -o read_null read_null.c 
$ ./read_null 
Segmentation fault: 11 (core dumped)
$ ~/usr/bin/clang -Wall -O3 -g -o read_null read_null.c 
$ ./read_null 
0

----------
components: Tests
messages: 152007
nosy: haypo, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_faulthandler: read_null test fails with current clang
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13874>
_______________________________________

From report at bugs.python.org  Thu Jan 26 15:27:57 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 26 Jan 2012 14:27:57 +0000
Subject: [New-bugs-announce] [issue13875] cmd: no user documentation
Message-ID: <1327588077.77.0.0954132482021.issue13875@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/cmd.html#

Documentation for cmd module is poor to explain the value of this module to users. Intro is too abstract - phrase "simple framework for writing line-oriented command interpreters" doesn't mean much. Perhaps word "interactive" is missing?

So, there is no part explaining the what cmd does exactly (intro fails) and no part explaining the main principle - How exactly does this framework allows to do this in a simple way? (I guess reference part under 'Cmd objects -> Cmd.cmdloop([intro]) -> p[4]` does that, but it is not the place you'd usually expect this info.

At the very least what could be done is a link to Doug's tutorial http://www.doughellmann.com/PyMOTW/cmd/

----------
assignee: docs at python
components: Documentation
messages: 152010
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: cmd: no user documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13875>
_______________________________________

From report at bugs.python.org  Thu Jan 26 15:36:03 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 26 Jan 2012 14:36:03 +0000
Subject: [New-bugs-announce] [issue13876] Sporadic failure in test_socket
Message-ID: <1327588563.2.0.447366914719.issue13876@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

When running the test suite, I occasionally get the following failure:

    ERROR: testRecvmsgEOF (test.test_socket.RecvmsgSCTPStreamTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/def/Lib/test/test_socket.py", line 2187, in testRecvmsgEOF
        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
      File "/home/nadeem/code/src/cpython/def/Lib/test/test_socket.py", line 1678, in doRecvmsg
        result = sock.recvmsg(bufsize, *args)
    OSError: [Errno 107] Transport endpoint is not connected

The machine in question is running Ubuntu 11.10 64-bit.

I haven't seen anything similar on any of the buildbots.

----------
messages: 152012
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: Sporadic failure in test_socket
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13876>
_______________________________________

From report at bugs.python.org  Thu Jan 26 16:50:10 2012
From: report at bugs.python.org (Jon Bringhurst)
Date: Thu, 26 Jan 2012 15:50:10 +0000
Subject: [New-bugs-announce] [issue13877] segfault when running smtplib
	example
Message-ID: <1327593010.34.0.461726513407.issue13877@psf.upfronthosting.co.za>


New submission from Jon Bringhurst <jon at bringhurst.org>:

I just ran into this while using the smtplib example on:

2.6 (r26:66714, Jan 17 2012, 11:02:11)
GCC 4.1.2 20080704 (Red Hat 4.1.2-44)

Running the program simply gives a "Segmentation Fault (core dumped)"

Running it under gdb...

[Thread debugging using libthread_db enabled]
[New Thread 0x2b0257007b80 (LWP 2567)]

Program received signal SIGSEGV, Segmentation fault.
PyEval_EvalFrameEx (f=0x17701d00, throwflag=<value optimized out>) at Python/ceval.c:4342
4342        if (!PyDict_Check(gobals)) {


See (permanently closed?) similar bug at:
http://bugs.python.org/issue1003195

----------
components: Interpreter Core
messages: 152020
nosy: Jon.Bringhurst
priority: normal
severity: normal
status: open
title: segfault when running smtplib example
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13877>
_______________________________________

From report at bugs.python.org  Thu Jan 26 17:57:18 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 26 Jan 2012 16:57:18 +0000
Subject: [New-bugs-announce] [issue13878] test_sched failures on Windows
	buildbot
Message-ID: <1327597038.78.0.0899603043053.issue13878@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4072/steps/test/logs/stdio:

    FAIL: test_enter (test.test_sched.TestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_sched.py", line 18, in test_enter
        self.assertEqual(l, [0.01, 0.02, 0.03, 0.04, 0.05])
    AssertionError: Lists differ: [0.01, 0.02, 0.03, 0.05, 0.04] != [0.01, 0.02, 0.03, 0.04, 0.05]

    First differing element 3:
    0.05
    0.04

    - [0.01, 0.02, 0.03, 0.05, 0.04]
    ?                        ------

    + [0.01, 0.02, 0.03, 0.04, 0.05]
    ?                    ++++++


http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4062/steps/test/logs/stdio:

    FAIL: test_queue (test.test_sched.TestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_sched.py", line 74, in test_queue
        self.assertEqual(list(scheduler.queue), [e1, e2, e3, e4, e5])
    AssertionError: Lists differ: [Event(time=1327366698.525, pr... != [Event(time=1327366698.525, pr...

    First differing element 3:
    Event(time=1327366698.565, priority=1, action=<function TestCase.test_queue.<locals>.<lambda> at 0x03419158>, argument=[], kwargs={})
    Event(time=1327366698.5709999, priority=1, action=<function TestCase.test_queue.<locals>.<lambda> at 0x03419158>, argument=[], kwargs={})

    Diff is 1268 characters long. Set self.maxDiff to None to see it.

----------
messages: 152022
nosy: giampaolo.rodola, nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: test_sched failures on Windows buildbot
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13878>
_______________________________________

From report at bugs.python.org  Thu Jan 26 17:59:28 2012
From: report at bugs.python.org (Tim Willis)
Date: Thu, 26 Jan 2012 16:59:28 +0000
Subject: [New-bugs-announce] [issue13879] Argparse does not support
	subparser aliases in 2.7
Message-ID: <1327597168.42.0.828007379667.issue13879@psf.upfronthosting.co.za>


New submission from Tim Willis <schadenfreude328 at gmail.com>:

Argparse documentation in 2.7 indicates support for an 'aliases' kwarg.  (Fourth example down from http://docs.python.org/dev/library/argparse.html#sub-commands)

While aliases work as expected in 3.2, use in 2.7 results in TypeError: __init__() got an unexpected keyword argument 'aliases'

----------
components: Library (Lib)
messages: 152024
nosy: Tim.Willis
priority: normal
severity: normal
status: open
title: Argparse does not support subparser aliases in 2.7
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13879>
_______________________________________

From report at bugs.python.org  Thu Jan 26 20:34:28 2012
From: report at bugs.python.org (__KFL__)
Date: Thu, 26 Jan 2012 19:34:28 +0000
Subject: [New-bugs-announce] [issue13880] pydoc -k throws "AssertionError:
	distutils has already	been patched by <class
	py2exe.Distribution at 0x0000000005987408>"
Message-ID: <1327606468.69.0.0708132604727.issue13880@psf.upfronthosting.co.za>


New submission from __KFL__ <lukefei at gmail.com>:

Pydoc fails on the following exception. There is a mail discussing it: http://mail.python.org/pipermail/python-list/2009-December/1230790.html

C:\Python27\Lib>pydoc -k file
...
...
Traceback (most recent call last):
  File "C:\Python27\Lib\pydoc.py", line 2338, in <module>
    if __name__ == '__main__': cli()
  File "C:\Python27\Lib\pydoc.py", line 2277, in cli
    apropos(val)
  File "C:\Python27\Lib\pydoc.py", line 1974, in apropos
    ModuleScanner().run(callback, key)
  File "C:\Python27\Lib\pydoc.py", line 1939, in run
    for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
  File "C:\Python27\Lib\pkgutil.py", line 110, in walk_packages
    __import__(name)
  File "C:\Python27\lib\site-packages\pypm\__init__.py", line 22, in <module>
    import setuptools
  File "C:\Python27\lib\site-packages\setuptools\__init__.py", line 2, in <module>
    from setuptools.extension import Extension, Library
  File "C:\Python27\lib\site-packages\setuptools\extension.py", line 2, in <module>
    from setuptools.dist import _get_unpatched
  File "C:\Python27\lib\site-packages\setuptools\dist.py", line 28, in <module>
    _Distribution = _get_unpatched(_Distribution)
  File "C:\Python27\lib\site-packages\setuptools\dist.py", line 24, in _get_unpatched
    "distutils has already been patched by %r" % cls
AssertionError: distutils has already been patched by <class py2exe.Distribution at 0x0000000005987408>

----------
messages: 152027
nosy: __KFL__
priority: normal
severity: normal
status: open
title: pydoc -k throws "AssertionError: distutils has already been patched by <class py2exe.Distribution at 0x0000000005987408>"
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13880>
_______________________________________

From report at bugs.python.org  Thu Jan 26 20:40:49 2012
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 26 Jan 2012 19:40:49 +0000
Subject: [New-bugs-announce] [issue13881] Stream encoder for zlib_codec
	doesn't use the	incremental encoder
Message-ID: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

The stream encoder for the zlib_codec doesn't use the incremental encoder, so it has limited usefulness in practice. This is easiest to show with an example.

Here is the behavior with the stream encoder:

>>> filelike = io.BytesIO()
>>> wrapped = codecs.getwriter('zlib_codec')(filelike)
>>> wrapped.write(b'hello')
>>> filelike.getvalue()
b'x\x9c\xab\x00\x00\x00y\x00y'
>>> wrapped.write(b'x')
>>> filelike.getvalue()
b'x\x9c\xab\x00\x00\x00y\x00yx\x9c\xab\x00\x00\x00y\x00y'
>>>

However, this is the behavior of the incremental encoder:

>>> ienc = codecs.getincrementalencoder('zlib_codec')()
>>> ienc.encode(b'x')
b'x\x9c'
>>> ienc.encode(b'x', final=True)
b'\xab\xa8\x00\x00\x01j\x00\xf1'
>>>

The stream encoder is apparently encoding each write as an individual block, but the incremental encoder buffers until it gets a block that's large enough to be meaningfully compressed.

Fixing this may require addressing a separate issue with stream encoders. Unlike with the GzipFile module, closing a stream encoder closes the underlying file. If this underlying file is a BytesIO, then closing makes it free its buffer, making it impossible to get at the completed file.

----------
components: IO
messages: 152029
nosy: amcnabb
priority: normal
severity: normal
status: open
title: Stream encoder for zlib_codec doesn't use the incremental encoder
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13881>
_______________________________________

From report at bugs.python.org  Thu Jan 26 22:00:37 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Jan 2012 21:00:37 +0000
Subject: [New-bugs-announce] [issue13882] Add format argument for
	time.time(), time.clock(),
	... to get a timestamp as a Decimal object
Message-ID: <1327611637.79.0.902972785006.issue13882@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Attached patch adds an optional format argument to time.time(), time.clock(), time.wallclock(), time.clock_gettime() and time.clock_getres() to get the timestamp as a different format. By default, the float type is still used, but it will be possible to pass "format" to get the timestamp as a decimal.Decimal object.

Some advantages of using decimal.Decimal instead of float:
 - no loss of precision during conversion from base 2 to base 10 (converting the float to a string)
 - the resolution of the clock is stored in the Decimal object
 - for big number, Decimal doesn't loose precision

Using Decimal is also motivated by the fact than Python 3.3 has now access to clock having a resolution of 1 nanosecond: clock_gettime(CLOCK_REALTIME). Well, it doesn't mean that the clock is accurate, but Python should not loose precision just because it uses floatting point instead of integers.

About the API: I chose to add a string argument to allow maybe later to support user defined formats, or at least add new builtin formats. For example, someone proposed 128 bits float in the issue #11457.

--

The internal format is:

typedef struct {
    time_t seconds;
    /* floatpart can be zero */
    size_t floatpart;
    /* divisor cannot be zero */
    size_t divisor;
    /* log10 of the clock resoltion, the real resolution is 10^resolution,
       resolution is in range [-9; 0] */
    int resolution;
} _PyTime_t;

I don't know if size_t is big enough to store any "floatpart" value: time.clock() uses a LARGE_INTEGER internally. I tested my patch on Linux 32 and 64 bits, but not yet on Windows.

The internal function encoding a timestamp to Decimal caches the resolution objects (10^resolution, common clock resolutions: 10^-6, 10^-9) in a dict, and a Context object.

I computed that 22 decimal digits should be enough to compute a timestamp of 10,000 years. Extract of my patch:

"Use 12 decimal digits to store 10,000 years in seconds + 9 decimal digits for the floating part in nanoseconds + 1 decimal digit to round correctly"

>>> str(int(3600*24*365.25*10000))
'315576000000'
>>> len(str(int(3600*24*365.25*10000)))
12

--

See also the issue #11457 which is linked to this topic, but not exactly the same because it concerns a low level function (os.stat()).

----------
components: Library (Lib)
files: time_decimal-2.patch
keywords: patch
messages: 152031
nosy: belopolsky, haypo, loewis
priority: normal
severity: normal
status: open
title: Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object
versions: Python 3.3
Added file: http://bugs.python.org/file24330/time_decimal-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13882>
_______________________________________

From report at bugs.python.org  Thu Jan 26 22:18:20 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 Jan 2012 21:18:20 +0000
Subject: [New-bugs-announce] [issue13883] PYTHONCASEOK docs mistakenly says
	it is limited to	Windows
Message-ID: <1327612700.31.0.384231885295.issue13883@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The docs for PYTHONCASEOK say it is limited to Windows, but in actuality in Python 3.x it applies to both Windows (including cygwin) and OS X. On Python 2.7 it applies to those plus RISCOS OS/2.

----------
assignee: docs at python
components: Documentation
messages: 152034
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: PYTHONCASEOK docs mistakenly says it is limited to Windows
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13883>
_______________________________________

From report at bugs.python.org  Fri Jan 27 00:41:04 2012
From: report at bugs.python.org (Tim McGreevy)
Date: Thu, 26 Jan 2012 23:41:04 +0000
Subject: [New-bugs-announce] [issue13884] IDLE 2.6.5 Recent Files undocks
Message-ID: <1327621264.5.0.587291207239.issue13884@psf.upfronthosting.co.za>


New submission from Tim McGreevy <mcgrete.drs at gmail.com>:

When selecting from menu:
File --> Recent Files
the 'Recent Files' dropdown list undocks from the IDLE gui / File dropdown list.  Even after selecting a past file, it remains open until closed manually.

Ubuntu LUCID
amd64
IDLE 2.6.5
TK version 8.5
All installed using Ubuntu supported PPA (Synaptic)

After closing 'Recent Files' subwindow, problem no longer persists until IDLE is terminated and restarted.

----------
components: IDLE
files: IDLE2.6.5_RecentFilesUndocked.png
messages: 152050
nosy: mcgrete
priority: normal
severity: normal
status: open
title: IDLE 2.6.5 Recent Files undocks
versions: Python 2.6
Added file: http://bugs.python.org/file24333/IDLE2.6.5_RecentFilesUndocked.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13884>
_______________________________________

From report at bugs.python.org  Fri Jan 27 09:25:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jan 2012 08:25:53 +0000
Subject: [New-bugs-announce] [issue13885] CVE-2011-3389: _ssl module always
	disables the CBC IV	attack countermeasure
Message-ID: <1327652753.95.0.174471030951.issue13885@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Original e-mail from Apple security team:

> Follow-up:  187806281
> 
> SSL 3.0 and TLS 1.0 are vulnerable to an attack described at
> 
> http://www.openssl.org/~bodo/tls-cbc.txt
> 
> OpenSSL includes a countermeasure which prevents the attack, but python
> 2.7 has, around line 372 of Modules/_ssl.c:
> 
> SSL_CTX_set_options(self->ctx, SSL_OP_ALL);
> 
> SSL_OP_ALL includes SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS which disables the 
> countermeasure.
> 
> 2.6 is similar.

----------
components: Extension Modules
messages: 152068
nosy: barry, benjamin.peterson, loewis, pitrou
priority: critical
severity: normal
stage: commit review
status: open
title: CVE-2011-3389: _ssl module always disables the CBC IV attack countermeasure
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13885>
_______________________________________

From report at bugs.python.org  Fri Jan 27 11:23:39 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 27 Jan 2012 10:23:39 +0000
Subject: [New-bugs-announce] [issue13886] readline-related test_builtin
	failure
Message-ID: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

I've recently come across a strange failure in the tests for the input()
built-in function:

    $ ./python -E -m test -v test_readline test_builtin

    [... snip ...]

    ======================================================================
    FAIL: test_input_tty_non_ascii (test.test_builtin.BuiltinTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1079, in test_input_tty_non_ascii
        self.check_input_tty("prompt?", b"quux\xe9", "utf-8")
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1070, in check_input_tty
        self.assertEqual(input_result, expected)
    AssertionError: 'quux' != 'quux\udce9'
    - quux
    + quux\udce9
    ?     +


    ======================================================================
    FAIL: test_input_tty_non_ascii_unicode_errors (test.test_builtin.BuiltinTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1083, in test_input_tty_non_ascii_unicode_errors
        self.check_input_tty("prompt?", b"quux\xe9", "ascii")
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1070, in check_input_tty
        self.assertEqual(input_result, expected)
    AssertionError: 'quux' != 'quux\udce9'
    - quux
    + quux\udce9
    ?     +

The failure only manifests itself if the readline module is loaded before
test_builtin runs (hence the presence of test_readline above). It will
not occur if regrtest is run with either of the -j or -W flags (which is
why it hasn't been seen on the buildbots).

The problem seems to be that readline assumes that its input should use
the locale encoding, and silently strips out any undecodable chars. This
breaks the tests mentioned above, since they set up sys.stdin to use the
surrogateescape error handler, expecting invalid characters to be escaped
rather than discarded.

This problem doesn't crop up if readline is *not* loaded, because in that
case PyOS_Readline() falls back to a stdio-based implementation
(PyOS_StdioReadline()) that preserves invalid characters, allowing them
to be handled properly by sys.stdin's encoding and error handler.

I have been able to fix the test failures with the attached patch, which
stops readline from eating invalid characters, making it consistent with
the stdio-based fallback. Can someone with more knowledge of readline
and/or locale issues advise whether the change is a good idea?

----------
components: Extension Modules
files: rl-locale.diff
keywords: patch
messages: 152080
nosy: nadeem.vawda
priority: normal
severity: normal
stage: patch review
status: open
title: readline-related test_builtin failure
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24337/rl-locale.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13886>
_______________________________________

From report at bugs.python.org  Fri Jan 27 11:50:03 2012
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Hees?=)
Date: Fri, 27 Jan 2012 10:50:03 +0000
Subject: [New-bugs-announce] [issue13887] defaultdict.get does not default
	to initial default but	None
Message-ID: <1327661403.58.0.135329216168.issue13887@psf.upfronthosting.co.za>


New submission from J?rn Hees <nrej9TyO at joernhees.de>:

I wanted to create a "function registrar" d using a defaultdict. The library that this registrar is passed to expects it to return functions taking 3 args. Now if the first call is d.get(x) it seems that in contrast to d[x] the default arg of get is returned (None) instead of the defaultdicts default. If i call d[x] first and then d.get(x) i get what i expected.

Example:

In [1]: def foo(a,b,c):
   ...:     return (a,b,c)
   ...: 

In [2]: from collections import defaultdict

In [3]: d = defaultdict(lambda:foo)

In [4]: d.get(1)

In [5]: d[1]
Out[5]: <function foo at 0x1015a2ed8>

In [6]: d.get(1)
Out[6]: <function foo at 0x1015a2ed8>

In [7]: d.get(2)(1,2,3)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/Users/joern/<ipython console> in <module>()

TypeError: 'NoneType' object is not callable

In [8]: d[2](1,2,3)
Out[8]: (1, 2, 3)

In [9]: d.get(2)(1,2,3)
Out[9]: (1, 2, 3)


I'm not sure this is the desired behavior, but it wasn't quite what i expected from a dictionary with a default.
If it is the desired behavior the documentation of defaultdict should include an explanation what happens.

----------
components: Extension Modules, Library (Lib)
messages: 152083
nosy: joern
priority: normal
severity: normal
status: open
title: defaultdict.get does not default to initial default but None
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13887>
_______________________________________

From report at bugs.python.org  Fri Jan 27 11:54:16 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 27 Jan 2012 10:54:16 +0000
Subject: [New-bugs-announce] [issue13888] test_builtin failure when run
	after test_tk
Message-ID: <1327661656.8.0.445863136974.issue13888@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

While investigating issue 13886, I found that test_builtin will fail when run
after test_tk:

    $ ./python -Wd -E -bb -m test -vuall test_tk test_builtin
    == CPython 3.3.0a0 (default:52f68c95e025, Jan 26 2012, 19:05:09) [GCC 4.6.1]
    ==   Linux-3.0.0-15-generic-x86_64-with-debian-wheezy-sid little-endian
    ==   /home/nadeem/src/cpython/def/build/test_python_4559
    Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0)

    [... snip ...]

    ======================================================================
    FAIL: test_input_tty (test.test_builtin.BuiltinTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1075, in test_input_tty
        self.check_input_tty("prompt", b"quux")
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1059, in check_input_tty
        % (len(lines), child_output.read()))
    AssertionError: got 0 lines in pipe but expected 2, child output was:
    quux

    promptCurrent thread 0x00007fb3bbed5720:
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1036 in check_input_tty
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1075 in test_input_tty
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 385 in _executeTestPart
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 440 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 492 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 105 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 67 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 105 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 67 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/runner.py", line 168 in run
      File "/home/nadeem/src/cpython/def/Lib/test/support.py", line 1369 in _run_suite
      File "/home/nadeem/src/cpython/def/Lib/test/support.py", line 1403 in run_unittest
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1469 in test_main
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 1221 in runtest_inner
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 918 in runtest
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 710 in main
      File "/home/nadeem/src/cpython/def/Lib/test/__main__.py", line 13 in <module>
      File "/home/nadeem/src/cpython/def/Lib/runpy.py", line 73 in _run_code
      File "/home/nadeem/src/cpython/def/Lib/runpy.py", line 160 in _run_module_as_main


    ======================================================================
    FAIL: test_input_tty_non_ascii (test.test_builtin.BuiltinTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1079, in test_input_tty_non_ascii
        self.check_input_tty("prompt?", b"quux\xe9", "utf-8")
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1059, in check_input_tty
        % (len(lines), child_output.read()))
    AssertionError: got 0 lines in pipe but expected 2, child output was:
    quux

    promptCurrent thread 0x00007fb3bbed5720:
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1036 in check_input_tty
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1079 in test_input_tty_non_ascii
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 385 in _executeTestPart
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 440 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 492 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 105 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 67 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 105 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 67 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/runner.py", line 168 in run
      File "/home/nadeem/src/cpython/def/Lib/test/support.py", line 1369 in _run_suite
      File "/home/nadeem/src/cpython/def/Lib/test/support.py", line 1403 in run_unittest
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1469 in test_main
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 1221 in runtest_inner
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 918 in runtest
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 710 in main
      File "/home/nadeem/src/cpython/def/Lib/test/__main__.py", line 13 in <module>
      File "/home/nadeem/src/cpython/def/Lib/runpy.py", line 73 in _run_code
      File "/home/nadeem/src/cpython/def/Lib/runpy.py", line 160 in _run_module_as_main


    ======================================================================
    FAIL: test_input_tty_non_ascii_unicode_errors (test.test_builtin.BuiltinTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1083, in test_input_tty_non_ascii_unicode_errors
        self.check_input_tty("prompt?", b"quux\xe9", "ascii")
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1059, in check_input_tty
        % (len(lines), child_output.read()))
    AssertionError: got 0 lines in pipe but expected 2, child output was:
    quux

    prompt?[xcb] Unknown sequence number while processing queue
    [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
    [xcb] Aborting, sorry about that.
    python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
    Fatal Python error: Aborted

    Current thread 0x00007fb3bbed5720:
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1036 in check_input_tty
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1083 in test_input_tty_non_ascii_unicode_errors
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 385 in _executeTestPart
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 440 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/case.py", line 492 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 105 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 67 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 105 in run
      File "/home/nadeem/src/cpython/def/Lib/unittest/suite.py", line 67 in __call__
      File "/home/nadeem/src/cpython/def/Lib/unittest/runner.py", line 168 in run
      File "/home/nadeem/src/cpython/def/Lib/test/support.py", line 1369 in _run_suite
      File "/home/nadeem/src/cpython/def/Lib/test/support.py", line 1403 in run_unittest
      File "/home/nadeem/src/cpython/def/Lib/test/test_builtin.py", line 1469 in test_main
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 1221 in runtest_inner
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 918 in runtest
      File "/home/nadeem/src/cpython/def/Lib/test/regrtest.py", line 710 in main
      File "/home/nadeem/src/cpython/def/Lib/test/__main__.py", line 13 in <module>
      File "/home/nadeem/src/cpython/def/Lib/runpy.py", line 73 in _run_code
      File "/home/nadeem/src/cpython/def/Lib/runpy.py", line 160 in _run_module_as_main

The failures will not occur if the test suite is run with the -j or -W flags,
as the failing tests are skipped if stdout is not a tty.

I've encountered the failures on both machines I've tested - one Ubuntu 11.10
64-bit (running Unity), and the other Xubuntu 11.10 32-bit (running XFCE).

----------
components: Tests
messages: 152084
nosy: gpolo, nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: test_builtin failure when run after test_tk
type: crash
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13888>
_______________________________________

From report at bugs.python.org  Fri Jan 27 15:58:23 2012
From: report at bugs.python.org (Samuel Iseli)
Date: Fri, 27 Jan 2012 14:58:23 +0000
Subject: [New-bugs-announce] [issue13889] str(float) and round(float) issues
	with FPU precision
Message-ID: <1327676303.66.0.487112802864.issue13889@psf.upfronthosting.co.za>


New submission from Samuel Iseli <samuel.iseli at gmail.com>:

We are using python as an embedded scripting environment in our ERP-product.
Since upgrading to python2.7 we have serious issues with floats:

>>> 28710.0
'2870:.0'
>>> round(28710.0)
2870.0

We are embedding Python in a Delphi-application.

The problem was already discussed in issue9980 and has to do with Delphi setting the FPU precision to 64bit (and relying on this setting) while the standard with Microsoft Tools is 53bits.
The routines _Py_dg_dtoa and _Py_dg_strtod in dtoa.c rely on the FPU precision set to 53bits.

Issue9980 was closed as "won't fix" but I propose to reconsider this decision for the following reasons:

- Delphi is still an important development environment for native win32 applications and has excellent Python embedding support through PythonForDelphi (http://code.google.com/p/python4delphi).

- Ensuring 53bit before calling python code is not practical in an embedded python environment with extensions in delphi (python may also call code that is implemented in delphi).

- The changes needed in pythoncore are minimal. Tests documented in issue9980 found no measurable performance impact.

- FPU precision switching is needed and already (partially) implemented for linx, where 64bit prec is standard.

Fixing this issues is absolutely vital for us, so we needed to compile a custom version of pythoncore.

I appended a .diff file detailling the patch.

Changes are needed in 2 places:
- pyport.h, defining the _PY_SET_53_BIT_PRECISION macros for MS visual c compiler
- floatobject.c, insert precision switching macros in _Py_double_round function.

In pystrtod.c the precision switching macros are already used.
pystrtod.c and floatobject.c are the only places in CPython where the dtoa.c functions are called.

The macros for visual-c are activated by defining HAVE_VC_FUNC_FOR_X87 preprocessor-symbol.

Hoping for inclusion of this patch.

Cheers
Samuel

----------
components: Interpreter Core
files: 120127_float_dtoa_fix_py2.7.2.diff
keywords: patch
messages: 152099
nosy: samuel.iseli
priority: normal
severity: normal
status: open
title: str(float) and round(float) issues with FPU precision
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file24341/120127_float_dtoa_fix_py2.7.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13889>
_______________________________________

From report at bugs.python.org  Fri Jan 27 17:50:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jan 2012 16:50:57 +0000
Subject: [New-bugs-announce] [issue13890] test_importlib failures under
	Windows
Message-ID: <1327683057.17.0.810855079387.issue13890@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I don't know if these are related to the latest changes, but they only appear on the 3.3 buildbots:

======================================================================
FAIL: test_case_insensitivity (importlib.test.extension.test_case_sensitivity.ExtensionModuleCaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\importlib\test\extension\test_case_sensitivity.py", line 30, in test_case_insensitivity
    self.assertTrue(hasattr(loader, 'load_module'))
AssertionError: False is not true

======================================================================
FAIL: test_insensitive (importlib.test.source.test_case_sensitivity.CaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\importlib\test\source\test_case_sensitivity.py", line 51, in test_insensitive
    self.assertTrue(hasattr(insensitive, 'load_module'))
AssertionError: False is not true

----------
components: Library (Lib), Tests
messages: 152102
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importlib failures under Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13890>
_______________________________________

From report at bugs.python.org  Fri Jan 27 18:33:53 2012
From: report at bugs.python.org (John Zimmerman)
Date: Fri, 27 Jan 2012 17:33:53 +0000
Subject: [New-bugs-announce] [issue13891] CPU DoS With Python's socket module
Message-ID: <1327685633.34.0.235701506916.issue13891@psf.upfronthosting.co.za>


New submission from John Zimmerman <johzimme at cisco.com>:

Python's socket module as included in Ubuntu Lucid (python version 2.6.5) does not correctly handle and exclude malformed UDP packets. This means that UDP listening programs written in python on this version are susceptible to malformed-UDP-packet based DoS attacks which cause severe CPU spikes in the python process. The spikes to recover once the attacks cease. If malformed UDP packets are properly identified in the library and excluded this will protect all UDP listening software written in python and using the standard sockets module from similar attacks. Currently all such software is vulnerable to such attacks.

----------
components: Library (Lib)
messages: 152103
nosy: johzimme
priority: normal
severity: normal
status: open
title: CPU DoS With Python's socket module
type: security
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13891>
_______________________________________

From report at bugs.python.org  Fri Jan 27 22:09:25 2012
From: report at bugs.python.org (Jack Jansen)
Date: Fri, 27 Jan 2012 21:09:25 +0000
Subject: [New-bugs-announce] [issue13892] distutils handling of windows
	manifest isn't optimal
Message-ID: <1327698565.84.0.667656042788.issue13892@psf.upfronthosting.co.za>


New submission from Jack Jansen <jackjansen at users.sourceforge.net>:

I found a problem with the handling of manifest files in the msvc9compiler. Distutils removes the reference to the MSVC runtime from the manifest resource, to enable installing the runtime system locally (i.e. to allow non-admins to install Python in their own directory, without needing admin access to the winSxS directory). Embedders of Python are suggested to the manifest for the MSCV runtime to their main program (i.e. the program embedding Python).

This is all a good idea, except for one use case: if you are including Python into a product that is itself a plugin to another product. And, of course, if you need to extend this Python with an extension module. In this case, you have no control over the manifest of the main program (which is the outer embedder). You have control over your own plugin (the one incorporating Python), but this intermediate manifest file is not taken into account when loading the distutils-generated .pyd file.

(imagining the amount of time it took me before I got to this analysis is left as an exercise to the reader:-)

I would suggest an option to distutils to skip the _remove_visual_c_ref() step.

----------
assignee: tarek
components: Distutils
messages: 152119
nosy: eric.araujo, jackjansen, tarek
priority: normal
severity: normal
status: open
title: distutils handling of windows manifest isn't optimal
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13892>
_______________________________________

From report at bugs.python.org  Sat Jan 28 00:12:16 2012
From: report at bugs.python.org (Giovanni Funchal)
Date: Fri, 27 Jan 2012 23:12:16 +0000
Subject: [New-bugs-announce] [issue13893] Make CGIHTTPServer capable of
	redirects (and status	other than 200)
Message-ID: <1327705936.4.0.817960222769.issue13893@psf.upfronthosting.co.za>


New submission from Giovanni Funchal <gafunchal at gmail.com>:

GIHTTPServer.py is a very handy module for quickly setting up a full HTTP server with CGI support. However, I noticed that it doesn't support responses other than "200 OK". So, for instance if the page wants to do a redirect (response 303), it just isn't supported. It's documented as so, but still I think this is a major drawback that can be easily overcome.

I have attached a patch against 2.7. I'd be happy to port it to dev branch if help provided as I'm new to Python. Reviews/suggestions more than welcome.

----------
components: Library (Lib)
files: CGIHTTPServer.patch
keywords: patch
messages: 152137
nosy: Giovanni.Funchal
priority: normal
severity: normal
status: open
title: Make CGIHTTPServer capable of redirects (and status other than 200)
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24342/CGIHTTPServer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13893>
_______________________________________

From report at bugs.python.org  Sat Jan 28 09:44:02 2012
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 28 Jan 2012 08:44:02 +0000
Subject: [New-bugs-announce] [issue13894] threading._CRLock should not be
	tested if _thread.RLock	isn't implemented
Message-ID: <1327740242.45.0.88821278342.issue13894@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

_threading.RLock is optional, and threading._CRLock is set to None if it isn't available. If this happens, the test_threading unittests crash.

Some implementations don't provide _thread.RLock.

Patch attached.

----------
components: Library (Lib)
files: skip-crlock-tests-if-not-implemented.patch
keywords: patch
messages: 152151
nosy: anacrolix
priority: normal
severity: normal
status: open
title: threading._CRLock should not be tested if _thread.RLock isn't implemented
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24345/skip-crlock-tests-if-not-implemented.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13894>
_______________________________________

From report at bugs.python.org  Sat Jan 28 11:38:16 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 28 Jan 2012 10:38:16 +0000
Subject: [New-bugs-announce] [issue13895] test_ssl hangs on Ubuntu
Message-ID: <1327747096.81.0.709589342449.issue13895@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

Since changeset b99c54acb22d, the ARM Ubuntu buildbot has been hanging in test_ssl:

    http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/250/steps/test/logs/stdio

I've been able to reproduce this behaviour on my AMD64 Ubuntu 11.10 machine.
The last output before it hangs is:

    test_protocol_sslv3 (test.test_ssl.ThreadedTests)
    Connecting to an SSLv3 server with various client options ... 
     SSLv3->SSLv3 CERT_NONE
     SSLv3->SSLv3 CERT_OPTIONAL
     SSLv3->SSLv3 CERT_REQUIRED
     {SSLv23->SSLv3} CERT_NONE

No such problem has shown up on the x86 Ubuntu Shared builder. This is probably
because it runs Ubuntu 8.04, whereas the ARM bot runs 11.10.

----------
messages: 152156
nosy: barry, giampaolo.rodola, janssen, nadeem.vawda, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl hangs on Ubuntu
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13895>
_______________________________________

From report at bugs.python.org  Sat Jan 28 12:12:30 2012
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 28 Jan 2012 11:12:30 +0000
Subject: [New-bugs-announce] [issue13896] shelf doesn't work with 'with'
Message-ID: <1327749150.13.0.147725255938.issue13896@psf.upfronthosting.co.za>


New submission from Filip Gruszczy?ski <gruszczy at gmail.com>:

It would be cool if use could use with to manage shelf object and forget about close.

----------
messages: 152159
nosy: gruszczy
priority: normal
severity: normal
status: open
title: shelf doesn't work with 'with'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13896>
_______________________________________

From report at bugs.python.org  Sat Jan 28 17:24:47 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 28 Jan 2012 16:24:47 +0000
Subject: [New-bugs-announce] [issue13897] Move fields relevant to
	coroutine/generators out of	frame into generator/threadstate
Message-ID: <1327767887.13.0.0676848614688.issue13897@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

The frame object has a number of fields which belong to the generator object.
By creating a CoState struct, these fields can be moved to generator/threadstate where they belong.

The interpreter no longer has to swap around exception state whenever generators are entered/exited.
The frame object is made more compact, reducing allocation/deallocation overhead (although benchmarking showed no significant difference) 

The attached patch reduces the code base by about 50 LOC overall.

----------
components: Interpreter Core
files: coro.patch
keywords: patch
messages: 152167
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Move fields relevant to coroutine/generators out of frame into generator/threadstate
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24350/coro.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13897>
_______________________________________

From report at bugs.python.org  Sat Jan 28 17:52:44 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 28 Jan 2012 16:52:44 +0000
Subject: [New-bugs-announce] [issue13898] Ignored exception in test_ssl
Message-ID: <1327769564.73.0.643604928649.issue13898@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

While running test_ssl in verbose mode, I noticed the following exception:

    [...]
    test_protocol_sslv3 (test.test_ssl.ThreadedTests)
    Connecting to an SSLv3 server with various client options ... 
     SSLv3->SSLv3 CERT_NONE
     SSLv3->SSLv3 CERT_OPTIONAL
     SSLv3->SSLv3 CERT_REQUIRED
     {SSLv23->SSLv3} CERT_NONE
    Exception in thread Thread-54:
    Traceback (most recent call last):
      File "/home/nadeem/src/cpython/def/Lib/threading.py", line 730, in _bootstrap_inner
        self.run()
      File "/home/nadeem/src/cpython/def/Lib/test/test_ssl.py", line 926, in run
        if not self.wrap_conn():
      File "/home/nadeem/src/cpython/def/Lib/test/test_ssl.py", line 880, in wrap_conn
        self.sock, server_side=True)
      File "/home/nadeem/src/cpython/def/Lib/ssl.py", line 206, in wrap_socket
        _context=self)
      File "/home/nadeem/src/cpython/def/Lib/ssl.py", line 293, in __init__
        raise x
      File "/home/nadeem/src/cpython/def/Lib/ssl.py", line 289, in __init__
        self.do_handshake()
      File "/home/nadeem/src/cpython/def/Lib/ssl.py", line 489, in do_handshake
        self._sslobj.do_handshake()
    ConnectionResetError: [Errno 104] Connection reset by peer

     {TLSv1->SSLv3} CERT_NONE
     SSLv23->SSLv3 CERT_NONE
    ok
    [...]

Note that the exception is ignored and the test still passes.

----------
components: Tests
messages: 152172
nosy: giampaolo.rodola, janssen, nadeem.vawda, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Ignored exception in test_ssl
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13898>
_______________________________________

From report at bugs.python.org  Sat Jan 28 23:28:53 2012
From: report at bugs.python.org (John Machin)
Date: Sat, 28 Jan 2012 22:28:53 +0000
Subject: [New-bugs-announce] [issue13899] re pattern r"[\A]" should work
	like "A" but matches	nothing. Ditto B and Z.
Message-ID: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at lexicon.net>:

Expected behaviour illustrated using "C":

>>> import re
>>> re.findall(r'[\C]', 'CCC')
['C', 'C', 'C']
>>> re.compile(r'[\C]', 128)
literal 67
<_sre.SRE_Pattern object at 0x01FC6E78>
>>> re.compile(r'C', 128)
literal 67
<_sre.SRE_Pattern object at 0x01FC6F08>

Incorrect behaviour exhibited by "A" (and by "B" and 
Z"):

>>> re.findall(r'[\A]', 'AAA')
[]
>>> re.compile(r'A', 128)
literal 65
<_sre.SRE_Pattern object at 0x01FC6F98>
>>> re.compile(r'[\A]', 128)
in
  at at_beginning_string #### FAIL ####
<_sre.SRE_Pattern object at 0x01FDF0B0>
>>>

Also there is no self-checking at runtime; the switch default has a comment to the effect that nothing can be done, so pretend that the unknown opcode matched nothing. Zen?

----------
messages: 152194
nosy: sjmachin
priority: normal
severity: normal
status: open
title: re pattern r"[\A]" should work like "A" but matches nothing. Ditto B and Z.
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13899>
_______________________________________

From report at bugs.python.org  Sun Jan 29 06:29:06 2012
From: report at bugs.python.org (Parker Phinney)
Date: Sun, 29 Jan 2012 05:29:06 +0000
Subject: [New-bugs-announce]
	[issue13900]	http://docs.python.org/library/email.parser.html#email.parser.Parser.parse
Message-ID: <1327814946.33.0.356095199195.issue13900@psf.upfronthosting.co.za>


Changes by Parker Phinney <gameguy43 at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: Parker.Phinney, docs at python
priority: normal
severity: normal
status: open
title: http://docs.python.org/library/email.parser.html#email.parser.Parser.parse
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13900>
_______________________________________

From report at bugs.python.org  Sun Jan 29 09:46:45 2012
From: report at bugs.python.org (toggtc)
Date: Sun, 29 Jan 2012 08:46:45 +0000
Subject: [New-bugs-announce] [issue13901] test_get_outputs (test_distutils)
	failure with	--enable-shared on Mac OS X
Message-ID: <1327826805.0.0.304314009246.issue13901@psf.upfronthosting.co.za>


New submission from toggtc <toggtc at gmail.com>:

Current 2.7.2 + building on OS X 10.7.2 and gcc 4.2.1 (Apple build 5666.3):

i686-apple-darwin11-gcc-4.2.1: /private/var/folders/jy/dhptnvj90b34s0135sb_g6w80000gn/T/tmpAfN6sj/foo.so: No such file or directory

======================================================================
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/toggtc/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/distutils/tests/test_build_ext.py", line 291, in test_get_outputs
    cmd.run()
  File "/Users/toggtc/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/Users/toggtc/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/distutils/command/build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "/Users/toggtc/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/distutils/command/build_ext.py", line 531, in build_extension
    target_lang=language)
  File "/Users/toggtc/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/distutils/ccompiler.py", line 741, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/Users/toggtc/.pythonbrew/pythons/Python-2.7.2/lib/python2.7/distutils/unixccompiler.py", line 258, in link
    raise LinkError, msg
LinkError: command 'gcc' failed with exit status 1
----

"DYLD_LIBRARY_PATH" is not defined in default environment of OS X.
but, ./configure and ./configure.in are:
    Darwin*)
    	LDLIBRARY='libpython$(VERSION).dylib'
	BLDLIBRARY='-L. -lpython$(VERSION)'
	RUNSHARED='DYLD_LIBRARY_PATH=`pwd`:${DYLD_LIBRARY_PATH}'

=> RUNSHARED=DYLD_LIBRARY_PATH=`pwd`:

and, test_build_ext.py:
 53     def _fixup_command(self, cmd):
 ...
 63         if (sysconfig.get_config_var('Py_ENABLE_SHARED') and
 64             not sys.platform.startswith('win')):
 65             runshared = sysconfig.get_config_var('RUNSHARED')
 66             if runshared is None:
 67                 cmd.library_dirs = ['.']
 68             else:
 69                 name, equals, value = runshared.partition('=')
 70                 cmd.library_dirs = value.split(os.pathsep)

=> library_dirs=['`pwd`', '']

link command via unixccompier:
gcc-4.2 ... /foo.o -L`pwd` -L (empty!) -o /private/var/folder.../foo.so

=> "No such file or directory"
---

(for 2.7.2) https://raw.github.com/toggtc/python-patch/master/2.7.2/distutils_test_fixup_command_2.7.2.patch
(for 3.2.2) https://raw.github.com/toggtc/python-patch/master/3.2.2/distutils_test_fixup_command_3.2.2.patch

----------
assignee: tarek
components: Distutils, Macintosh
messages: 152219
nosy: eric.araujo, tarek, toggtc
priority: normal
severity: normal
status: open
title: test_get_outputs (test_distutils) failure with --enable-shared on Mac OS X
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13901>
_______________________________________

From akscool.1990 at gmail.com  Sun Jan 29 14:07:20 2012
From: akscool.1990 at gmail.com (akshay suri)
Date: Sun, 29 Jan 2012 18:37:20 +0530
Subject: [New-bugs-announce] error in running IDLE
Message-ID: <CAO2O6tjsZ9x5j_PTFXdBCV6uk_9NSPB1BKfmTqb_a47vQcyzmg@mail.gmail.com>

i am using windows 7.
I'm having trouble with opening the python 2.6 IDLE-program. When I try to
start
it, it gives an errormessage wich states that it can not make a connection,
possibly because of a firewall. However, adding it to firewalls exeptions or
even disabeling the firewall has no effect.

These are the errors:
1st. 'Socket error: Connection refused', with the name IDLE subprocess Error
2nd. 'IDLE's subprocess didn't make connection. Either IDLE can't start a
subprocess or personal firewall software is blocking the connection.

Please help.......

-- 


*Regards,*

AKSHAY SURI
B.Tech | ECE
University  |  JIIT,NOIDA
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20120129/749517a3/attachment.html>

From report at bugs.python.org  Sun Jan 29 14:53:31 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 29 Jan 2012 13:53:31 +0000
Subject: [New-bugs-announce] [issue13902] Sporadic test_threading failure on
	FreeBSD 6.4 buildbot
Message-ID: <1327845211.23.0.0250327265855.issue13902@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/2206/steps/test/logs/stdio

    FAIL: test_6_daemon_threads (test.test_threading.ThreadJoinOnShutdown)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_threading.py", line 675, in test_6_daemon_threads
        self.assertFalse(err)
    AssertionError: b'[52879 refs]\nT' is not false

----------
components: Tests
keywords: buildbot
messages: 152226
nosy: nadeem.vawda, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Sporadic test_threading failure on FreeBSD 6.4 buildbot
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13902>
_______________________________________

From report at bugs.python.org  Sun Jan 29 15:26:46 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Jan 2012 14:26:46 +0000
Subject: [New-bugs-announce] [issue13903] New shared-keys dictionary
	implementation
Message-ID: <1327847206.97.0.499643364955.issue13903@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

The proposed dictionary implementation allows sharing of keys & hashes between dictionaries. This leads to substantial memory savings for object-oriented programs. For non-OO programs the impact is negligible.

----------
components: Interpreter Core
hgrepos: 109
messages: 152229
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: New shared-keys dictionary implementation
type: performance
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13903>
_______________________________________

From report at bugs.python.org  Sun Jan 29 17:38:40 2012
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 29 Jan 2012 16:38:40 +0000
Subject: [New-bugs-announce] [issue13904] Generator as *args: TypeError
	replaced
Message-ID: <1327855120.91.0.5569840716.issue13904@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

>>> set().union(*(None[k] for k in range(5)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: union() argument after * must be a sequence, not generator

Clearly, exception in not relevant, since next line works:

>>> set().union(*([k] for k in range(5)))
{0, 1, 2, 3, 4}

Correct exception would be

>>> None[1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not subscriptable

Problem is in python function call mechanics.
set().union can be replaced by any callable;
Generator can be replaced by any TypeError-raising iterable. Exceptions other then TypeError are handled correctly.

Python/ceval.c:4322
ext_do_call() converts stararg to tuple.
If any TypeError is raised, it is replaced with
TypeError("%s argument after * must be a sequence, not %s")


Proposed solution:

Probably, we can avoid replacing TypeError. Exceptions in the above cases would become relevant, and

>>> int(*None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type object argument after * must be a sequence, not NoneType

would become

>>> int(*None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not iterable

so exception is still recognizable (and, may be, even more relevant, since we don't actually need _sequence_ as stararg, _iterable_ would be enough).

----------
components: Interpreter Core
files: typeerror-replaced-in-stararg.diff
keywords: patch
messages: 152243
nosy: july
priority: normal
severity: normal
status: open
title: Generator as *args: TypeError replaced
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24358/typeerror-replaced-in-stararg.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13904>
_______________________________________

From report at bugs.python.org  Sun Jan 29 20:58:52 2012
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 29 Jan 2012 19:58:52 +0000
Subject: [New-bugs-announce] [issue13905] Built-in Types Comparisons should
	mention rich	comparison methods
Message-ID: <1327867132.3.0.913390477966.issue13905@psf.upfronthosting.co.za>


New submission from Catalin Iacob <iacobcatalin at gmail.com>:

In 2.7 the Comparisons section of stdtypes.rst only talks about __cmp__ and never mentions the rich comparison methods:
"Instances of a class normally compare as non-equal unless the class defines the __cmp__() method. Refer to Basic customization) for information on the use of this method to effect object comparisons."

The first sentence is false, instances can also compare as equal if they define __eq__. And since __cmp__ is gone in Python3, I think the rich comparison methods should at least be mentioned, or even emphasized over __cmp__ to help people write more forward compatible code.

----------
assignee: docs at python
components: Documentation
messages: 152254
nosy: catalin.iacob, docs at python
priority: normal
severity: normal
status: open
title: Built-in Types Comparisons should mention rich comparison methods
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13905>
_______________________________________

From report at bugs.python.org  Sun Jan 29 23:18:07 2012
From: report at bugs.python.org (Alexander Maksimenko)
Date: Sun, 29 Jan 2012 22:18:07 +0000
Subject: [New-bugs-announce] [issue13906] mimetypes.py under windows - bad
	exception catch
Message-ID: <1327875487.38.0.0330076110954.issue13906@psf.upfronthosting.co.za>


New submission from Alexander Maksimenko <alex.mclander at gmail.com>:

mimetypes.py(249) expectts Unicode*En*codeError, but Unicode*De*codeError happens when registry has non latin symbols (Vista Home 64).

I just change cathc jn next line to UnicodeDecodeError and all now works fine. But may be error not here, but on encode method which raise "negative" exception


F:\>c:\python27\python -m SimpleHTTPServer
Traceback (most recent call last):
  File "test.py", line 2, in <module>
    import SimpleHTTPServer
  File "c:\python27\lib\SimpleHTTPServer.py", line 27, in <module>
    class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
  File "c:\python27\lib\SimpleHTTPServer.py", line 204, in SimpleHTTPRequestHandler
    mimetypes.init() # try to read system mime.types
  File "c:\python27\lib\mimetypes.py", line 355, in init
    db.read_windows_registry()
  File "c:\python27\lib\mimetypes.py", line 259, in read_windows_registry
    for ctype in enum_types(mimedb):
  File "c:\python27\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)


---------- here after changes -----------------

F:\>c:\python27\python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
mc-quad - - [30/Jan/2012 02:02:18] "GET / HTTP/1.1" 200 -
mc-quad - - [30/Jan/2012 02:02:18] code 404, message File not found
mc-quad - - [30/Jan/2012 02:02:18] "GET /favicon.ico HTTP/1.1" 404 -

----------
components: Library (Lib)
messages: 152267
nosy: mclander
priority: normal
severity: normal
status: open
title: mimetypes.py under windows - bad exception catch
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13906>
_______________________________________

From report at bugs.python.org  Sun Jan 29 23:45:27 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Jan 2012 22:45:27 +0000
Subject: [New-bugs-announce] [issue13907] test_pprint relies on
	set/dictionary repr() ordering
Message-ID: <1327877127.5.0.775790034164.issue13907@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

The function test_set_reprs() includes the comment:
"Consequently, this test is fragile and implementation-dependent"
Changing the dictionary iteration ordering breaks it.

----------
components: Tests
messages: 152272
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: test_pprint relies on set/dictionary repr() ordering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13907>
_______________________________________

From report at bugs.python.org  Mon Jan 30 00:17:09 2012
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 29 Jan 2012 23:17:09 +0000
Subject: [New-bugs-announce] [issue13908] PyType_FromSpec() lacks
	PyType_Ready() call
Message-ID: <1327879029.72.0.4665491693.issue13908@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

As already stated by Amaury in http://mail.python.org/pipermail/python-dev/2011-October/113829.html, that leads to crashes:

>>> import xxlimited
>>> repr(xxlimited.Str)
[1]    19575 segmentation fault (core dumped)  ./python

----------
files: pytype_fromspec.patch
keywords: patch
messages: 152282
nosy: Trundle, amaury.forgeotdarc, loewis
priority: normal
severity: normal
status: open
title: PyType_FromSpec() lacks PyType_Ready() call
type: crash
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24363/pytype_fromspec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13908>
_______________________________________

From report at bugs.python.org  Mon Jan 30 00:25:34 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Jan 2012 23:25:34 +0000
Subject: [New-bugs-announce] [issue13909] Ordering of free variables in dis
	is dependent on dict	ordering.
Message-ID: <1327879534.06.0.507724097117.issue13909@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

This only seems to apply to free variables, not local or cell variables.

The offending tests are lines 429 & 430 of Lib/test/test_dis.py
      (tricky, code_info_tricky),
      (co_tricky_nested_f, code_info_tricky_nested_f),


Changing PyDict_MINSIZE to 4 provokes this failure
python3 -m test.test_dis

----------
components: Tests
messages: 152284
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Ordering of free variables in dis is dependent on dict ordering.
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13909>
_______________________________________

From report at bugs.python.org  Mon Jan 30 00:31:12 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Jan 2012 23:31:12 +0000
Subject: [New-bugs-announce] [issue13910] test_packaging is dependent on
	dict ordering.
Message-ID: <1327879872.45.0.0954403986846.issue13910@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

Changing PyDict_MINSIZE to 4 causes the following failure:

python -m test.test_packaging
...
Traceback (most recent call last):
  File "/home/mark/python/cpython/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/mark/python/cpython/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/mark/python/cpython/Lib/test/test_packaging.py", line 5, in <module>
    test_main()
  File "/home/mark/python/cpython/Lib/test/support.py", line 1496, in decorator
    return func(*args)
  File "/home/mark/python/cpython/Lib/packaging/tests/__main__.py", line 18, in test_main
    run_unittest(test_loader.discover(start_dir, top_level_dir=top_dir))
  File "/home/mark/python/cpython/Lib/test/support.py", line 1403, in run_unittest
    _run_suite(suite)
  File "/home/mark/python/cpython/Lib/test/support.py", line 1378, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/home/mark/python/cpython/Lib/packaging/tests/test_create.py", line 168, in test_convert_setup_py_to_cfg
    """))
AssertionError: '[metadata]\nname = pyxfoil\nversion = 0.2\nsummary = Python bindings for the Xf [truncated]... != '[metadata]\nname = pyxfoil\nversion = 0.2\nsummary = Python bindings for the Xf [truncated]...
  [metadata]
  name = pyxfoil
  version = 0.2
  summary = Python bindings for the Xfoil engine
  download_url = UNKNOWN
  home_page = http://www.python-science.org/project/pyxfoil
  maintainer = Andr? Espaze
  maintainer_email = andre.espaze at logilab.fr
  description = My super Death-scription
         |barbar is now on the public domain,
         |ho, baby !

  [files]
  packages = pyxfoil
      babar
      me
  modules = my_lib
      mymodule
  scripts = my_script
      bin/run
  extra_files = Martinique/Lamentin/dady
      Martinique/Lamentin/mumy
      Martinique/Lamentin/sys
      Martinique/Lamentin/bro
      setup.py
      README
-     pyxfoil/fengine.so
      Pom
      Flora
      Alexander
+     pyxfoil/fengine.so

  resources =
      README.rst = {doc}
      pyxfoil.1 = {man}

----------
messages: 152286
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: test_packaging is dependent on dict ordering.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13910>
_______________________________________

From report at bugs.python.org  Mon Jan 30 00:35:52 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Jan 2012 23:35:52 +0000
Subject: [New-bugs-announce] [issue13911] test_trace depends on dict repr()
	ordering
Message-ID: <1327880152.89.0.0711859595035.issue13911@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

Changing PyDict_MINSIZE to 4 causes the following failure
python -m test.test_trace  
... 
======================================================================
ERROR: test_coverage (__main__.TestCoverage)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mark/python/cpython/Lib/test/test_trace.py", line 307, in test_coverage
    self._coverage(tracer)
  File "/home/mark/python/cpython/Lib/test/test_trace.py", line 300, in _coverage
    tracer.run(cmd)
  File "/home/mark/python/cpython/Lib/trace.py", line 501, in run
    self.runctx(cmd, dict, dict)
  File "/home/mark/python/cpython/Lib/trace.py", line 509, in runctx
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/home/mark/python/cpython/Lib/test/test_pprint.py", line 479, in test_main
    test.support.run_unittest(QueryTestCase)
  File "/home/mark/python/cpython/Lib/test/support.py", line 1403, in run_unittest
    _run_suite(suite)
  File "/home/mark/python/cpython/Lib/test/support.py", line 1378, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/home/mark/python/cpython/Lib/test/test_pprint.py", line 273, in test_set_reprs
    self.assertEqual(pprint.pformat(cube), cube_repr_tgt)
AssertionError: '{frozenset(): frozenset({frozenset({2}), frozenset({0}), frozenset({1})}),\n fr [truncated]... != '{frozenset(): frozenset({frozenset({2}), frozenset({0}), frozenset({1})}),\n fr [truncated]...
Diff is 1436 characters long. Set self.maxDiff to None to see it.


======================================================================
ERROR: test_coverage_ignore (__main__.TestCoverage)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mark/python/cpython/Lib/test/test_trace.py", line 322, in test_coverage_ignore
    self._coverage(tracer)
  File "/home/mark/python/cpython/Lib/test/test_trace.py", line 300, in _coverage
    tracer.run(cmd)
  File "/home/mark/python/cpython/Lib/trace.py", line 501, in run
    self.runctx(cmd, dict, dict)
  File "/home/mark/python/cpython/Lib/trace.py", line 509, in runctx
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/home/mark/python/cpython/Lib/test/test_pprint.py", line 479, in test_main
    test.support.run_unittest(QueryTestCase)
  File "/home/mark/python/cpython/Lib/test/support.py", line 1403, in run_unittest
    _run_suite(suite)
  File "/home/mark/python/cpython/Lib/test/support.py", line 1378, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/home/mark/python/cpython/Lib/test/test_pprint.py", line 273, in test_set_reprs
    self.assertEqual(pprint.pformat(cube), cube_repr_tgt)
AssertionError: '{frozenset(): frozenset({frozenset({2}), frozenset({0}), frozenset({1})}),\n fr [truncated]... != '{frozenset(): frozenset({frozenset({2}), frozenset({0}), frozenset({1})}),\n fr [truncated]...
Diff is 1436 characters long. Set self.maxDiff to None to see it.

----------
components: Tests
messages: 152288
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: test_trace  depends on dict repr() ordering
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13911>
_______________________________________

From report at bugs.python.org  Mon Jan 30 18:00:47 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 30 Jan 2012 17:00:47 +0000
Subject: [New-bugs-announce] [issue13912] ImportError using __import__ and
	relative level 1
Message-ID: <1327942847.95.0.649353892202.issue13912@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

The Python 2.7.2 docs say this about __import__:

    Positive values for level indicate the number of parent directories to search relative to the directory of the module calling __import__().

But I find that even when setting level=1, the parent directory is not searched.

I've created this project tree to replicate the issue:

    jaraco at devjaraco:~$ tree master
    master
    ??? __init__.py
    ??? pkgA
    ??? ??? foo.py
    ??? ??? __init__.py
    ??? pkgB
        ??? bar.py
        ??? __init.py

    2 directories, 5 files
    jaraco at devjaraco:~$ cat master/pkgA/foo.py

    bar = __import__('pkgB', level=1).bar
    jaraco at devjaraco:~$ cat master/pkgB/bar.py
    var = "success"

It fails as so with python 2.7.2:

    jaraco at devjaraco:~$ python2.7 -c "import master.pkgA.foo"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "master/pkgA/foo.py", line 2, in <module>
        bar = __import__('pkgB', level=1).bar
    ImportError: No module named pkgB


It's conceivable I'm not using this correctly, but if so, I'm unable to find my mistake. I've confirmed that foo.__name__ is 'master.pkgA.foo'. I've tried using level=2 (in case I was off by one, but that wasn't the case).

----------
components: Interpreter Core
messages: 152331
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: ImportError using __import__ and relative level 1
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13912>
_______________________________________

From report at bugs.python.org  Tue Jan 31 18:27:56 2012
From: report at bugs.python.org (Kang-Hao (Kenny) Lu)
Date: Tue, 31 Jan 2012 17:27:56 +0000
Subject: [New-bugs-announce] [issue13913] utf-8 or utf8 or utf-8 (codec
	display name inconsistency)
Message-ID: <1328030876.68.0.627537179228.issue13913@psf.upfronthosting.co.za>


New submission from Kang-Hao (Kenny) Lu <kennyluck at csail.mit.edu>:

Since Python 3.2.2 (I don't have earlier version to test with),

>>> "\udc80".encode("utf-8")
UnicodeEncodeError: *utf-8* codec can't encode character '\udc80'...

but

>>> b"\xff".decode("utf-8")
UnicodeDecodeError: *utf8* codec can't decode byte 0xff in position 0

and the table on the documentation of the codec module suggests *utf_8* as the name of the codec, which I believe to be equivalent to "utf_8" because '-' is not a valid character of an identifier.

Can we at least make the above two consistent? I would go for "utf-8", which was probably introduced for rejecting surrogates, but "utf8" has been there for years. What do we do? I am happy to submit patches for all branches. These are one-liners anyway.

The backward compatibility risk should be pretty low as usually you don't get encoding from these errors and I don't see any use of PyUnicode(Encode|Decode)Error_GetEncoding in trunk, although I'm using it for issue #12892. 

Also, "latin_1" displays as *latin-1* but "iso2022-jp" displays as *iso2022_jp*. I care less about this nit though.

----------
components: Unicode
messages: 152399
nosy: ezio.melotti, kennyluck
priority: normal
severity: normal
status: open
title: utf-8 or utf8 or utf-8 (codec display name inconsistency)
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13913>
_______________________________________

From report at bugs.python.org  Tue Jan 31 22:45:41 2012
From: report at bugs.python.org (py.user)
Date: Tue, 31 Jan 2012 21:45:41 +0000
Subject: [New-bugs-announce] [issue13914] In module re the repeat interval
	{} doesn't accept	numbers greater than 65535
Message-ID: <1328046341.18.0.439922472722.issue13914@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> import re
>>> len(re.search(r'a+', 'a' * 100000).group())
100000
>>>
>>> re.search(r'a{65536,}', 'a' * 100000)
Traceback (most recent call last):
  File "/usr/local/lib/python3.2/functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (<class 'str'>, 'a{65536,}', 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/re.py", line 158, in search
    return _compile(pattern, flags).search(string)
  File "/usr/local/lib/python3.2/re.py", line 255, in _compile
    return _compile_typed(type(pattern), pattern, flags)
  File "/usr/local/lib/python3.2/functools.py", line 180, in wrapper
    result = user_function(*args, **kwds)
  File "/usr/local/lib/python3.2/re.py", line 267, in _compile_typed
    return sre_compile.compile(pattern, flags)
  File "/usr/local/lib/python3.2/sre_compile.py", line 491, in compile
    p = sre_parse.parse(p, flags)
  File "/usr/local/lib/python3.2/sre_parse.py", line 692, in parse
    p = _parse_sub(source, pattern, 0)
  File "/usr/local/lib/python3.2/sre_parse.py", line 315, in _parse_sub
    itemsappend(_parse(source, state))
  File "/usr/local/lib/python3.2/sre_parse.py", line 511, in _parse
    raise error("bad repeat interval")
sre_constants.error: bad repeat interval
>>>
>>>
>>> re.search(r'a{65536}', 'a' * 100000)
Traceback (most recent call last):
  File "/usr/local/lib/python3.2/functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (<class 'str'>, 'a{65536}', 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/re.py", line 158, in search
    return _compile(pattern, flags).search(string)
  File "/usr/local/lib/python3.2/re.py", line 255, in _compile
    return _compile_typed(type(pattern), pattern, flags)
  File "/usr/local/lib/python3.2/functools.py", line 180, in wrapper
    result = user_function(*args, **kwds)
  File "/usr/local/lib/python3.2/re.py", line 267, in _compile_typed
    return sre_compile.compile(pattern, flags)
  File "/usr/local/lib/python3.2/sre_compile.py", line 514, in compile
    groupindex, indexgroup
OverflowError: regular expression code size limit exceeded
>>>

----------
components: Library (Lib), Regular Expressions
messages: 152409
nosy: ezio.melotti, py.user
priority: normal
severity: normal
status: open
title: In module re the repeat interval {} doesn't accept numbers greater than 65535
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13914>
_______________________________________