From report at bugs.python.org  Wed Feb  1 00:39:58 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 Jan 2012 23:39:58 +0000
Subject: [New-bugs-announce] [issue13915] Update Tutorial 6.1.3 for PEP 3145
Message-ID: <1328053198.63.0.994035147287.issue13915@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/tutorial/modules.html#compiled-python-files
needs to be updated for 3.2+ to reflect 
http://python.org/dev/peps/pep-3147/

The first sentence is still technically correct, but finding x.pyc in the same directory as x.py is now an anomaly, so that sentence, revised, should be near the bottom. Otherwise, the text should say that the default is to put x.<version>.pyc in __pycache__, where <version> is, for instance, 'cpython-32'. Note that this allows other implementations and other versions of cpython to use the same .py file.

I do not know if there is anywhere else that this info is or should be. Using Python?.

----------
assignee: docs at python
components: Documentation
messages: 152415
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Update Tutorial 6.1.3 for PEP 3145
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  1 00:51:11 2012
From: report at bugs.python.org (Kang-Hao (Kenny) Lu)
Date: Tue, 31 Jan 2012 23:51:11 +0000
Subject: [New-bugs-announce] [issue13916] disallow the "surrogatepass"
	handler for non utf-*	encodings
Message-ID: <1328053871.05.0.70184707738.issue13916@psf.upfronthosting.co.za>


New submission from Kang-Hao (Kenny) Lu <kennyluck at csail.mit.edu>:

Currently the "surrogatepass" handler always encodes the surrogates in UTF-8 and hence the behavior for, say, "\udc80".encode("latin-1", "surrogatepass").decode("latin-1") might be unexpected and I don't even know what would, say, "\udc80\udc80".encode("big5", "surrogatepass").decode("big5"), return. Regardless of the fact that the documentation says "surrogatepass" is specific to utf-8", the currently behavior is arguably not too harmful thanks to PyBytesObject's '\0' ending (so that ((p[0] & 0xf0) == 0xe0 || (p[1] & 0xc0) == 0x80 || (p[2] & 0xc0) == 0x80) in PyCodec_SurrogatePassErrors would not crash).

However, I suggest we have the system either 1) raise early LookupError 2) raise the original Unicode(Decode|Encoding)Exception as soon as PyCodec_SurrogatePassErrors is called. I prefer the former.

Having this could shorten PyCodec_SurrogatePassErrors significantly in the patch I will shortly submit for issue #12892 as all the error conditions for utf-8, utf-16 and utf-32 are predicable* and almost all the conditionals could be removed. (The * statement is arguable if someone initializes interp->codec_search_path before _PyCodecRegistry_Init and the utf-16/32 encoders are overwritten. I don't think we need to worry about this too much though. Or am I wrong here?)

----------
components: Unicode
messages: 152416
nosy: ezio.melotti, kennyluck
priority: normal
severity: normal
status: open
title: disallow the "surrogatepass" handler for non  utf-* encodings
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  1 14:03:46 2012
From: report at bugs.python.org (Carlo Di Dato)
Date: Wed, 01 Feb 2012 13:03:46 +0000
Subject: [New-bugs-announce] [issue13917] Python 2.7.2 and 3.2.2 execl crash
Message-ID: <1328101426.59.0.731366036036.issue13917@psf.upfronthosting.co.za>


New submission from Carlo Di Dato <shinnai at autistici.org>:

These lines make Python 2.7.2 and 3.2.2 crash

import os
os.execl("cmd.exe", "")

Regards

----------
components: Windows
messages: 152428
nosy: shinnai
priority: normal
severity: normal
status: open
title: Python 2.7.2 and 3.2.2 execl crash
type: crash
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Feb  1 15:12:21 2012
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Wed, 01 Feb 2012 14:12:21 +0000
Subject: [New-bugs-announce] [issue13918] locale.atof documentation is
	missing func argument
Message-ID: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>


New submission from C?dric Krier <cedric.krier at b2ck.com>:

atof has a func argument used to instantiate the result but it is missing in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 152430
nosy: ced, docs at python
priority: normal
severity: normal
status: open
title: locale.atof documentation is missing func argument
type: enhancement

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

From report at bugs.python.org  Wed Feb  1 16:03:26 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 15:03:26 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMTM5MTldIGtpc3PCoG15wqBi?=
	=?utf-8?q?all=C2=A0sac?=
Message-ID: <1328108606.22.0.135137838492.issue13919@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: kiss?my?ball?sac
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  1 16:13:26 2012
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 01 Feb 2012 15:13:26 +0000
Subject: [New-bugs-announce] [issue13920] intern() doc wrong spelling
Message-ID: <1328109206.92.0.270712922412.issue13920@psf.upfronthosting.co.za>


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

http://docs.python.org/library/functions.html#intern

Visit the upper link andewsqEz80olp

----------
assignee: docs at python
components: Documentation
hgrepos: 110
messages: 152435
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: intern() doc wrong spelling
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  1 21:57:38 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 01 Feb 2012 20:57:38 +0000
Subject: [New-bugs-announce] [issue13921] sqlite3: OptimizedUnicode doesn't
	work in Py3k
Message-ID: <1328129858.32.0.164852943165.issue13921@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

Connection.text_factory can be used to control what objects are
returned for the TEXT data type. An excerpt from the docs:

    For efficiency reasons, there?s also a way to return str
    objects only for non-ASCII data, and bytes otherwise. To
    activate it, set this attribute to sqlite3.OptimizedUnicode.

However, it always returns Unicode strings now. There's even a
test for this feature which is obviously wrong:

    def CheckOptimizedUnicode(self):
        self.con.text_factory = sqlite.OptimizedUnicode
        austria = "?sterreich"
        germany = "Deutchland"
        a_row = self.con.execute("select ?", (austria,)).fetchone()
        d_row = self.con.execute("select ?", (germany,)).fetchone()
        self.assertTrue(type(a_row[0]) == str, "type of non-ASCII row must be str")
        self.assertTrue(type(d_row[0]) == str, "type of ASCII-only row must be str")

It checks for str in both cases even though it should test for
bytes in the latter case.

---

The user can get bytes if he wants to by saying so explicitly.
Having the library mix bytes and unicode by itself makes it
harder for the user. Furthermore, I don't really buy
the "efficiency" reason here, so I'd vote for removing the whole
OptimizeUnicode thing. It has never worked for Py3k so it would
be safe.

----------
components: Library (Lib)
messages: 152441
nosy: petri.lehtinen, pitrou
priority: normal
severity: normal
status: open
title: sqlite3: OptimizedUnicode doesn't work in Py3k
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  1 22:42:36 2012
From: report at bugs.python.org (Warren Turkal)
Date: Wed, 01 Feb 2012 21:42:36 +0000
Subject: [New-bugs-announce] [issue13922] argparse handling multiple "--" in
	args improperly
Message-ID: <1328132556.72.0.92385645061.issue13922@psf.upfronthosting.co.za>


New submission from Warren Turkal <wt at penguintechs.org>:

I have a program that runs something like the following:
$ hack run -- :target --arg1 --arg2 arg3 arg4

This basically runs a program identified by :target with the args. However, I cannot pass "--" to the program. For example, if I type:
$ hack run -- :hack run -- :target clean --help

the second "--" is swallowed by the parser, and I get an the help for "hack run" instead of instead of "hack clean". The run subcommand just does the following:

all_args = [target.bin_path] + args.args
os.execv(target.bin_path, all_args)

However, the first hack run has the following list for args:
args = Namespace(args=['run', ':hack', 'clean', '--help'], func=<function do_run at 0x19c3e60>, target=':hack')

Where is the second "--"? I would have expected the args list to be:
args=['run', '--', ':hack', 'clean', '--help']

About the python version, I am using python 2.6. However, I am using the latest release of argparse from [1] and am assuming that it's very similar code.

[1]http://code.google.com/p/argparse/downloads/list

----------
messages: 152443
nosy: Warren.Turkal
priority: normal
severity: normal
status: open
title: argparse handling multiple "--" in args improperly
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Feb  1 22:54:32 2012
From: report at bugs.python.org (Warren Turkal)
Date: Wed, 01 Feb 2012 21:54:32 +0000
Subject: [New-bugs-announce] [issue13923] new formatter for argparse
Message-ID: <1328133272.3.0.771637871025.issue13923@psf.upfronthosting.co.za>


New submission from Warren Turkal <wt at penguintechs.org>:

It would be really nice to have a formatter for argparse that would respect explicit new lines while still wrapping lines otherwise.

This would allow the description and epilog to have be a little more structured while still getting the advantage of line wrapping.

----------
messages: 152444
nosy: Warren.Turkal
priority: normal
severity: normal
status: open
title: new formatter for argparse
type: enhancement

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

From report at bugs.python.org  Wed Feb  1 23:29:56 2012
From: report at bugs.python.org (Ivaylo Popov)
Date: Wed, 01 Feb 2012 22:29:56 +0000
Subject: [New-bugs-announce] [issue13924] Mercurial robots.txt should let
	robots crawl landing	pages.
Message-ID: <1328135396.1.0.0965106732225.issue13924@psf.upfronthosting.co.za>


New submission from Ivaylo Popov <popov.ivo at gmail.com>:

http://hg.python.org/robots.txt currently disallows all robots from all paths. This means that the site doesn't show up in Google search results seeking, for instance, browsing access to the python source
https://www.google.com/search?ie=UTF-8&q=python+source+browse
https://www.google.com/search?ie=UTF-8&q=python+repo+browse
https://www.google.com/search?ie=UTF-8&q=hg+python+browse
etc...

Instead, robots.txt should allow access to the landing page, http://hg.python.org/, and the landing pages for hosted projects, e.g. http://hg.python.org/cpython/, while prohibiting access to the */rev/*, */shortlog/*, ..., directories.

This change would be very easy, cost virtually nothing, and let users find the mercurial repository viewer from search engines. Note that http://svn.python.org/ does show up in search results, as an illustration of how convenient this is.

----------
components: None
messages: 152446
nosy: Ivaylo.Popov
priority: normal
severity: normal
status: open
title: Mercurial robots.txt should let robots crawl landing pages.
type: enhancement

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

From report at bugs.python.org  Thu Feb  2 01:40:49 2012
From: report at bugs.python.org (Dave E)
Date: Thu, 02 Feb 2012 00:40:49 +0000
Subject: [New-bugs-announce] [issue13925] making assignments to an empty two
	dimensional list
Message-ID: <1328143249.02.0.799282824218.issue13925@psf.upfronthosting.co.za>


New submission from Dave E <david.elzinga at gmail.com>:

I might be missing something, but I am expecting the following code to print out a list of lists with each internal list holding one number[0-4], but instead the internal lists are a copy of the list "count".  

#!/usr/bin/python
count = range(4)
twoDimensionList = [[]] * len(count)
for i in range(len(count)):
   twoDimensionList[i].append(count[i])
print twoDimensionList

Should print: 
[[0], [1], [2], [3]]

but erroneously prints:
[[0, 1, 2, 3], [0, 1, 2, 3], [0, 1, 2, 3], [0, 1, 2, 3]]

----------
files: twoDimensionalList.py
messages: 152450
nosy: drathlian
priority: normal
severity: normal
status: open
title: making assignments to an empty two dimensional list
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24390/twoDimensionalList.py

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

From report at bugs.python.org  Thu Feb  2 15:29:29 2012
From: report at bugs.python.org (Jeroen)
Date: Thu, 02 Feb 2012 14:29:29 +0000
Subject: [New-bugs-announce] [issue13926] IDLE closes when requesting a list
	of available modules	in the online help utility
Message-ID: <1328192969.57.0.104447705618.issue13926@psf.upfronthosting.co.za>


Changes by Jeroen <dariojee at gmail.com>:


----------
components: IDLE
nosy: Jeroen
priority: normal
severity: normal
status: open
title: IDLE closes when requesting a list of available modules in the online help utility
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  2 21:49:36 2012
From: report at bugs.python.org (Roger Caldwell)
Date: Thu, 02 Feb 2012 20:49:36 +0000
Subject: [New-bugs-announce] [issue13927] Extra spaces in the output of
	time.ctime
Message-ID: <1328215776.48.0.974828105123.issue13927@psf.upfronthosting.co.za>


New submission from Roger Caldwell <roger at monkey.net>:

Hi.  I found this today and thought I would report.  I could not find anywhere that it was expected behavior.  When using time.ctime() to convert a date which only has 1 digit in the day position it returs a string with 2 spaces after the month vs one.

example
In [2]: import os,time

In [3]: time.ctime(os.path.getmtime('file.cfg'))
Out[3]: 'Tue Dec 13 18:52:58 2011'

In [4]: time.ctime(os.path.getmtime('14d-1.log'))
Out[4]: 'Tue Feb  1 19:53:11 2011'

Is this expected behavior?

----------
components: None
messages: 152475
nosy: Roger.Caldwell
priority: normal
severity: normal
status: open
title: Extra spaces in the output of time.ctime
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  3 04:59:59 2012
From: report at bugs.python.org (adamhj)
Date: Fri, 03 Feb 2012 03:59:59 +0000
Subject: [New-bugs-announce] [issue13928] bug in
	asyncore.dispatcher_with_send
Message-ID: <1328241599.62.0.482443622644.issue13928@psf.upfronthosting.co.za>


New submission from adamhj <adamhm at gmail.com>:

i found 2 relative bugs in asyncore.dispatcher_with_send class:

one is in the asyncore.dispatcher_with_send.writable():
    def writable(self):
        return (not self.connected) or len(self.out_buffer)
why is a not connected connection writable? i think this is definitely a bug
my fix:
    def writable(self):
        return self.connected and len(self.out_buffer)

another bug is more obscure, i'm not sure is it a bug or something should be handled by user(programmer)

the bug is also in asyncore.dispatcher_with_send class, and maybe also in asyncore.dispatcher class. asyncore.dispatcher uses unblocking socket to handle network missions, when we use the connect() method of dispatcher to establish the socket, it will call socket.connect_ex() method to create the connection, however, socket.connect_ex() may return 10035(EWOULDBLOCK) as it is an unblocking socket indicates that the connection creating is not finished yet, if we call dispatcher.connect() immediately after .connect(), socket error 10057 may be raised, indicating that the socket is not established yet, then the asyncore main loop catches this exception, and calls handle_error(in my case i close the connection in handle_error so the connection which would be established with no problem breaks), i think there should be a connection state check in asyncore.dispatcher.send(), or at least in asyncore.dispatcher_with_send.send.

my fix for asyncore.dispatcher_with_send.send():
    def send(self, data):
        if self.debug:
            self.log_info('sending %s' % repr(data))
        self.out_buffer = self.out_buffer + data
        if self.connected:        # do not call send() if connection is
            self.initiate_send()  # not established yet, just put data 
                                  # in buffer

for the second bug, to reproduce it, just create a unblocking socket to a remote, long delay port with socket.connect_ex and call send immediately

----------
components: Library (Lib)
messages: 152494
nosy: adamhj
priority: normal
severity: normal
status: open
title: bug in asyncore.dispatcher_with_send
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  3 07:50:23 2012
From: report at bugs.python.org (Israel Fruchter)
Date: Fri, 03 Feb 2012 06:50:23 +0000
Subject: [New-bugs-announce] [issue13929] fnmatch to support escape
	characters
Message-ID: <1328251823.76.0.3651219427.issue13929@psf.upfronthosting.co.za>


New submission from Israel Fruchter <israel.fruchter at gmail.com>:

fnmatch to support escape characters:
like that:

>>> name = "Document[Ver.2].doc"
>>> pattern = "*\[Ver.2\]*"
>>> fnmatch.fnmatch(name, pattern)
True

that's also fix glob module:
>>> pattern = "ipconfig /\?"
>>> glob.glob(pattern)
"ipconfig /?"

----------
components: Library (Lib)
messages: 152495
nosy: fruch
priority: normal
severity: normal
status: open
title: fnmatch to support escape characters
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/issue13929>
_______________________________________

From report at bugs.python.org  Fri Feb  3 08:41:28 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 03 Feb 2012 07:41:28 +0000
Subject: [New-bugs-announce] [issue13930] lib2to3 ability to output files
	into a different	directory and alter their names
Message-ID: <1328254888.57.0.86339015419.issue13930@psf.upfronthosting.co.za>


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

In order for lib2to3 to be integrated into parts of our workflow at work we need it to be able to write converted code out to new directory and modify the filename in the process.  While doing that, it is very convenient if it can also write all files regardless of if refactoring caused any changes.

This patch adds those three features.

Uploading it to the bugtracker in hope of it showing up with a code review link.

----------
assignee: gregory.p.smith
components: 2to3 (2.x to 3.x conversion tool)
files: 2to3-output-to-new-dir-gps01.patch
hgrepos: 111
keywords: patch
messages: 152498
nosy: gregory.p.smith, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: lib2to3 ability to output files into a different directory and alter their names
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24406/2to3-output-to-new-dir-gps01.patch

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

From report at bugs.python.org  Fri Feb  3 16:44:56 2012
From: report at bugs.python.org (zxw)
Date: Fri, 03 Feb 2012 15:44:56 +0000
Subject: [New-bugs-announce] [issue13931] os.path.exists inconsistent
	between 32 bit and 64 bit
Message-ID: <1328283896.91.0.836013924946.issue13931@psf.upfronthosting.co.za>


New submission from zxw <eeyore.tkc at gmail.com>:

When I run the following line while the 32 bit version of python is installed it returns false, however with the 64 bit version it correctly returns true.
os.path.exists('C:\\Windows\\System32\\msg.exe')

I'm using Python 2.7.2 with Windows 7 Professional 64bit.

----------
components: Windows
messages: 152524
nosy: zxw
priority: normal
severity: normal
status: open
title: os.path.exists inconsistent between 32 bit and 64 bit
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  3 16:50:44 2012
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBCYXJ0aMOpbMOpbXk=?=)
Date: Fri, 03 Feb 2012 15:50:44 +0000
Subject: [New-bugs-announce] [issue13932] If some test module fails to
	import another module	unittest reports a very misleading message
Message-ID: <1328284244.56.0.791299564661.issue13932@psf.upfronthosting.co.za>


New submission from S?bastien Barth?l?my <barthelemy at crans.org>:

If some test module (say, testmath) fails to import some other module, unittest reports a very misleading message:

  AttributeError: 'module' object has no attribute 'testmath'

Would it be possible improve the message or, better, to simply make the test as failed. (Maybe be by inspecting the ImportError exception message).

Consider the following example (and notice the typo at "import mathhh"):

mkdir -p test
touch test/__init__.py
cat > test/testmath.py <<EOL
import unittest
import mathhh
class MathTestCase(unittest.TestCase):
    def testSin(self):
        self.assertEqual(math.sin(0), 0)
EOL
python -m unittest test.testmath

it returns 

Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/lib/python2.7/unittest/__main__.py", line 12, in <module>
    main(module=None)
  File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__
    self.parseArgs(argv)
  File "/usr/lib/python2.7/unittest/main.py", line 149, in parseArgs
    self.createTests()
  File "/usr/lib/python2.7/unittest/main.py", line 158, in createTests
    self.module)
  File "/usr/lib/python2.7/unittest/loader.py", line 128, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python2.7/unittest/loader.py", line 100, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'testmath'

----------
components: Library (Lib)
messages: 152525
nosy: sbarthelemy
priority: normal
severity: normal
status: open
title: If some test module fails to import another module unittest reports a very misleading message
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  3 17:00:06 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 03 Feb 2012 16:00:06 +0000
Subject: [New-bugs-announce] [issue13933] IDLE:not able to complete the
	hashlib module
Message-ID: <1328284806.31.0.442750340549.issue13933@psf.upfronthosting.co.za>


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

No completion appears when I import hashlib in IDLE and type in "hashlib." and press Tab to complete.
With any other module it works.

----------
components: IDLE, Library (Lib)
messages: 152531
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: IDLE:not able to complete the hashlib module
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Feb  3 19:44:21 2012
From: report at bugs.python.org (poq)
Date: Fri, 03 Feb 2012 18:44:21 +0000
Subject: [New-bugs-announce] [issue13934] sqlite3 test typo
Message-ID: <1328294661.43.0.135509150445.issue13934@psf.upfronthosting.co.za>


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

The test CheckCollationIsUsed in Lib/sqlite3/test/hooks.py never runs because it checks the wrong version tuple. Patch attached.

----------
components: Tests
files: sqlite3-test-hooks.patch
keywords: patch
messages: 152548
nosy: poq
priority: normal
severity: normal
status: open
title: sqlite3 test typo
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24412/sqlite3-test-hooks.patch

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

From report at bugs.python.org  Fri Feb  3 19:56:31 2012
From: report at bugs.python.org (Oskar Wycislak)
Date: Fri, 03 Feb 2012 18:56:31 +0000
Subject: [New-bugs-announce] [issue13935] Tarfile - Fixed GNU tar header
	base-256 handling
Message-ID: <1328295391.26.0.207109805209.issue13935@psf.upfronthosting.co.za>


New submission from Oskar Wycislak <cantorek at gmail.com>:

On line 199 in tarfile.py comparison should be done without chr() because s[0] is an integer.
Also on line 208 there should be no ord() for the same reason.

I think this is fixed in Python 3.3

I'm sorry for not providing a patch but it's late and I do not have mercurial installed.

----------
components: Library (Lib)
messages: 152550
nosy: canto
priority: normal
severity: normal
status: open
title: Tarfile - Fixed GNU tar header base-256 handling
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb  3 21:43:16 2012
From: report at bugs.python.org (Lakin Wecker)
Date: Fri, 03 Feb 2012 20:43:16 +0000
Subject: [New-bugs-announce] [issue13936] datetime.time(0, 0,
	0) evaluates to False despite being a valid time
Message-ID: <1328301796.8.0.996607861145.issue13936@psf.upfronthosting.co.za>


New submission from Lakin Wecker <lakin.wecker at gmail.com>:

midnight is represented by datetime.time(0,0,0).  However, this time (unlike all other valid times, including datetime.time(0,0,1)) evalutes to false in if conditions:

import datetime
if datetime.time(0,0,0):
    print "datetime.time(0,0,0) is not a bug!"
else:
    print "datetime.time(0,0,0) is a bug!"

if datetime.time(0,0,1):
    print "datetime.time(0,0,1) is not a bug!"
else:
    print "datetime.time(0,0,1) is a bug!"

----------
messages: 152556
nosy: Lakin.Wecker
priority: normal
severity: normal
status: open
title: datetime.time(0,0,0) evaluates to False despite being a valid time

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

From report at bugs.python.org  Fri Feb  3 22:29:23 2012
From: report at bugs.python.org (Ben Timby)
Date: Fri, 03 Feb 2012 21:29:23 +0000
Subject: [New-bugs-announce] [issue13937] multiprocessing.ThreadPool.join()
	blocks indefinitely.
Message-ID: <1328304563.24.0.329312202759.issue13937@psf.upfronthosting.co.za>


New submission from Ben Timby <btimby at gmail.com>:

If you instantiate a ThreadPool, then call map() with an empty list, the join() method will block indefinitely on self._result_handler.join()

$ python
> from multiprocessing.pool import ThreadPool
> t = ThreadPool(1)
> t.map_async(lambda x: x, [])
> t.close()
> t.join()  # <- never returns

I was not able to determine the root cause, however, I found that the join() blocks when joining the _result_handler thread.

----------
components: Library (Lib)
messages: 152566
nosy: Ben.Timby
priority: normal
severity: normal
status: open
title: multiprocessing.ThreadPool.join() blocks indefinitely.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  4 06:31:33 2012
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 04 Feb 2012 05:31:33 +0000
Subject: [New-bugs-announce] [issue13938] 2to3 fails to convert
	types.StringTypes appropriately
Message-ID: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>


New submission from Mark Hammond <skippy.hammond at gmail.com>:

test_types.py converts "types.StringTypes" to "str" - but types.StringTypes is a tuple, so expressions like "type(x) in type.StringTypes" fails after conversion with "TypeError: argument of type 'type' is not iterable"

Attaching a fix and test.

Note that the fixer still seems "strange" after this fix - types.StringType gets converted to "bytes" but types.StringTypes uses str.  This means the expression "type.StringType in type.StringTypes" evaluates to True in 2.x but False once converted - however, that should probably be tackled in a different bug - the fact the expression now causes a TypeError once converted is more blatantly wrong and the focus of this bug.

----------
components: 2to3 (2.x to 3.x conversion tool)
files: fix_stringtypes_fixer.patch
keywords: patch
messages: 152592
nosy: mhammond
priority: normal
severity: normal
status: open
title: 2to3 fails to convert types.StringTypes appropriately
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24415/fix_stringtypes_fixer.patch

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

From report at bugs.python.org  Sat Feb  4 12:42:30 2012
From: report at bugs.python.org (brian baker)
Date: Sat, 04 Feb 2012 11:42:30 +0000
Subject: [New-bugs-announce] [issue13939] excessive cpu usage
Message-ID: <1328355750.52.0.65922609962.issue13939@psf.upfronthosting.co.za>


New submission from brian baker <brian.m.baker at gmail.com>:

python causing one of my dual core cpu's to run @ 100% running ubuntu 12.04 with gnome-shell 3.3.4

----------
components: None
messages: 152610
nosy: brian-m-baker
priority: normal
severity: normal
status: open
title: excessive cpu usage
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  4 13:04:58 2012
From: report at bugs.python.org (Johannes Bauer)
Date: Sat, 04 Feb 2012 12:04:58 +0000
Subject: [New-bugs-announce] [issue13940] imaplib: Mailbox names are not
	quoted
Message-ID: <1328357098.01.0.78801274991.issue13940@psf.upfronthosting.co.za>


New submission from Johannes Bauer <dfnsonfsduifb at gmx.de>:

imaplib does not qupote mailbox names when it's sending it's query to the server in response to a status request, for example. This will lead to very strange errors if mailboxes are accessed which contain spaces:

i.e.

connection.status("mailbox name", "(MESSAGES)")

will return

  File "/home/joe/test/imaplib.py", line 920, in _command_complete
    raise self.error('%s command error: %s %s' % (name, typ, data))
imaplib.error: STATUS command error: BAD [b'Error in IMAP command STATUS: Status items must be list.']

which indicates that the error is within the actual flag list. It is not, however:

connection.status("\"mailbox name\"", "(MESSAGES)")

works as expected. This may arguably be or not be a bug -- however it is REALLY confusing to the user. Maybe at least a note should be included somewhere that -- just to be safe -- mailbox names should be quoted.

All the best,
Joe

----------
components: Library (Lib)
messages: 152612
nosy: joebauer
priority: normal
severity: normal
status: open
title: imaplib: Mailbox names are not quoted
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Feb  4 13:31:54 2012
From: report at bugs.python.org (Manish Mishra)
Date: Sat, 04 Feb 2012 12:31:54 +0000
Subject: [New-bugs-announce] [issue13941] Your Python may not be configured
	for Tk
Message-ID: <1328358714.03.0.716590047445.issue13941@psf.upfronthosting.co.za>


New submission from Manish Mishra <yogmaya at rediffmail.com>:

I am trying to install Python3.2.2 on Ubuntu 11.10.  I downloaded the tar file. Then as per readme file did ./configure , make, make test, and then  sudo make install.  When ?make? command is issued following appears along with many other messages 

Python build finished, but the necessary bits to build these modules were not found:
_curses            _curses_panel      _dbm            
_gdbm              _sqlite3           _ssl            
_tkinter           bz2                readline        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

Now after final installation when I run idle following message appears 

** IDLE can't import Tkinter.  Your Python may not be configured for Tk. **

I tried ?sudo apt-get install python3-tk? and got following message
python3-tk is already the newest version.

I am new to programming and ubuntu both. Please Help.
Thanks n regards.

----------
components: Tkinter
messages: 152614
nosy: manish671
priority: normal
severity: normal
status: open
title: Your Python may not be configured for Tk
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  4 14:38:21 2012
From: report at bugs.python.org (weary)
Date: Sat, 04 Feb 2012 13:38:21 +0000
Subject: [New-bugs-announce] [issue13942] ssl.wrap_socket does not work on
	socket.socketpair()'s
Message-ID: <1328362701.19.0.854143759056.issue13942@psf.upfronthosting.co.za>


New submission from weary <bugs.python at weary.nl>:

ssl.wrap_socket does not work on socket.socketpair()'s

note, this is the same as issue 1552, but for python 2.7. Also, the supplied patch does not work (patch results in: TypeError: must be _socket.socket, not _socketobject)


>>> import ssl
>>> import socket
>>> s1, s2 = socket.socketpair()
>>> ssl.wrap_socket(s1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/ssl.py", line 372, in wrap_socket
    ciphers=ciphers)
  File "/usr/lib/python2.7/ssl.py", line 105, in __init__
    socket.__init__(self, _sock=sock._sock)
AttributeError: '_socket.socket' object has no attribute '_sock'

----------
components: IO
messages: 152621
nosy: weary
priority: normal
severity: normal
status: open
title: ssl.wrap_socket does not work on socket.socketpair()'s
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  4 21:41:08 2012
From: report at bugs.python.org (Patrick Andrew)
Date: Sat, 04 Feb 2012 20:41:08 +0000
Subject: [New-bugs-announce] [issue13943] Lib/distutils/command/build_py
	fails when package string	is unicode
Message-ID: <1328388068.27.0.743003863578.issue13943@psf.upfronthosting.co.za>


New submission from Patrick Andrew <pandrew at isilon.com>:

When a package list is built using Unicode strings, distutils fails to build the package with a TypeError.

This patch alternatively checks for 'unicode' as the instance type and also prints the type in the type error for easier debugging.

----------
assignee: tarek
components: Distutils
files: patch-Lib-distutils-command-build_py.py
messages: 152643
nosy: eric.araujo, patrick.andrew, tarek
priority: normal
severity: normal
status: open
title: Lib/distutils/command/build_py fails when package string is unicode
versions: Python 2.7
Added file: http://bugs.python.org/file24422/patch-Lib-distutils-command-build_py.py

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

From report at bugs.python.org  Sun Feb  5 04:04:40 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 05 Feb 2012 03:04:40 +0000
Subject: [New-bugs-announce] [issue13944] HMAC object called hmac
Message-ID: <1328411080.71.0.906401120074.issue13944@psf.upfronthosting.co.za>


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

When the documentation for hashlib says "An HMAC object has the following methods:" the list of methods says hmac.xxx which is wrong and should be HMAC.xxx.
Thanks

----------
assignee: docs at python
components: Documentation
messages: 152657
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: HMAC object called hmac
type: enhancement
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Feb  5 04:12:22 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 05 Feb 2012 03:12:22 +0000
Subject: [New-bugs-announce] [issue13945] Mistake in the text for PEP-383
Message-ID: <1328411542.41.0.837889864027.issue13945@psf.upfronthosting.co.za>


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

"chosers" should be "choosers" in 'External libraries that operate on file names (such as GUI file chosers) should also encode them according to the PEP.' in text for PEP-383 (http://www.python.org/dev/peps/pep-0383/)

----------
messages: 152658
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Mistake in the text for PEP-383
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb  5 20:48:01 2012
From: report at bugs.python.org (Nicolas)
Date: Sun, 05 Feb 2012 19:48:01 +0000
Subject: [New-bugs-announce] [issue13946] readline completer could return an
	iterable
Message-ID: <1328471281.77.0.152059916947.issue13946@psf.upfronthosting.co.za>


New submission from Nicolas <nicolas-gaudin at laposte.net>:

The function set by readline.set_completer must return one completion per call.  This should be great if we can return an iterable, because with current implementation I have to write a wrapper:

cache = None
def completer(text, state):
  if cache:
    if len(cache) > 0:
      return cache.pop(0)
    else:
      cache = None
      return None
  res = completer_returning_iterable(text)
  if isinstance(res, str) or res == None:
    return res
  cache = res
  return completer(text, state)
readline.set_completer(completer)

And completer_returning_list, the true completer, returns a pythonic iterable for all possible completion.

----------
components: Library (Lib)
messages: 152703
nosy: nicolas_49
priority: normal
severity: normal
status: open
title: readline completer could return an iterable
type: enhancement
versions: Python 3.1

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

From report at bugs.python.org  Mon Feb  6 05:13:36 2012
From: report at bugs.python.org (Jack Miller)
Date: Mon, 06 Feb 2012 04:13:36 +0000
Subject: [New-bugs-announce] [issue13947] gdbm reorganize() leaves hanging
	file descriptor
Message-ID: <1328501616.08.0.882414908885.issue13947@psf.upfronthosting.co.za>


New submission from Jack Miller <jack at codezen.org>:

I've discovered that using either 2.7.2 or 3.2.2 (from Arch) reorganizing gdbm databases leave hanging file descriptors that will cause EAGAIN errors trying to reopen it until the process is killed. For example:

Python 2.7.2 (default, Jan 31 2012, 13:19:49) 
[GCC 4.6.2 20120120 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gdbm
>>> o = gdbm.open("test27", "c")
>>> o.reorganize()
>>> o.close()
>>> o = gdbm.open("test27", "w")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
gdbm.error: (11, 'Resource temporarily unavailable')
>>>

By using lsof you can see that after reorganize() test27 has two open file descriptors, and after close() one is still open with no (obvious) way to close it. This happens with freshly created and populated databases and regardless of open mode flags.

I also tested this on 3.2.2 with dbm.gnu and got identical behavior.

----------
messages: 152719
nosy: themoken
priority: normal
severity: normal
status: open
title: gdbm reorganize() leaves hanging file descriptor
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Feb  6 09:28:08 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 08:28:08 +0000
Subject: [New-bugs-announce] [issue13948] rm needless use of set function
Message-ID: <1328516888.02.0.726524948471.issue13948@psf.upfronthosting.co.za>


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

I assume that the set() function was used to get rid of duplicates from self.versions, but there aren't any and the test would pass even if there were.

----------
assignee: tarek
components: Distutils2
files: rm-needless-use-of-set-function.patch
keywords: patch
messages: 152725
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: rm needless use of set function
type: behavior
Added file: http://bugs.python.org/file24430/rm-needless-use-of-set-function.patch

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

From report at bugs.python.org  Mon Feb  6 09:30:20 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 08:30:20 +0000
Subject: [New-bugs-announce] [issue13949] rm needless use of pass statement
Message-ID: <1328517020.67.0.388528127173.issue13949@psf.upfronthosting.co.za>


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

I found the use of the pass statement redundant.

----------
assignee: tarek
components: Distutils2
files: rm-needless-use-of-pass-keyword.patch
keywords: patch
messages: 152726
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: rm needless use of pass statement
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24431/rm-needless-use-of-pass-keyword.patch

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

From report at bugs.python.org  Mon Feb  6 09:32:27 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 08:32:27 +0000
Subject: [New-bugs-announce] [issue13950] rm commented-out code
Message-ID: <1328517147.42.0.318507953737.issue13950@psf.upfronthosting.co.za>


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

It does not appear that the commented-out code adds any value. If anything, it's maybe just a distraction.

----------
assignee: tarek
components: Distutils2
files: rm-commented-out-code.patch
keywords: patch
messages: 152727
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: rm commented-out code
versions: Python 3.3
Added file: http://bugs.python.org/file24432/rm-commented-out-code.patch

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

From report at bugs.python.org  Mon Feb  6 14:30:30 2012
From: report at bugs.python.org (Graeme Glass)
Date: Mon, 06 Feb 2012 13:30:30 +0000
Subject: [New-bugs-announce] [issue13951] Seg Fault in .so called by ctypes
	causes the interpreter	to Seg Fault
Message-ID: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>


New submission from Graeme Glass <graemeglass at gmail.com>:

When doing something obviously incorrect (read, wrong/stupid) while calling libX11.so.6 via ctypes, it causes a Segmentation fault, which in turn cause the python interpreter to fall over with a Segmentation fault.  

My question is, is this the correct behaviour? Should it seg fault or just throw an exception? 

Details below.

graeme at roger:~$ uname -a
Linux roger 3.0.0-15-generic-pae #26-Ubuntu SMP Fri Jan 20 17:07:31 UTC 2012 i686 i686 i386 GNU/Linux

graeme at roger:~$ python 
Python 2.7.2+ (default, Oct  4 2011, 20:03:08) 
[GCC 4.6.1] on linux2

graeme at roger:~$ python2.6
Python 2.6.7 (r267:88850, Aug 11 2011, 12:16:10) 
[GCC 4.6.1] on linux2

## The example code
graeme at roger:~$ cat xtest.py 

from ctypes import cdll
dll = cdll.LoadLibrary('libX11.so.6')
d = dll.XOpenDisplay(None)
root = dll.XDefaultRootWindow(d)
dll.XWarpPointer(d,None,root,0,0,0,0,20,39)
dll.XCloseDisplay(d)
dll.XCloseDisplay(d) #2nd call, should not be called, is not needed. Causes seg fault.

##The results
graeme at roger:~$ pdb2.7 xtest.py 
> /home/graeme/xtest.py(1)<module>()
-> from ctypes import cdll
(Pdb) c
Segmentation fault

graeme at roger:~$ python2.7 xtest.py 
Segmentation fault

graeme at roger:~$ ipython-2.7 xtest.py 
Segmentation fault

graeme at roger:~$ ipython-2.6 xtest.py 
Segmentation fault

graeme at roger:~$ gdb python2.7
(gdb) set args xtest.py
(gdb) run
Starting program: /usr/bin/python xtest.py
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x151) at malloc.c:3709
3709	malloc.c: No such file or directory.
	in malloc.c


graeme at roger:~$ python2.6 xtest.py 
*** glibc detected *** python2.6: double free or corruption (!prev): 0x083533a0 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0xb7402bc2]
/lib/i386-linux-gnu/libc.so.6(+0x6f862)[0xb7403862]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xb740694d]
/usr/lib/i386-linux-gnu/libX11.so.6(+0x9232b)[0xb6ff732b]
/usr/lib/i386-linux-gnu/libX11.so.6(_XFreeDisplayStructure+0x16f)[0xb6f8bddf]
/usr/lib/i386-linux-gnu/libX11.so.6(XCloseDisplay+0xd9)[0xb6f78179]
/usr/lib/python2.6/lib-dynload/_ctypes.so(ffi_call_SYSV+0x1a)[0xb70c548a]
/usr/lib/python2.6/lib-dynload/_ctypes.so(ffi_call+0x6f)[0xb70c51bf]
/usr/lib/python2.6/lib-dynload/_ctypes.so(_CallProc+0x2c2)[0xb70bfd12]
/usr/lib/python2.6/lib-dynload/_ctypes.so(+0x61ed)[0xb70b71ed]
python2.6(PyObject_Call+0x4d)[0x80648cd]
python2.6(PyEval_EvalFrameEx+0x3984)[0x80d6514]
python2.6(PyEval_EvalCodeEx+0x882)[0x80d96e2]
python2.6(PyEval_EvalCode+0x57)[0x80d97e7]
python2.6(PyRun_FileExFlags+0xa6)[0x80f8b26]
python2.6(PyRun_SimpleFileExFlags+0xc6)[0x80f98b6]
python2.6(Py_Main+0xa49)[0x805be59]
python2.6(main+0x1b)[0x805affb]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb73ad113]
python2.6[0x805b021]
======= Memory map: ========
08048000-08255000 r-xp 00000000 08:06 4459238    /usr/bin/python2.6
08255000-08256000 r--p 0020c000 08:06 4459238    /usr/bin/python2.6
08256000-082a5000 rw-p 0020d000 08:06 4459238    /usr/bin/python2.6
082a5000-082ae000 rw-p 00000000 00:00 0 
082d2000-08374000 rw-p 00000000 00:00 0          [heap]
b6e00000-b6e21000 rw-p 00000000 00:00 0 
b6e21000-b6f00000 ---p 00000000 00:00 0 
b6f28000-b6f44000 r-xp 00000000 08:06 2097174    /lib/i386-linux-gnu/libgcc_s.so.1
b6f44000-b6f45000 r--p 0001b000 08:06 2097174    /lib/i386-linux-gnu/libgcc_s.so.1
b6f45000-b6f46000 rw-p 0001c000 08:06 2097174    /lib/i386-linux-gnu/libgcc_s.so.1
b6f46000-b6f63000 r-xp 00000000 08:06 4458588    /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f63000-b6f64000 r--p 0001c000 08:06 4458588    /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f64000-b6f65000 rw-p 0001d000 08:06 4458588    /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f65000-b7096000 r-xp 00000000 08:06 4458582    /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7096000-b7097000 ---p 00131000 08:06 4458582    /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7097000-b7098000 r--p 00131000 08:06 4458582    /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7098000-b709a000 rw-p 00132000 08:06 4458582    /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b709a000-b709b000 rw-p 00000000 00:00 0 
b70b1000-b70c8000 r-xp 00000000 08:06 3634       /usr/lib/python2.6/lib-dynload/_ctypes.so
b70c8000-b70cb000 r--p 00017000 08:06 3634       /usr/lib/python2.6/lib-dynload/_ctypes.so
b70cb000-b70ce000 rw-p 0001a000 08:06 3634       /usr/lib/python2.6/lib-dynload/_ctypes.so
b70ce000-b710f000 rw-p 00000000 00:00 0 
b7110000-b7111000 r--p 00299000 08:06 4464349    /usr/lib/locale/locale-archive
b7111000-b7311000 r--p 00000000 08:06 4464349    /usr/lib/locale/locale-archive
b7311000-b7394000 rw-p 00000000 00:00 0 
b7394000-b750a000 r-xp 00000000 08:06 2097561    /lib/i386-linux-gnu/libc-2.13.so
b750a000-b750c000 r--p 00176000 08:06 2097561    /lib/i386-linux-gnu/libc-2.13.so
b750c000-b750d000 rw-p 00178000 08:06 2097561    /lib/i386-linux-gnu/libc-2.13.so
b750d000-b7511000 rw-p 00000000 00:00 0 
b7511000-b7539000 r-xp 00000000 08:06 2097567    /lib/i386-linux-gnu/libm-2.13.so
b7539000-b753a000 r--p 00028000 08:06 2097567    /lib/i386-linux-gnu/libm-2.13.so
b753a000-b753b000 rw-p 00029000 08:06 2097567    /lib/i386-linux-gnu/libm-2.13.so
b753b000-b754e000 r-xp 00000000 08:06 2098068    /lib/i386-linux-gnu/libz.so.1.2.3.4
b754e000-b754f000 r--p 00012000 08:06 2098068    /lib/i386-linux-gnu/libz.so.1.2.3.4
b754f000-b7550000 rw-p 00013000 08:06 2098068    /lib/i386-linux-gnu/libz.so.1.2.3.4
b7550000-b76dd000 r-xp 00000000 08:06 2097531    /lib/i386-linux-gnu/libcrypto.so.1.0.0
b76dd000-b76eb000 r--p 0018c000 08:06 2097531    /lib/i386-linux-gnu/libcrypto.so.1.0.0
b76eb000-b76f1000 rw-p 0019a000 08:06 2097531    /lib/i386-linux-gnu/libcrypto.so.1.0.0
b76f1000-b76f4000 rw-p 00000000 00:00 0 
b76f4000-b773c000 r-xp 00000000 08:06 2097532    /lib/i386-linux-gnu/libssl.so.1.0.0
b773c000-b773e000 r--p 00047000 08:06 2097532    /lib/i386-linux-gnu/libssl.so.1.0.0
b773e000-b7741000 rw-p 00049000 08:06 2097532    /lib/i386-linux-gnu/libssl.so.1.0.0
b7741000-b7743000 r-xp 00000000 08:06 2099412    /lib/i386-linux-gnu/libutil-2.13.so
b7743000-b7744000 r--p 00001000 08:06 2099412    /lib/i386-linux-gnu/libutil-2.13.so
b7744000-b7745000 rw-p 00002000 08:06 2099412    /lib/i386-linux-gnu/libutil-2.13.so
b7745000-b7746000 rw-p 00000000 00:00 0 
b7746000-b7749000 r-xp 00000000 08:06 2097565    /lib/i386-linux-gnu/libdl-2.13.so
b7749000-b774a000 r--p 00002000 08:06 2097565    /lib/i386-linux-gnu/libdl-2.13.so
b774a000-b774b000 rw-p 00003000 08:06 2097565    /lib/i386-linux-gnu/libdl-2.13.so
b774b000-b7762000 r-xp 00000000 08:06 2099407    /lib/i386-linux-gnu/libpthread-2.13.so
b7762000-b7763000 r--p 00016000 08:06 2099407    /lib/i386-linux-gnu/libpthread-2.13.so
b7763000-b7764000 rw-p 00017000 08:06 2099407    /lib/i386-linux-gnu/libpthread-2.13.so
b7764000-b7766000 rw-p 00000000 00:00 0 
b7770000-b7775000 r-xp 00000000 08:06 4458586    /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b7775000-b7776000 r--p 00004000 08:06 4458586    /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b7776000-b7777000 rw-p 00005000 08:06 4458586    /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b7777000-b7779000 r-xp 00000000 08:06 4458584    /usr/lib/i386-linux-gnu/libXau.so.6.0.0
b7779000-b777a000 r--p 00001000 08:06 4458584    /usr/lib/i386-linux-gnu/libXau.so.6.0.0
b777a000-b777b000 rw-p 00002000 08:06 4458584    /usr/lib/i386-linux-gnu/libXau.so.6.0.0
b777b000-b777c000 rwxp 00000000 00:00 0 
b777c000-b777e000 rw-p 00000000 00:00 0 
b777e000-b777f000 r-xp 00000000 00:00 0          [vdso]
b777f000-b779d000 r-xp 00000000 08:06 2097504    /lib/i386-linux-gnu/ld-2.13.so
b779d000-b779e000 r--p 0001d000 08:06 2097504    /lib/i386-linux-gnu/ld-2.13.so
b779e000-b779f000 rw-p 0001e000 08:06 2097504    /lib/i386-linux-gnu/ld-2.13.so
bfb52000-bfb73000 rw-p 00000000 00:00 0          [stack]
Aborted

----------
components: ctypes
messages: 152735
nosy: graemeglass
priority: normal
severity: normal
status: open
title: Seg Fault in .so called by ctypes causes the interpreter to Seg Fault
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  6 18:43:56 2012
From: report at bugs.python.org (Ian Davis)
Date: Mon, 06 Feb 2012 17:43:56 +0000
Subject: [New-bugs-announce] [issue13952] mimetypes doesn't recognize .csv
Message-ID: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>


New submission from Ian Davis <iwd32900 at yahoo.com>:

The mimetypes module does not respond with "text/csv" for files that end in ".csv", and I think it should  :)  For goodness sake, "text/tab-delimited-values" is in there as ".tsv", and that seems much less used (to me).

----------
components: Library (Lib)
messages: 152751
nosy: iwd32900
priority: normal
severity: normal
status: open
title: mimetypes doesn't recognize .csv
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  6 19:59:00 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 18:59:00 +0000
Subject: [New-bugs-announce] [issue13953] test_packaging: unused test?
Message-ID: <1328554740.27.0.167211242761.issue13953@psf.upfronthosting.co.za>


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

I'm not sure what's happening here (not sure how doctest works), but I suspect that there is no test at all. Perhaps it was forgotten: http://hg.python.org/cpython/file/567767a6df02/Lib/packaging/tests/test_version.py#l68.

I say this because it whatever change I make to that long string, I always get a successful test.

----------
assignee: tarek
components: Distutils2
messages: 152756
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: test_packaging: unused test?
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb  6 21:35:15 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Feb 2012 20:35:15 +0000
Subject: [New-bugs-announce] [issue13954] Add regrtest option to record test
	results to a file
Message-ID: <1328560515.13.0.686472532234.issue13954@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The idea is that if a test succeeded then it is written to a file commented out(including skipped tests w/ the appropriate comment), and if a test failed then it is left uncommented. This way the failing tests can simply be passed to --fromfile for easy repeatability. This becomes especially handy when randomizing test order and there is some dependency on a previously run test as you can begin to uncomment tests until you find the trigger.

This can also be used with some other new flag which lists which tests to skip (i.e. the inverse of --fromfile). This is helpful when you don't want to run tests in some branch when you know they are failing in the default branch already and you are not trying to fix them.

----------
components: Tests
messages: 152771
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Add regrtest option to record test results to a file
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb  6 21:45:44 2012
From: report at bugs.python.org (Samuel Bronson)
Date: Mon, 06 Feb 2012 20:45:44 +0000
Subject: [New-bugs-announce] [issue13955] email: RFC 2822 has been obsoleted
	by RFC 5322
Message-ID: <1328561144.0.0.46908466856.issue13955@psf.upfronthosting.co.za>


New submission from Samuel Bronson <naesten at gmail.com>:

As you can see by looking at <http://tools.ietf.org/html/rfc2822> or <http://tools.ietf.org/html/rfc5322>, RFC 2822 has been obsoleted by RFC 5322.

It would probably be a good idea to update the email package to support it, if in fact anything needs changing, and to mention/link to the new RFC in the documentation.

(It would probably *not* be a good idea to stop mentioning RFC 2822, though, since that's rather more well known, and the number is a bit more memorable for those who've heard of RFC 822. I'm actually a bit surprised the new one didn't get numbered 5822...)

----------
components: Library (Lib)
messages: 152772
nosy: SamB
priority: normal
severity: normal
status: open
title: email: RFC 2822 has been obsoleted by RFC 5322
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  6 21:46:38 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 06 Feb 2012 20:46:38 +0000
Subject: [New-bugs-announce] [issue13956] add a note regarding building on
	recent versions of	Debian and Ubuntu
Message-ID: <1328561198.71.0.464040865268.issue13956@psf.upfronthosting.co.za>


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

I was puzzled why the various parts, like readline and ssl, failed to be built into my Python. It was after seeing #11715 that I realized I needed to install dpkg-dev, whose binary, dpkg-architecture, helps detect the locations of those libraries ().

----------
components: Devguide
files: note-on-building-on-recent-debian-releases.patch
keywords: patch
messages: 152773
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: add a note regarding building on recent versions of Debian and Ubuntu
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24438/note-on-building-on-recent-debian-releases.patch

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

From report at bugs.python.org  Mon Feb  6 21:59:41 2012
From: report at bugs.python.org (Samuel Bronson)
Date: Mon, 06 Feb 2012 20:59:41 +0000
Subject: [New-bugs-announce] [issue13957] parsedate_tz doesn't distinguish
	-0000 from +0000
Message-ID: <1328561981.97.0.928015101931.issue13957@psf.upfronthosting.co.za>


New submission from Samuel Bronson <naesten at gmail.com>:

This is what I'm seeing:

>>> import email.utils
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 +0000')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -0000')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)

But RFC 5322 says:

>    minutes).  The form "+0000" SHOULD be used to indicate a time zone at
>    Universal Time.  Though "-0000" also indicates Universal Time, it is
>    used to indicate that the time was generated on a system that may be
>    in a local time zone other than Universal Time and that the date-time
>    contains no information about the local time zone.

(As does RFC 2822, which RFC 5322 obsoletes.)

And the documentation for email.utils.parsedate_tz is:

> Performs the same function as parsedate(), but returns either None or a
> 10-tuple; the first 9 elements make up a tuple that can be passed directly to
> time.mktime(), and the tenth is the offset of the date?s timezone from UTC
> (which is the official term for Greenwich Mean Time) [1]. If the input string
> has no timezone, the last element of the tuple returned is None. Note that
> indexes 6, 7, and 8 of the result tuple are not usable.

So it seems like I should have seen:

>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -0000')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, None)

----------
components: Library (Lib)
messages: 152774
nosy: SamB
priority: normal
severity: normal
status: open
title: parsedate_tz doesn't distinguish -0000 from +0000
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  6 22:08:01 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 06 Feb 2012 21:08:01 +0000
Subject: [New-bugs-announce] [issue13958] Comment _PyUnicode_FromId
Message-ID: <1328562481.37.0.963430075051.issue13958@psf.upfronthosting.co.za>


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

Add a comment explaining why _PyUnicode_FromId can (and should) assume ASCII-only identifiers.


	/* PEP3131 guarantees that all python-internal identifiers
	   are ASCII-only.  Violating this would break some supported
	   C compilers. */

See http://mail.python.org/pipermail/python-dev/2012-February/116234.html

----------
components: Unicode
messages: 152775
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: Comment _PyUnicode_FromId
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  7 01:51:30 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 07 Feb 2012 00:51:30 +0000
Subject: [New-bugs-announce] [issue13959] Re-implement parts of imp in pure
	Python
Message-ID: <1328575890.24.0.0737633689073.issue13959@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

A bunch of code in Python/import.c exists purely for the imp module, but a large chunk of it does not need to be implemented in C but instead can be implemented in Python code.

Once importlib is bootstrapped in then an attempt to scale back the C code should be done by re-implementing parts of imp in pure Python (either in some _imp module or directly in _importlib itself).

----------
components: Library (Lib)
messages: 152800
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Re-implement parts of imp in pure Python
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  7 12:56:36 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 07 Feb 2012 11:56:36 +0000
Subject: [New-bugs-announce] [issue13960] Handling of broken comments in
	HTMLParser
Message-ID: <1328615796.36.0.0693404155355.issue13960@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

html.parser fails to handle the following invalid comments:
<! foo >
<! bar -->
<! -- baz -->
The attached patch follows the HTML5 specs [0], and parses them as "bogus comments".  Currently the patch fixes the problem only when strict=False, but it might be better to make this the default behavior and apply it to 2.7 too.

[0]: http://www.w3.org/TR/html5/tokenization.html#bogus-comment-state

----------
components: Library (Lib)
files: issue13960.diff
keywords: patch
messages: 152806
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
stage: patch review
status: open
title: Handling of broken comments in HTMLParser
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24443/issue13960.diff

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

From report at bugs.python.org  Tue Feb  7 15:26:36 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 07 Feb 2012 14:26:36 +0000
Subject: [New-bugs-announce] [issue13961] Have importlib use os.replace()
Message-ID: <1328624796.15.0.577971130856.issue13961@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The new os.replace() function should be used by importlib.

----------
components: Library (Lib)
messages: 152810
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Have importlib use os.replace()
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  7 17:16:27 2012
From: report at bugs.python.org (Ray)
Date: Tue, 07 Feb 2012 16:16:27 +0000
Subject: [New-bugs-announce] [issue13962] multiple lib and include
	directories on Linux
Message-ID: <1328631387.63.0.77049382306.issue13962@psf.upfronthosting.co.za>


New submission from Ray <rpqpro at hotmail.com>:

I'm opening a new ticket based on ticket 13511 (http://bugs.python.org/issue13511) since the last one was closed.  Read ronaldoussoren's post in Ticket 13511 in case you're still confused. 

There is no way to specify multiple lib and include directories on Linux when installing Python 2.7; other versions of Python may be affected.

----------
assignee: tarek
components: Build, Distutils, Installation
messages: 152812
nosy: eric.araujo, rpq, tarek
priority: normal
severity: normal
status: open
title: multiple lib and include directories on Linux
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb  7 17:24:38 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 07 Feb 2012 16:24:38 +0000
Subject: [New-bugs-announce] [issue13963] dev guide has no mention of
	mechanics of patch review
Message-ID: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I've been waiting for patch review of my work on http://bugs.python.org/issue13703 only to discover that people *have* been reviewing it.

It turns out that next to some of the patches in the issue tracker there's a "review" link, which takes me to http://bugs.python.org/review/13703/show and there's a whole second conversation going on about the issue there.  I haven't been getting any emails about it.

I've been looking through http://docs.python.org/devguide but I can't see any mention of the mechanics of patch review, or that this secondary site exists.  
Clearly I missed something big, but was it actually documented anywhere?

http://docs.python.org/devguide/patch.html mentions uploading patches for review, and talks about an iterative process of commenting and refining a patch, but when I read it, I assumed it was referring to discussion within the issue, rather than on this secondary site.

Some questions:
  * Do all patches go into this review site, or do I have to do something extra to get them to land there?
  * I have patches for both 2.6 and 3.1 - are they kept separate, or do they affect each other's "delta from patch set"?
  * Is there a way to enable notifications, e.g. for me to receive emails when someone comments on my patch?  or to put a comment into the *issue* noting that someone commented on the patch?

Thanks

----------
components: Devguide
messages: 152813
nosy: dmalcolm, ezio.melotti
priority: normal
severity: normal
status: open
title: dev guide has no mention of mechanics of patch review

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

From report at bugs.python.org  Wed Feb  8 02:19:54 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Feb 2012 01:19:54 +0000
Subject: [New-bugs-announce] [issue13964] os.utimensat() and os.futimes()
	should accept Decimal, drop os.futimens()
Message-ID: <1328663994.2.0.189878263913.issue13964@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python 3.3 has 4 new functions to set the access and modification time of a file (only os.utime() was already present in Python 3.2). New functions taking timestamp with a nanonsecond resolution use a tuple of int because the float type doesn't support nanosecond resolution. Thanks to the PEP 410, we can simplify the API to use a simple number (int, float or Decimal) instead of a tuple of 2 integers.

Current API:

- futimes(fd[, (atime, mtime)]): 1 argument for timestamps
- lutimes(path[, (atime, mtime)]): 1 argument for timestamps
- utime(path[, (atime, mtime)]): 1 argument for timestamps

- futimens(fd[, (atime_sec, atime_nsec), (mtime_sec, mtime_nsec)]): 2 arguments for timestamps
- utimensat(dirfd, path[, atime=(atime_sec, atime_nsec), mtime=(mtime_sec, mtime_nsec), flags=0]): 2 arguments for timestamps

I propose to:

- support Decimal type in all functions: avoid conversion to float to not lose precision
- remove os.futimens(): os.futimes() does already use futimens() if the function is present (and Decimal can be used to get nanosecond resolution)
- change os.utimensat() API to: os.utimensat(dirfd, path[, (atime, mtime), flags=0])

----------
components: Library (Lib)
messages: 152825
nosy: haypo, ncoghlan
priority: normal
severity: normal
status: open
title: os.utimensat() and os.futimes() should accept Decimal, drop os.futimens()
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb  8 02:57:15 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Feb 2012 01:57:15 +0000
Subject: [New-bugs-announce] [issue13965] Windows 64-bit installer actually
	installing a 32-bit	version
Message-ID: <1328666235.95.0.56390698095.issue13965@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

On the downloader page, http://www.python.org/download/releases/2.7.2/ there is an entry "?Windows X86-64 MSI Installer" that links to http://www.python.org/ftp/python/2.7.2/python-2.7.2.amd64.msi

Running this installer succeeds and show messages that a 64-bit version of Python is being installed; however, running Python shows that only a 32-bit version is being run despite a welcome message stating that a 64-bit version is being run:


C:\Python27>python
Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxint
2147483647

----------
assignee: loewis
components: Installation
messages: 152827
nosy: loewis, rhettinger
priority: normal
severity: normal
status: open
title: Windows 64-bit installer actually installing a 32-bit version
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  8 08:49:28 2012
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgQXR0aWxhIFTDs3Ro?=)
Date: Wed, 08 Feb 2012 07:49:28 +0000
Subject: [New-bugs-announce] [issue13966] Add disable_interspersed_args()
	to	argparse.ArgumentParser
Message-ID: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>


New submission from L?szl? Attila T?th <laszlo.attila.toth at gmail.com>:

If someone ports his code from optparse to argparse, there is a limit, that options and non-options can be mixed by default, and this behaviour cannot be disabled easily, an extra '--' argument is required in the command line.

In some cases it is much prettier to explicitly disable this, as was available in the deprecated optparse module.

I attach a patch that does this, adds disable_interspersed_args() to argparse.ArgumentParser.

----------
components: Library (Lib)
files: argparse.patch
keywords: patch
messages: 152839
nosy: Laszlo.Attila.Toth
priority: normal
severity: normal
status: open
title: Add disable_interspersed_args() to argparse.ArgumentParser
versions: Python 2.7
Added file: http://bugs.python.org/file24449/argparse.patch

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

From report at bugs.python.org  Wed Feb  8 10:04:55 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 09:04:55 +0000
Subject: [New-bugs-announce] [issue13967] also test for an empty pathname
Message-ID: <1328691895.76.0.461063464523.issue13967@psf.upfronthosting.co.za>


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

increases coverage by one line: http://hg.python.org/cpython/file/58bd6a58365d/Lib/packaging/util.py#l110

----------
assignee: tarek
components: Distutils2
files: test-for-empty-string.patch
keywords: patch
messages: 152840
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: also test for an empty pathname
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24450/test-for-empty-string.patch

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

From report at bugs.python.org  Wed Feb  8 12:22:26 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Wed, 08 Feb 2012 11:22:26 +0000
Subject: [New-bugs-announce] [issue13968] Add a recursive function to the
	glob package
Message-ID: <1328700146.65.0.884103301197.issue13968@psf.upfronthosting.co.za>


New submission from Yuval Greenfield <ubershmekel at gmail.com>:

This is a feature I've wanted to use in too many times to remember. I've made a patch with an implementation, docs and a test. I've named the function rglob and tried to stay within the conventions of the glob package.

----------
components: Library (Lib)
files: rglob.patch
keywords: patch
messages: 152843
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: Add a recursive function to the glob package
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file24451/rglob.patch

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

From report at bugs.python.org  Wed Feb  8 12:56:38 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 08 Feb 2012 11:56:38 +0000
Subject: [New-bugs-announce] [issue13969] path name must always be string
Message-ID: <1328702198.23.0.695483013492.issue13969@psf.upfronthosting.co.za>


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

I was writing a test that could return True for "if not pathname" (http://hg.python.org/cpython/file/58bd6a58365d/Lib/packaging/util.py#l109), and included all values I know that could return a False value, but then I realised that the only value we should check against is an empty string... I don't think any other type is applicable.

I left None as a valid type, otherwise some other test (test_command_install_dist.py) fails.

----------
files: path-name-must-be-string-or-None.patch
keywords: patch
messages: 152845
nosy: tshepang
priority: normal
severity: normal
status: open
title: path name must always be string
Added file: http://bugs.python.org/file24452/path-name-must-be-string-or-None.patch

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

From report at bugs.python.org  Wed Feb  8 18:41:57 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 08 Feb 2012 17:41:57 +0000
Subject: [New-bugs-announce] [issue13970] frameobject should not have
	f_yieldfrom attribute
Message-ID: <1328722917.98.0.121121534686.issue13970@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

The f_yieldfrom field should not be visible at Python level, it is an internal implementation detail.

Patch attached.

----------
files: remove_f_yieldfrom.patch
keywords: patch
messages: 152895
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: frameobject should not have f_yieldfrom attribute
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24457/remove_f_yieldfrom.patch

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

From report at bugs.python.org  Wed Feb  8 19:44:23 2012
From: report at bugs.python.org (umedoblock)
Date: Wed, 08 Feb 2012 18:44:23 +0000
Subject: [New-bugs-announce] [issue13971] format() doesn't parse str.
Message-ID: <1328726663.18.0.681265030532.issue13971@psf.upfronthosting.co.za>


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

format() mis understaning.
please pay attention to [0], [x].

>>> d = {0: "a", "0": "A"}
>>> 'd[0] = {0[0]}'.format(d)
'd[0] = a'
>>> 'd[0] = {0["0"]}'.format(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: '"0"'
>>> d2 = {"x": 100}
>>> 'd2[x] = {0[x]}'.format(d2)
'd2[x] = 100'

----------
components: Regular Expressions
messages: 152897
nosy: ezio.melotti, umedoblock
priority: normal
severity: normal
status: open
title: format() doesn't parse str.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb  9 09:16:28 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 09 Feb 2012 08:16:28 +0000
Subject: [New-bugs-announce] [issue13972] set and frozenset constructors
	don't accept multiple	iterables
Message-ID: <1328775388.29.0.217148871947.issue13972@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

set.update() and friends accept multiple iterables. IMHO, set and frozenset constructors should, too.

----------
components: Interpreter Core
messages: 152931
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: set and frozenset constructors don't accept multiple iterables
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb  9 09:22:37 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 09 Feb 2012 08:22:37 +0000
Subject: [New-bugs-announce] [issue13973] urllib.parse is imported twice in
	xmlrpc.client
Message-ID: <1328775757.49.0.00418569487883.issue13973@psf.upfronthosting.co.za>


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

urllib.parse is imported twice in xmlrpc.client, and it also breaks pep8

----------
components: Library (Lib)
files: duplicate-imports.patch
keywords: patch
messages: 152932
nosy: tshepang
priority: normal
severity: normal
status: open
title: urllib.parse is imported twice in xmlrpc.client
versions: Python 3.3
Added file: http://bugs.python.org/file24462/duplicate-imports.patch

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

From report at bugs.python.org  Thu Feb  9 09:24:35 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 09 Feb 2012 08:24:35 +0000
Subject: [New-bugs-announce] [issue13974] packaging: test for set_platform()
Message-ID: <1328775875.69.0.230962367845.issue13974@psf.upfronthosting.co.za>


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

slightly increases test coverage

----------
assignee: tarek
components: Distutils2
files: test-set-platform.patch
keywords: patch
messages: 152933
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: packaging: test for set_platform()
versions: Python 3.3
Added file: http://bugs.python.org/file24463/test-set-platform.patch

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

From report at bugs.python.org  Thu Feb  9 09:29:06 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 09 Feb 2012 08:29:06 +0000
Subject: [New-bugs-announce] [issue13975] packaging: change_root() test for
	os2
Message-ID: <1328776146.47.0.653545071003.issue13975@psf.upfronthosting.co.za>


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

increases coverage a bit

----------
assignee: tarek
components: Distutils2
files: test-change_root-in-os2.patch
keywords: patch
messages: 152934
nosy: alexis, eric.araujo, tarek, tshepang
priority: normal
severity: normal
status: open
title: packaging: change_root() test for os2
versions: Python 3.3
Added file: http://bugs.python.org/file24464/test-change_root-in-os2.patch

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

From report at bugs.python.org  Thu Feb  9 16:07:18 2012
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 09 Feb 2012 15:07:18 +0000
Subject: [New-bugs-announce] [issue13976] threading.local doesn't support
	super()
Message-ID: <1328800038.58.0.378315403366.issue13976@psf.upfronthosting.co.za>


New submission from Dima Tisnek <dimaqq at gmail.com>:

import threading
import pprint


class A:
    def __init__(self, **kw):
        pprint.pprint("a")
        super(A, self).__init__()


class B(threading.local, A):
    def __init__(self, **kw):
        pprint.pprint("b")
        super(B, self).__init__()

if __name__ == "__main__":
    B()



breaks (prints only b) in python 2. tested 2.7.2

works (prints b, a) in python 3, tested 3.2.2

threading.local is before A on purpose, to have different A attribute in different threads, not shown in the example.

caveat implementor: it may be impossible to support both super().__init__ and explicit threading.local.__init__ at the same time; explicit initialization is used far and wide in legacy code.

----------
components: None
messages: 152947
nosy: Dima.Tisnek, pitrou
priority: normal
severity: normal
status: open
title: threading.local doesn't support super()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  9 18:53:55 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 09 Feb 2012 17:53:55 +0000
Subject: [New-bugs-announce] [issue13977] importlib simplification
Message-ID: <1328810035.88.0.967764974247.issue13977@psf.upfronthosting.co.za>


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

http://hg.python.org/cpython/file/aba513307f78/Lib/importlib/_bootstrap.py#l974


  974     # The hell that is fromlist ...
  975     if not fromlist:
  976         # Return up to the first dot in 'name'. This is
complicated by the fact
  977         # that 'name' may be relative.
  978         if level == 0:
  979             return sys.modules[name.partition('.')[0]]
  980         elif not name:
  981             return module
  982         else:
  983             cut_off = len(name) - len(name.partition('.')[0])
  984             return sys.modules[module.__name__[:-cut_off]]

If level is 0, should name == module.__name__?

Yes.
 

If so, then I think that simplifies to

   if not name:
       return module
   genericname=module.__name__.rpartition(".")[0]
   return sys.modules[genericname]

Seems right. Can you file a bug and assign it to me?

----------
messages: 152970
nosy: Jim.Jewett, brett.cannon
priority: normal
severity: normal
status: open
title: importlib simplification

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

From report at bugs.python.org  Thu Feb  9 19:24:08 2012
From: report at bugs.python.org (=?utf-8?q?Javier_Jard=C3=B3n?=)
Date: Thu, 09 Feb 2012 18:24:08 +0000
Subject: [New-bugs-announce] [issue13978] OSError exception in
	multiprocessing module when using	os.remove() on NFS
Message-ID: <1328811848.71.0.527301304196.issue13978@psf.upfronthosting.co.za>


New submission from Javier Jard?n <jjardon at gnome.org>:

I have this little test case:

import multiprocessing
 
manager = multiprocessing.Manager()
del manager

and I get this:

Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/util.py", line 261, in _run_finalizers
    finalizer()
  File "/usr/lib/python2.7/multiprocessing/util.py", line 200, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/lib/python2.7/shutil.py", line 249, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "/usr/lib/python2.7/shutil.py", line 247, in rmtree
    os.remove(fullname)
OSError: [Errno 16] Device or resource busy: '/nfs/tmp/pymp-f7R9S6/.nfs00000000e039692f00000236'

(the TMDIR directory is in a nfs server)

----------
components: Extension Modules
messages: 152972
nosy: jjardon
priority: normal
severity: normal
status: open
title: OSError exception in multiprocessing module when using os.remove() on NFS
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb  9 22:10:08 2012
From: report at bugs.python.org (David Goulet)
Date: Thu, 09 Feb 2012 21:10:08 +0000
Subject: [New-bugs-announce] [issue13979] Automatic *libc.so loading
	behaviour
Message-ID: <1328821808.41.0.811189579105.issue13979@psf.upfronthosting.co.za>


New submission from David Goulet <dgoulet at efficios.com>:

I'm working with the LTTng (Linux Tracing) team and we came across a problem with our user-space tracer and Python default behaviour. We provide a libc wrapper that instrument free() and malloc() and is usable with a simple LD_PRELOAD.

This lib *was* named "liblttng-ust-libc.so" and we came across python software registering to our trace registry daemon (meaning that somehow the python binary is using our in-process library). We dig a bit and found this:

Lib/ctypes/utils.py:

def _findLib_ldconfig(name):
       # XXX assuming GLIBC's ldconfig (with option -p)
       expr = r'/[^\(\)\s]*lib%s\.[^\(\)\s]*' % re.escape(name)
       res = re.search(expr,
                       os.popen('/sbin/ldconfig -p 2>/dev/null').read())

and, at least, also found in _findLib_gcc(name) and _findSoname_ldconfig(name).

This cause Python to use any library ending with "libc.so" to be loaded....

I don't know the reasons behind this but we are concerned about "future issues" with this kind of behaviour.

Thanks

----------
components: ctypes
messages: 152988
nosy: dgoulet
priority: normal
severity: normal
status: open
title: Automatic *libc.so loading behaviour
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Feb  9 23:12:58 2012
From: report at bugs.python.org (fif0)
Date: Thu, 09 Feb 2012 22:12:58 +0000
Subject: [New-bugs-announce] [issue13980] getcwd problem
Message-ID: <1328825578.61.0.813080767189.issue13980@psf.upfronthosting.co.za>


New submission from fif0 <hendrik.schneider at xantrum.de>:

Please take a look at the detached file.

At the first call of the methode foo(), path and the second getcwd are the same. After the directory change, the default value path is not the the current working directory.

----------
components: Interpreter Core
files: maybe_a_bug.py
messages: 152991
nosy: fif0
priority: normal
severity: normal
status: open
title: getcwd problem
versions: Python 2.7
Added file: http://bugs.python.org/file24472/maybe_a_bug.py

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

From report at bugs.python.org  Fri Feb 10 00:00:34 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Feb 2012 23:00:34 +0000
Subject: [New-bugs-announce] [issue13981] time.sleep() should use
	nanosleep() if available
Message-ID: <1328828434.41.0.993247720876.issue13981@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

With the PEP 410, it is possible to store timestamps with a resolution of 1 nanosecond. Python should use nanosleep() if the function is available for time.sleep().

This issue depends on issue #13882.

----------
components: Library (Lib)
messages: 153000
nosy: haypo
priority: normal
severity: normal
status: open
title: time.sleep() should use nanosleep() if available
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 10 07:17:57 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 06:17:57 +0000
Subject: [New-bugs-announce] [issue13982] python returning errorneous value
	for sqrt
Message-ID: <1328854677.42.0.867049948528.issue13982@psf.upfronthosting.co.za>


New submission from Shivam <shivam.agarwal at aricent.com>:

On mips64 biit machine running linux I have installed python2.4_2.4.4 from link "http://archive.debian.net/etch/python2.4" using below commands:

./configure ?enable-shared
make 
make install  

But when I check value of sqrt(9.0) on python, python returns:?4.9406564584124654e-324? rather than ?3.0?. 

Can anybody let me know what may be the reason for this.

Regards
Shivam Agarwal

----------
messages: 153026
nosy: shivam_python_issues
priority: normal
severity: normal
status: open
title: python returning errorneous value for sqrt
type: behavior
versions: 3rd party

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

From report at bugs.python.org  Fri Feb 10 07:45:05 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 06:45:05 +0000
Subject: [New-bugs-announce] [issue13983] make test giving bus error
Message-ID: <1328856305.29.0.849660995129.issue13983@psf.upfronthosting.co.za>


New submission from Shivam <shivam.agarwal at aricent.com>:

Hi All,
   On mips64 biit machine running linux I have installed python2.4_2.4.4 from link "http://archive.debian.net/etch/python2.4" using below commands:

./configure ?enable-shared
make
make install  

But make test fails with bus error, below is the log for same:

octeon:~/depend_resolv/python2.4-2.4.4.orig# make test
case $MAKEFLAGS in \
        *-s*) LD_LIBRARY_PATH=/root/depend_resolv/python2.4-2.4.4.orig: CC='gcc -pthread' LDSHARED='gcc -pthread
 -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
        *) LD_LIBRARY_PATH=/root/depend_resolv/python2.4-2.4.4.orig: CC='gcc -pthread' LDSHARED='gcc -pthread -s
hared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
        esac
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building 'dbm' extension
gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -DHAVE_NDBM_H -I. -I/root/depe
nd_resolv/python2.4-2.4.4.orig/./Include -I/usr/local/include -I/root/depend_resolv/python2.4-2.4.4.orig/Include
 -I/root/depend_resolv/python2.4-2.4.4.orig -c /root/depend_resolv/python2.4-2.4.4.orig/Modules/dbmmodule.c -o b
uild/temp.linux-mips64-2.4/dbmmodule.o
gcc -pthread -shared build/temp.linux-mips64-2.4/dbmmodule.o -L/usr/local/lib -o build/lib.linux-mips64-2.4/dbm.
so
*** WARNING: renaming "dbm" since importing it failed: build/lib.linux-mips64-2.4/dbm.so: undefined symbol: dbm_
error
running build_scripts
find ./Lib -name '*.py[co]' -print | xargs rm -f
LD_LIBRARY_PATH=/root/depend_resolv/python2.4-2.4.4.orig: ./python -E -tt ./Lib/test/regrtest.py -l 
make: *** [test] Bus error
LD_LIBRARY_PATH=/root/depend_resolv/python2.4-2.4.4.orig: ./python -E -tt ./Lib/test/regrtest.py -l 
test_grammar
test_opcodes
test_operations
test_builtin
make: *** [test] Bus error

----------
messages: 153027
nosy: shivam_python_issues
priority: normal
severity: normal
status: open
title: make test giving bus error
type: compile error

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

From report at bugs.python.org  Fri Feb 10 09:07:36 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 08:07:36 +0000
Subject: [New-bugs-announce] [issue13984] Python2.6 compilation breaking on
	mips64 bit machine
Message-ID: <1328861256.08.0.514487145098.issue13984@psf.upfronthosting.co.za>


New submission from Shivam <shivam.agarwal at aricent.com>:

Hi All,
  I am getting follwoing error when compiling Python2.6 on mips 64.

"
Failed to find the necessary bits to build these modules:
_bsddb             _tkinter           bsddb185        
bz2                dl                 imageop         
readline           sunaudiodev        zlib            
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_ctypes            datetime           dbm             
"

----------
components: None
messages: 153031
nosy: shivam_python_issues
priority: normal
severity: normal
status: open
title: Python2.6 compilation breaking on mips64 bit machine
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb 10 11:50:22 2012
From: report at bugs.python.org (marc dechico)
Date: Fri, 10 Feb 2012 10:50:22 +0000
Subject: [New-bugs-announce] [issue13985] Menu.tk_popup : menu doesn't
	disapear when main window	is iconified.
Message-ID: <1328871022.99.0.882272597763.issue13985@psf.upfronthosting.co.za>


New submission from marc dechico <marc.dechico at gmail.com>:

actions do discover the bug  with the source I have given:

pushing the right button to get the pop-up menu .

going out of the popup_menu  still pushing the right button.

the menu doesn't disapear when releasing the button.

and still doesn't disapear when iconnifying the main window.

I suppose the pop up_menu  should behave in a transient way.

when doing such a thing with google-chrome I first have my popup menu disapear and I need to click again to iconify.

perhaps we should have the choice and have access to a transient function.

----------
components: Tkinter
files: popupmenu.py
messages: 153037
nosy: marc.dechico
priority: normal
severity: normal
status: open
title: Menu.tk_popup  : menu doesn't disapear when main window is iconified.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24474/popupmenu.py

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

From report at bugs.python.org  Fri Feb 10 12:43:58 2012
From: report at bugs.python.org (Shivam)
Date: Fri, 10 Feb 2012 11:43:58 +0000
Subject: [New-bugs-announce] [issue13986] ValueError: cannot convert float
	NaN to integer
Message-ID: <1328874238.47.0.897260032056.issue13986@psf.upfronthosting.co.za>


New submission from Shivam <shivam.agarwal at aricent.com>:

Hi Team,
   Kindly help me in resolving below issue which arises when we do "make install" as it is show stopper for us.

Listing /usr/local/lib/python2.7 ...
Compiling /usr/local/lib/python2.7/BaseHTTPServer.py ...
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/compileall.py", line 213, in <module>
    exit_status = int(not main())
  File "/usr/local/lib/python2.7/compileall.py", line 200, in main
    force, rx, quiet):
  File "/usr/local/lib/python2.7/compileall.py", line 50, in compile_dir
    if not compile_file(fullname, ddir, force, rx, quiet):
  File "/usr/local/lib/python2.7/compileall.py", line 99, in compile_file
    ok = py_compile.compile(fullname, None, dfile, True)
  File "/usr/local/lib/python2.7/py_compile.py", line 108, in compile
    timestamp = long(os.fstat(f.fileno()).st_mtime)
ValueError: cannot convert float NaN to integer
make: *** [libinstall] Error 1


Addtionaly:
-----------
At the time of make below message is flashed as well:

Failed to build these modules:
datetime           dbm

----------
components: Build
messages: 153039
nosy: shivam_python_issues
priority: normal
severity: normal
status: open
title: ValueError: cannot convert float NaN to integer
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 10 14:45:58 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Feb 2012 13:45:58 +0000
Subject: [New-bugs-announce] [issue13987] Handling of broken markup in
	HTMLParser on 2.7
Message-ID: <1328881558.78.0.634398241399.issue13987@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch fixes a few problems with HTMLParser on 2.7.
Instead of raising error when invalid markup is detected, the parser now consumes the invalid input and proceeds.  This patch is a partial backport of #1486713.

After this two more patches will follow.
The first will get rid of errors raised while parsing declarations and should also solve #13576:
     def unknown_decl(self, data):
-        self.error("unknown declaration: %r" % (data,))
+        pass

The second will take care of "bogus comments" (see #13960).

Once this is done HTMLParser should be able to parse (almost) everything.  I'm planning to commit this before the release of 2.7.3.

----------
assignee: ezio.melotti
components: Library (Lib)
files: issue13987.diff
keywords: patch
messages: 153043
nosy: benjamin.peterson, eric.araujo, ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Handling of broken markup in HTMLParser on 2.7
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24475/issue13987.diff

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

From report at bugs.python.org  Fri Feb 10 15:52:57 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 10 Feb 2012 14:52:57 +0000
Subject: [New-bugs-announce] [issue13988] Expose the C implementation of
	ElementTree by default	when importing ElementTree
Message-ID: <1328885577.51.0.77313357168.issue13988@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Following the discussion on python-dev [1], this issue will track the re-organization of Lib/xml/etree to expose the C implementation (_elementtree) by default when importing ElementTree. The test suite will also have to be updated - it's required that it exercises both the C and the Python implementations.

I would like to make the import "magic" simple. Thus, the idea I currently plan to pursue is:

* xml/etree/ElementTree.py will be a simple facade that attempts to 'import *' from _elementtree, and on failure does 'import *' from pyElementTree
* The current contents of xml/etree/ElementTree.py will move to xml/etree/pyElementTree.py
* xml/etree/cElementTree.py disappears.

The test suite will be modified accordingly.


I'll be working on creating a patch for this. Any help, ideas, comments and discussions are more than welcome.


[1] http://mail.python.org/pipermail/python-dev/2012-February/116278.html

----------
components: Library (Lib)
messages: 153052
nosy: effbot, eli.bendersky, flox, scoder
priority: normal
severity: normal
status: open
title: Expose the C implementation of ElementTree by default when importing ElementTree
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 10 18:14:54 2012
From: report at bugs.python.org (Peter)
Date: Fri, 10 Feb 2012 17:14:54 +0000
Subject: [New-bugs-announce] [issue13989] gzip always returns byte strings,
	no text mode
Message-ID: <1328894094.18.0.18729195074.issue13989@psf.upfronthosting.co.za>


New submission from Peter <p.j.a.cock at googlemail.com>:

Consider the following example where I have a gzipped text file,

$ python3
Python 3.2 (r32:88445, Feb 28 2011, 17:04:33) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> with gzip.open("ex1.sam.gz") as handle:
...     line = handle.readline()
... 
>>> line
b'EAS56_57:6:190:289:82\t69\tchr1\t100\t0\t*\t=\t100\t0\tCTCAAGGTTGTTGCAAGGGGGTCTATGTGAACAAA\t<<<7<<<;<<<<<<<<8;;<7;4<;<;;;;;94<;\tMF:i:192\n'

Notice the file was opened in binary mode ("rb" is the default for gzip.open which is surprising given "t" is the default for open on Python 3), and a byte string is returned.

Now try explicitly using non-binary reading "r", and again you get bytes rather than a (unicode) string as I would expect:

>>> with gzip.open("ex1.sam.gz", "r") as handle:
...     line = handle.readline()
... 
>>> line
b'EAS56_57:6:190:289:82\t69\tchr1\t100\t0\t*\t=\t100\t0\tCTCAAGGTTGTTGCAAGGGGGTCTATGTGAACAAA\t<<<7<<<;<<<<<<<<8;;<7;4<;<;;;;;94<;\tMF:i:192\n'


Now try and use "t" or "rt" to be even more explicit that text mode is desired,

>>> with gzip.open("ex1.sam.gz", "t") as handle:
...     line = handle.readline()
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pjcock/lib/python3.2/gzip.py", line 46, in open
    return GzipFile(filename, mode, compresslevel)
  File "/Users/pjcock/lib/python3.2/gzip.py", line 157, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
ValueError: can't have text and binary mode at once


>>> with gzip.open("ex1.sam.gz", "rt") as handle:
...     line = handle.readline()
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pjcock/lib/python3.2/gzip.py", line 46, in open
    return GzipFile(filename, mode, compresslevel)
  File "/Users/pjcock/lib/python3.2/gzip.py", line 157, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
ValueError: can't have text and binary mode at once


See also Issue #5148 which is perhaps somewhat related.

----------
components: None
messages: 153067
nosy: maubp
priority: normal
severity: normal
status: open
title: gzip always returns byte strings, no text mode
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 10 18:32:34 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Fri, 10 Feb 2012 17:32:34 +0000
Subject: [New-bugs-announce] [issue13990] Benchmarks: 2to3 failures on the
	py3 side
Message-ID: <1328895154.39.0.105937484663.issue13990@psf.upfronthosting.co.za>


New submission from Francisco Mart?n Brugu? <francismb at email.de>:

Steps to reproduce:
after following the usage instructions from make_perf3.sh go to the the py3 benchmarks directory and run the lib/2to3 tests (python3.2 test.py). The result are 3 failures and 17 errors. The equivalent procedure in the py2 benchmarks directory succeeds (python2.7 test.py).

A summary is attached (the whole paste at http://pastebin.com/PAAhGsdR)

Cheers,
francis

----------
assignee: collinwinter
components: 2to3 (2.x to 3.x conversion tool), Benchmarks
files: FailuresErrors.txt
messages: 153069
nosy: collinwinter, francismb
priority: normal
severity: normal
status: open
title: Benchmarks: 2to3 failures on the py3 side
versions: Python 3.2
Added file: http://bugs.python.org/file24477/FailuresErrors.txt

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

From report at bugs.python.org  Fri Feb 10 21:53:23 2012
From: report at bugs.python.org (andrea crotti)
Date: Fri, 10 Feb 2012 20:53:23 +0000
Subject: [New-bugs-announce] [issue13991] namespace packages depending on
	order
Message-ID: <1328907203.29.0.677752935093.issue13991@psf.upfronthosting.co.za>


New submission from andrea crotti <andrea.crotti.0 at gmail.com>:

I am not really sure that it is a bug, but for me it's at least not the expected behaviour.
In short supposing I have two namespace packages ab and ac (as seen in the tar file), this works perfectly:

import sys
from os import path
sys.path.append(path.abspath('ab'))
sys.path.append(path.abspath('ac'))

from a.b import api as api_ab
from a.c import api as api_ac


But this doesn't:
import sys
from os import path
sys.path.append(path.abspath('ab'))

from a.b import api as api_ab

sys.path.append(path.abspath('ac'))
from a.c import api as api_ac

And raises an ImportError
from a.c import api as api_ac
ImportError: No module named c

Which means that if you actually append all the paths containing package resources before trying to import something it works, but if you interleave the path mangling, it won't..

Is this a bug or maybe I'm doing something wrong?

----------
assignee: tarek
components: Distutils
files: namespace.tar.gz
messages: 153076
nosy: andrea.crotti, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: namespace packages depending on order
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file24478/namespace.tar.gz

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

From report at bugs.python.org  Sat Feb 11 13:55:53 2012
From: report at bugs.python.org (Aaron Staley)
Date: Sat, 11 Feb 2012 12:55:53 +0000
Subject: [New-bugs-announce] [issue13992] Segfault in PyTrash_destroy_chain
Message-ID: <1328964953.21.0.536994091719.issue13992@psf.upfronthosting.co.za>


New submission from Aaron Staley <usaar33 at gmail.com>:

Am frequently getting segmentation faults with my python program.  I am utilizing heavy use of threading and sockets.

All sorts of ones are showing in syslog:

kernel: [7763578.475590] python[10097]: segfault at 88e5a0 ip 000000000088e5a0 sp 00007f640efd4028 error 15 in python2.7[833000+69000]
Feb 11 11:39:41 ip-10-8-197-187 kernel: [7762910.806782] python[6228]: segfault at 16 ip 0000000000000016 sp 00007fe488fb0028 error 14 in python2.7[400000+233000]
Feb 11 07:36:09 ip-10-8-197-187 kernel: [7748298.747145] python[11376]: segfault at 16 ip 0000000000000016 sp 00007f28767ab028 error 14 in python2.7[400000+233000]

Managed to capture one coredump:

Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000009 in ?? ()
(gdb) where
#0  0x0000000000000009 in ?? ()
#1  0x000000000046670f in _PyTrash_destroy_chain () at ../Objects/object.c:2448
#2  0x00000000004bd0df in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x0, defcount=0, closure=
    (<cell at remote 0x293ef68>, <cell at remote 0x21c78d8>, <cell at remote 0x239e168>, <cell at remote 0x219ef30>, <cell at remote 0x2397a28>, <cell at remote 0x2129868>, <cell at remote 0x2397590>, <cell at remote 0x2397be8>, <cell at remote 0x2397fa0>)) at ../Python/ceval.c:3264
#3  0x00000000004b6a5b in fast_function (nk=<optimized out>, na=0, n=<optimized out>, pp_stack=0x7f778ef9c1b0, func=<function at remote 0x20afa28>) at ../Python/ceval.c:4117
#4  call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c1b0) at ../Python/ceval.c:4042
#5  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#6  0x00000000004bcd2d in PyEval_EvalCodeEx (co=0x168f6b0, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x169f260, defcount=2, closure=
    0x0) at ../Python/ceval.c:3253
#7  0x00000000004b6a5b in fast_function (nk=<optimized out>, na=3, n=<optimized out>, pp_stack=0x7f778ef9c3a0, func=<function at remote 0x16a00c8>) at ../Python/ceval.c:4117
#8  call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c3a0) at ../Python/ceval.c:4042
#9  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#10 0x00000000004bd325 in PyEval_EvalCodeEx (co=0x168f8b0, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=5, defs=0x169a6c8, defcount=5, closure=
    0x0) at ../Python/ceval.c:3253
#11 0x00000000004b6a5b in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7f778ef9c590, func=<function at remote 0x16a0140>) at ../Python/ceval.c:4117
#12 call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c590) at ../Python/ceval.c:4042
#13 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#14 0x00000000004bcd2d in PyEval_EvalCodeEx (co=0x168a130, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x1684d28, defcount=1, closure=
    0x0) at ../Python/ceval.c:3253
#15 0x00000000004b6a5b in fast_function (nk=<optimized out>, na=2, n=<optimized out>, pp_stack=0x7f778ef9c780, func=<function at remote 0x1763758>) at ../Python/ceval.c:4117
#16 call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c780) at ../Python/ceval.c:4042
#17 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#18 0x00000000004b6d77 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=0x7f778ef9c8c0, func=<function at remote 0x1ebf050>) at ../Python/ceval.c:4107
#19 call_function (oparg=<optimized out>, pp_stack=0x7f778ef9c8c0) at ../Python/ceval.c:4042
#20 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#21 0x00000000004b6d77 in fast_function (nk=<optimized out>, na=<optimized out>, n=<optimized out>, pp_stack=0x7f778ef9ca00, func=<function at remote 0xc5f5f0>) at ../Python/ceval.c:4107
#22 call_function (oparg=<optimized out>, pp_stack=0x7f778ef9ca00) at ../Python/ceval.c:4042
#23 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at ../Python/ceval.c:2666
#24 0x00000000004bcd2d in PyEval_EvalCodeEx (co=0xc0d9b0, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kws=<optimized out>, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at ../Python/ceval.c:3253
#25 0x0000000000448edf in function_call (func=<function at remote 0xc5f500>, arg=
    (<ProvisionThread(_Thread__ident=140151476573952, _Thread__block=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x33d2fd0>, acquire=<built-in method acquire of thread.lock object at remote 0x33d2fd0>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x33d2fd0>) at remote 0x327a790>, _Thread__name='Thread-193', _Thread__daemonic=True, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x33d2b10>, acquire=<built-in method acquire of thread.lock object at remote 0x33d2b10>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x33d2b10>) at remote 0x327ab10>) at remote 0x33a6350>, _Thread__stderr=<file at remote 0x7f77cffb0270>, instance=<Instance(kernel=u'aki-825ea7eb', root_device_type=u'ebs', private_dns_name=u'ip-10-64-50-6.ec2.internal', previous_state=None, spot_instance_request_id=None, hypervis...(truncated), kw=0x0) at ../Objects/funcobject.c:526
#26 0x000000000041ad2a in PyObject_Call (func=<function at remote 0xc5f500>, arg=<optimized out>, kw=<optimized out>) at ../Objects/abstract.c:2529
#27 0x000000000043074e in instancemethod_call (func=<function at remote 0xc5f500>, arg=
    (<ProvisionThread(_Thread__ident=140151476573952, _Thread__block=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x33d2fd0>, acquire=<built-in method acquire of thread.lock object at remote 0x33d2fd0>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x33d2fd0>) at remote 0x327a790>, _Thread__name='Thread-193', _Thread__daemonic=True, _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x33d2b10>, acquire=<built-in method acquire of thread.lock object at remote 0x33d2b10>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x33d2b10>) at remote 0x327ab10>) at remote 0x33a6350>, _Thread__stderr=<file at remote 0x7f77cffb0270>, instance=<Instance(kernel=u'aki-825ea7eb', root_device_type=u'ebs', private_dns_name=u'ip-10-64-50-6.ec2.internal', previous_state=None, spot_instance_request_id=None, hypervis...(truncated), kw=0x0) at ../Objects/classobject.c:2578
#28 0x000000000041ad2a in PyObject_Call (func=<instancemethod at remote 0x34fa320>, arg=<optimized out>, kw=<optimized out>) at ../Objects/abstract.c:2529
#29 0x00000000004b5d76 in PyEval_CallObjectWithKeywords (func=<instancemethod at remote 0x34fa320>, arg=(), kw=<optimized out>) at ../Python/ceval.c:3890
#30 0x00000000004f06c0 in t_bootstrap (boot_raw=<optimized out>) at ../Modules/threadmodule.c:614
#31 0x00007f77cfbafefc in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#32 0x00007f77cea4789d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#33 0x0000000000000000 in ?? ()

----------
components: Interpreter Core
messages: 153123
nosy: Aaron.Staley
priority: normal
severity: normal
status: open
title: Segfault in PyTrash_destroy_chain
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 11 14:49:57 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 11 Feb 2012 13:49:57 +0000
Subject: [New-bugs-announce] [issue13993] Handling of broken end tags in
	HTMLParser
Message-ID: <1328968197.87.0.293618482144.issue13993@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch fixes the parser to handle broken end tags like:
</label</p>
</div end tmAd-leaderBoard>
</<h4>
</li class="unit">
</li\r\n\t\t\t\t\t\t</ul>
</><

----------
assignee: ezio.melotti
components: Library (Lib)
files: issue13993.diff
keywords: patch
messages: 153126
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
stage: commit review
status: open
title: Handling of broken end tags in HTMLParser
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24487/issue13993.diff

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

From report at bugs.python.org  Sat Feb 11 17:41:56 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Feb 2012 16:41:56 +0000
Subject: [New-bugs-announce] [issue13994] incomplete revert in 2.7 Distutils
	left two copies of	customize_compiler
Message-ID: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

While final testing Distutils changes for Issue13590, I noticed that a few tests were failing unexpectedly on 2.7.x but passing on 3.2.x.  Upon further investigation, I discovered that in 2.7 there are two copies of "customize_compiler", the function being modified in Issue13590.  It appears that at one point prior to the decision to make no feature changes to Distutils, that customize_compiler was moved from distutils.sysconfig to distutils.ccompiler (fa69e891edf4).  Then, when the decision was made to revert changes and proceed with a new Distutils2/packaging, feature changes were reverted in 2.7 but, for unexplained reasons, only part of the changes were reverted (ad22bc22dddc).  Perhaps a clue is in the commit message:
  "reverting partially distutils to its 2.6.x state so 2.7a4 looks more
   like the 2.7b1 in this. the whole revert will occur after a4 is tagged "

>From the change logs, I see no evidence that the whole revert ever happened.  This has left 2.7 Distutils with two virtually identical versions of customize_compiler with some commands and tests calling one and others calling the other.  (In 3.2.x, the only version is in distutils.sysconfig.)  They *were* virtually identically until Issue13590 changed one and missed the other.

Patch to follow which completes the revert for customize_compiler and brings 2.7.x and 3.2.2 back into sync with respect to this.  This patch is needed immediately for the upcoming 2.7.3 release.  I strongly urge a more complete audit for other discrepancies between the 2.7.x and 3.2.x versions of Distutils; this isn't the first time we've been burned recently by the effects of the reverts in 2.7.

----------
assignee: tarek
components: Distutils
messages: 153130
nosy: benjamin.peterson, eric.araujo, ned.deily, tarek
priority: release blocker
severity: normal
stage: needs patch
status: open
title: incomplete revert in 2.7 Distutils left two copies of customize_compiler
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 11 21:16:17 2012
From: report at bugs.python.org (Matthew Woodcraft)
Date: Sat, 11 Feb 2012 20:16:17 +0000
Subject: [New-bugs-announce] [issue13995] sqlite3 Cursor.rowcount
	documentation for old sqlite bug
Message-ID: <1328991377.3.0.315009784222.issue13995@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

The documentation for the sqlite3 module contains the following statement, under 'Cursor.rowcount':

  For DELETE statements, SQLite reports rowcount as 0 if you make a DELETE FROM table without any condition.

This doesn't happen for me (with sqlite 3.7.9): rowcount returns the correct value in this case.

According to http://www.sqlite.org/lang_delete.html#truncateopt , this was a bug that was fixed in SQLite 3.6.5 (in 2008).

So I think the Python documentation should either omit this paragraph, or else explain that it only applies to older versions of SQLite.


Also, the first example under 'Using shortcut methods' has code to work around this bug, which should perhaps be removed.

----------
assignee: docs at python
components: Documentation
messages: 153136
nosy: docs at python, mattheww
priority: normal
severity: normal
status: open
title: sqlite3 Cursor.rowcount documentation for old sqlite bug

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

From report at bugs.python.org  Sat Feb 11 22:11:09 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 11 Feb 2012 21:11:09 +0000
Subject: [New-bugs-announce] [issue13996] "What's New in Python" should have
	initial release date	on heading
Message-ID: <1328994669.43.0.0878472757687.issue13996@psf.upfronthosting.co.za>


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

As an example, the date near the top of this document http://docs.python.org/py3k/whatsnew/3.0.html matches that of today, which can be misleading (it appears as if the thing was released today).

Also, by initial release, I mean the first "final", not the point release. Maybe any other date mentioned would perhaps be the date the docs were updated, *not* the date they were rebuilt.

----------
assignee: docs at python
components: Documentation
messages: 153138
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: "What's New in Python" should have initial release date on heading
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/issue13996>
_______________________________________

From report at bugs.python.org  Sun Feb 12 05:33:07 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Feb 2012 04:33:07 +0000
Subject: [New-bugs-announce] [issue13997] Add open_ascii() builtin
Message-ID: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>


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

(This proposes a new builtin, so may need to become a PEP)

A common programming task is "I want to process this text file, I know it's in an ASCII compatible encoding, I don't know which one specifically, but I'm only manipulating the ASCII parts so it doesn't matter".

In Python 2, you handle that task by doing:

    f = open(fname)

The non-ASCII parts are then carried along as 8-bit bytes and reproduced faithfully when written back out.

In Python 3, you handle it by doing:

    f = open(fname, encoding="ascii", errors="surrogateescape")

The non-ASCII parts are then carried along as code points in the Unicode Private Use Area and reproduced faithfully when written back out.

It would be significantly more friendly to beginners (and migrants from Python 2) if the following shorthand spelling was available out of the box:

    f = open_ascii(fname)

----------
messages: 153164
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add open_ascii() builtin

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

From report at bugs.python.org  Sun Feb 12 09:54:43 2012
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sun, 12 Feb 2012 08:54:43 +0000
Subject: [New-bugs-announce] [issue13998] Lookbehind assertions go behind
	the start position for	the match
Message-ID: <1329036883.7.0.662970564139.issue13998@psf.upfronthosting.co.za>


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

compiled regex objects' match method offers an optional "pos" parameter described to be roughly equivalent to slicing except for how it treats the "^" operation. See http://docs.python.org/library/re.html#re.RegexObject.search

However, the behavior of lookbehind assertions also differs:

>>> re.compile("(?<=a)b").match("ab", 1)
<_sre.SRE_Match object at 0x...>
>>> re.compile("(?<=a)b").match("ab"[1:])
>>>

This alone might be a documentation bug, but the behavior is also inconsistent with the behavior of lookahead assertions, which do *not* look past the endpos:

>>> re.compile("a(?=b)").match("ab", 0, 1)
>>> re.compile("a(?=b)").match("ab")
<_sre.SRE_Match object at 0x...>
>>>

----------
components: Regular Expressions
messages: 153188
nosy: Devin Jeanpierre, ezio.melotti
priority: normal
severity: normal
status: open
title: Lookbehind assertions go behind the start position for the match
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Feb 12 19:46:04 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 12 Feb 2012 18:46:04 +0000
Subject: [New-bugs-announce] [issue13999] Queue references in
	multiprocessing doc points to Queue	module and not to self
Message-ID: <1329072364.23.0.444581618774.issue13999@psf.upfronthosting.co.za>


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

At the subject says, several references to Queue are linking to Queue module and not to multiprocessing.

----------
assignee: docs at python
components: Documentation
messages: 153218
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Queue references in multiprocessing doc points to Queue module and not to self
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 13 10:54:09 2012
From: report at bugs.python.org (Andrew Moffat)
Date: Mon, 13 Feb 2012 09:54:09 +0000
Subject: [New-bugs-announce] [issue14000] Subprocess stdin.flush does not
	flush
Message-ID: <1329126849.72.0.845817080547.issue14000@psf.upfronthosting.co.za>


New submission from Andrew Moffat <andrew.robert.moffat at gmail.com>:

The following code only works if the "p.stdin.close()" line is uncommented.  It seems that stdin only flushes to the process on stdin.close(), not on stdin.flush().

-----------------------------------

import subprocess as subp
import threading
import time


p = subp.Popen(["tr", "[:lower:]", "[:upper:]"],
    stdin=subp.PIPE, stderr=subp.PIPE, stdout=subp.PIPE, close_fds=True)


def read(stdout):
    while True:
        line = stdout.readline()
        if not line: break
        print(line.decode("utf8"))

t = threading.Thread(target=read, args=(p.stdout,))
t.daemon = True
t.start()

p.stdin.write("uppercase\n".encode())
p.stdin.flush()
#p.stdin.close()

time.sleep(1)

----------
components: None
messages: 153257
nosy: amoffat
priority: normal
severity: normal
status: open
title: Subprocess stdin.flush does not flush
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Feb 13 14:45:34 2012
From: report at bugs.python.org (Jan Lieskovsky)
Date: Mon, 13 Feb 2012 13:45:34 +0000
Subject: [New-bugs-announce] [issue14001] Python v2.7.2 / v3.2.2
	(SimpleXMLRPCServer): DoS	(excessive CPU usage) by processing
	malformed XMLRPC / HTTP	POST request
Message-ID: <1329140734.41.0.0376676358855.issue14001@psf.upfronthosting.co.za>


New submission from Jan Lieskovsky <iankko at seznam.cz>:

A denial of service flaw was found in the way Simple XML-RPC Server module of Python processed client connections, that were closed prior the complete request body has been received. A remote attacker could use this flaw to cause Python Simple XML-RPC based server process to consume excessive amount of CPU.

Credit:
Issue reported by Daniel Callaghan

References:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=789790

Steps to reproduce:
------------------
A) for v3.2.2 version:

1) start server:
cat s.py 
#!/usr/local/bin/python3

from xmlrpc.server import SimpleXMLRPCServer
server = SimpleXMLRPCServer(('127.0.0.1', 12345))
server.serve_forever()

2) # top

3) issue request from client:
echo -e 'POST /RPC2 HTTP/1.0\r\nContent-Length: 100\r\n\r\nlol bye' | nc localhost 12345

Return to 'top' screen and see, how CPU consumption on particular host quickly moves to 100%.

B) for v2.7.2 version:

1) start server:

cat s.py 
#!/usr/bin/python

from SimpleXMLRPCServer import SimpleXMLRPCServer

server = SimpleXMLRPCServer(('127.0.0.1', 12345))
server.serve_forever()

Steps 2) and 3) for v2.7.2 version are identical to
those for v3.2.2 version.

----------
components: Library (Lib)
messages: 153267
nosy: iankko
priority: normal
severity: normal
status: open
title: Python v2.7.2 / v3.2.2 (SimpleXMLRPCServer): DoS (excessive CPU usage) by processing malformed XMLRPC / HTTP POST request
type: security
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Feb 13 16:32:08 2012
From: report at bugs.python.org (Paul Moore)
Date: Mon, 13 Feb 2012 15:32:08 +0000
Subject: [New-bugs-announce] [issue14002] distutils2 fails to install a
	package from PyPI on	Python 2.7.2
Message-ID: <1329147128.07.0.548553326464.issue14002@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

I created a bdist_wininst installer for distutils2 and installed it into my Python 2.7.2 installation. This is on Wondows, 32-bit. I then tried to do a simple install to test it was working.

>python -m distutils2.run install stemming
Checking the installation location...
Getting information about 'stemming'...
extensions in requires.txt are not supported (used by u'Genshi' 0.6)
u'pywin32': u'214' is not a valid version (field 'Version')
extensions in requires.txt are not supported (used by u'sqlpython' 1.7.2)
Traceback (most recent call last):
  File "D:\Apps\Python27\lib\runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "D:\Apps\Python27\lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 664, in <module>
    sys.exit(main())
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 651, in main
    return dispatcher()
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 639, in __call__
    return func(self, self.args)
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "D:\Apps\Python27\lib\site-packages\distutils2\run.py", line 167, in _install
    return not install(target)
  File "D:\Apps\Python27\lib\site-packages\distutils2\install.py", line 514, in install
    info = get_infos(project)
  File "D:\Apps\Python27\lib\site-packages\distutils2\install.py", line 338, in get_infos
    release = index.get_release(requirements)
  File "D:\Apps\Python27\lib\site-packages\distutils2\pypi\wrapper.py", line 28, in decorator
    if f != func.im_self and hasattr(f, func.f_name):
AttributeError: 'function' object has no attribute 'f_name'

The initial errors look like complaints about existing packages I have installed by other means (setuptools or bdist_wininst). The final one looks like a bug in distutils2, though.

----------
assignee: tarek
components: Distutils2
messages: 153278
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: distutils2 fails to install a package from PyPI on Python 2.7.2
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 13 20:05:35 2012
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Mon, 13 Feb 2012 19:05:35 +0000
Subject: [New-bugs-announce] [issue14003] __self__ on built-in functions is
	not as documented
Message-ID: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>


New submission from ????? ???????? <DXDragon at yandex.ru>:

The language reference says this in section 3.2:
 
~
Built-in functions
 
A built-in function object is a wrapper around a C function. Examples of built-in functions are len() and math.sin() <...> Special read-only attributes: <...> __self__ is set to None (but see the next item) <...>.
~

That is not the case:

ActivePython 3.2.2.3 (ActiveState Software Inc.) based on
Python 3.2.2 (default, Sep  8 2011, 10:55:13) [MSC v.1500 64 bit (AMD64)]  
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len.__self__
<module 'builtins' (built-in)>
>>> open.__self__
<module 'io' (built-in)>
>>> import math
>>> math.sin.__self__
<module 'math' (built-in)>

----------
assignee: docs at python
components: Documentation
messages: 153287
nosy: SpecLad, docs at python
priority: normal
severity: normal
status: open
title: __self__ on built-in functions is not as documented
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb 13 21:57:08 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 13 Feb 2012 20:57:08 +0000
Subject: [New-bugs-announce] [issue14004] Distutils filelist selects too
	many files on Windows
Message-ID: <1329166628.27.0.616152401371.issue14004@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

When using a MANIFEST.in with only "include *.txt", on Windows, distutils grabs too many files. I set DISTUTILS_DEBUG=1 and ran ./setup.py sdist on the keyring library and it included this output:

    include *.txt
    include_pattern: applying regex r'^[^/]*\.txt\Z(?ms)'
     adding CHANGES.txt
     adding CONTRIBUTORS.txt
     adding .hg\last-message.txt
     adding keyring.egg-info\dependency_links.txt
     adding keyring.egg-info\requires.txt
     adding keyring.egg-info\SOURCES.txt
     adding keyring.egg-info\top_level.txt

As you can see, this is not a recursive include, but it's matching several files not in the supplied pattern (files in .hg/ and keyring.egg-info/).

It's obvious from the regular expression that the regex doesn't properly account for os.sep.

----------
assignee: tarek
components: Distutils
messages: 153302
nosy: eric.araujo, jason.coombs, tarek
priority: normal
severity: normal
status: open
title: Distutils filelist selects too many files on Windows
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 13 23:51:06 2012
From: report at bugs.python.org (Scott Bowman)
Date: Mon, 13 Feb 2012 22:51:06 +0000
Subject: [New-bugs-announce] [issue14005] IDLE Crash when running/saving a
	file
Message-ID: <1329173466.12.0.791681771945.issue14005@psf.upfronthosting.co.za>


New submission from Scott Bowman <scott.thomas.bowman at gmail.com>:

Whenever I save or try to run a program from the text editor window, IDLE crashes. Any suggestions? I'm running Windows 7, btw.

----------
components: None
messages: 153305
nosy: Scott.Bowman
priority: normal
severity: normal
status: open
title: IDLE Crash when running/saving a file
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb 14 04:28:45 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 03:28:45 +0000
Subject: [New-bugs-announce] [issue14006] Improve the documentation of
	xml.etree.ElementTree
Message-ID: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The documentation of xml.etree.ElementTree has to be improved. The first, very obvious step, would be to start the documentation page with a general overview of the module + some simple examples. The current opening section makes no sense for this module.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 153318
nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, flox, scoder
priority: normal
severity: normal
status: open
title: Improve the documentation of xml.etree.ElementTree
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 14 05:16:28 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 14 Feb 2012 04:16:28 +0000
Subject: [New-bugs-announce] [issue14007] xml.etree.ElementTree - XMLParser
	and TreeBuilder's	doctype() method missing
Message-ID: <1329192988.64.0.354189735973.issue14007@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Although documented, the C accelerator of xml.etree.ElementTree (used by default since issue 13988) does not use or define the doctype() methods of the XMLParser and TreeBuilder classes, although this method is documented.

As far as I can tell, this problem exists in 3.2 as well and wasn't introduced by the changes in issue 13988.

----------
components: Library (Lib)
messages: 153324
nosy: effbot, eli.bendersky, ezio.melotti, flox
priority: high
severity: normal
stage: needs patch
status: open
title: xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 14 12:38:59 2012
From: report at bugs.python.org (Yuval Greenfield)
Date: Tue, 14 Feb 2012 11:38:59 +0000
Subject: [New-bugs-announce] [issue14008] Python uses the new source when
	reporting an old	exception
Message-ID: <1329219539.12.0.054946832037.issue14008@psf.upfronthosting.co.za>


New submission from Yuval Greenfield <ubershmekel at gmail.com>:

I ran the following code:

    import time
    time.sleep(10)
    print 1 / 0


And then modified the source before it hit the exception, python prints out the wrong lines from the new source file.


    e:\Dropbox\dev\python\metricbot>c:\python32\python test.py
    Traceback (most recent call last):
      File "test.py", line 3, in <module>
        alkdf;alsdkf;l
    ZeroDivisionError: division by zero


What should have been printed out:

    e:\Dropbox\dev\python\metricbot>test.py
    Traceback (most recent call last):
      File "E:\Dropbox\dev\python\metricbot\test.py", line 3, in <module>
        print 1 / 0
    ZeroDivisionError: integer division or modulo by zero


Although this is a toy example, I did run in to the problem when working on a long running script that I was upgrading.

Tested it and got the same results on python 2.7 and 3.2.

----------
components: Interpreter Core
messages: 153337
nosy: ubershmekel
priority: normal
severity: normal
status: open
title: Python uses the new source when reporting an old exception
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 14 16:26:43 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 15:26:43 +0000
Subject: [New-bugs-announce] [issue14009] Clearer documentation for
	cElementTree
Message-ID: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

This patch should clarify how to use cElementTree usage, as well as improving indexing.

----------
assignee: docs at python
components: Documentation
messages: 153338
nosy: docs at python, eli.bendersky, eric.araujo
priority: normal
severity: normal
stage: commit review
status: open
title: Clearer documentation for cElementTree
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb 14 16:58:26 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 14 Feb 2012 15:58:26 +0000
Subject: [New-bugs-announce] [issue14010] deeply nested filter segfaults
Message-ID: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

http://paste.pocoo.org/show/550884/ will reliably segfault Python3 on all platforms (similar versions for Python2 using itertools work)

----------
components: Interpreter Core
messages: 153344
nosy: alex, benjamin.peterson
priority: normal
severity: normal
status: open
title: deeply nested filter segfaults
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/issue14010>
_______________________________________

From report at bugs.python.org  Tue Feb 14 17:03:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:03:51 +0000
Subject: [New-bugs-announce] [issue14011] packaging should use shutil
	archiving functions	transparently
Message-ID: <1329235431.19.0.233591312424.issue14011@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The packaging commands sdist and bdist can create various kinds of archives.  The function used to create them is thankfully just a thin wrapper around shutil.make_archive (extracted from distutils), and sdist also uses shutil.get_archive_formats to validate its --formats option.  bdist however maintains its own registry.

The docstrings, help texts and reST documentation also contain out-of-sync duplicate lists of allowed formats.

I?m working on a patch to fix this duplication.

----------
assignee: eric.araujo
components: Distutils2
messages: 153346
nosy: alexis, eric.araujo
priority: normal
severity: normal
status: open
title: packaging should use shutil archiving functions transparently
type: enhancement
versions: 3rd party, Python 3.3

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

From report at bugs.python.org  Tue Feb 14 17:10:37 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:10:37 +0000
Subject: [New-bugs-announce] [issue14012] Misc tarfile fixes
Message-ID: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found a few possible bugs in tarfile:

- ?mode in 'raw'? can give false positives for '' or 'ra'.  Most of the code also checks for ?len(mode) > 1?, but I find clearer and safer to just use ?mode in ('r', 'a', 'w')?.

- To use the shadowed builtin ?open?, tarfile uses both ?import as? and a local alias ?bltin_open = open?.  However, the second idiom would break if tarfile were reloaded.

- Error messages don?t say what the invalid mode was.  (Error messages are not part of the language, but nonetheless maybe it?s best not to commit that to stable branches.)

----------
components: Library (Lib)
files: tarfile-misc-bugs-3.2.diff
keywords: patch
messages: 153348
nosy: eric.araujo, lars.gustaebel
priority: normal
severity: normal
stage: commit review
status: open
title: Misc tarfile fixes
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24520/tarfile-misc-bugs-3.2.diff

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

From report at bugs.python.org  Tue Feb 14 17:27:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Feb 2012 16:27:27 +0000
Subject: [New-bugs-announce] [issue14013] tarfile should expose supported
	formats
Message-ID: <1329236847.51.0.270430673151.issue14013@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

shutil contains high-level functions to create a zipfile or a tarball.  When a new format is added to the tarfile module, then shutil needs to be updated manually.  If tarfile exposed the names of the compressors it supports, then shutil could just automatically support everything that tarfile supports instead of having to re-do import dances for optional modules (bz2, lzma, zlib) and also duplicate formats in its doc.

This may also be useful for other code wanting to do some introspection.

Attached patch implements tarfile.formats, a list of strings (I thought about using a frozenset but then followed the precedent set by the 3.3 crypt module).  Tests and docs not updated, I wanted to get Lars? approval on the principle first.

One could argue that this is not needed: compression modules are not added often; updating shutil after updating tarfile is not hard; it is not that useful to have access to the list of supported formats.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 153350
nosy: docs at python, eric.araujo, lars.gustaebel, nadeem.vawda
priority: normal
severity: normal
stage: patch review
status: open
title: tarfile should expose supported formats
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 14 19:01:53 2012
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 14 Feb 2012 18:01:53 +0000
Subject: [New-bugs-announce] [issue14014] codecs.StreamWriter.reset contract
	not fulfilled
Message-ID: <1329242513.77.0.581823861095.issue14014@psf.upfronthosting.co.za>


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

def reset(self):

        """ Flushes and resets the codec buffers used for keeping state.

            Calling this method should ensure that the data on the
            output is put into a clean state, that allows appending
            of new fresh data without having to rescan the whole
            stream to recover state.

        """
        pass

This does not ensure that the stream is flushed, as the docstring promises.  I believe the following would work better.


    def reset(self):
        """ Flushes and resets the codec buffers used for keeping state.

            Calling this method should ensure that the data on the
            output is put into a clean state, that allows appending
            of new fresh data without having to rescan the whole
            stream to recover state.

        """
        if hasattr(self.stream, "flush"): self.stream.flush()

----------
components: Unicode
messages: 153354
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: codecs.StreamWriter.reset contract not fulfilled
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb 14 19:56:30 2012
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 14 Feb 2012 18:56:30 +0000
Subject: [New-bugs-announce] [issue14015] surrogateescape largely missing
	from documentation
Message-ID: <1329245790.15.0.430373154575.issue14015@psf.upfronthosting.co.za>


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

Recent discussion on the mailing lists and in http://bugs.python.org/issue13997 make it clear that the best way to get python2 results for "ASCII-in-the-parts-I-might-process-or-change" is to replace 

    f = open(fname)
with
    f = open(fname, encoding="ascii", errors="surrogateescape")

Unfortunately, surrogateescape (let alone this recipe) is not easily discoverable.  

http://docs.python.org/dev/library/functions.html#open lists 5 error-handlers -- but not this one.  It says that other error handlers are possible if they are registered with http://docs.python.org/dev/library/codecs.html#codecs.register_error but I haven't found a way to determine which error handlers are already registered.

The codecs.register (as opposed to register_error) documentation does list it as a possible value, but that is the only reference.

The other 5 error handlers are also available as module-level functions within the codecs module, and have their own documenation sections within http://docs.python.org/dev/library/codecs.html

Neither help(open) nor import codecs; help(codecs) provides any hints of the existence of surrogateescape.  Both explicitly suggest that it does not exist, by enumerating other values.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 153359
nosy: Jim.Jewett, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: surrogateescape largely missing from documentation
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Feb 14 20:12:27 2012
From: report at bugs.python.org (Srikantha Kadur)
Date: Tue, 14 Feb 2012 19:12:27 +0000
Subject: [New-bugs-announce] [issue14016] Usage of socket.sendall() in
	multiple threads
Message-ID: <1329246747.9.0.165584216371.issue14016@psf.upfronthosting.co.za>


New submission from Srikantha Kadur <srikanthkadur at gmail.com>:

Here is my code.

    Func1():
        .
        .
        CliSock, addr = ServSocket.accept()
        print 'DataPortServ:Connected by', addr
	data.DataSendSock = CliSock
        
	for cnt in range(data.ThreadCnt):
            SessionId = startSessionId + SessionIdCnt* cnt      
            thread.start_new_thread(ThreadHandleDataPort,(("Thead"+str(cnt)),data,EventCnt[cnt],EventCnt[cnt+1],UECntPerThread,ip,SessionId))
            time.sleep(0.005)

ThreadHandleDataPort(args):
    #here i use socket.sendall
     while True:
        if ( 3 != data.bRunFlag):     
           if (len(data.AddedEvents) != 0) | (len(data.AddedReasons) != 0):
               #time.sleep(5)
     	       for EventCnt in range(StartEvent,StopEvent):
                   .
                   .
                   .
                   data.DataSendSock.sendall(SendEvent)
                   .
                   .

My application is a server and it accepts connection from the client on a port and start sending some messages to the client. While sending messages i use multiple threads for the same socket based on required traffic. 

I do not modify any global variables but i read only global variables.But at high Loads my messages are being corrupted, here is the snippet of the corruption

actual message should have been 
ABS1,1328577019.57,181138955,

instead im getting
ABS1,1329218634.91,181ABS1

so here is my Q:
Do i need to lock the socket before sending inside the threads or Python modules will take care of it? Please suggest.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 153361
nosy: srikadur
priority: normal
severity: normal
status: open
title: Usage of socket.sendall() in multiple threads
type: behavior

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

From report at bugs.python.org  Wed Feb 15 00:49:33 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 14 Feb 2012 23:49:33 +0000
Subject: [New-bugs-announce] [issue14017] io.TextIOWrapper should expose a
	documented	write_through attribute
Message-ID: <1329263373.63.0.201487376726.issue14017@psf.upfronthosting.co.za>


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

io.TextIOWrapper acquired a new "write_through" argument for 3.3, but that is not exposed as a documented attribute.

This is needed so that a text wrapper can be replaced with an equivalent that only alters selected settings (such as the Unicode error handler).

----------
components: Library (Lib)
messages: 153376
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: io.TextIOWrapper should expose a documented write_through attribute
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 15 02:01:28 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Feb 2012 01:01:28 +0000
Subject: [New-bugs-announce] [issue14018] OS X installer does not detect bad
	symlinks created by	Xcode 3.2.6
Message-ID: <1329267688.42.0.5159808393.issue14018@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

Xcode 3.2.6, the most recent release for OS X 10.6 (Snow Leopard), has a subtle but critical bug that affects Python builds using OS X SDKs (--enable-universalsdk=/Developer/SDKs/MacOSX10.?.sdk).  The Xcode installer creates faulty symlinks to /Library within  /Developer/SDKs.  The net effect is that frameworks installed in /Library, such as ActiveState Tcl and Tk, are not found during a build using the SDK as they should be.

$ cd /Developer/SDKs/MacOSX10.6.sdk/Library
$ ls -l
total 8
lrwxr-xr-x  1 root  wheel  19 Mar 17 18:24 Frameworks@ -> 
/Library/Frameworks
 
it ends up with an extra Frameworks directory so that
 
/Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks/Frameworks/ -> /Library/Frameworks
 
The solution is to manually go in and fix the symlinks in 
/Developer/SDKs/MacOSX10.6.sdk, and remember to do so again if you have 
to reinstall Xcode 3.2.6.  AFAIK, this bug is unique to Xcode 3.2.6, not 
earlier versions of 3.2.x.

The effect on Python builds is that tkinter is linked against the Apple-supplied Tcl and Tk frameworks rather than the ActiveState ones which is not what is desired.

While the problem is created by Apple, the OS X Python installer build script, Mac/BuildScript/build-installer.py, should include a post-build check using otool -L that _tkinter.so is linked as expected.  The script already includes tests pre-build to ensure that the additional frameworks are in place.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 153381
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: OS X installer does not detect bad symlinks created by Xcode 3.2.6
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb 15 09:15:04 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 15 Feb 2012 08:15:04 +0000
Subject: [New-bugs-announce] [issue14019] Unify tests for str.format and
	string.Formatter
Message-ID: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>


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

A couple of issues have arisen where features were added to str.format without similarly being added to string.Formatter.

This is only possible because the test cases for the two are currently almost entirely separate.

A common set of tests defined as (fmt, args, kwargs, output) tuples would help ensure that the implementations remained consistent in the future.

----------
components: Tests
messages: 153392
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Unify tests for str.format and string.Formatter
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 15 14:59:32 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Feb 2012 13:59:32 +0000
Subject: [New-bugs-announce] [issue14020] Improve HTMLParser doc
Message-ID: <1329314372.41.0.194033246825.issue14020@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Attached patch reworks a bit the HTMLParser doc:
 - moved the basic example on the top and showed the output;
 - added a more complete parser with other examples;
 - fixed some factual errors;
 - added additional information for some methods;
 - added a couple of headers to divide the sections;
 - rephrased the text a bit to be more coherent and clear;
 - fixed a few links, typos, and terms;

I think the note about IE condcoms could be removed by the handle_comment doc, since it's already in the examples at the bottom.  A note in handle_data about the behavior with buffered input might be added in addition to the example at the bottom.

----------
assignee: ezio.melotti
components: Documentation
files: issue14020.diff
keywords: patch
messages: 153401
nosy: eli.bendersky, eric.araujo, ezio.melotti, terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: Improve HTMLParser doc
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24523/issue14020.diff

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

From report at bugs.python.org  Wed Feb 15 17:58:45 2012
From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=)
Date: Wed, 15 Feb 2012 16:58:45 +0000
Subject: [New-bugs-announce] [issue14021] Write pkg_info with local
	encoding(GBK) will be a	problem.
Message-ID: <1329325125.52.0.801195380714.issue14021@psf.upfronthosting.co.za>


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

D:\CI\bld\vcs\pygit2>python setup.py install
Find C:\Python32\python.exe
Using C:\Python32\python.exe
running install
running bdist_egg
running egg_info
writing pygit2.egg-info\PKG-INFO
Traceback (most recent call last):
  File "setup.py", line 106, in <module>
    **kwargs)
  File "C:\Python32\lib\distutils\core.py", line 148, in setup
    dist.run_commands()
  File "C:\Python32\lib\distutils\dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "C:\Python32\lib\distutils\dist.py", line 936, in run_command
    cmd_obj.run()
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\install.py", line 73, in run
    self.do_egg_install()
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\install.py", line 93, in do_egg_install
    self.run_command('bdist_egg')
  File "C:\Python32\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\Python32\lib\distutils\dist.py", line 936, in run_command
    cmd_obj.run()
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\bdist_egg.py", line 172, in run
    self.run_command("egg_info")
  File "C:\Python32\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\Python32\lib\distutils\dist.py", line 936, in run_command
    cmd_obj.run()
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\egg_info.py", line 172, in run
    writer(self, ep.name, os.path.join(self.egg_info,ep.name))
  File "C:\Python32\lib\site-packages\distribute-0.6.24-py3.2.egg\setuptools\command\egg_info.py", line 384, in write_pkg_info
    metadata.write_pkg_info(cmd.egg_info)
  File "C:\Python32\lib\distutils\dist.py", line 1015, in write_pkg_info
    self.write_pkg_file(pkg_info)
  File "C:\Python32\lib\distutils\dist.py", line 1031, in write_pkg_file
    file.write('Author: %s\n' % self.get_contact() )
UnicodeEncodeError: 'gbk' codec can't encode character '\xf1' in position 20: illegal multibyte sequence

D:\CI\bld\vcs\pygit2>
It's better to use utf8 instead.

----------
assignee: tarek
components: Distutils
messages: 153415
nosy: eric.araujo, tarek, ??.?
priority: normal
severity: normal
status: open
title: Write pkg_info with local encoding(GBK) will be a problem.
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 15 18:18:30 2012
From: report at bugs.python.org (Don Caldwell)
Date: Wed, 15 Feb 2012 17:18:30 +0000
Subject: [New-bugs-announce] [issue14022] bug in pkgutil.py with suggested
	fix
Message-ID: <1329326310.67.0.0755107537402.issue14022@psf.upfronthosting.co.za>


New submission from Don Caldwell <dfwcnj at gmail.com>:

in iter_modules there is a loop for fn in os.listdir(path): that can
fail on an OSError exception. here is a patch

                try:
                    for fn in os.listdir(path):
                        subname = inspect.getmodulename(fn)
                        if subname=='__init__':
                            ispkg = True
                            break
                    else:
                        continue    # not a package
                except OSError as (errno, strerror):
                    print "%s: %s\n" % (fn, strerror)

----------
components: Library (Lib)
messages: 153421
nosy: dfwc
priority: normal
severity: normal
status: open
title: bug in pkgutil.py with suggested fix
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb 15 18:32:39 2012
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Wed, 15 Feb 2012 17:32:39 +0000
Subject: [New-bugs-announce] [issue14023] bytes implied to be mutable
Message-ID: <1329327159.64.0.799949559846.issue14023@psf.upfronthosting.co.za>


New submission from ????? ???????? <DXDragon at yandex.ru>:

The language reference in section 5.2.2 states:

~
With the exception of bytes literals, these all correspond to immutable data types, <...>
~

But bytes objects are immutable as well.

----------
assignee: docs at python
components: Documentation
messages: 153422
nosy: SpecLad, docs at python
priority: normal
severity: normal
status: open
title: bytes implied to be mutable
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 15 19:08:23 2012
From: report at bugs.python.org (James Lekas)
Date: Wed, 15 Feb 2012 18:08:23 +0000
Subject: [New-bugs-announce] [issue14024] logging.Formatter Cache Prevents
	Exception Format	Overriding
Message-ID: <1329329303.3.0.810065424227.issue14024@psf.upfronthosting.co.za>


New submission from James Lekas <lekas at sonic.net>:

logging.Formatter.format() creates a cache called exc_text with a copy of the traceback text which it uses for all log handlers (I think).  When this cache is set, format() does not call formatException to format the exception/traceback data.

Unfortunately, this means that one cannot override logging.Formatter.formatException() for a specific log Handler.  For example, to create a stripped-down exception message for emailing to a non-technical audience, one might create the derived class NoStaceTraceFormatter, and attach an instance to the SMTPHandler using setFormatter():

class NoStackTraceFormatter(logging.Formatter):
    def formatException(self, exc_info):  # Don't emit the stack trace
        return '\n'.join(traceback.format_exception_only(exc_info[0], exc_info[1])) # type and value only

At least when other handlers exist for the logger, the new formatException call will probably never be invoked. (This might depend on the order in which the handlers are called when an exception log message arrives: the first handler would define the exception text.)

One partial workaround is to override the logging.Formatter.format() method to defeat the cache, causing the overriding formatException to be called.

    def format(self, record):
        record.exc_text = None # Defeat the common cache so formatException will be called.
        return logging.Formatter.format(self, record)

Unfortunately, this will create a new cached copy of the special-purpose exception text, possibly causing downstream handlers to emit the wrong message.

A possible solution would be to move the caching from logging.Formatter.format() to logging.Formatter.formatException, which would at least allow an individual handler to ignore the cache.  (However, all handlers would share the cache, possibly leading to trouble.)

The cache should probably be eliminated, as the premise on which it is based, "it's constant anyway", isn't strictly true.

----------
components: Library (Lib)
messages: 153425
nosy: jimlekas
priority: normal
severity: normal
status: open
title: logging.Formatter Cache Prevents Exception Format Overriding
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 15 22:00:00 2012
From: report at bugs.python.org (Jaap Karssenberg)
Date: Wed, 15 Feb 2012 21:00:00 +0000
Subject: [New-bugs-announce] [issue14025] unittest.TestCase.assertEqual does
	not show diff when	comparing str with unicode
Message-ID: <1329339600.71.0.863718430096.issue14025@psf.upfronthosting.co.za>


New submission from Jaap Karssenberg <jaap.karssenberg at gmail.com>:

When you compare two multiline strings with unittest.TestCase.assertEqual it is supposed to dispatch to assertMultiLineEqual and show a diff when the strings differ.

However this only works for two string of the same type (str or unicode). But mixing the two will just give the default message that they differ without the diff. THis is due to the way the dispatch checks types. Probably need to make an exception for comparing str with unicode.

Note that if the contents of both strings are the same, the assert will regard them equal, so it is not a strict check on the type perse.

----------
components: Library (Lib)
messages: 153434
nosy: jaap.karssenberg
priority: normal
severity: normal
status: open
title: unittest.TestCase.assertEqual does not show diff when comparing str with unicode
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 16 00:26:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 15 Feb 2012 23:26:11 +0000
Subject: [New-bugs-announce] [issue14026] test_cmd_line_script should
	include more sys.argv checks
Message-ID: <1329348371.61.0.243009313176.issue14026@psf.upfronthosting.co.za>


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

Currently, test_cmd_line_script only checks sys.argv[0] is set correctly.

It should pass some extra values after the script name, then include an appropriate check in the output of the launched script.

----------
components: Tests
keywords: easy
messages: 153448
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_cmd_line_script should include more sys.argv checks
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 16 07:32:19 2012
From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=)
Date: Thu, 16 Feb 2012 06:32:19 +0000
Subject: [New-bugs-announce] [issue14027] distutils2 lack of pysetup.bat
Message-ID: <1329373939.69.0.162264279004.issue14027@psf.upfronthosting.co.za>


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

Patch attaced.

----------
assignee: tarek
components: Distutils2
files: pysetup.bat
messages: 153460
nosy: alexis, eric.araujo, tarek, ??.?
priority: normal
severity: normal
status: open
title: distutils2 lack of pysetup.bat
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24528/pysetup.bat

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

From report at bugs.python.org  Thu Feb 16 08:57:53 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 16 Feb 2012 07:57:53 +0000
Subject: [New-bugs-announce] [issue14028] random.choice hits ValueError:
	cannot convert float NaN	to integer
Message-ID: <1329379073.39.0.519578524869.issue14028@psf.upfronthosting.co.za>


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

Using a 32-bit Python 2.6.5 on a Linux system at work we observed the following:

  File "/.../lib/python2.6/tempfile.py", line 349, in mktemp
    name = names.next()
  File "/.../lib/python2.6/tempfile.py", line 134, in next
    letters = [choose(c) for dummy in "123456"]
  File "/.../lib/python2.6/random.py", line 261, in choice
    return seq[int(self.random() * len(seq))]  # raises IndexError if seq is empty
ValueError: cannot convert float NaN to integer

This is rare and hard to reproduce.  The hardware appears to be healthy and this was on a server with ECC.


Some searching reveals that other people have hit this in random.choice in Python 2.7 as well:  https://bugs.launchpad.net/ubuntu/+source/desktopcouch/+bug/886159

The ubuntu developer seems to think this is related to time.time() returning NaN at some point (I haven't looked into that myself).

----------
messages: 153464
nosy: gregory.p.smith, tim_one
priority: normal
severity: normal
status: open
title: random.choice hits ValueError: cannot convert float NaN to integer
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/issue14028>
_______________________________________

From report at bugs.python.org  Thu Feb 16 10:02:00 2012
From: report at bugs.python.org (Lyudmil Nenov)
Date: Thu, 16 Feb 2012 09:02:00 +0000
Subject: [New-bugs-announce] [issue14029] When using setattr identifiers can
	start with any	character
Message-ID: <1329382920.47.0.960341753942.issue14029@psf.upfronthosting.co.za>


New submission from Lyudmil Nenov <lnenov at mm-sol.com>:

I am not sure if this is actually a bug. 

Given documentation @ http://docs.python.org/release/2.5.2/ref/identifiers.html, the issue is that setattr does not appear to check identifier for naming convention.

See a short example below. Running on windows

>>> sys.version_info(major=2, minor=7, micro=1, releaselevel='final', serial=0)
>>> sys.version_info
sys.version_info(major=2, minor=7, micro=1, releaselevel='final', serial=0)
>>> class Example():
	pass
>>> example = Example()
>>> example. at foo = 4
SyntaxError: invalid syntax
>>> setattr(example, '@foo', 'bar')
>>> dir(example)
['@foo', '__doc__', '__module__']
>>> example. at foo
SyntaxError: invalid syntax
>>> getattr(example, '@foo')
'bar'

----------
messages: 153468
nosy: lnenov
priority: normal
severity: normal
status: open
title: When using setattr identifiers can start with any character
type: behavior

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

From report at bugs.python.org  Thu Feb 16 10:37:15 2012
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 16 Feb 2012 09:37:15 +0000
Subject: [New-bugs-announce] [issue14030] Be more careful about selecting
	the compiler in distutils
Message-ID: <1329385035.22.0.0715283153402.issue14030@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

distutils incorrectly handles CFLAGS as 1 argument instead of
space-separated list of arguments. distutils should respect environment
variables, which set compiler, linker etc.

--- Lib/distutils/unixccompiler.py
+++ Lib/distutils/unixccompiler.py
@@ -297,7 +297,7 @@
        # this time, there's no way to determine this information from
        # the configuration data stored in the Python installation, so
        # we use this hack.
-        compiler = os.path.basename(sysconfig.get_config_var("CC"))
+        compiler = os.path.basename(self.compiler[0])
        if sys.platform[:6] == "darwin":
            # MacOSX's linker doesn't understand the -R flag at all
            return "-L" + dir

Patch was created by Arfrever Frehtes Taifersar Arahesis (arfrever.fta at gmail.com). It was originally written for PyPy, but it seems like it should actually apply to the stdlib. This patch is for 2.7, I'm hoping it could be taken as a bug fix.

----------
messages: 153471
nosy: djc
priority: normal
severity: normal
status: open
title: Be more careful about selecting the compiler in distutils

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

From report at bugs.python.org  Thu Feb 16 16:20:49 2012
From: report at bugs.python.org (Guido Kollerie)
Date: Thu, 16 Feb 2012 15:20:49 +0000
Subject: [New-bugs-announce] [issue14031] logging module cannot format
	str.format log messages
Message-ID: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za>


New submission from Guido Kollerie <guido at kollerie.com>:

When logging messages with variable data one typically writes:

    username = 'Guido'
    logging.info('User %s logged in', username)

However Python 3 has support str.format (PEP 3101). If one has adopted str.format for formatting strings in Python 3 code one should also be able to write the above as:

    logging.info('User {} logged in', username)

However this currently is not supported. For backwards compatibility,% style logging should remain the default. However when a logger is configured using:

    import logging
    logging.basicConfig(style='{', format='{levelname}:{message}')

all subsequent calls to logging.debug, logging.info, logging.warning, logging.error, logging.critical, logging.exception and logging.log should use str.format for formatting.

----------
messages: 153481
nosy: gkoller
priority: normal
severity: normal
status: open
title: logging module cannot format str.format log messages
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 16 17:17:51 2012
From: report at bugs.python.org (Jason Yeo)
Date: Thu, 16 Feb 2012 16:17:51 +0000
Subject: [New-bugs-announce] [issue14032] test_cmd_line_script prints
	undefined 'data' variable
Message-ID: <1329409071.29.0.619315923648.issue14032@psf.upfronthosting.co.za>


New submission from Jason Yeo <jasonyeo88 at gmail.com>:

Hi, I'm new around here. I was trying to fix issue 14026 and I found this problem. In test_cmd_line_script, the test_issue8202 tries to print an undefined data variable when verbose is set to > 1. I have a patch attached to print(out) instead of print(data). Please let me know if this is the correct thing to do.

----------
components: Tests
files: mypatch
messages: 153485
nosy: Jason.Yeo
priority: normal
severity: normal
status: open
title: test_cmd_line_script prints undefined 'data' variable
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file24531/mypatch

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

From report at bugs.python.org  Thu Feb 16 17:44:12 2012
From: report at bugs.python.org (=?utf-8?b?5YuH5YiaIOe9lw==?=)
Date: Thu, 16 Feb 2012 16:44:12 +0000
Subject: [New-bugs-announce] [issue14033] distutils problem with setup.py
	build &setup.py install	vs direct setup.py install
Message-ID: <1329410652.02.0.479827647227.issue14033@psf.upfronthosting.co.za>


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

D:\CI\bld\vcs>build-pygit2.bat

D:\CI\bld\vcs\pygit2>call python setup.py build  & call python setup.py install  & cd /d D:\CI\bld\vcs
running build
running build_py
running build_ext
building 'pygit2' extension
creating build
creating build\temp.win32-3.2
creating build\temp.win32-3.2\Release
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -ID:\CI\Tools\vcs\libgit2\include -IC:\Python32\
include -IC:\Python32\PC /Tcpygit2.c /Fobuild\temp.win32-3.2\Release\pygit2.obj
pygit2.c
pygit2.c(476) : warning C4101: 'aux' : unreferenced local variable
pygit2.c(498) : warning C4101: 'err' : unreferenced local variable
pygit2.c(1088) : warning C4101: 'err' : unreferenced local variable
pygit2.c(1185) : warning C4244: 'function' : conversion from 'git_time_t' to 'long', possible loss of data
pygit2.c(2794) : warning C4244: 'function' : conversion from 'const git_time_t' to 'long', possible loss of data
creating build\lib.win32-3.2
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:D:\CI\Tools\vcs\libgit2\lib /LIBPATH:C:\Pytho
n32\libs /LIBPATH:C:\Python32\PCbuild git2.lib /EXPORT:PyInit_pygit2 build\temp.win32-3.2\Release\pygit2.obj /OUT:build\lib.win32-3.2\pygit2.pyd /IMPL
IB:build\temp.win32-3.2\Release\pygit2.lib /MANIFESTFILE:build\temp.win32-3.2\Release\pygit2.pyd.manifest
   Creating library build\temp.win32-3.2\Release\pygit2.lib and object build\temp.win32-3.2\Release\pygit2.exp
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-3.2\Release\pygit2.pyd.manifest -outputresource:build\lib.
win32-3.2\pygit2.pyd;2
copying D:\CI\Tools\vcs\libgit2\bin\git2.dll -> pygit2
running install
running build
running build_py
copying pygit2\git2.dll -> build\lib.win32-3.2
running build_ext
running install_lib
copying build\lib.win32-3.2\git2.dll -> C:\Python32\Lib\site-packages
copying build\lib.win32-3.2\pygit2.pyd -> C:\Python32\Lib\site-packages
running install_egg_info
Writing C:\Python32\Lib\site-packages\pygit2-0.16.0-py3.2.egg-info

D:\CI\bld\vcs>

Direct install

D:\CI\bld\vcs>build-pygit2.bat

D:\CI\bld\vcs\pygit2>call python setup.py install  & cd /d D:\CI\bld\vcs
running install
running build
running build_py
running build_ext
building 'pygit2' extension
creating build
creating build\temp.win32-3.2
creating build\temp.win32-3.2\Release
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -ID:\CI\Tools\vcs\libgit2\include -IC:\Python32\
include -IC:\Python32\PC /Tcpygit2.c /Fobuild\temp.win32-3.2\Release\pygit2.obj
pygit2.c
pygit2.c(476) : warning C4101: 'aux' : unreferenced local variable
pygit2.c(498) : warning C4101: 'err' : unreferenced local variable
pygit2.c(1088) : warning C4101: 'err' : unreferenced local variable
pygit2.c(1185) : warning C4244: 'function' : conversion from 'git_time_t' to 'long', possible loss of data
pygit2.c(2794) : warning C4244: 'function' : conversion from 'const git_time_t' to 'long', possible loss of data
creating build\lib.win32-3.2
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:D:\CI\Tools\vcs\libgit2\lib /LIBPATH:C:\Pytho
n32\libs /LIBPATH:C:\Python32\PCbuild git2.lib /EXPORT:PyInit_pygit2 build\temp.win32-3.2\Release\pygit2.obj /OUT:build\lib.win32-3.2\pygit2.pyd /IMPL
IB:build\temp.win32-3.2\Release\pygit2.lib /MANIFESTFILE:build\temp.win32-3.2\Release\pygit2.pyd.manifest
   Creating library build\temp.win32-3.2\Release\pygit2.lib and object build\temp.win32-3.2\Release\pygit2.exp
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-3.2\Release\pygit2.pyd.manifest -outputresource:build\lib.
win32-3.2\pygit2.pyd;2
copying D:\CI\Tools\vcs\libgit2\bin\git2.dll -> pygit2
running install_lib
copying build\lib.win32-3.2\pygit2.pyd -> C:\Python32\Lib\site-packages
running install_egg_info
Writing C:\Python32\Lib\site-packages\pygit2-0.16.0-py3.2.egg-info

D:\CI\bld\vcs>

----------
assignee: tarek
components: Distutils
messages: 153486
nosy: eric.araujo, tarek, ??.?
priority: normal
severity: normal
status: open
title: distutils problem with setup.py build &setup.py install vs direct setup.py install
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 16 19:34:22 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 16 Feb 2012 18:34:22 +0000
Subject: [New-bugs-announce] [issue14034] the example in argparse doc is too
	complex
Message-ID: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>


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

The argparse example (http://docs.python.org/dev/library/argparse.html#example) introduces way too many concepts too early. It's written as if targeted to existing users of optparse, instead of newcomers to Python's CLI handling.

Perhaps the example could be more gentle, or if there is insistence on showing off, maybe the page could be kept as-is, but with a link to some tutorial (as is done with logging: http://docs.python.org/dev/library/logging.html).

----------
assignee: docs at python
components: Documentation
messages: 153491
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: the example in argparse doc is too complex
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb 16 22:36:07 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 16 Feb 2012 21:36:07 +0000
Subject: [New-bugs-announce] [issue14035] behavior of
	test.support.import_fresh_module
Message-ID: <1329428167.53.0.868098431264.issue14035@psf.upfronthosting.co.za>


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

While writing tests xml.etree, I hit a strange behaviour of import_fresh_module.

How to reproduce:

- dummy/__init__.py
- dummy/foo.py
- dummy/bar.py
- test_fresh_import.py


# 'dummy/foo.py'
from dummy.bar import func

# 'dummy/bar.py'
fortytwo = 42
def func():
    assert fortytwo == 42

# 'test_fresh_import.py'
(see attachment)


# Output:
~ $ ./python.exe test_fresh_import.py 
OK dummy.foo
OK dummy.bar
OK dummy.bar
OK dummy.foo
Traceback (most recent call last):
  File "test_fresh_import.py", line 24, in <module>
    test_fresh(m)
  File "test_fresh_import.py", line 5, in test_fresh
    rv = module.func()
  File "./dummy/bar.py", line 6, in func
    assert fortytwo == 42
AssertionError

----------
components: Tests
files: test_fresh_import.py
messages: 153503
nosy: eli.bendersky, flox, ncoghlan
priority: normal
severity: normal
status: open
title: behavior of test.support.import_fresh_module
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24534/test_fresh_import.py

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

From report at bugs.python.org  Fri Feb 17 00:40:39 2012
From: report at bugs.python.org (zulla)
Date: Thu, 16 Feb 2012 23:40:39 +0000
Subject: [New-bugs-announce] [issue14036] urlparse insufficient port
	property validation
Message-ID: <1329435639.39.0.341536822512.issue14036@psf.upfronthosting.co.za>


New submission from zulla <dan at defendassist.com>:

The "port" component of a URL is not properly be sanitized or validated. This may lead to the evasion of netloc/hostname based filters or exceptions.

----------
components: Library (Lib)
files: testurllib.py
messages: 153512
nosy: zulla
priority: normal
severity: normal
status: open
title: urlparse insufficient port property validation
type: security
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24535/testurllib.py

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

From report at bugs.python.org  Fri Feb 17 00:46:45 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 23:46:45 +0000
Subject: [New-bugs-announce] [issue14037] Allow grouping of argparse
	subparser commands in help	output
Message-ID: <1329436005.81.0.273577688528.issue14037@psf.upfronthosting.co.za>


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

I've just started using the argparse subparser feature, and it's very nice. However, I'd love to be able to group the different subparser commands into different sections the way I can group ordinary arguments with add_argument_group().

Initially I thought just calling "parser.add_subparsers()" multiple times with different "title" values would work, but argparse doesn't currently like that - it errors out with "cannot have multiple subparser arguments".

I propose that instead of treating this case as an error, argparse should treat it as a way for defining subparser groups - there would still only be a single subparser argument accepted, but the individual commands would appear grouped appropriately in the help output.

----------
components: Library (Lib)
messages: 153514
nosy: bethard, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow grouping of argparse subparser commands in help output
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 17 00:48:55 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 16 Feb 2012 23:48:55 +0000
Subject: [New-bugs-announce] [issue14038] Packaging test support code raises
	exception
Message-ID: <1329436135.78.0.959753149495.issue14038@psf.upfronthosting.co.za>


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

test_packaging has started failing in the pythonv branch:

======================================================================
ERROR: test_old_record_extensions (packaging.tests.test_command_install_dist.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.3/packaging/tests/test_command_install_dist.py", line 214, in test_old_record_extensions
    support.copy_xxmodule_c(project_dir)
  File "/usr/local/lib/python3.3/packaging/tests/support.py", line 334, in copy_xxmodule_c
    filename = _get_xxmodule_path()
  File "/usr/local/lib/python3.3/packaging/tests/support.py", line 346, in _get_xxmodule_path
    if os.path.exists(path):
UnboundLocalError: local variable 'path' referenced before assignment

======================================================================
ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.3/packaging/tests/test_command_build_ext.py", line 30, in test_build_ext
    support.copy_xxmodule_c(self.tmp_dir)
  File "/usr/local/lib/python3.3/packaging/tests/support.py", line 334, in copy_xxmodule_c
    filename = _get_xxmodule_path()
  File "/usr/local/lib/python3.3/packaging/tests/support.py", line 346, in _get_xxmodule_path
    if os.path.exists(path):
UnboundLocalError: local variable 'path' referenced before assignment

Upon investigation, the code for _get_xxmodule_path is this:

def _get_xxmodule_path():
    if sysconfig.is_python_build():
        srcdir = sysconfig.get_config_var('projectbase')
        path = os.path.join(os.getcwd(), srcdir, 'Modules', 'xxmodule.c')
    else:
        os.path.join(os.path.dirname(__file__), 'xxmodule.c')
    if os.path.exists(path):
        return path

It looks as if the else: path should have a "path = " ... with that change, the test_packaging failures go away.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 153515
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: Packaging test support code raises exception
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 17 00:51:44 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Feb 2012 23:51:44 +0000
Subject: [New-bugs-announce] [issue14039] Add "metavar" argument to
	add_subparsers() in argparse
Message-ID: <1329436304.54.0.709137632289.issue14039@psf.upfronthosting.co.za>


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

Currently, using add_subparsers() means that the entire list of subcommands is added to the main usage message. This gets rather unwieldy when there are a lot of subcommands.

It would be nice if the add_subparsers() method accepted a "metavar" argument that would be substituted into the usage string instead of using the subparser list directly.

----------
components: Library (Lib)
messages: 153516
nosy: bethard, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "metavar" argument to add_subparsers() in argparse
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 17 14:36:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 13:36:36 +0000
Subject: [New-bugs-announce] [issue14040] Deprecate some of the module file
	formats
Message-ID: <1329485796.8.0.890516593146.issue14040@psf.upfronthosting.co.za>


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

Stating module files of the form "xxxmodule.so" consumes all 1/3 of stat calls at startup. Looking at the site-packages folders on my machine, both for 2.7 and 3.2, reveals no C extension that follows such naming.

This patch deprecates such module namings, so that they can be removed in a later version.

----------
components: Interpreter Core, Library (Lib)
files: impsuffix.patch
keywords: patch
messages: 153544
nosy: barry, brett.cannon, dmalcolm, loewis, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate some of the module file formats
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24544/impsuffix.patch

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

From report at bugs.python.org  Fri Feb 17 16:31:24 2012
From: report at bugs.python.org (totycro)
Date: Fri, 17 Feb 2012 15:31:24 +0000
Subject: [New-bugs-announce] [issue14041] bsddb DB_RUNRECOVERY crash on
	write access
Message-ID: <1329492684.4.0.589795973037.issue14041@psf.upfronthosting.co.za>


New submission from totycro <malli at gmx.at>:

The attached file data.db should be a valid bsddb file, still i get this crash on write:

 File "/usr/lib64/python2.7/bsddb/__init__.py", line 280, in wrapF
    self.db[key] = value
 DBRunRecoveryError: (-30974, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument')

Full traceback: http://pastebin.com/A1VSPV9Q

I can reproduce the crash with python 2.7.2 with just these lines (it doesn't crash on empty db files):


import shelve
a = shelve.open("data.db")

b="crashin.."*20000

a['content/scenarios/tutorial_da.yaml'] = b
a['content/scenarios/tutorial_cs.yaml'] = b

----------
files: data.db
messages: 153551
nosy: totycro
priority: normal
severity: normal
status: open
title: bsddb DB_RUNRECOVERY crash on write access
versions: Python 2.7
Added file: http://bugs.python.org/file24545/data.db

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

From report at bugs.python.org  Fri Feb 17 17:07:50 2012
From: report at bugs.python.org (Tom Christie)
Date: Fri, 17 Feb 2012 16:07:50 +0000
Subject: [New-bugs-announce] [issue14042] json.dumps() documentation is
	slightly incorrect.
Message-ID: <1329494870.59.0.571991231564.issue14042@psf.upfronthosting.co.za>


New submission from Tom Christie <tom at tomchristie.com>:

json.dumps() documentation is slightly incorrect.

http://docs.python.org/library/json.html#json.dumps

Reads:

  "If ensure_ascii is False, then the return value will be a unicode instance."

Should read:

  "If ensure_ascii is False, then the return value MAY BE be a unicode instance."

(Without the caps of course)

bash: python
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> type(json.dumps({'a': 1}, ensure_ascii=False))
<type 'str'>

Tested against 2.6 and 2.7.

----------
components: Library (Lib)
messages: 153558
nosy: tomchristie
priority: normal
severity: normal
status: open
title: json.dumps() documentation is slightly incorrect.
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Feb 17 17:38:28 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Feb 2012 16:38:28 +0000
Subject: [New-bugs-announce] [issue14043] Speed-up importlib's _FileFinder
Message-ID: <1329496708.57.0.639882345046.issue14043@psf.upfronthosting.co.za>


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

This patch makes importlib's _FileFinder more than 10x faster by keeping a cache of directory entries. It's actually faster than imp.find_module()!

-> imp.find_module:

$ ./python -m timeit -s "import imp" "imp.find_module('logging', None)"
10000 loops, best of 3: 69.9 usec per loop
$ ./python -m timeit -s "import imp" "imp.find_module('bisect', None)"
10000 loops, best of 3: 108 usec per loop

-> unpatched importlib:

$ ./python -m timeit -s "from importlib._bootstrap import _DefaultPathFinder as Finder" "Finder.find_module('logging', None)"
1000 loops, best of 3: 431 usec per loop
$ ./python -m timeit -s "from importlib._bootstrap import _DefaultPathFinder as Finder" "Finder.find_module('bisect', None)"
1000 loops, best of 3: 468 usec per loop

-> patched importlib:

$ ./python -m timeit -s "from importlib._bootstrap import _DefaultPathFinder as Finder" "Finder.find_module('logging', None)"
10000 loops, best of 3: 37.5 usec per loop
$ ./python -m timeit -s "from importlib._bootstrap import _DefaultPathFinder as Finder" "Finder.find_module('bisect', None)"
10000 loops, best of 3: 36.9 usec per loop

----------
components: Interpreter Core, Library (Lib)
files: find_module_cache.patch
keywords: patch
messages: 153566
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Speed-up importlib's _FileFinder
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24547/find_module_cache.patch

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

From report at bugs.python.org  Fri Feb 17 18:36:17 2012
From: report at bugs.python.org (Alex Quinn)
Date: Fri, 17 Feb 2012 17:36:17 +0000
Subject: [New-bugs-announce] [issue14044] IncompleteRead error with urllib2
	or urllib.request --	fine with urllib, wget, or curl
Message-ID: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za>


New submission from Alex Quinn <aq2009 at alexquinn.org>:

When accessing this URL, both urllib2 (Py2) and urlib.client (Py3) raise an IncompleteRead error.
http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199

Previous discussions about similar errors suggest that this may be due to a problem with the server and chunked data transfer.  (See links below.)  I can't understand what that means.  However, this works fine with urllib (Py2), curl, wget, and all regular web browsers I've tried it with.  Thus, I would have expected urllib2 (Py2) and urllib.request (Py3) to cope with it similarly.

Versions I've tested with:
- Fails with urllib2 + Python 2.5.4, 2.6.1, 2.7.2  (Error messages vary.)
- Fails with urllib.request + Python 3.1.2, 3.2.2
- Succeeds with urllib + Python 2.5.4, 2.6.1, 2.7.2
- Succeeds with wget 1.11.1
- Succeeds with curl 7.15.5

___________________________________________________________
TEST CASES

# FAILS - Python 2.7, 2.6, 2.5
import urllib2
url = "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199"
xml_str = urllib2.urlopen(url).read() # Raises httplib.IncompleteRead

# FAILS - Python 3.2, 3.1
import urllib.request
url = "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199"
xml_str = urllib.request.urlopen(url).read() # Raises http.client.IncompleteRead

# SUCCEEDS - Python 2.7, 2.6, 2.5
import urllib
url = "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199"
xml_str = urllib.urlopen(url).read()
dom = xml.dom.minidom.parseString(xml_str) # Verify XML is complete
print("urllib:  %d bytes received and parsed successfully"%len(xml_str))

# SUCCEEDS - wget
wget -O- "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199" | wc

# SUCCEEDS - curl - prints an error, but returns the full data anyway
curl "http://info.kingcounty.gov/health/ehs/foodsafety/inspections/XmlRest.aspx?Zip_Code=98199" | wc

___________________________________________________________
RELATED DISCUSSIONS

http://www.gossamer-threads.com/lists/python/python/847985
http://bugs.python.org/issue11463  (closed)
http://bugs.python.org/issue6785   (closed)
http://bugs.python.org/issue6312   (closed)

----------
components: Library (Lib)
messages: 153581
nosy: Alex Quinn
priority: normal
severity: normal
status: open
title: IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Feb 18 04:13:38 2012
From: report at bugs.python.org (py.user)
Date: Sat, 18 Feb 2012 03:13:38 +0000
Subject: [New-bugs-announce] [issue14045] In regex pattern long unicode
	character isn't recognized	by repetition characters +, * and {}
Message-ID: <1329534818.23.0.573239991753.issue14045@psf.upfronthosting.co.za>


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

>>> import re
>>> '\U00000061'
'a'
>>> '\U00100061'
'\U00100061'
>>> re.search('\U00100061', '\U00100061' * 10).group()
'\U00100061'
>>> re.search('\U00100061+', '\U00100061' * 10).group()
'\U00100061'
>>> re.search('(\U00100061)+', '\U00100061' * 10).group()
'\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061\U00100061'
>>> 
>>>
>>> re.search('\U00100061{3}', '\U00100061' * 10)
>>> re.search('(\U00100061){3}', '\U00100061' * 10).group()
'\U00100061\U00100061\U00100061'
>>>

----------
components: Library (Lib), Regular Expressions
messages: 153629
nosy: ezio.melotti, py.user
priority: normal
severity: normal
status: open
title: In regex pattern long unicode character isn't recognized by repetition characters +, * and {}
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb 18 06:21:49 2012
From: report at bugs.python.org (Mansour)
Date: Sat, 18 Feb 2012 05:21:49 +0000
Subject: [New-bugs-announce] [issue14046] argparse: assertion failure if
	optional argument has	square/round brackets in metavar
Message-ID: <1329542509.5.0.84021889574.issue14046@psf.upfronthosting.co.za>


New submission from Mansour <mansour at oxplot.com>:

I have a web server written in python which takes an optional argument telling it what IP and port to bind to. Here's the definition:

parser.add_argument(
  '-b', '--bind',
  metavar="[ip]:port",
  type=unicode,
  help="IP and port to bind to."
)

There are several other arguments as well. When the usage is printed (due to parse failures or -h), if the command line is longer than terminal width, it is wrapped. Here is the (relevant) code in argparse.py:311 which deals with this scenario:

# wrap the usage parts if it's too long
text_width = self._width - self._current_indent 
if len(prefix) + len(usage) > text_width: 
 
  # break usage into wrappable parts 
  part_regexp = r'\(.*?\)+|\[.*?\]+|\S+' 
  opt_usage = format(optionals, groups) 
  pos_usage = format(positionals, groups) 
  opt_parts = _re.findall(part_regexp, opt_usage) 
  pos_parts = _re.findall(part_regexp, pos_usage) 
  assert ' '.join(opt_parts) == opt_usage
  assert ' '.join(pos_parts) == pos_usage

Note how part_regexp extracts words, and text surrounded with round/square brackets. Now the argument I defined above, when displayed in usage text, looks like this: [-b [ip]:port]

part_regexp however, will cut it into "[-b [ip]" and ":port]" and concatenated later with " ", it will have an extra space which causes the first assertion to fail.

I fiddled with part_regexp but that proved unreliable at best. I think the opt_parts should be obtained, not from the final formatted text, but from actual argument objects.

For a demonstration, see the attachment.

----------
components: Library (Lib)
files: argparse_wrap_test.py
messages: 153632
nosy: oxplot
priority: normal
severity: normal
status: open
title: argparse: assertion failure if optional argument has square/round brackets in metavar
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file24554/argparse_wrap_test.py

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

From report at bugs.python.org  Sat Feb 18 08:23:28 2012
From: report at bugs.python.org (Michal Sladek)
Date: Sat, 18 Feb 2012 07:23:28 +0000
Subject: [New-bugs-announce] [issue14047] UTF-8 Email Header
Message-ID: <1329549808.72.0.457462714436.issue14047@psf.upfronthosting.co.za>


New submission from Michal Sladek <michal at sladkovi.eu>:

Hello!

I am not a programmer so I appologize if I just don't understand the docs properly. I need to wirte a function which sends emails with utf-8 encoded subject and body. I tried something like this:

def sendMail (fromAddr, toAddr, subject, body = '', attachment = ''):
    message = email.mime.multipart.MIMEMultipart()
    message.add_header('From',fromAddr)
    message.add_header('To',toAddr)
    message['Subject'] = email.header.Header(subject,'utf-8')
    if (body != ''):
        msgPart = email.mime.text.MIMEText(body,'plain','utf-8')
        message.attach(msgPart)
    if (attachment != ''):
        if os.path.exists(attachment) == True:
            filename = attachment.rpartition(os.sep)[2]
            fp = open(attachment,'rb')
            msgPart = email.mime.base.MIMEBase('application','octet-stream')
            msgPart.set_payload(fp.read())
            fp.close()
            email.encoders.encode_base64(msgPart)
            msgPart.add_header('Content-Disposition','attachment',filename=filename)
            message.attach(msgPart)
    if smtpPort == 25:
        smtpCon = smtplib.SMTP(smtpSrv,smtpPort)
    else:
        smtpCon = smtplib.SMTP_SSL(smtpSrv,smtpPort)
    if (smtpUser != '') and (smtpPass != ''):
        smtpCon.login(smtpUser,smtpPass)
    smtpCon.send_message(message,mail_options=['UTF8SMTP','8BITMIME'])
    logger.info (_('Sent mail to: {0} with subject: {1}').format(toAddr,subject))
    smtpCon.quit()

I realized that adding email subject this way somehow brokes the message, so that the plain text body of the message is not visible on receiving side. I had to chnage the code like this:

    base64Subject = base64.b64encode(subject.encode('utf-8')).decode()
    encodedSubject = '=?UTF-8?B?{0}?='.format(base64Subject)
    message.add_header('Subject',encodedSubject)

Am I doing something wrong?

----------
messages: 153634
nosy: msladek
priority: normal
severity: normal
status: open
title: UTF-8 Email Header
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb 18 10:00:50 2012
From: report at bugs.python.org (Scott Bannert)
Date: Sat, 18 Feb 2012 09:00:50 +0000
Subject: [New-bugs-announce] [issue14048] calendar bug related to September
	2-14, 1752
Message-ID: <1329555650.42.0.80388367005.issue14048@psf.upfronthosting.co.za>


New submission from Scott Bannert <bannerts at gmail.com>:

Note: this is my first time to submit a bug or use this system

I might have found an issue with the calendar related to the point of time in history when the date was necessary to correct by 11 days.  Anyhow, the correction is made in a GNU+linux machine, so it seems like something worth fixing in python.  

How I discovered it:
I was reading through some posts on reddit when I came up on this one:
http://www.reddit.com/r/linux/comments/9jl2t/1_open_a_linux_terminal_2_enter_cal_9_1752_3_shit/
which seemed to state that in the September of 1752, they decided to skip from Wednesday the 2nd to Thursday the 14th.  Out of curiosity, I decided to see if Python had it recorded this way by typing in the following commands in python:

>>> import calendar
>>> calendar.TextCalendar().pryear(1752)

It was not corrected for the two versions of python I tried using (2.7 and 3.2).

----------
messages: 153635
nosy: bannerts
priority: normal
severity: normal
status: open
title: calendar bug related to September 2-14, 1752
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Feb 18 13:59:58 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 18 Feb 2012 12:59:58 +0000
Subject: [New-bugs-announce] [issue14049] execfile() fails on files that use
	global variables	inside functions
Message-ID: <1329569998.87.0.931536345344.issue14049@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

main.py below fails to execute local.py, which work ok (outputs '2') when processed directly in console.

Docs are not explaining anything. They spread fear and uncertainty around locals, but nothing is said why globals may fail.
http://docs.python.org/library/functions.html#execfile


---[cut main.py]---
values = {}
glavues = {}
execfile('local.py', glavues, values)
---[/cut]-----------

---[cut local.py]---
x = 1
def weird():
    y = x + 1
    return y
print weird()
---[/cut]-----------



Traceback (most recent call last):
  File "main.py", line 5, in <module>
    execfile('local.py', glavues, values)
  File "local.py", line 7, in <module>
    print weird()
  File "local.py", line 5, in weird
    y = x + 1
NameError: global name 'x' is not defined

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 153643
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: execfile() fails on files that use global variables inside functions
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 18 17:58:49 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 18 Feb 2012 16:58:49 +0000
Subject: [New-bugs-announce] [issue14050] Tutorial,
	list.sort() and items comparability
Message-ID: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>


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

I'm providing patches for what reported at http://mail.python.org/pipermail/docs/2012-February/007481.html . I'm not sure on wording or even if we want them in the tutorial section, but I think it would be nice to have it documented nonetheless.

----------
assignee: docs at python
components: Documentation
files: list_sort-py27.diff
keywords: patch
messages: 153648
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Tutorial, list.sort() and items comparability
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24557/list_sort-py27.diff

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

From report at bugs.python.org  Sat Feb 18 18:45:29 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 18 Feb 2012 17:45:29 +0000
Subject: [New-bugs-announce] [issue14051] Cannot set attributes on
	staticmethod
Message-ID: <1329587129.39.0.150393564133.issue14051@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

This is inconsistant with regular functions, which unfortunately prevents them from being used interchangeably.

----------
messages: 153649
nosy: alex
priority: normal
severity: normal
status: open
title: Cannot set attributes on staticmethod

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

From report at bugs.python.org  Sat Feb 18 21:38:47 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Feb 2012 20:38:47 +0000
Subject: [New-bugs-announce] [issue14052] importlib mixes up '.' and
	os.getcwd()
Message-ID: <1329597527.35.0.680600221226.issue14052@psf.upfronthosting.co.za>


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

An empty sys.path string means the current directory in relative terms:

$ touch foo.py
$ python3 -c "import foo; print(foo.__file__)"
foo.py


But importlib uses os.getcwd() instead in PathFinder._path_importer_cache(). This impacts semantics of path searching, as well as the values of __file__ and __cached__ attributes.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 153656
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: importlib mixes up '.' and os.getcwd()
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb 19 15:24:31 2012
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sun, 19 Feb 2012 14:24:31 +0000
Subject: [New-bugs-announce] [issue14053] Make Tools/scripts/patchcheck.py
	compatible with	mercurial mqueues.
Message-ID: <1329661471.35.0.733956428931.issue14053@psf.upfronthosting.co.za>


New submission from Francisco Mart?n Brugu? <francismb at email.de>:

The devguide (http://docs.python.org/devguide/patch.html) recommends the use of the mercurial ?mq? feature to work with patches and that works IMHO very well. It also states that before sending the patch a sanity check should be done ('devguide: Preparation and Generation'). At this stage, if one has the patch as tip (hg qapplied), the advice to run ?pathcheck? doesn't help as no changes are noticed.

The message is:
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will work.
-----------------------------------------------
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 0 files
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0 files
Docs modified ... NO
Misc/ACKS updated ... NO
Misc/NEWS updated ... NO
The tool should check if some mq patches are applied (from ?normal? tip to ?mqtip? and make it's checks there.

Thanks in advance !

Francis

----------
components: Demos and Tools, Devguide
messages: 153703
nosy: ezio.melotti, francismb
priority: normal
severity: normal
status: open
title: Make Tools/scripts/patchcheck.py compatible with mercurial mqueues.

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

From report at bugs.python.org  Sun Feb 19 18:10:41 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Feb 2012 17:10:41 +0000
Subject: [New-bugs-announce] [issue14054] test_importlib failures under
	Windows
Message-ID: <1329671441.02.0.700049402355.issue14054@psf.upfronthosting.co.za>


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

======================================================================
FAIL: test_case_sensitive (importlib.test.extension.test_case_sensitivity.ExtensionModuleCaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\importlib\test\extension\test_case_sensitivity.py", line 27, in test_case_sensitive
    self.assertIsNone(loader)
AssertionError: <importlib._bootstrap._ExtensionFileLoader object at 0x07C0C850> is not None

======================================================================
FAIL: test_sensitive (importlib.test.source.test_case_sensitivity.CaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\importlib\test\source\test_case_sensitivity.py", line 46, in test_sensitive
    self.assertIsNone(insensitive)
AssertionError: <importlib._bootstrap._SourceFileLoader object at 0x1259FDC8> is not None

----------
assignee: brett.cannon
components: Library (Lib), Tests
messages: 153711
nosy: brett.cannon, pitrou
priority: high
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/issue14054>
_______________________________________

From report at bugs.python.org  Sun Feb 19 21:28:46 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 19 Feb 2012 20:28:46 +0000
Subject: [New-bugs-announce] [issue14055] Implement __sizeof__ for etree
	Element
Message-ID: <1329683326.4.0.779702582093.issue14055@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The cElementTree Element currently returns an incorrect response to sys.getsizeof, as it doesn't account for the extra structure, and for the child pointers array. This patch corrects the computation.

----------
files: sizeof.diff
keywords: patch
messages: 153726
nosy: loewis
priority: normal
severity: normal
status: open
title: Implement __sizeof__ for etree Element
Added file: http://bugs.python.org/file24570/sizeof.diff

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

From report at bugs.python.org  Mon Feb 20 00:32:55 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Feb 2012 23:32:55 +0000
Subject: [New-bugs-announce] [issue14056] Misc doc changes for tarfile
Message-ID: <1329694375.61.0.870450235951.issue14056@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

A few things to improve in tarfile?s doc:

a) I found the heading ?The following variables are available on module level? strange; does ?variable? mean that users are able to edit tarfile.ENCODING to control the default encoding used?  The answer is no, as ENCODING is bound to a function default argument value and a class attribute at import time.  I suggest changing this heading for something like ?Module-level constants?, and move it before the doc for the *_FORMATS constants (the attached diff makes it look like I moved these constants, but I actually moved ENCODING?same result).

b) The doc does not say that the availability of compression formats depends on the optional compilation of some modules.  Someone following the link to the module docs for gzip, bz2 or lzma can find the info, but I think a bit more explicitness wouldn?t hurt.  The attached patch for 3.2 tries to inline the info, but is a bit clumsy; alternatively, a table like this could be added near the top:

   Support depends on the availability of certain optional modules:

   ========= =========================================== =============
   Format    Description                                 Requires
   ========= =========================================== =============
   ``xz``    xz'ed tar file (:file:`.tar.xz`)            :mod:`lzma`
   ``bz2``   bzip2'ed tar file (:file:`.tar.bz2`)        :mod:`bz2`
   ``gz``    gzip'ed tar file (:file:`.tar.gz`)          :mod:`gzip`
   ========= =========================================== =============

c) The seealso section links to zipfile, just like the into text, but not to shutil.

Please let me know what suggestions you approve or reject and I?ll commit them.

----------
assignee: eric.araujo
components: Documentation
files: misc-tarfile-doc-changes-3.2.diff
keywords: patch
messages: 153733
nosy: eric.araujo, lars.gustaebel
priority: normal
severity: normal
stage: commit review
status: open
title: Misc doc changes for tarfile
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24571/misc-tarfile-doc-changes-3.2.diff

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

From report at bugs.python.org  Mon Feb 20 00:47:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Feb 2012 23:47:15 +0000
Subject: [New-bugs-announce] [issue14057] Speedup sysconfig startup
Message-ID: <1329695235.07.0.0035365594313.issue14057@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

On my laptop, start Python compiled in debug mode takes 600 ms. Half of this time is spend in the site module. And most of this time is spend in load the sysconfig module, which parse sysconfig.cfg, just to get the user site packages directory.

Attached patch adds a copy of configparser.RawConfigParser, specialized to parse sysconfig.cfg. Using this patch, Python startup is 25% faster (I didn't check in release mode).

----------
files: sysconfig_parser.patch
keywords: patch
messages: 153735
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Speedup sysconfig startup
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24572/sysconfig_parser.patch

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

From report at bugs.python.org  Mon Feb 20 01:45:47 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Feb 2012 00:45:47 +0000
Subject: [New-bugs-announce] [issue14058] test_sys has started failing
Message-ID: <1329698747.36.0.192554030731.issue14058@psf.upfronthosting.co.za>


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

vinay at eta-natty:~/tools/cpython$ ./python Lib/test/regrtest.py test_sys
[1/1] test_sys
test test_sys failed -- Traceback (most recent call last):
  File "/home/vinay/tools/cpython/Lib/test/test_sys.py", line 737, in test_objecttypes
    class c():
  File "/home/vinay/tools/cpython/Lib/test/test_sys.py", line 745, in c
    check(foo, size(h + 'P'))
  File "/home/vinay/tools/cpython/Lib/test/test_sys.py", line 616, in check_sizeof
    self.assertEqual(result, size, msg)
AssertionError: 28 != 24 : wrong size for <class 'staticmethod'>: got 28, expected 24

1 test failed:
    test_sys

Failure on Ubuntu Natty (32-bit) and also occurs on Mac OS X 10.5.8.

----------
components: Library (Lib)
messages: 153741
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: test_sys has started failing
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 20 01:52:18 2012
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 20 Feb 2012 00:52:18 +0000
Subject: [New-bugs-announce] [issue14059] Implement multiprocessing.Barrier
Message-ID: <1329699138.74.0.937439869593.issue14059@psf.upfronthosting.co.za>


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

There is no Barrier in multiprocessing corresponding to threading.Barrier.

----------
components: Library (Lib)
messages: 153744
nosy: anacrolix
priority: normal
severity: normal
status: open
title: Implement multiprocessing.Barrier
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 20 01:56:06 2012
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 20 Feb 2012 00:56:06 +0000
Subject: [New-bugs-announce] [issue14060] Implement a CSP-style channel
Message-ID: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za>


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

>From the mailing list, there is some interest in a CSP-style channel. http://mail.python.org/pipermail/python-ideas/2012-February/014073.html

----------
components: Library (Lib)
messages: 153748
nosy: anacrolix
priority: normal
severity: normal
status: open
title: Implement a CSP-style channel
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 20 03:31:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Feb 2012 02:31:07 +0000
Subject: [New-bugs-announce] [issue14061] Clean up archiving code in shutil
Message-ID: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

shutil.make_archive suffers from these issues:

- It always supports the 'zip' and 'gztar' formats but if Python is built without zlib then they won?t work.  Even if this is probably rare, the code should be robust.  Likewise, the tests detect the availability of bz2 but not zlib/gzip.

- If zipfile is not found, it tries to call a zip program.  I think this approach (inherited from distutils, which did that before zipfile and tarfile were in the stdlib) should be dropped.  I don?t like shutil using distutils.spawn, I don?t like a Python module calling an external program, and I think nearly everyone has a Python compiled with zlib now.

I want to work on a patch to fix this.  The first point would not change the behavior for most users, it would only modify the list of formats ?guaranteed? by the docs, so I think it?s okay for stable branches; the second point is probably inappropriate for stable branches.

----------
components: Library (Lib)
messages: 153760
nosy: eric.araujo, georg.brandl, nadeem.vawda, tarek
priority: normal
severity: normal
status: open
title: Clean up archiving code in shutil
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb 20 09:03:29 2012
From: report at bugs.python.org (Michal Sladek)
Date: Mon, 20 Feb 2012 08:03:29 +0000
Subject: [New-bugs-announce] [issue14062] UTF-8 Email Subject problem
Message-ID: <1329725009.21.0.0898146100656.issue14062@psf.upfronthosting.co.za>


New submission from Michal Sladek <michal at sladkovi.eu>:

Hello!

I think there is a problem when adding UTF-8 subject to email message. I wrote following function (its code is based on examples I found in offical docs) which should send an email with UTF-8 subject, UTF-8 plain text body and attached file when all arguments are given. 
fromAddr - address of sender
toAddr - address of recipient
subject - subject
body - text of email body
attachment - full path to file we want to attach

Here is the code:

def sendMail (fromAddr, toAddr, subject, body = '', attachment = ''):
    message = email.mime.multipart.MIMEMultipart()
    message.add_header('From',fromAddr)
    message.add_header('To',toAddr)

    message['Subject'] = email.header.Header(subject,'utf-8')

    if (body != ''):
        msgPart = email.mime.text.MIMEText(body,'plain','utf-8')
        message.attach(msgPart)
    if (attachment != ''):
        if os.path.exists(attachment) == True:
            filename = attachment.rpartition(os.sep)[2]
            fp = open(attachment,'rb')
            msgPart = email.mime.base.MIMEBase('application','octet-stream')
            msgPart.set_payload(fp.read())
            fp.close()
            email.encoders.encode_base64(msgPart)
            msgPart.add_header('Content-Disposition','attachment',filename=filename)
            message.attach(msgPart)
    if smtpPort == 25:
        smtpCon = smtplib.SMTP(smtpSrv,smtpPort)
    else:
        smtpCon = smtplib.SMTP_SSL(smtpSrv,smtpPort)
    if (smtpUser != '') and (smtpPass != ''):
        smtpCon.login(smtpUser,smtpPass)
    smtpCon.send_message(message,mail_options=['UTF8SMTP','8BITMIME'])
    smtpCon.quit()

Running the function with following arguments:

sendMail('rzrobot at seznam.cz','msladek at volny.cz','?lu?ou?k? k??','?p?l ??belsk? ?dy')

produces following output on receiving side:

Return-Path: <rzrobot at seznam.cz>
Received: from smtp2.seznam.cz (smtp2.seznam.cz [77.75.76.43])
	by mx1.volny.cz (Postfix) with ESMTP id DD6BB2E09CD
	for <msladek at volny.cz>; Mon, 20 Feb 2012 08:34:38 +0100 (CET)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=seznam.cz;
	h=Received:Content-Type:MIME-Version:From:To:Subject:--===============1029508565==:MIME-Version:Content-Transfer-Encoding:X-Smtpd:X-Seznam-User:X-Session:X-Country:X-Virus-Info:X-Seznam-SPF:X-Seznam-DomainKeys;
	b=cdU1VSRTCDf0x2CeBNbLJxYSOhSy7r9lNp+1s7+bed6AGBI48vufe3q7f8JFxlfTc
	ulZIDptWi6PMvlZYCBkh1uzTKcihZR7MCoxgW0PJLO1LX5elTJsZ/GTc5oe/GZXkTPT
	qwj1EQIlVn0dpZtt4jIzfC2RrO2IRieR2rozeQM=
Received: from dvr.ph.sladkovi.eu (ip-84-42-150-218.net.upcbroadband.cz [84.42.150.218])	by email-relay2.ng.seznam.cz (Seznam SMTPD 1.2.15-6 at 18976) with ESMTP;	Mon, 20 Feb 2012 08:34:35 +0100 (CET)  
Content-Type: multipart/mixed; boundary="===============1029508565=="
MIME-Version: 1.0
From: rzrobot at seznam.cz
To: msladek at volny.cz
Subject: =?utf-8?b?xb5sdcWlb3XEjWvDvSBrxa/FiA==?= 
X-DKIM-Status: fail
X-Virus: no (m2.volny.internal - Mon, 20 Feb 2012 08:34:40 +0100 (CET))
X-Spam: no (m2.volny.internal - Mon, 20 Feb 2012 08:34:41 +0100 (CET))
X-Received-Date: Mon, 20 Feb 2012 08:34:42 +0100 (CET)

--===============1029508565==:Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
X-Smtpd: 1.2.15-6 at 18976
X-Seznam-User: rzrobot at seznam.cz
X-Session: 11
X-Country: CZ
X-Virus-Info:clean
X-Seznam-SPF:neutral
X-Seznam-DomainKeys:unknown

w7pwxJtsIMSPw6FiZWxza8OpIMOzZHk=

--===============1029508565==--

Although no attachment argument was given, the client says that message has an attachment of unknown type and that message does not contain any text at all. See that message part header :Content-Type: text/plain; charset="utf-8" is part of the message part boundary instead of beeing inside of the message part.

When I change the code of function to generate the subject manually and add it via add_header like this:

def sendMail (fromAddr, toAddr, subject, body = '', attachment = ''):
    message = email.mime.multipart.MIMEMultipart()
    message.add_header('From',fromAddr)
    message.add_header('To',toAddr)

    base64Subject = base64.b64encode(subject.encode('utf-8')).decode()
    encodedSubject = '=?UTF-8?B?{0}?='.format(base64Subject)
    message.add_header('Subject',encodedSubject)

    if (body != ''):
        msgPart = email.mime.text.MIMEText(body,'plain','utf-8')
        message.attach(msgPart)
    if (attachment != ''):
        if os.path.exists(attachment) == True:
            filename = attachment.rpartition(os.sep)[2]
            fp = open(attachment,'rb')
            msgPart = email.mime.base.MIMEBase('application','octet-stream')
            msgPart.set_payload(fp.read())
            fp.close()
            email.encoders.encode_base64(msgPart)
            msgPart.add_header('Content-Disposition','attachment',filename=filename)
            message.attach(msgPart)
    if smtpPort == 25:
        smtpCon = smtplib.SMTP(smtpSrv,smtpPort)
    else:
        smtpCon = smtplib.SMTP_SSL(smtpSrv,smtpPort)
    if (smtpUser != '') and (smtpPass != ''):
        smtpCon.login(smtpUser,smtpPass)
    smtpCon.send_message(message,mail_options=['UTF8SMTP','8BITMIME'])
    smtpCon.quit()

Then everything is OK on receiving side, both subject and plaint text body are visible:

Return-Path: <rzrobot at seznam.cz>
Received: from smtp2.seznam.cz (smtp2.seznam.cz [77.75.76.43])
	by mx1.volny.cz (Postfix) with ESMTP id 177092E0825
	for <msladek at volny.cz>; Mon, 20 Feb 2012 08:51:58 +0100 (CET)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=seznam.cz;
	h=Received:Content-Type:MIME-Version:From:To:Subject:X-Smtpd:X-Seznam-User:X-Session:X-Country:X-Virus-Info:X-Seznam-SPF:X-Seznam-DomainKeys;
	b=F2A6GhX0TWVjnrB4vx/ayc1BTGDFxBI96oI0fk/gr/tgP0jlV1UC91m4i/O4ay+Bg
	lfka88qa71XZOlHtY2vl7zxYjGPJ97pRCdtqWB+JcNOa5bMsk6lmjMHh+A+FQ2e7+yb
	1F091t0nMcQlarriF8sD5rNjhuRYjvCv7kKbt8s=
Received: from dvr.ph.sladkovi.eu (ip-84-42-150-218.net.upcbroadband.cz [84.42.150.218])	by email-relay1.ng.seznam.cz (Seznam SMTPD 1.2.15-6 at 18976) with ESMTP;	Mon, 20 Feb 2012 08:51:55 +0100 (CET)  
Content-Type: multipart/mixed; boundary="===============1044203895=="
MIME-Version: 1.0
From: rzrobot at seznam.cz
To: msladek at volny.cz
Subject: =?UTF-8?B?xb5sdcWlb3XEjWvDvSBrxa/FiA==?=
X-Smtpd: 1.2.15-6 at 18976
X-Seznam-User: rzrobot at seznam.cz
X-Session: 11
X-Country: CZ
X-Virus-Info: clean
X-Seznam-SPF: neutral
X-Seznam-DomainKeys: unknown
X-DKIM-Status: pass seznam.cz
X-Virus: no (m2.volny.internal - Mon, 20 Feb 2012 08:52:00 +0100 (CET))
X-Spam: no (m2.volny.internal - Mon, 20 Feb 2012 08:52:01 +0100 (CET))
X-Received-Date: Mon, 20 Feb 2012 08:52:01 +0100 (CET)

--===============1044203895==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

w7pwxJtsIMSPw6FiZWxza8OpIMOzZHk=

--===============1044203895==--

I am not a programmer so I might overlook some obvious mistake in my code but for now I think it's a bug.

----------
components: None
messages: 153766
nosy: msladek
priority: normal
severity: normal
status: open
title: UTF-8 Email Subject problem
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb 20 12:06:06 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Feb 2012 11:06:06 +0000
Subject: [New-bugs-announce] [issue14063] test_importlib failure on Mac OS X
Message-ID: <1329735966.21.0.756949345027.issue14063@psf.upfronthosting.co.za>


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

======================================================================
FAIL: test_insensitive (importlib.test.source.test_case_sensitivity.CaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/importlib/test/source/test_case_sensitivity.py", line 56, in test_insensitive
    self.assertIn(self.name, sensitive.get_filename(self.name))
AssertionError: 'MoDuLe' not found in '/var/folders/ZN/ZNY48Gb3FyW7he0qBsYJME+++TI/-Tmp-/tmpx6934s/sensitive/module.py'

Failure occurs when tested using a framework build (make frameworkinstall) on Mac OS X 10.5.8 (Leopard).

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 153776
nosy: brett.cannon, ronaldoussoren, vinay.sajip
priority: normal
severity: normal
status: open
title: test_importlib failure on Mac OS X
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 20 13:56:39 2012
From: report at bugs.python.org (Bithin A)
Date: Mon, 20 Feb 2012 12:56:39 +0000
Subject: [New-bugs-announce] [issue14064] collections module imported twice
	in urllib/parse.py
Message-ID: <1329742599.87.0.0630282328331.issue14064@psf.upfronthosting.co.za>


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

In urllib/parse.py the collections module is imported twice which is against the PEP8-- Style Guide for Python Code.

----------
components: Library (Lib)
files: multiple_imports.patch
keywords: patch
messages: 153780
nosy: Bithin.A
priority: normal
severity: normal
status: open
title: collections module imported twice in urllib/parse.py
Added file: http://bugs.python.org/file24577/multiple_imports.patch

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

From report at bugs.python.org  Mon Feb 20 17:26:48 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 20 Feb 2012 16:26:48 +0000
Subject: [New-bugs-announce] [issue14065] Element should support cyclic GC
Message-ID: <1329755208.03.0.143933032526.issue14065@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The C implementation of xml.etree.ElementTree.Element needs to support cyclic GC. The attached script demonstrates the lack to support that: in 3.2, the script passes; in 3.3 (7697223df6df) it fails with an AssertionError as the cycle was not cleared. 

This is an incompatible change from 3.2.

----------
files: a.py
messages: 153784
nosy: loewis
priority: normal
severity: normal
status: open
title: Element should support cyclic GC
versions: Python 3.3
Added file: http://bugs.python.org/file24578/a.py

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

From report at bugs.python.org  Mon Feb 20 20:01:41 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 20 Feb 2012 19:01:41 +0000
Subject: [New-bugs-announce] [issue14066] Crash in imputil.imp.find_module
	when a *directory*	exists with the given name due to
	double-close of FILE*
Message-ID: <1329764501.42.0.487589660736.issue14066@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

$ mkdir some_directory_ending_with_a.py
$ python -c "import imputil; imputil.imp.find_module('some_directory_ending_with_a')"
*** glibc detected *** python: double free or corruption (!prev): 0x0000000001589bf0 ***
Aborted

What's happening is that call_find_module opens fp, and tries to create a PyFileObject from it:

  2844     if (fp != NULL) {
>>2845         fob = PyFile_FromFile(fp, pathname, fdp->mode, fclose);
  2846         if (fob == NULL) {
  2847             fclose(fp);
  2848             return NULL;
  2849         }
  2850     }

The call fails at the very end of fill_file_fields() inside the call to dircheck() here:
   180      f->f_fp = fp;
   181      f = dircheck(f);
   182      return (PyObject *) f;
   183  }
   184  

but f->fp == fp

Hence when fill_file_fields returns NULL, and f is cleaned up here:
   484      if (fill_file_fields(f, fp, o_name, mode, close) == NULL) {
>> 485          Py_DECREF(f);
   486          Py_DECREF(o_name);
   487          return NULL;
   488      }

then f->fp is closed within file_dealloc()

Then, when PyFile_FromFile returns NULL, call_find_module calls fclose(fp):
  2844     if (fp != NULL) {
  2845         fob = PyFile_FromFile(fp, pathname, fdp->mode, fclose);
  2846         if (fob == NULL) {
>>2847             fclose(fp);
  2848             return NULL;
  2849         }
  2850     }

and it attempts to close fp for the second time.

The documentation for PyFile_FromFile:
  http://docs.python.org/c-api/file.html#PyFile_FromFile
says:
"Return NULL and close the file using close on failure".

It therefore looks like call_find_module's fclose(fp) is incorrect here, and is what leads to the double-free.

----------
components: Library (Lib)
messages: 153799
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: Crash in imputil.imp.find_module when a *directory* exists with the given name due to double-close of FILE*
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 20 22:18:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Feb 2012 21:18:07 +0000
Subject: [New-bugs-announce] [issue14067] Avoid more stat() calls in
	importlib
Message-ID: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>


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

This is an experimental patch that limits the frequency of stat() calls in _FileFinder.find_module(). It speeds up finding modules by 2x here, but unfortunately breaks some tests (which expect modules to appear immediately when created).

----------
components: Library (Lib)
files: imptime.patch
keywords: patch
messages: 153809
nosy: brett.cannon, ncoghlan, pitrou
priority: low
severity: normal
status: open
title: Avoid more stat() calls in importlib
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file24583/imptime.patch

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

From report at bugs.python.org  Tue Feb 21 03:52:04 2012
From: report at bugs.python.org (=?utf-8?b?5ZCv5pyXIOadqA==?=)
Date: Tue, 21 Feb 2012 02:52:04 +0000
Subject: [New-bugs-announce] [issue14068] problem with re
Message-ID: <1329792724.0.0.725083325394.issue14068@psf.upfronthosting.co.za>


Changes by ?? ? <yangqilang at gmail.com>:


----------
nosy: ??.?
priority: normal
severity: normal
status: open
title: problem with re

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

From report at bugs.python.org  Tue Feb 21 03:55:59 2012
From: report at bugs.python.org (py.user)
Date: Tue, 21 Feb 2012 02:55:59 +0000
Subject: [New-bugs-announce] [issue14069] In extensions (?...) the
	lookbehind assertion cannot	choose between the beginning of
	string and a letter
Message-ID: <1329792959.02.0.649716496368.issue14069@psf.upfronthosting.co.za>


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

>>> import re
>>> re.search(r'(?<=(a|b))(\w+)', 'abc').groups()
('a', 'bc')
>>> re.search(r'(?<=(^))(\w+)', 'abc').groups()
('', 'abc')
>>> re.search(r'(?<=(^|$))(\w+)', 'abc').groups()
('', 'abc')
>>> re.search(r'(?<=($|^))(\w+)', 'abc').groups()
('', 'abc')
>>> re.search(r'(?<=(^|a))(\w+)', 'abc').groups()
Traceback (most recent call last):
  File "/usr/local/lib/python3.2/functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (<class 'str'>, '(?<=(^|a))(\\w+)', 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 495, in compile
    code = _code(p, flags)
  File "/usr/local/lib/python3.2/sre_compile.py", line 480, in _code
    _compile(code, p.data, flags)
  File "/usr/local/lib/python3.2/sre_compile.py", line 115, in _compile
    raise error("look-behind requires fixed-width pattern")
sre_constants.error: look-behind requires fixed-width pattern
>>>

----------
components: Library (Lib), Regular Expressions
messages: 153836
nosy: ezio.melotti, py.user
priority: normal
severity: normal
status: open
title: In extensions (?...) the lookbehind assertion cannot choose between the beginning of string and a letter
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb 21 04:00:21 2012
From: report at bugs.python.org (Tim McNamara)
Date: Tue, 21 Feb 2012 03:00:21 +0000
Subject: [New-bugs-announce] [issue14070] reload(module,
	ignore_pyc=True) flag
Message-ID: <1329793221.07.0.0985593378146.issue14070@psf.upfronthosting.co.za>


New submission from Tim McNamara <paperless at timmcnamara.co.nz>:

When developing Python code, I often find myself needing to run "rm *.pyc" so that the interpreter will ignore any new changes that I have made to source files. It's really frustrating when forgotten.

Adding a flag to the reload builtin would go a long way to simplify this process.

----------
components: IO
messages: 153839
nosy: timClicks
priority: normal
severity: normal
status: open
title: reload(module, ignore_pyc=True) flag

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

From report at bugs.python.org  Tue Feb 21 07:54:47 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 21 Feb 2012 06:54:47 +0000
Subject: [New-bugs-announce] [issue14071] allow more than one hash seed per
	process (move	_Py_HashSecret into PyInterpreterState)
Message-ID: <1329807287.0.0.916593271901.issue14071@psf.upfronthosting.co.za>


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

The newly added hash randomization seed (issue 13703) is a global defined in object/object.c that is initialized only once within a process by a call from Py_InitializeEx().

For applications embedding Python interpreters it may be useful for them to NOT share a hash randomization seed across all interpreter instances within that process.  That way long living processes or processes serving many independent tasks can avoid using the same hash seed for separate tasks.

----------
components: Interpreter Core
messages: 153855
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: allow more than one hash seed per process (move _Py_HashSecret into PyInterpreterState)
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 21 10:43:52 2012
From: report at bugs.python.org (Ivan Herman)
Date: Tue, 21 Feb 2012 09:43:52 +0000
Subject: [New-bugs-announce] [issue14072] urlparse on tel: URI-s misses the
	scheme in some cases
Message-ID: <1329817432.49.0.397391260888.issue14072@psf.upfronthosting.co.za>


Changes by Ivan Herman <ivan.herman at cwi.nl>:


----------
components: None
nosy: ivan_herman
priority: normal
severity: normal
status: open
title: urlparse on tel: URI-s misses the scheme in some cases
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 21 15:12:08 2012
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 21 Feb 2012 14:12:08 +0000
Subject: [New-bugs-announce] [issue14073] allow per-thread atexit()
Message-ID: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

If you try to run the code below and stop it with ctrl+C, it will lock because atexit is never reached.

Antoine proposed to add a way to have one atexit() per thread, so we can call some cleanup code when the app shuts down and there are running threads.


{{{
from wsgiref.simple_server import make_server
import threading
import time
import atexit


class Work(threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)
        self.running = False

    def run(self):
        self.running = True
        while self.running:
            time.sleep(.2)

    def stop(self):
        self.running = False
        self.join()

worker = Work()


def shutdown():
    # bye-bye
    print 'bye bye'
    worker.stop()


atexit.register(shutdown)


def hello_world_app(environ, start_response):
    status = '200 OK' # HTTP Status
    headers = [('Content-type', 'text/plain')]
    start_response(status, headers)
    return ["Hello World"]

def main():
    worker.start()
    return make_server('', 8000, hello_world_app)

if __name__ == '__main__':
    server = main()
    server.serve_forever()
}}}

----------
messages: 153871
nosy: tarek
priority: normal
severity: normal
status: open
title: allow per-thread atexit()
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb 21 18:38:38 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 21 Feb 2012 17:38:38 +0000
Subject: [New-bugs-announce] [issue14074] argparse does not allow nargs>1
	for positional arguments	but doesn't allow metavar to be a tuple
Message-ID: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>


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

Here's four commands to demonstrate my problem:

My sample code:
$ cat prog.py 
import argparse
parse = argparse.ArgumentParser()
parse.add_argument("foo", nargs=2, metavar=("foo", "bar"))
args = parse.parse_args()
print(args)

This output could be friendlier:
$ python3 prog.py --help
Traceback (most recent call last):
  File "prog.py", line 4, in <module>
    args = parse.parse_args()
  File "/home/wena/cpython/Lib/argparse.py", line 1722, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/home/wena/cpython/Lib/argparse.py", line 1754, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/home/wena/cpython/Lib/argparse.py", line 1960, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/home/wena/cpython/Lib/argparse.py", line 1900, in consume_optional
    take_action(action, args, option_string)
  File "/home/wena/cpython/Lib/argparse.py", line 1828, in take_action
    action(self, namespace, argument_values, option_string)
  File "/home/wena/cpython/Lib/argparse.py", line 1015, in __call__
    parser.print_help()
  File "/home/wena/cpython/Lib/argparse.py", line 2347, in print_help
    self._print_message(self.format_help(), file)
  File "/home/wena/cpython/Lib/argparse.py", line 2314, in format_help
    formatter.add_arguments(action_group._group_actions)
  File "/home/wena/cpython/Lib/argparse.py", line 270, in add_arguments
    self.add_argument(action)
  File "/home/wena/cpython/Lib/argparse.py", line 255, in add_argument
    invocations = [get_invocation(action)]
  File "/home/wena/cpython/Lib/argparse.py", line 533, in _format_action_invocation
    metavar, = self._metavar_formatter(action, default)(1)
ValueError: too many values to unpack (expected 1)

On Python 3.2 (from Debian), I get "error: too few arguments". But with latest mercurial I get:
$ python3 prog.py
Traceback (most recent call last):
  File "prog.py", line 4, in <module>
    args = parse.parse_args()
  File "/home/wena/cpython/Lib/argparse.py", line 1722, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/home/wena/cpython/Lib/argparse.py", line 1754, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/home/wena/cpython/Lib/argparse.py", line 1973, in _parse_known_args
    ', '.join(required_actions))
TypeError: sequence item 0: expected str instance, tuple found

But this looks okay:
$ python3 prog.py a b
Namespace(foo=['a', 'b'])

----------
components: Library (Lib)
messages: 153884
nosy: tshepang
priority: normal
severity: normal
status: open
title: argparse does not allow nargs>1 for positional arguments but doesn't allow metavar to be a tuple
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 21 19:16:39 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 21 Feb 2012 18:16:39 +0000
Subject: [New-bugs-announce] [issue14075] argparse: unused method?
Message-ID: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>


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

It appears to me that the function I removed (see attached patch) is unused. Since I wasn't sure, I ran the entire test suite, and there wasn't a regression.

----------
components: Library (Lib)
files: rm-unused-function.patch
keywords: patch
messages: 153889
nosy: tshepang
priority: normal
severity: normal
status: open
title: argparse: unused method?
versions: Python 3.3
Added file: http://bugs.python.org/file24591/rm-unused-function.patch

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

From report at bugs.python.org  Tue Feb 21 20:39:32 2012
From: report at bugs.python.org (GuGu)
Date: Tue, 21 Feb 2012 19:39:32 +0000
Subject: [New-bugs-announce] [issue14076] sqlite3 module ignores placeholers
	in CREATE TRIGGER code
Message-ID: <1329853172.58.0.728674289337.issue14076@psf.upfronthosting.co.za>


New submission from GuGu <andrey at kostenko.name>:

When I try to use placeholders in CREATE TRIGGER (for django-denorm module) SQLite module just ignores placeholders and sends `None` to it.

For example:

  In [11]: c.cursor().execute('CREATE TRIGGER test1 after insert on a for each row begin UPDATE a SET b=?; END', '1').fetchone()

  In [12]: c.cursor().execute('INSERT INTO a values (100)')
  Out[12]: <pysqlite2.dbapi2.Cursor at 0x101d77e30>

  In [13]: c.cursor().execute('SELECT * FROM a').fetchall()
  Out[13]: [(None,), (None,), (None,)]

  In [14]: c.cursor().execute('DROP TRIGGER test1')
  Out[14]: <pysqlite2.dbapi2.Cursor at 0x101d77f10>

  In [15]: c.cursor().execute('CREATE TRIGGER test1 after insert on a for each row begin UPDATE a SET b=1; END').fetchone()

  In [16]: c.cursor().execute('INSERT INTO a values (100)')
  Out[16]: <pysqlite2.dbapi2.Cursor at 0x101d77f80>

  In [17]: c.cursor().execute('SELECT * FROM a').fetchall()
  Out[17]: [(u'1',), (u'1',), (u'1',), (u'1',)]

In MySQLdb and psycopg2 creating triggers with a placeholder works.

----------
components: Library (Lib)
messages: 153896
nosy: GuGu
priority: normal
severity: normal
status: open
title: sqlite3 module ignores placeholers in CREATE TRIGGER code
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 21 21:32:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Feb 2012 20:32:15 +0000
Subject: [New-bugs-announce] [issue14077] sporadic test_multiprocessing
	failure
Message-ID: <1329856335.15.0.565948372805.issue14077@psf.upfronthosting.co.za>


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

Just saw this on a buildbot:

======================================================================
ERROR: test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_multiprocessing.py", line 1513, in test_rapid_restart
    queue = manager.get_queue()
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/multiprocessing/managers.py", line 666, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/multiprocessing/managers.py", line 564, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/multiprocessing/connection.py", line 773, in XmlClient
    import xmlrpc.client as xmlrpclib
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 542, in load_module
    return self._load_module(fullname)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 220, in module_for_loader_wrapper
    return fxn(self, module, *args, **kwargs)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 424, in _load_module
    code_object = self.get_code(name)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 529, in get_code
    self.set_data(bytecode_path, data)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 597, in set_data
    _write_atomic(path, data)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/importlib/_bootstrap.py", line 134, in _write_atomic
    fd = _os.open(path_tmp, _os.O_EXCL | _os.O_CREAT | _os.O_WRONLY, 0o666)
FileExistsError: [Errno 17] File exists: '/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/__pycache__/__init__.cpython-33.pyc.140684930127088'

(http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/3288 )

----------
components: Library (Lib)
messages: 153898
nosy: brett.cannon, neologix, pitrou
priority: normal
severity: normal
status: open
title: sporadic test_multiprocessing failure
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 21 23:25:34 2012
From: report at bugs.python.org (Leon Matthews)
Date: Tue, 21 Feb 2012 22:25:34 +0000
Subject: [New-bugs-announce] [issue14078] Add 'sourceline' property to
	xml.etree Elements
Message-ID: <1329863134.79.0.699697784351.issue14078@psf.upfronthosting.co.za>


New submission from Leon Matthews <leon at lost.co.nz>:

The lxml implementation of the ElementTree API puts a `sourceline` property onto every Element object, which I recently found useful when producing diagnostic messages.  I think it would be a useful improvement to make the standard library's ElementTree implementation.

The attached patch works by copying the current line number from the Expat parser into the Element object after the Element object is created (so as to minimise its intrusiveness for now).

The patch is just a proof of concept, and although all tests pass, the patch currently smells a little hacky and fragile to me.  Hopefully though, it will start a discussion with somebody more experienced.

PS. So as not to create a hard dependency on lxml.etree, in my project I worked around the issue as follows.  While this works in my case, the standard library seems a more logical place for this change::

    class XMLParserWithLines(XMLParser):
        """
        Add a `sourceline` attribute to element, like lxml.etree
        """
        def _start_list(self, *args, **kwargs):
            element = super(self.__class__, self)._start_list(*args, **kwargs)
        element.sourceline = self._parser.CurrentLineNumber
        return element

    
    >>> tree = ElementTree()
    >>> tree.parse(path, parser=XMLParserWithLines())
    >>> ...

----------
components: Library (Lib)
files: elementtree-sourceline.diff
keywords: patch
messages: 153907
nosy: leonov
priority: normal
severity: normal
status: open
title: Add 'sourceline' property to xml.etree Elements
versions: Python 3.3
Added file: http://bugs.python.org/file24594/elementtree-sourceline.diff

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

From report at bugs.python.org  Tue Feb 21 23:56:51 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 21 Feb 2012 22:56:51 +0000
Subject: [New-bugs-announce] [issue14079] Problems with recent
	test_subprocess changes
Message-ID: <1329865011.81.0.762834414848.issue14079@psf.upfronthosting.co.za>


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

There appears to be a problem with a recent change made to test_subprocess to try and speed it up a bit. The commit with a problem seems to be 834650d63130 by Ross Lagerwall on 12 Feb 2012, and the problem is in test_poll(), which now looks like this:

    def test_poll(self):
        p = subprocess.Popen([sys.executable, "-c",
                              "import os",
                              "os.read(1)"], stdin=subprocess.PIPE)
        self.addCleanup(p.stdin.close)
        self.assertIsNone(p.poll())
        os.write(p.stdin.fileno(), b'A')
        p.wait()
        # Subsequent invocations should just return the returncode
        self.assertEqual(p.poll(), 0)

A number of problems here: -c only takes one parameter, so for example

./python -c "import os" "os.read(1)"

never does anything with the "os.read(1)". Possibly

"import os; os.read(1)"

was meant, but that doesn't work either: os.read takes two parameters, fd and n, so it seems that what is wanted is

"import os; os.read(0, 1)"

which appears to fulfill the intent to read a byte from stdin.

Because the command being run is effectively

python -c "import os"

the spawned command returns immediately. This (it would appear) leads to a race between the test process and the spawned process, such that sometimes the poll() returns None and sometimes it returns 0, due to the vagaries of the exact circumstances when the test is run. So the test passes on some machines but not on others.

It looks like it would be good to change the Popen call to use "import os; os.read(0, 1)" as the "-c" parameter value.

----------
messages: 153912
nosy: rosslagerwall, vinay.sajip
priority: normal
severity: normal
status: open
title: Problems with recent test_subprocess changes
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 02:36:01 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 01:36:01 +0000
Subject: [New-bugs-announce] [issue14080] Sporadic test_imp failure
Message-ID: <1329874561.39.0.329557516679.issue14080@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1845/steps/test/logs/stdio

======================================================================
FAIL: test_package___file__ (test.test_imp.PEP3147Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imp.py", line 333, in test_package___file__
    os.sep.join(('.', 'pep3147', '__init__.py')))
AssertionError: 'pep3147/__init__.py' != './pep3147/__init__.py'
- pep3147/__init__.py
+ ./pep3147/__init__.py
? ++

----------
components: Library (Lib), Tests
messages: 153917
nosy: brett.cannon, ncoghlan, pitrou, skrah
priority: normal
severity: normal
status: open
title: Sporadic test_imp failure
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 02:54:10 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 01:54:10 +0000
Subject: [New-bugs-announce] [issue14081] Allow "maxsplit" argument to
	str.split() to be passed as	a keyword argument
Message-ID: <1329875650.41.0.375574316124.issue14081@psf.upfronthosting.co.za>


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

Currently, setting maxsplit for the default "any whitespace" behaviour requires the following cryptic incantation:

    'do re mi fa'.split(None, 1)

That would be significantly more comprehensible as:

    'do re mi fa'.split(maxsplit=1)

(I noticed this when trying to figure out why http://hyperpolyglot.org/scripting#split-notes resorted to using the re module to achieve this)

----------
components: Interpreter Core
messages: 153920
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow "maxsplit" argument to str.split() to be passed as a keyword argument
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 03:17:33 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Feb 2012 02:17:33 +0000
Subject: [New-bugs-announce] [issue14082] shutil doesn't support extended
	attributes
Message-ID: <1329877053.45.0.515473127253.issue14082@psf.upfronthosting.co.za>


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

shutil doesn't provide any function which copies extended attributes on files. Note that "cp -a" does copy xattrs, but "cp -p" doesn't (and copy2() claims to work like "cp -p").

----------
components: Library (Lib)
messages: 153922
nosy: benjamin.peterson, hynek, neologix, pitrou
priority: low
severity: normal
status: open
title: shutil doesn't support extended attributes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 03:27:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Feb 2012 02:27:40 +0000
Subject: [New-bugs-announce] [issue14083] Use local timezone offset by
	default in datetime.timezone
Message-ID: <1329877660.24.0.480060426072.issue14083@psf.upfronthosting.co.za>


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

Currently, datetime.timezone requires that the offset be specified explicitly.

It would be more convenient if the local offset was used by default.

Since the time module already exposes the offset details for the local timezone, this would just make:

  local_tz = datetime.timezone()

equivalent to the current complex incantation:

  local_tz = datetime.timezone(datetime.timedelta(hours=(time.timezone / -3600 + tm.tm_isdst)))

Then getting a timezone aware version of the local time would just be:

  now = datetime.datetime.now(datetime.timezone())

Similar to the existing spelling for UTC:

  now = datetime.datetime.now(datetime.timezone.utc)

(Inspired by http://hyperpolyglot.org/scripting#timezone-offset-notes)

----------
components: Library (Lib)
messages: 153923
nosy: belopolsky, lemburg, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Use local timezone offset by default in datetime.timezone
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 09:37:48 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 08:37:48 +0000
Subject: [New-bugs-announce] [issue14084] test_imp resource leak
Message-ID: <1329899868.11.0.386279986218.issue14084@psf.upfronthosting.co.za>


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

I tried to reproduce the failure from #14080 using this:

./python -m test -uall -v -F test_imp


After around 500 iterations the test fails:


======================================================================
ERROR: test_find_module_encoding (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_imp.py", line 58, in test_find_module_encoding
    with imp.find_module('module_' + mod, self.test_path)[0] as fd:
OSError: [Errno 24] Too many open files

======================================================================
ERROR: test_issue1267 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_imp.py", line 70, in test_issue1267
    self.test_path)
OSError: [Errno 24] Too many open files

======================================================================
ERROR: test_issue3594 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_imp.py", line 92, in test_issue3594
    file, filename, info = imp.find_module(temp_mod_name)
OSError: [Errno 24] Too many open files

======================================================================
ERROR: test_issue9319 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_imp.py", line 182, in test_issue9319
    imp.find_module, "badsyntax_pep3120", [path])
  File "/home/stefan/pydev/cpython/Lib/unittest/case.py", line 571, in assertRaises
    return context.handle('assertRaises', callableObj, args, kwargs)
  File "/home/stefan/pydev/cpython/Lib/unittest/case.py", line 135, in handle
    callable_obj(*args, **kwargs)
OSError: [Errno 24] Too many open files

----------
components: Interpreter Core
messages: 153935
nosy: brett.cannon, pitrou, skrah
priority: normal
severity: normal
status: open
title: test_imp resource leak
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 09:51:32 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Feb 2012 08:51:32 +0000
Subject: [New-bugs-announce] [issue14085] PyUnicode_WRITE: "comparison is
	always true" warnings
Message-ID: <1329900692.24.0.951186261982.issue14085@psf.upfronthosting.co.za>


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

The FreeBSD-9.0 bot shows a couple of warnings because some comparisons
in PyUnicode_WRITE are always true:

Objects/unicodeobject.c:2598: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2598: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2598: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2671: warning: comparison is always true due to limited range of data type
Objects/unicodeobject.c:2671: warning: comparison is always true due to limited range of data type

[...]

----------
components: Interpreter Core
messages: 153936
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: PyUnicode_WRITE: "comparison is always true" warnings
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 10:25:56 2012
From: report at bugs.python.org (David)
Date: Wed, 22 Feb 2012 09:25:56 +0000
Subject: [New-bugs-announce] [issue14086] str(KeyError("Foo")) Unexpected
	Result
Message-ID: <1329902756.66.0.575500165148.issue14086@psf.upfronthosting.co.za>


New submission from David <vencabot_teppoo at hotmail.com>:

The __str__() method of the KeyError class seems to put quotes around the argument given to the class. This was causing bizarre, escaped quotation marks to appear in my code (where the result of str(e) is often passed as the argument of another Exception), and it took me a while to figure out where the problem lies, which says to me that the behavior is obscure and unexpected-enough to not be Python-like.

I appreciate that the quotation marks are put around the erroneous key:
>>> my_dict = {"foo": 1}
>>> my_dict["bar"]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'bar'

The quotation marks should be added to the argument as or before being passed -- not when the KeyError is converted to a str. Consider the following example, where a server is informing the client of invalid input:
>>> def validate_parameters(parameters_dict):
....    try:
....        validate(parameters_dict["foo"])
....        validate(parameters_dict["bar"])
....    except KeyError as e:
....        raise KeyError("Missing parameter {}.".format(e))
....
>>> def handle(parameters_dict):
....    # Validate the parameters before we do anything with them.
....    try:
....        validate_parameters(parameters_dict)
....    except Exception as e:
....        send_to_client("ERR: {}".format(e))
....

In this example, the client receives a string that looks like this:
\"Missing parameter 'foo'.\"
just because I wanted to re-raise a KeyError with a little bit of clarification. I've been doing this sort of re-raising a lot in this project and I don't see anything wrong with it, and I haven't had this kind of problem with any other Exception, which is why the bug took me a while to track down.

Consider these snippets from the Python Tutorial:
"For convenience, the exception instance defines __str__() so the arguments can be printed directly without having to reference .args."

"If an exception has arguments, they are printed as the last part (?detail?) of the message for unhandled exceptions."

Clearly, KeyError.__str__() is not printing my arguments directly. Also, the 'detail' of an unhandled KeyError exception, because of this behavior, is also != to its argument.

I believe that Python should preserve consistency by fixing this behavior. If the default KeyError arguments would look nicer with quotation marks, pass them with quotation marks, but maintain the sanctity and simplicity of Exception.__str__() as described in the tutorial. It makes more sense.

PS: My current project involves a lot of validation not because I don't usually believe that it's "easier to ask forgiveness," but because it's a scheduler for TV recordings, and, in that case, the client will want to know when there's a problem with their input BEFORE their recording of Survivor fails while they're at work and can't do anything about it.

----------
messages: 153941
nosy: vencabot_teppoo
priority: normal
severity: normal
status: open
title: str(KeyError("Foo")) Unexpected Result
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 22 16:01:25 2012
From: report at bugs.python.org (sbt)
Date: Wed, 22 Feb 2012 15:01:25 +0000
Subject: [New-bugs-announce] [issue14087] multiprocessing.Condition.wait_for
	missing
Message-ID: <1329922885.58.0.881756065062.issue14087@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

multiprocessing.Condition is missing a counterpart for the wait_for() method added to threading.Condition in Python 3.2.

I will work on a patch.

----------
components: Library (Lib)
messages: 153956
nosy: sbt
priority: normal
severity: normal
status: open
title: multiprocessing.Condition.wait_for missing
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 17:36:57 2012
From: report at bugs.python.org (Antonio Ribeiro)
Date: Wed, 22 Feb 2012 16:36:57 +0000
Subject: [New-bugs-announce] [issue14088] sys.executable generating
	canonical path
Message-ID: <1329928617.24.0.609517948319.issue14088@psf.upfronthosting.co.za>


New submission from Antonio Ribeiro <alvesjunior.antonio at gmail.com>:

Hi all,

As it is my first time here, I'll try to explay step-by-step why I'm providing this path, and why I think that it is changing something that I believe that is not correct.

First of all, I was trying to run one individual test, as the dev guide says:

./python -m test -v test_sys

but, instead of run this test from the root directory of the project, I run it from ./Lib/test, so I did:

../../python -m test -v test_sys

and it returned an error. The reason is that my sys.executable was not an abspath. When I went to see why it is different, I get this value to sys.executable:

sys.executable -> '/home/antonio/Projects/cpython/Lib/test/../../python'

I'm not sure if I'm thinking write, but for me don't look nice to have this value as sys.executable, once the real path should be:

'/home/antonio/Projects/cpython/python'

So I'm providing a paatch that do exactly this.

Hope you enjoy

----------
components: None
files: canonical_path.diff
keywords: patch
messages: 153970
nosy: alvesjnr
priority: normal
severity: normal
status: open
title: sys.executable generating canonical path
type: behavior
Added file: http://bugs.python.org/file24604/canonical_path.diff

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

From report at bugs.python.org  Wed Feb 22 19:10:39 2012
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Wed, 22 Feb 2012 18:10:39 +0000
Subject: [New-bugs-announce] [issue14089] Patch to increase fractions lib
	test coverage
Message-ID: <1329934239.36.0.224119101932.issue14089@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

The last few missing bits to complete test coverage of 'fractions.py' library.

./python.exe -E -Wd -m test -v -T -D ../coverage/test_fractions test_fractions

lines   cov%   module   (path)
  270   100%   fractions   (/Users/family/Documents/code/python/repo/Lib/fractions.py)

----------
components: Tests
files: test_fractions.patch
keywords: patch
messages: 153979
nosy: Oleg.Plakhotnyuk, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Patch to increase fractions lib test coverage
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24605/test_fractions.patch

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

From report at bugs.python.org  Wed Feb 22 21:59:37 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 20:59:37 +0000
Subject: [New-bugs-announce] [issue14090] Bus error on test_big_buffer() of
	test_zlib, buildbot AMD64 debian bigmem 3.x
Message-ID: <1329944377.36.0.413864839881.issue14090@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

[241/364/1] test_zlib
Fatal Python error: Bus error

Current thread 0x00002b8f2240d260:
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_zlib.py", line 96 in test_big_buffer
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 440 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/case.py", line 492 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 105 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 105 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/unittest/runner.py", line 168 in run
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1369 in _run_suite
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py", line 1403 in run_unittest
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_zlib.py", line 666 in test_main
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 1221 in runtest_inner
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 907 in runtest
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/regrtest.py", line 710 in main
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/__main__.py", line 13 in <module>
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/runpy.py", line 73 in _run_code
  File "/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/runpy.py", line 160 in _run_module_as_main
make: *** [buildbottest] Bus error

http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/136/steps/test/logs/stdio

----------
messages: 153987
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Bus error on test_big_buffer() of test_zlib, buildbot AMD64 debian bigmem 3.x
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 22 23:00:04 2012
From: report at bugs.python.org (Massimo Paladin)
Date: Wed, 22 Feb 2012 22:00:04 +0000
Subject: [New-bugs-announce] [issue14091] python subprocess hangs if script
	called from another	directory
Message-ID: <1329948004.01.0.833709233922.issue14091@psf.upfronthosting.co.za>


New submission from Massimo Paladin <massimo.paladin at gmail.com>:

Here is the behavior I am getting only on Python 2.7.2 in a Fedora 16:
$ cat /tmp/example.py
from subprocess import Popen,PIPE
args = "whatever program".split()
p = Popen(args)

If I run the program with:
$ cd /tmp/; python example.py

I get following as expected
Traceback (most recent call last):
  File "example.py", line 7, in <module>
    p = Popen(args)
  File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

Instead if I run the program with:
$ cd ~; python /tmp/example.py

It hangs until I stop it with ctrl-c

On the same machine python 3.2.1 works fine.
On a mac with python 2.7.1 works fine.
On a rhel5 with python 2.4 works fine too.

----------
components: None
messages: 153994
nosy: Massimo.Paladin
priority: normal
severity: normal
status: open
title: python subprocess hangs if script called from another directory
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 23 00:29:08 2012
From: report at bugs.python.org (Lex Berezhny)
Date: Wed, 22 Feb 2012 23:29:08 +0000
Subject: [New-bugs-announce] [issue14092] __name__ inconsistently applied in
	class definition
Message-ID: <1329953348.22.0.00582409575183.issue14092@psf.upfronthosting.co.za>


New submission from Lex Berezhny <eukreign at gmail.com>:

The following behavior doesn't make sense, especially since it works correctly for other special attributes:

>>> class F:
	__name__ = "Foo"

>>> F.__name__
'F'
>>> F().__name__
'Foo'
>>> F.__name__ = 'Foo'
>>> F.__name__
'Foo'


Works fine for __module__ and others:

>>> class F:
	__module__ = "mod"
	
>>> F.__module__
'mod'
>>> F
<class mod.F at 0x0212B360>

----------
components: Interpreter Core
messages: 154013
nosy: eukreign
priority: normal
severity: normal
status: open
title: __name__ inconsistently applied in class definition
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/issue14092>
_______________________________________

From report at bugs.python.org  Thu Feb 23 00:37:06 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 Feb 2012 23:37:06 +0000
Subject: [New-bugs-announce] [issue14093] Mercurial version information not
	appearing in Windows	builds
Message-ID: <1329953826.97.0.233883201006.issue14093@psf.upfronthosting.co.za>


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

Currently, the Mercurial revision information is not appearing in Windows builds - they always appear to be "default". This appears to be because the relevant information is not passed to getbuildinfo.c.

The attached patch rectifies this, making the assumption that "hg" will always be accessible on the path. The basic method is to call "hg id -bit" and then pass the branch, tag and revision information when compiling getbuildinfo.c.

If "hg" is not in the path, no Mercurial information is added (i.e. the current behaviour).

----------
components: Build, Windows
files: build-info-diff.diff
keywords: patch
messages: 154014
nosy: loewis, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: Mercurial version information not appearing in Windows builds
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24608/build-info-diff.diff

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

From report at bugs.python.org  Thu Feb 23 00:47:50 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Feb 2012 23:47:50 +0000
Subject: [New-bugs-announce] [issue14094] nt.realpath() should use
	GetFinalPathNameByHandle() when	available
Message-ID: <1329954470.08.0.180096078595.issue14094@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

nt.realpath() should use GetFinalPathNameByHandleW() when available, instead of GetFullPathNameW(), to resolve symlinks.

By the way, it's strange that Py_GetFinalPathNameByHandleW() is called with VOLUME_NAME_NT to get the buffer size, and then with VOLUME_NAME_DOS. Is it a bug?

    /* We have a good handle to the target, use it to determine the
       target path name. */
    buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT);

    if(!buf_size)
        return win32_error_object("GetFinalPathNameByHandle", po);

    target_path = (wchar_t *)malloc((buf_size+1)*sizeof(wchar_t));
    if(!target_path)
        return PyErr_NoMemory();

    result_length = Py_GetFinalPathNameByHandleW(hFile, target_path,
                                                 buf_size, VOLUME_NAME_DOS);

See also issue #9333 (issue which added os.symlink() on Windows).

----------
components: Library (Lib)
messages: 154018
nosy: brian.curtin, haypo, pitrou
priority: normal
severity: normal
status: open
title: nt.realpath() should use GetFinalPathNameByHandle() when available
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 23 01:27:45 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 00:27:45 +0000
Subject: [New-bugs-announce] [issue14095] type_new() removes __qualname__
	from the input dictionary
Message-ID: <1329956865.57.0.697177106628.issue14095@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

The C function type_new() creates a copy the dictionary for __dict__ and modifies the copy... except for __qualname__: it does modify the input dictionary before the copy.
---
def f(): pass

d = {'__qualname__': 42, '__new__': f}
assert d['__new__'] is f
assert '__qualname__' in d
Enum = type.__new__(type, 'Enum', (), d)
assert d['__new__'] is f
assert '__qualname__' in d
---

I don't know if it is expected. If not, the copy should be done before.

----------
messages: 154020
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: type_new() removes __qualname__ from the input dictionary
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 23 03:41:32 2012
From: report at bugs.python.org (wang)
Date: Thu, 23 Feb 2012 02:41:32 +0000
Subject: [New-bugs-announce] [issue14096] Python 3.1 IDLE has a bug.Can fix
	it?
Message-ID: <1329964892.44.0.577555550319.issue14096@psf.upfronthosting.co.za>


New submission from wang <zevboy at gmail.com>:

paltform is windows.
generate this bug:
within IDLE edtor.
first select some text.
second press down the shift key.
third  press  the end key.
fourth press the home key.
last IDLE quit with no message and document with no save.

----------
components: IDLE
messages: 154037
nosy: guxianminer
priority: normal
severity: normal
status: open
title: Python 3.1 IDLE has a bug.Can fix it?
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Thu Feb 23 06:37:53 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Feb 2012 05:37:53 +0000
Subject: [New-bugs-announce] [issue14097] Improve the "introduction" page of
	the tutorial
Message-ID: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

I was reading the "introduction" page of the tutorial [0], and noticed a few things that could be improved:
 1) the first paragraph is a bit confusing, showing a simple example and explaining what the >>> is would be better;
 2) comments can be introduced later too, they are not really necessary at the beginning;
 3) the first example is supposed to introduce numbers and basic operations, but it's still going on with the comments;
 4) the note about floating point issues is not so relevant anymore nowadays, so it could be (re)moved;
 5) "A value can be assigned to several variables simultaneously:" is not technically correct;
 6) "Variables must be ?defined? (assigned a value) before they can be used" this might be improved too;
 7) almost half of the section about numbers goes on explaining complex numbers.  This is totally unnecessary here, I think that mentioning them and maybe showing a simple example is more than enough.  Another option is to make a subsection with a note that says that the section can be skipped;
 8) the examples in this part lack some space (e.g. "a=3.0+4.0j");
 9) the print() function could get a better introduction and used in the first set of string examples;
 10) suggesting to use continuation lines with a trailing \ in string literals is not a good idea, it's better to use """...""" or implicit concatenation inside ();
 11) "Degenerate slice indices are handled gracefully" it might be better to show that it's not the same for "non-slice" indices;
 12) the "About Unicode" section could link to the Unicode HOWTO;
 13) while it's true that lists can contain different types of object, they usually shouldn't;
 14) while the "while" example is good (it first shows a piece of code and then explains what it does), I would introduce the "if" and the "for" first.  The "while" is arguably the most complex and less used of the three statements.

[0]: http://docs.python.org/py3k/tutorial/introduction.html

----------
assignee: docs at python
components: Documentation
messages: 154051
nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve the "introduction" page of the tutorial
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb 23 08:58:41 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Feb 2012 07:58:41 +0000
Subject: [New-bugs-announce] [issue14098] provide public C-API for
	reading/setting sys.exc_info()
Message-ID: <1329983921.26.0.0291312337524.issue14098@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Following up on recent mailing list threads on pypy-dev and python-dev, this is a request for adding a public C-API to read and write the sys.exc_info() fields, currently stored in tstate->exc_*.

While not of major interest for CPython itself, this C-API addition would allow other Python implementations (currently PyPy) to hide their internal representation of these fields and to allow extensions that need to access them (most notably those generated by the Cython compiler) to write portable code.

Martin von L?wis proposed the names PyErr_GetExcInfo() and PyErr_SetExcInfo(), making them simple getter and setter functions that operate on owned references.

http://thread.gmane.org/gmane.comp.python.devel/129787/focus=129792

I'm currently working on a patch for CPython 3.3.

----------
components: Interpreter Core
messages: 154052
nosy: loewis, scoder
priority: normal
severity: normal
status: open
title: provide public C-API for reading/setting sys.exc_info()
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 23 11:46:32 2012
From: report at bugs.python.org (Stepan Kasal)
Date: Thu, 23 Feb 2012 10:46:32 +0000
Subject: [New-bugs-announce] [issue14099] zipfile: ZipFile.open() should not
	reopen the underlying	file
Message-ID: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>


New submission from Stepan Kasal <kasal at ucw.cz>:

When a file inside a zip is open, the underlying zip file is open again.
(Unless the file name is unknown, because the ZipFile object was created with fp only.)

This design is incorrect, insecure, and ineffective:
- the reopen uses the same string as file name, but on unix-like systems that file name may no longer exist, or may point to a different file
- opening n files from the same zip archive consumes n OS file descriptors, wasting resources

I believe that the parent ZipFile object and all the child ZipExtFile objects should keep the same fp.  The last one would close it.

I'm working on a patch currently.

----------
components: Library (Lib)
messages: 154058
nosy: kasal
priority: normal
severity: normal
status: open
title: zipfile: ZipFile.open() should not reopen the underlying file
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb 23 15:58:10 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 23 Feb 2012 14:58:10 +0000
Subject: [New-bugs-announce] [issue14100] expose a note a hidden note
Message-ID: <1330009090.66.0.133471342458.issue14100@psf.upfronthosting.co.za>


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

I wonder if this note was hidden deliberately.

----------
assignee: docs at python
components: Documentation
files: make-note-visible.patch
keywords: patch
messages: 154065
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: expose a note a hidden note
versions: Python 3.3
Added file: http://bugs.python.org/file24612/make-note-visible.patch

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

From report at bugs.python.org  Thu Feb 23 21:07:13 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Thu, 23 Feb 2012 20:07:13 +0000
Subject: [New-bugs-announce] [issue14101] example function in tertools.count
	is misindented
Message-ID: <1330027633.46.0.670191761588.issue14101@psf.upfronthosting.co.za>


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

Indentation is broken.

diff --git a/Modules/itertoolsmodule.c b/Modules/itertoolsmodule.c
--- a/Modules/itertoolsmodule.c
+++ b/Modules/itertoolsmodule.c
@@ -3221,10 +3221,10 @@
 Return a count object whose .__next__() method returns consecutive values.\n\
 Equivalent to:\n\n\
     def count(firstval=0, step=1):\n\
-    x = firstval\n\
-    while 1:\n\
-        yield x\n\
-        x += step\n");
+        x = firstval\n\
+        while 1:\n\
+            yield x\n\
+            x += step\n");

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: itertools-count-indentation.diff
keywords: patch
messages: 154084
nosy: docs at python, zbysz
priority: normal
severity: normal
status: open
title: example function in tertools.count is misindented
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24618/itertools-count-indentation.diff

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

From report at bugs.python.org  Thu Feb 23 22:16:00 2012
From: report at bugs.python.org (Daniel Walsh)
Date: Thu, 23 Feb 2012 21:16:00 +0000
Subject: [New-bugs-announce] [issue14102] argparser should create a man page
	for me.
Message-ID: <1330031760.56.0.8938390885.issue14102@psf.upfronthosting.co.za>


New submission from Daniel Walsh <rhatdan at gmail.com>:

I have developed a new tool virt-sandbox-service using argparse.  Currently the argparse has the ability to print help and usage.  Being naturally lazy, I think it should be able to print out a man page also.  This would help with development and make maintaining the different documents.

----------
components: None
messages: 154090
nosy: Daniel.Walsh, dmalcolm
priority: normal
severity: normal
status: open
title: argparser should create a man page for me.
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 23 22:18:02 2012
From: report at bugs.python.org (Daniel Walsh)
Date: Thu, 23 Feb 2012 21:18:02 +0000
Subject: [New-bugs-announce] [issue14103] argparser should create a
	bash_completion script for me.
Message-ID: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>


New submission from Daniel Walsh <rhatdan at gmail.com>:

I have developed a new tool virt-sandbox-service using argparse.  Currently the argparse has the ability to print help and usage.  Being naturally lazy, I think it should be able to generate a bash_completion script also.

----------
messages: 154091
nosy: Daniel.Walsh, dmalcolm
priority: normal
severity: normal
status: open
title: argparser should create a bash_completion script for me.

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

From report at bugs.python.org  Fri Feb 24 00:09:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Feb 2012 23:09:15 +0000
Subject: [New-bugs-announce] [issue14104] Implement time.monotonic() on Mac
	OS X
Message-ID: <1330038555.4.0.559569598295.issue14104@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

time.monotonic() can use mach_absolute_time() on Mac OS X. mach_timebase_info() may be used to convert the result to a number of seconds. Examples:

https://github.com/ThomasHabets/monotonic_clock/blob/master/src/monotonic_mach.c
http://svn.boost.org/svn/boost/trunk/boost/chrono/detail/inlined/mac/chrono.hpp
(search steady_clock)

Another way is to use clock_get_time() with host_get_clock_service(SYSTEM_CLOCK). Example:

https://github.com/gavinbeatty/python-monotonic-time/blob/master/darwin.c

----------
components: Library (Lib)
messages: 154095
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Implement time.monotonic() on Mac OS X
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 24 02:35:27 2012
From: report at bugs.python.org (Larry A. Taylor)
Date: Fri, 24 Feb 2012 01:35:27 +0000
Subject: [New-bugs-announce] [issue14105] Breakpoints in debug lost if line
	is inserted; IDLE
Message-ID: <1330047327.02.0.291761854329.issue14105@psf.upfronthosting.co.za>


New submission from Larry A. Taylor <larry.taylor at bankofamerica.com>:

My environment is Windows XP, using IDLE and Python 2.7 distribution.

Open an IDLE Python shell. Open the file with three lines in it, 1,2 and 3.

In IDLE, Set Breakpoint on Line 2.

In Shell, set Debug.

In IDLE, select run. 

In the Debug window, click Go.

Run stops at line 2, displayed in Debug. Click Quit.

Edit the file, inserting a line 0, like: print "this is line 0". Save the file

Run again, Go in Debug. 

The breakpoint has disappeared and the debugger does not stop on line 2 (now the third line). It doesn't stop anywhere.

Delete line 0, and set breakpoint on line 2 again. At the end of the file, insert a line 4, such as: print "this is line 4".

Run again, Go in Debug.

The breakpoint is preserved, and the debugger stops at line 2.

This is inconsistent behavior. I expect that a breakpoint will not disappear, and that it will always point to the same line, moving down when the line moves down. The breakpoint should move up if the line it refers to moves up.

----------
components: IDLE, Windows
files: debug-line-numbers.py
messages: 154104
nosy: ltaylor934
priority: normal
severity: normal
status: open
title: Breakpoints in debug lost if line is inserted; IDLE
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24621/debug-line-numbers.py

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

From report at bugs.python.org  Fri Feb 24 15:46:35 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 14:46:35 +0000
Subject: [New-bugs-announce] [issue14106] Distutils manifest:
	recursive-(include|exclude) matches	suffix instead of full filename
Message-ID: <1330094795.44.0.467789061974.issue14106@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

As I understand it, a MANIFEST.in directive:

    recursive-include foo bar.*

is meant to match files under foo for with names beginning with "bar.".
However, the actual regex that is generated for this line is:

    r'^foo/.*bar\.[^/]*\Z(?ms)'

which matches any filename under foo that contains "bar." anywhere in the
base filename. For example, if foo contains files bar.py and test_bar.py,
then the pattern will match both filenames. Is this the intended
behaviour? I would have expected it to only match bar.py.

If the desired behavior is what I expected (and not how it currently
works), then the desired regex is:

    r'^foo/(.*/)?bar\.[^/]*\Z(?ms)'

The attached patch (against 2.7) implements this change. It is dependent
on the fix for issue 6884. I have tested it on both Linux and Windows.

----------
files: recursive-include.diff
keywords: patch
messages: 154137
nosy: eric.araujo, nadeem.vawda, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Distutils manifest: recursive-(include|exclude) matches suffix instead of full filename
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24628/recursive-include.diff

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

From report at bugs.python.org  Fri Feb 24 16:17:26 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 15:17:26 +0000
Subject: [New-bugs-announce] [issue14107] Debian bigmem buildbot hanging in
	test_bigmem
Message-ID: <1330096646.48.0.414006184823.issue14107@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

On the debian bigmem  buildbot, test_bigmem hangs until it gets killed
by a timeout:

    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/134/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/131/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/129/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/128/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/123/steps/test/logs/stdio
    http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/85/steps/test/logs/stdio

This has happened on every run I've checked that hasn't crashed before
reaching test_bigmem for some other reason (e.g. the recently-fixed zlib
bus error), as far back as the buildbot history goes.

Issue 5438 might be related.

----------
components: Tests
keywords: buildbot
messages: 154139
nosy: loewis, nadeem.vawda, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Debian bigmem buildbot hanging in test_bigmem
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 24 19:07:25 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 18:07:25 +0000
Subject: [New-bugs-announce] [issue14108] test_shutil: failures in symlink
	tests
Message-ID: <1330106845.06.0.919301753215.issue14108@psf.upfronthosting.co.za>


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

These two tests fail on Windows 7:

======================================================================                                      
FAIL: test_copymode_follow_symlinks (test.test_shutil.TestShutil)                                           
----------------------------------------------------------------------                                      
Traceback (most recent call last):                                                                          
  File "C:\Users\stefan\hg\master\lib\test\test_shutil.py", line 194, 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:\Users\stefan\hg\master\lib\test\test_shutil.py", line 59, in wrap                                
    return func(*args, **kwargs)                                                                            
  File "C:\Users\stefan\hg\master\lib\test\test_shutil.py", line 1137, in test_move_dangling_symlink        
    self.assertEqual(os.path.realpath(src), os.path.realpath(dst_link))                                     
AssertionError: 'c:\\users\\stefan\\appdata\\local\\temp\\tmp7a4jc3\\baz' != 'c:\\users\\stefan\\appdata\\lo
cal\\temp\\tmp9ucl3b\\quux'                                                                                 
- c:\users\stefan\appdata\local\temp\tmp7a4jc3\baz                                                          
?                                       ^^^^   ^^^                                                          
+ c:\users\stefan\appdata\local\temp\tmp9ucl3b\quux                                                         
?                                       ^^ + + ^^^^

----------
components: Tests
messages: 154142
nosy: skrah
priority: normal
severity: normal
status: open
title: test_shutil: failures in symlink tests
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 24 19:30:16 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 18:30:16 +0000
Subject: [New-bugs-announce] [issue14109] test_lib2to3: failure on Windows 7
Message-ID: <1330108216.18.0.0457510512891.issue14109@psf.upfronthosting.co.za>


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

This failure occurs on the Windows 7 buildbot:

[302/364] test_lib2to3
--- D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\lib2to3\tests\test_main.py	2012-02-13 21:57:29.273004000 -0500
+++ @	2012-02-24 11:59:54.408966500 -0500
@@ -42,7 +42,7 @@
             sys.stderr = save_stderr
 
     def test_unencodable_diff(self):
-        input_stream = io.StringIO("print 'nothing'\nprint u'?ber'\n")
+        input_stream = io.StringIO("print 'nothing'\nprint u'?ber'\n")
         out = io.BytesIO()
         out_enc = codecs.getwriter("ascii")(out)
         err = io.StringIO()

----------
components: Tests
messages: 154144
nosy: benjamin.peterson, skrah
priority: normal
severity: normal
status: open
title: test_lib2to3: failure on Windows 7
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 24 20:24:35 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 24 Feb 2012 19:24:35 +0000
Subject: [New-bugs-announce] [issue14110] FreeBSD: test_os fails if user is
	in the wheel group
Message-ID: <1330111475.14.0.550886598364.issue14110@psf.upfronthosting.co.za>


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

On FreeBSD, if the user is a member of the group 'wheel', these
tests fail:


======================================================================
FAIL: test_setegid (test.test_os.PosixUidGidTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/stefan/hg/cpython/Lib/test/test_os.py", line 1090, in test_setegid
    self.assertRaises(os.error, os.setegid, 0)
AssertionError: OSError not raised by setegid

======================================================================
FAIL: test_setgid (test.test_os.PosixUidGidTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/stefan/hg/cpython/Lib/test/test_os.py", line 1078, in test_setgid
    self.assertRaises(os.error, os.setgid, 0)
AssertionError: OSError not raised by setgid

======================================================================
FAIL: test_setregid (test.test_os.PosixUidGidTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/stefan/hg/cpython/Lib/test/test_os.py", line 1110, in test_setregid
    self.assertRaises(os.error, os.setregid, 0, 0)
AssertionError: OSError not raised by setregid

----------
components: Tests
messages: 154148
nosy: skrah
priority: low
severity: normal
status: open
title: FreeBSD: test_os fails if user is in the wheel group
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 24 20:47:19 2012
From: report at bugs.python.org (Larry A. Taylor)
Date: Fri, 24 Feb 2012 19:47:19 +0000
Subject: [New-bugs-announce] [issue14111] IDLE Debugger should handle
	interrupts
Message-ID: <1330112839.68.0.0096879566667.issue14111@psf.upfronthosting.co.za>


New submission from Larry A. Taylor <larry.taylor at bankofamerica.com>:

The attached script runs a long processing loop.

Start it in IDLE. Open the script and run it.

Press control-C. Result: message, KeyboardInterrupt with traceback message.

In shell window, turn on Debugger. Run the script.

Press control-C. Result: Restrat message shown in Python Shell. Debug Control shows no change.

Expected behavior: For keyboard interrupt, or for any uncaught exception, Debug Control should show the same information as if there was a breakpoint. For instance, the stack with line numbers, locals and globals.

Better: make a way to interrupt the program in a long loop or process, so that the programmer can tell -- live -- where the program is, and where most of the time is being used. Then use the regular buttons, Go, etc. to continue the process, possibly interrupted again.

Also: the IDLE Python Shell and Debug Control show no "running" indicator, so there is no easy way to tell if the program is still going.

----------
components: IDLE, Windows
files: debug-running-or-stopped.py
messages: 154150
nosy: ltaylor934
priority: normal
severity: normal
status: open
title: IDLE Debugger should handle interrupts
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file24631/debug-running-or-stopped.py

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

From report at bugs.python.org  Fri Feb 24 20:50:05 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 24 Feb 2012 19:50:05 +0000
Subject: [New-bugs-announce] [issue14112] tutorial intro talks of "shallow
	copy" concept without	explanation
Message-ID: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za>


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

Relevant line: http://hg.python.org/cpython/file/e2eccc906354/Doc/tutorial/introduction.rst#l487

When the concept is introduced, it appears like there's an assumption that the reader would know what it means. I'm curious if it's that common a term that it should be taken for granted, or if it deserves a definition.

----------
assignee: docs at python
components: Documentation
messages: 154151
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: tutorial intro talks of "shallow copy" concept without explanation
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 24 21:13:18 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 24 Feb 2012 20:13:18 +0000
Subject: [New-bugs-announce] [issue14113] Failure in test_strptime on Windows
Message-ID: <1330114398.55.0.713486121761.issue14113@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

Recent failures on one of the Windows XP buildbots:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6049/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6051/steps/test/logs/stdio

    FAIL: test_date_time (test.test_strptime.LocaleTime_Tests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_strptime.py", line 91, in test_date_time
        "LC_date_time incorrect")
    AssertionError: False is not true : LC_date_time incorrect

----------
components: Tests, Windows
keywords: buildbot
messages: 154153
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: Failure in test_strptime on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 24 21:15:30 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Feb 2012 20:15:30 +0000
Subject: [New-bugs-announce] [issue14114] 2.7.3rc1 chm gives JS error
Message-ID: <1330114530.4.0.50026951866.issue14114@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The 2.7.3rc1 chm give the following error when opened

Line: 1 Char: 1
The Value of the property "$" is null or undefined, not a function (translated from German)
Code: 0
URL: mk:@MSITStore:C:\Users\martin\27\python\Doc\build\htmlhelp\python273rc1.chm::/_static/copybutton.js

Clicking "yes" lets me proceed to the contents of the file.

----------
messages: 154154
nosy: loewis
priority: normal
severity: normal
status: open
title: 2.7.3rc1 chm gives JS error

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

From report at bugs.python.org  Fri Feb 24 21:26:24 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Feb 2012 20:26:24 +0000
Subject: [New-bugs-announce] [issue14115] 2.7.3rc hangs on test_asynchat on
	32-bit Windows
Message-ID: <1330115184.52.0.720295270361.issue14115@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

As the title says: test_asynchat appears to hang on Windows.

----------
messages: 154155
nosy: loewis
priority: normal
severity: normal
status: open
title: 2.7.3rc hangs on test_asynchat on 32-bit Windows

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

From report at bugs.python.org  Fri Feb 24 22:03:01 2012
From: report at bugs.python.org (sbt)
Date: Fri, 24 Feb 2012 21:03:01 +0000
Subject: [New-bugs-announce] [issue14116] Lock.__enter__() method returns
	True instead of self
Message-ID: <1330117381.1.0.499178307418.issue14116@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

The __enter__() methods of Lock, RLock, Semaphore and Condition in threading (and multiprocessing) all return True.  This seems to contradict the documentation for the context protocol which says

  contextmanager.__enter__()

    Enter the runtime context and return either this object or 
    another object related to the runtime context. The value 
    returned by this method is bound to the identifier in the
    as clause of with statements using this context manager.

    ...

I don't think True qualifies as "another object related to the runtime context".

It looks like an oversight caused by making __enter__() an alias for acquire().  Is it reasonable to change this for 3.3?  I tripped over the issue when I tried writing

  with Condition() as c:
    ...

----------
components: Library (Lib)
messages: 154161
nosy: sbt
priority: normal
severity: normal
status: open
title: Lock.__enter__() method returns True instead of self
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb 24 22:52:45 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Feb 2012 21:52:45 +0000
Subject: [New-bugs-announce] [issue14117] Turtledemo: exception and minor
	glitches.
Message-ID: <1330120365.77.0.428280648922.issue14117@psf.upfronthosting.co.za>


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

Win7, 3.2.2, python -m turtledemo in Command Prompt Window

After running clock example, hitting Stop results in following:
Clock face, including hands, is erased. Day and date are left (intentional?), and the following appears back in command prompt window.

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "C:\Programs\Python32\lib\tkinter\__init__.py", line 487, in callit
    func(*args)
  File "C:\Programs\Python32\lib\turtledemo\clock.py", line 116, in tick
    second_hand.setheading(6*sekunde)
  File "C:\Programs\Python32\lib\turtle.py", line 1936, in setheading
    self._rotate(angle)
  File "C:\Programs\Python32\lib\turtle.py", line 3279, in _rotate
    self._update()
  File "C:\Programs\Python32\lib\turtle.py", line 2660, in _update
    self._update_data()
  File "C:\Programs\Python32\lib\turtle.py", line 2646, in _update_data
    self.screen._incrementudc()
  File "C:\Programs\Python32\lib\turtle.py", line 1285, in _incrementudc
    raise Terminator
turtle.Terminator

Demo continues to run.

Paint: Left clicking mouse moves dot without painting. Right clicking changes mode so left clicking draws line. It also causes some filling of enclosed regions. This double action is slightly obscure. The prompt on the bottom of the screen says "Use mouse/keys or Stop" As near as I can tell, keys are inactive. So prompt could delete '/keys'.

Module doc strings that explain each demo should be wrapped so that they appear in the code window without scrolling. Or the left window could be wider, especially if the user widens the window. 800x600 screens are pretty rare these days. 

'Wikipedia' is a poor name for something just because it happened to be there. 'Rosette', for instance, would be better.

----------
components: Library (Lib)
messages: 154164
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: Turtledemo: exception and minor glitches.
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Feb 25 00:38:06 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 24 Feb 2012 23:38:06 +0000
Subject: [New-bugs-announce] [issue14118] _pickle.c structure cleanup
Message-ID: <1330126686.15.0.366051703347.issue14118@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

While working on #6784, I've looked at _pickle.c and found it quite... daunting: 6500 lines and 185kB. I have been working on a bit of cleanup, and I'd like some comments on this.

I'm working on adapting
_pickle.c into the following structure:

_pickle.c takes care of the module initialization
_pickle/*.c are helper files for this (global functions/definitions)
_pickle/PicklerObject contains all files that relate to the Pickler
class - initialization, all functions, etc, and
_pickle/PicklerObject/picklers/*.c contains all pickling functions,
split out into groups (corresponding to pickletools.StackObjects)

This should end in a tree where every .c module lists the relevant dependencies (and as such should be compilable on itself).

Currently, I'm at the point where PicklerObject roughly has the structure I want (although not every file is compilable on itself yet). As such, I feel this is the right moment to ask if it would be seen as an useful improvement in trunk, and to see if anyone has suggestions for improvements.

hg repos: https://bitbucket.org/valhallasw/cpython/src/0810ffadffa3/Modules/_pickle/PicklerObject (_pickle_clean branch)

----------
components: Extension Modules
hgrepos: 114
messages: 154165
nosy: valhallasw
priority: normal
severity: normal
status: open
title: _pickle.c structure cleanup
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb 25 01:19:02 2012
From: report at bugs.python.org (Nam Nguyen)
Date: Sat, 25 Feb 2012 00:19:02 +0000
Subject: [New-bugs-announce] [issue14119] Ability to adjust queue size in
	Executors
Message-ID: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za>


New submission from Nam Nguyen <bitsink at gmail.com>:

I am running into a memory consumption issue with concurrent.futures module. Its Executors do not have a public API to adjust their queue size.  and the queues are created unbounded initially.

It would be helpful to have some public method or a parameter at construction time to limit this queue size.

----------
components: Library (Lib)
messages: 154175
nosy: Nam.Nguyen
priority: normal
severity: normal
status: open
title: Ability to adjust queue size in Executors
type: enhancement

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

From report at bugs.python.org  Sat Feb 25 09:45:20 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 25 Feb 2012 08:45:20 +0000
Subject: [New-bugs-announce] [issue14120] ARM Ubuntu 3.x buildbot failing
	test_dbm
Message-ID: <1330159520.1.0.928033022024.issue14120@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

The ARM Ubuntu 3.x buildbot often fails test_dbm:

http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/364/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/367/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/368/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/372/steps/test/logs/stdio

    ======================================================================
    ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 70, in test_anydbm_creation
        self.read_helper(f)
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 111, in read_helper
        self.assertEqual(self._dict[key], f[key.encode("ascii")])
    KeyError: b'0'

    ======================================================================
    ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 85, in test_anydbm_modification
        self.read_helper(f)
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 111, in read_helper
        self.assertEqual(self._dict[key], f[key.encode("ascii")])
    KeyError: b'0'

    ======================================================================
    ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 91, in test_anydbm_read
        self.read_helper(f)
      File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_dbm.py", line 111, in read_helper
        self.assertEqual(self._dict[key], f[key.encode("ascii")])
    KeyError: b'0'

The stdio logs also show possibly-related output on stderr:

    test test_dbm failed
    @test_27319_tmp.db: unable to flush: No such file or directory
    @test_27319_tmp.db: unable to flush: No such file or directory

This is printed before the error tracebacks, but I assume it actually
happens afterwards (which is entirely possible if stderr is line-buffered
and stdout is not).

----------
components: Tests
keywords: buildbot
messages: 154215
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: ARM Ubuntu 3.x buildbot failing test_dbm
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb 25 10:12:01 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 25 Feb 2012 09:12:01 +0000
Subject: [New-bugs-announce] [issue14121] add a convenience C-API function
	for unpacking iterables
Message-ID: <1330161121.09.0.794717935446.issue14121@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

In the context of better interfacing of PyPy with Cython, it appears that simple looking things like PyTuple_GET_ITEM() are often rather involved in PyPy's C-API implementation. However, since functions/macros like these are used very frequently, this has an effect on the achievable performance.

It occurred to me that there are cases that involve many C-API calls where the intention is simply to unpack a sequence (or iterable) of known length, often just 2 or 3 items. Argument unpacking is one such situation (for which there are appropriate C-API functions), dict item iteration or iteration over enumerate() are other well known cases (at least in Python space). As the one obvious way to handle the general use case, I propose the following addition of a convenience function to the C-API:

int PyIter_Unpack(PyObject* iterable, Py_ssize_t min_unpack, Py_ssize_t max_unpack, ...)

As indicated by the names, it's meant to unpack any iterable or iterator, really, i.e. it would fall back to iteration if the iterable is neither a tuple nor list, for which special handling code makes the most sense. I thought about naming it PySequence_Unpack(), but that would imply that it should reject unordered (or, for safety, any unknown) iterables and non-sequence iterator as input, which IMHO would complicate matters more than it would help. A warning about unordered iterables in the documentation should be enough. I would expect that most users would actually know the type of sequence that they are processing.

The "max_unpack" parameter gives the number of varargs that follows, which are all either of type PyObject** or NULL, the latter indicating that the value is not of interest. Non-NULL pointers will receive a new reference to the item at the corresponding index.

The "min_unpack" parameter is made available for error checking. If less items are found in the iterable, the function sets a ValueError and returns -1. Assignments may or may not have taken place at this point, but no owned references are passed back in this case. If, on successful unpacking, the number of unpacked items is smaller than "max_unpack", all remaining item pointers will be set to NULL. Users who do not care about the number of items would pass 0 and those who know the exact length would pass that as both "min_unpack" and "max_unpack".

There is one case I'm not sure about yet, and that's how to handle the case of finding more items than "max_unpack" requests. I think it's just as convenient in some cases to automatically raise an exception, as it is in other cases to just ignore them. I think a way to solve this could be to not raise an exception, but to return 0 when all items were processed and 1 when there are remaining items. In this case, users who care could check the result and if they consider left-over items an error, clean up the returned references and raise an error manually. Alternatively, the function could return the number of unpacked items, but that may involve more work on the user side in order to find out what needs to be done. The drawback of a tristate return with and without errors set is that the straight forward "if (PyIter_Unpack(...))" check is no longer enough to correctly detect and propagate errors. Also, when passing an iterator, the function would have to eat one more value in order to determine the return code. That may not be what the caller wants.

Maybe an additional flag parameter ("check_size") could solve this. If true, the function will check the size of sequences and report longer sequences as errors, and for iterators, will unpack the next item and report it as error if available. If false, additional values will be ignored for sequences and no attempt will be made for iterators to unpack more items than requested.


Because of the questions above, and because this addition involves a certain redundancy with what's there already (namely the argument and tuple unpacking functions which do not work on lists or arbitrary iterables and/or raise the wrong exceptions), I'm asking for comments before writing up a patch. Any thoughts on this?

----------
components: Interpreter Core
messages: 154217
nosy: scoder
priority: normal
severity: normal
status: open
title: add a convenience C-API function for unpacking iterables
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb 25 18:29:07 2012
From: report at bugs.python.org (=?utf-8?q?F=C3=A9lix-Antoine_Fortin?=)
Date: Sat, 25 Feb 2012 17:29:07 +0000
Subject: [New-bugs-announce] [issue14122] operator: div() instead of
	truediv() in documention	since 3.1.2
Message-ID: <1330190947.0.0.577940760696.issue14122@psf.upfronthosting.co.za>


New submission from F?lix-Antoine Fortin <felixantoinefortin+python at gmail.com>:

A small regression was introduced by the changeset 57209 in the documentation of the operator module.

In the abstract operations table in section 9.3.1 the first of two lines
on Division, the associated function should be : truediv() instead of div(), since operator.div() no longer exists in Python 3. In changeset 57209, this corresponds to the line 408 of the file Doc/library/operator.rst.

I have included the patch for the changeset 57209.

----------
assignee: docs at python
components: Documentation
files: operator_div.patch
keywords: patch
messages: 154277
nosy: docs at python, felixantoinefortin
priority: normal
severity: normal
status: open
title: operator: div() instead of truediv() in documention since 3.1.2
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24639/operator_div.patch

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

From report at bugs.python.org  Sat Feb 25 21:48:48 2012
From: report at bugs.python.org (Christine Jones)
Date: Sat, 25 Feb 2012 20:48:48 +0000
Subject: [New-bugs-announce] [issue14123] Doc change re old and new string
	formatting
Message-ID: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>


New submission from Christine Jones <silly.english.knights at gmail.com>:

Change to this http://docs.python.org/py3k/library/stdtypes.html as suggested by Nick Coghlan here http://www.gossamer-threads.com/lists/python/dev/969817

"The formatting operations described here are modelled on C's printf()
syntax. They only support formatting of certain builtin types, and the
use of a binary operator means that care may be needed in order to
format tuples and dictionaries correctly. As the new string formatting
syntax is more powerful, flexible, extensible and handles tuples and
dictionaries naturally, it is recommended for new code. However, there
are no current plans to deprecate printf-style formatting."

----------
assignee: docs at python
components: Documentation
messages: 154283
nosy: docs at python, telephonebook
priority: normal
severity: normal
status: open
title: Doc change re old and new string formatting

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

From report at bugs.python.org  Sat Feb 25 21:56:02 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 25 Feb 2012 20:56:02 +0000
Subject: [New-bugs-announce] [issue14124] _pickle.c comment/documentation
	improvement
Message-ID: <1330203362.98.0.289163571674.issue14124@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

As suggested by loewis in msg154233, I created some documentation to help people get started with _pickle.c.

----------
assignee: docs at python
components: Documentation, Extension Modules
files: _pickle_c_doc.diff
keywords: patch
messages: 154284
nosy: docs at python, valhallasw
priority: normal
severity: normal
status: open
title: _pickle.c comment/documentation improvement
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24641/_pickle_c_doc.diff

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

From report at bugs.python.org  Sat Feb 25 23:47:31 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Feb 2012 22:47:31 +0000
Subject: [New-bugs-announce] [issue14125] Windows: failures in refleak mode
Message-ID: <1330210051.4.0.773065627544.issue14125@psf.upfronthosting.co.za>


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

The following tests fail on Windows in refleak mode. I used
24ca28cc9c9c as a reference point. Build is x64. Summary:

test_concurrent_futures, test_datetime, test_multiprocessing, test_strftime and test_time are leaking.



C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_multiprocessing              
[1/1] test_multiprocessing                                                                                 
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_multiprocessing leaked [3, 3, 3, 3] references, sum=12                                                
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing                          
1 test failed:                                                                                             
    test_multiprocessing                                                                                   
[172456 refs]


C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_concurrent_futures           
[1/1] test_concurrent_futures                                                                              
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_concurrent_futures leaked [1524, 1518, 1524, 1524] references, sum=6090                               
1 test failed:                                                                                             
    test_concurrent_futures                                                                                
[170398 refs]                                                                                              
                     

C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_datetime                     
[1/1] test_datetime                                                                                        
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_datetime leaked [20, 20, 20, 20] references, sum=80                                                   
1 test failed:                                                                                             
    test_datetime                                                                                          
[191763 refs]                                                                                            



C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_strftime                     
[1/1] test_strftime                                                                                        
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_strftime leaked [2761, 2761, 2761, 2761] references, sum=11044                                        
1 test failed:                                                                                             
    test_strftime                                                                                          
[170275 refs]                                                                                          


C:\Users\stefan\hg\master\PCbuild>amd64\python_d.exe -m test -uall -R :: test_time                         
[1/1] test_time                                                                                            
beginning 9 repetitions                                                                                    
123456789                                                                                                  
.........                                                                                                  
test_time leaked [1, 1, 1, 1] references, sum=4                                                            
1 test failed:                                                                                             
    test_time                                                                                              
[144556 refs]

----------
messages: 154287
nosy: skrah
priority: normal
severity: normal
status: open
title: Windows: failures in refleak mode
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Sun Feb 26 00:29:27 2012
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 25 Feb 2012 23:29:27 +0000
Subject: [New-bugs-announce] [issue14126] Speed up list comprehensions by
	preallocating the list	where possible
Message-ID: <1330212567.11.0.0699848649478.issue14126@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

This adds a new opcode which for certain list comprehensions (ones with no if statements and only a single comprehension), preallocates the list to the appropriate size.

Patch is against 2.7, because it was a bit easier.  On:


def f():
    for i in range(10000):
        [j for j in range(10000)]

f()


Here's the speedup:


alex at alex-gaynor-laptop:/tmp$ # Fresh 2.7 branch
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m6.418s
user	0m6.408s
sys	0m0.004s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.670s
user	0m5.648s
sys	0m0.008s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.688s
user	0m5.672s
sys	0m0.008s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.688s
user	0m5.676s
sys	0m0.004s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.690s
user	0m5.684s
sys	0m0.000s
alex at alex-gaynor-laptop:/tmp$ 
alex at alex-gaynor-laptop:/tmp$ 
alex at alex-gaynor-laptop:/tmp$ # With patch
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m6.085s
user	0m6.064s
sys	0m0.008s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.728s
user	0m5.720s
sys	0m0.004s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m5.783s
user	0m5.772s
sys	0m0.004s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m4.730s
user	0m4.716s
sys	0m0.008s
alex at alex-gaynor-laptop:/tmp$ time ~/projects/cpython/python t.py 

real	0m4.691s
user	0m4.680s
sys	0m0.004s

----------
components: Interpreter Core
files: preallocate.diff
keywords: patch
messages: 154288
nosy: alex
priority: normal
severity: normal
status: open
title: Speed up list comprehensions by preallocating the list where possible
versions: Python 3.4
Added file: http://bugs.python.org/file24642/preallocate.diff

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

From report at bugs.python.org  Sun Feb 26 10:23:22 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Feb 2012 09:23:22 +0000
Subject: [New-bugs-announce] [issue14127] os.stat and os.utime: allow
	preserving exact metadata
Message-ID: <1330248202.41.0.0356274409354.issue14127@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Following on from Guido's rejection of PEP 410:
http://mail.python.org/pipermail/python-dev/2012-February/116837.html

This bug is the proposed hammering-out space for how to preserve exact metadata for st_atime / st_mtime between os.stat and os.utime.

(Yes, there's already #11457 -- but that went pretty far down the rabbit hole of Decimal.  I thought maybe a fresh start would be best.)

----------
components: Library (Lib)
messages: 154316
nosy: larry
priority: normal
severity: normal
status: open
title: os.stat and os.utime: allow preserving exact metadata
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Feb 26 10:30:20 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 09:30:20 +0000
Subject: [New-bugs-announce] [issue14128] _elementtree should expose types
	and factory functions	consistently with ElementTree
Message-ID: <1330248620.3.0.71621144947.issue14128@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Element, XMLParser and TreeBuilder are types in ElementTree, but factory functions in _elementtree. The latter should be modified to be consistent with the former.

----------
assignee: eli.bendersky
components: Library (Lib)
messages: 154317
nosy: eli.bendersky, flox, scoder
priority: high
severity: normal
stage: needs patch
status: open
title: _elementtree should expose types and factory functions consistently with ElementTree
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Feb 26 12:08:58 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 26 Feb 2012 11:08:58 +0000
Subject: [New-bugs-announce] [issue14129] Corrections for the "extending" doc
Message-ID: <1330254538.51.0.802028199864.issue14129@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

I'm now carefully reading through the "extending" documentation pages. This issue will record various problems I find on the way, with the intention of fixing them eventually.

----------
assignee: eli.bendersky
components: Documentation
keywords: easy
messages: 154325
nosy: eli.bendersky
priority: low
severity: normal
status: open
title: Corrections for the "extending" doc
versions: Python 3.3

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

From report at bugs.python.org  Sun Feb 26 13:20:55 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 26 Feb 2012 12:20:55 +0000
Subject: [New-bugs-announce] [issue14130] memoryview: add multi-dimensional
	indexing and slicing
Message-ID: <1330258855.41.0.545433436542.issue14130@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
assignee: skrah
nosy: ncoghlan, pitrou, pv, skrah, teoliphant
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview: add multi-dimensional indexing and slicing
type: enhancement

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

From report at bugs.python.org  Sun Feb 26 13:33:05 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Feb 2012 12:33:05 +0000
Subject: [New-bugs-announce] [issue14131] test_threading failure on WIndows
	7 3.x buildbot
Message-ID: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4458/steps/test/logs/stdio

Appears to be new, but also isn't obviously related to any recent checkins that I noticed.

(the Win7 buildbot for trunk isn't in a good place, with regular test_packaging and test_strptime values, too).

----------
keywords: buildbot
messages: 154339
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_threading failure on WIndows 7 3.x buildbot
versions: Python 3.3

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

From report at bugs.python.org  Sun Feb 26 16:15:31 2012
From: report at bugs.python.org (=?utf-8?q?J=C3=A1n_Janech?=)
Date: Sun, 26 Feb 2012 15:15:31 +0000
Subject: [New-bugs-announce] [issue14132] Redirect is not working correctly
	in urllib2
Message-ID: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>


New submission from J?n Janech <janech at kios.sk>:

When only the query string is sent by the server as the redirect url, urllib2 redirects to incorrect address.

Error is occuring on the page http://kniznica.uniza.sk/opac. Server sends only the query string part of the uri in the Location header (ie. ?fs=04D07295D4434730A51C95A9F1727373&fn=main). Path is then incorrectly stripped from the original url, and urllib2 redirects to http://kniznica.uniza.sk/?fs=04D07295D4434730A51C95A9F1727373&fn=main.

The error was introduced in the fix of the issue #2464. I think, the attached patch is fixing the error (it is working for me).

----------
components: Library (Lib)
files: urllib2_redirect_fix.patch
keywords: patch
messages: 154356
nosy: janik
priority: normal
severity: normal
status: open
title: Redirect is not working correctly in urllib2
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24647/urllib2_redirect_fix.patch

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

From report at bugs.python.org  Sun Feb 26 16:19:22 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Feb 2012 15:19:22 +0000
Subject: [New-bugs-announce] [issue14133] improved PEP 409 implementation
Message-ID: <1330269562.83.0.382343969435.issue14133@psf.upfronthosting.co.za>


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

It uses a __suppress_context__ attribute rather than the whole Ellipsis mess.

----------
components: Interpreter Core
files: pep409.patch
keywords: patch
messages: 154358
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: improved PEP 409 implementation
versions: Python 3.3
Added file: http://bugs.python.org/file24648/pep409.patch

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

From report at bugs.python.org  Sun Feb 26 23:19:01 2012
From: report at bugs.python.org (Andrej A Antonov)
Date: Sun, 26 Feb 2012 22:19:01 +0000
Subject: [New-bugs-announce] [issue14134] "xmlrpc.client.ServerProxy()" --
	need for	"timeout"-parameter
Message-ID: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za>


New submission from Andrej A Antonov <polymorphm at gmail.com>:

good day!

"xmlrpc.client.ServerProxy()" -- not has "timeout"-parameter

"xmlrpc.client.Transport()" and "xmlrpc.client.SafeTransport()" -- not has "timeout"-parameter too

but "http.client.HTTPConnection()" and http.client.HTTPSConnection() -- has "timeout"-parameter

----------
components: Library (Lib)
messages: 154409
nosy: polymorphm
priority: normal
severity: normal
status: open
title: "xmlrpc.client.ServerProxy()" --  need for "timeout"-parameter
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Feb 26 23:47:48 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 26 Feb 2012 22:47:48 +0000
Subject: [New-bugs-announce] [issue14135] check for locale changes in
	test.support
Message-ID: <1330296468.42.0.0463135348779.issue14135@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Issue #14113 pointed out that test.support doesn't check if tests mucked with the locale after running.

----------
components: Tests
keywords: easy
messages: 154414
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: check for locale changes in test.support
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 27 03:23:20 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Feb 2012 02:23:20 +0000
Subject: [New-bugs-announce] [issue14136] Simplify PEP 409 command line test
	and move it to	test_cmd_line_script
Message-ID: <1330309400.02.0.0793594491787.issue14136@psf.upfronthosting.co.za>


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

I stuffed up the review on one of the new tests in the PEP 409 patch - the one that checks if the exception context is suppressed correctly from the command line.

That test should be drastically simplified and moved from test_raise to test_cmd_line_script.

----------
assignee: ncoghlan
components: Tests
messages: 154425
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Simplify PEP 409 command line test and move it to test_cmd_line_script
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 27 03:59:59 2012
From: report at bugs.python.org (Narnie Harshoe)
Date: Mon, 27 Feb 2012 02:59:59 +0000
Subject: [New-bugs-announce] [issue14137] GTK3 Segmentation fault from
	Warning: g_object_notify:	assertion `G_IS_OBJECT (object)' failed
Message-ID: <1330311599.64.0.412967212338.issue14137@psf.upfronthosting.co.za>


New submission from Narnie Harshoe <signupnarnie at gmail.com>:

Using the following code for a Gtk.CellRenderSpin results in the following error after changing the spin button several times.

The error is:

/usr/lib/python2.7/dist-packages/gi/types.py:43: Warning: g_object_notify: assertion `G_IS_OBJECT (object)' failed
  return info.invoke(*args, **kwargs)
Segmentation fault

#! /usr/bin/env python
# -*- coding: utf-8 -*-

from gi.repository import Gtk

class CellRendererSpinWindow(Gtk.Window):

    def __init__(self):
        Gtk.Window.__init__(self, title="CellRendererSpin Example")

        self.set_default_size(200, 200)

        self.liststore = Gtk.ListStore(str, int)
        self.liststore.append(["Oranges", 5])
        self.liststore.append(["Apples", 4])
        self.liststore.append(["Bananas", 2])

        treeview = Gtk.TreeView(model=self.liststore)

        renderer_text = Gtk.CellRendererText()
        column_text = Gtk.TreeViewColumn("Fruit", renderer_text, text=0)
        treeview.append_column(column_text)

        renderer_spin = Gtk.CellRendererSpin()
        renderer_spin.connect("edited", self.on_amount_edited)
        renderer_spin.set_property("editable", True)

        adjustment = Gtk.Adjustment(0, 0, 100, 1, 10, 0)
        renderer_spin.set_property("adjustment", adjustment)

        column_spin = Gtk.TreeViewColumn("Amount", renderer_spin, text=1)
        treeview.append_column(column_spin)

        self.add(treeview)

    def on_amount_edited(self, widget, path, value):
        self.liststore[path][1] = int(value)

win = CellRendererSpinWindow()
win.connect("delete-event", Gtk.main_quit)
win.show_all()
Gtk.main()

This code comes from http://python-gtk-3-tutorial.readthedocs.org/en/latest/cellrenderers.html

It is confirmed by another user via Ubuntu launchpad at https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/908889

My system is a Debian system tracking debian testing.

Exact python --version is Python 2.7.2+

----------
components: None
messages: 154426
nosy: Narnie.Harshoe
priority: normal
severity: normal
status: open
title: GTK3 Segmentation fault from Warning: g_object_notify: assertion `G_IS_OBJECT (object)' failed
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 27 04:13:28 2012
From: report at bugs.python.org (Narnie Harshoe)
Date: Mon, 27 Feb 2012 03:13:28 +0000
Subject: [New-bugs-announce] [issue14138] Ctrl-C does not terminate GTK3
	Gtk.main() loop when	program run from command line
Message-ID: <1330312408.32.0.611668312241.issue14138@psf.upfronthosting.co.za>


New submission from Narnie Harshoe <signupnarnie at gmail.com>:

In a normal python program, Ctrl-C will set up a KeyboardInterrupt and terminate the program. This works with a normal python script, including GTK2 gtk.main(), but GTK3 Gtk.main() (even when used in a more robust GTK program that coded below) will not terminate with Ctrl-C requiring a Ctrl-Z and killing the job to terminate. See the commmand line output below:

$ python -c "while True:
>  pass
> "
^CTraceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt


$ python -c "import gtk
> gtk.main()
> "
^CTraceback (most recent call last):
  File "<string>", line 2, in <module>
KeyboardInterrupt


$ python -c "from gi.repository import Gtk
> Gtk.main()
> "
^C
^C
^Z
[1]+  Stopped                 python -c "from gi.repository import Gtk
Gtk.main()
"
$ kill %1

[1]+  Stopped                 python -c "from gi.repository import Gtk
Gtk.main()
"

The behaviour under Gtk.main() should be changed to respond to the KeyboardInterrupt.

----------
components: None
messages: 154427
nosy: Narnie.Harshoe
priority: normal
severity: normal
status: open
title: Ctrl-C does not terminate GTK3 Gtk.main() loop when program run from command line
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb 27 12:14:04 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 11:14:04 +0000
Subject: [New-bugs-announce] [issue14139] test_ftplib: segfault
Message-ID: <1330341244.46.0.956938686476.issue14139@psf.upfronthosting.co.za>


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

Seen on a Windows buildbot:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4223/steps/test/logs/stdio

Fatal Python error: Segmentation fault

Current thread 0x000007e4:
  File "D:\Buildslave\3.x.moore-windows\build\lib\ssl.py", line 476 in unwrap
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_ftplib.py", line 333 in _do_ssl_shutdown
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_ftplib.py", line 394 in close
  File "D:\Buildslave\3.x.moore-windows\build\lib\asyncore.py", line 577 in close_all
  File "../lib/test/regrtest.py", line 1043 in restore_asyncore_socket_map
  File "../lib/test/regrtest.py", line 1188 in __exit__
  File "../lib/test/regrtest.py", line 1225 in runtest_inner
  File "../lib/test/regrtest.py", line 907 in runtest
  File "../lib/test/regrtest.py", line 710 in main
  File "../lib/test/regrtest.py", line 1812 in <module>


Perhaps see also:

http://mail.python.org/pipermail/python-list/2011-May/1272350.html

----------
components: Tests
messages: 154452
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ftplib: segfault
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 27 12:22:10 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Feb 2012 11:22:10 +0000
Subject: [New-bugs-announce] [issue14140] packaging tests: add helpers to
	create and inspect a	tree of files
Message-ID: <1330341730.18.0.549794058583.issue14140@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Many packaging tests use functions like os.mkdir and open to create files in order to test commands or actions, or slightly higher-level helpers like packaging.tests.support.TempdirManager.write_file.

I think this could be much more automated.  There should be an helper function which could accept a string with a custom format describing directories, files and their contents, then create the files in a temp directory and later cleans it all.  Likewise, it should be easier to check what new files are created (i.e. in the build or dist directory) and what their contents are.

My ultimate goal is to move from low-level tests which use command objects directly to higher-level tests which actually run the pysetup script and check the results, so that tests get closer to what people do.  This will also remove cruft in the tests, and let us change details more easily (because we?ll be testing behavior, not internal attributes or exact output).

----------
assignee: eric.araujo
components: Distutils2
messages: 154453
nosy: alexis, eric.araujo, francismb, python-dev, shane.moore, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: packaging tests: add helpers to create and inspect a tree of files
type: enhancement
versions: 3rd party

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

From report at bugs.python.org  Mon Feb 27 17:32:32 2012
From: report at bugs.python.org (Steve McConnel)
Date: Mon, 27 Feb 2012 16:32:32 +0000
Subject: [New-bugs-announce] [issue14141] 2.7.2 64-bit Windows library has
	__impt_Py* for several	symbols instead of __imp__Py*
Message-ID: <1330360352.45.0.311661027338.issue14141@psf.upfronthosting.co.za>


New submission from Steve McConnel <stephen_mcconnel at sil.org>:

The Python27.lib file shipped with the 64-bit Windows installer (.msi) has several symbols with improper values.  The problem appears to be a single underscore instead of a double underscore between __imp and Py in the symbol.  Attempting to build our application which links to Python in Visual Studio 2008, the following symbols are undefined due to this problem:
 __imp__PyCallable_Check
 __imp__PyClass_Type
 __imp__PyDict_GetItemString
 __imp__PyErr_Clear
 __imp__PyErr_Fetch
 __imp__PyErr_Occurred
 __imp__PyImport_ImportModule
 __imp__PyInstance_Type
 __imp__PyModule_GetDict
 __imp__PyObject_CallObject
 __imp__PyRun_SimpleStringFlags
 __imp__PyString_AsString
 __imp__PyString_AsStringAndSize
 __imp__PyString_FromStringAndSize
 __imp__PyString_Type
 __imp__PyTraceBack_Type
 __imp__PyTuple_New
 __imp__PyTuple_SetItem
 __imp__PyType_IsSubtype
 __imp__PyUnicodeUCS2_AsUnicode
 __imp__PyUnicodeUCS2_FromUnicode
 __imp__PyUnicodeUCS2_GetSize
 __imp__Py_DecRef
 __imp__Py_Finalize
 __imp__Py_Initialize

These symbols appear to be properly defined in the 32-bit version.

----------
messages: 154487
nosy: Steve.McConnel
priority: normal
severity: normal
status: open
title: 2.7.2 64-bit Windows library has __impt_Py* for several symbols instead of __imp__Py*

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

From report at bugs.python.org  Mon Feb 27 18:33:14 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Feb 2012 17:33:14 +0000
Subject: [New-bugs-announce] [issue14142] getlocale(LC_ALL) behavior
Message-ID: <1330363994.24.0.841585589979.issue14142@psf.upfronthosting.co.za>


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

This came up in #14113. getlocale(LC_ALL) is documented to fail, at
least that's how I read this:

   "category may be one of the LC_* values except LC_ALL."


But in fact getlocale(LC_ALL) works if there is no semicolon in the
locale name:

>>> getlocale(LC_ALL)
('en_US', 'ISO8859-1')


I would prefer if getlocale(LC_ALL) fails consistently. If that's
not possible, then this is a documentation issue.

----------
messages: 154495
nosy: skrah
priority: normal
severity: normal
status: open
title: getlocale(LC_ALL) behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 27 20:07:40 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 27 Feb 2012 19:07:40 +0000
Subject: [New-bugs-announce] [issue14143] test_ntpath failure on Windows
Message-ID: <1330369660.88.0.127957807148.issue14143@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6075/steps/test/logs/stdio

    FAIL: test_time (test.test_ntpath.NtCommonTest)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_genericpath.py", line 127, in test_time
        self.pathmodule.getmtime(support.TESTFN)
    AssertionError: 1330364192.9002845 not less than or equal to 1330363190.76044

It seems the file's modification time is earlier than its creation time by ~1002s.

----------
components: Tests, Windows
keywords: buildbot
messages: 154503
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ntpath failure on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 27 23:44:09 2012
From: report at bugs.python.org (Jay Deiman)
Date: Mon, 27 Feb 2012 22:44:09 +0000
Subject: [New-bugs-announce] [issue14144] urllib2 HTTPRedirectHandler not
	handling POST data in	redirect
Message-ID: <1330382649.62.0.524230876085.issue14144@psf.upfronthosting.co.za>


New submission from Jay Deiman <admin at splitstreams.com>:

I've noticed that urllib2's HTTPRedirectHandler does not redirect a POST request with the POST data.  

If you send a POST request to a server with data, the data is dropped when the new Request is made to the new url.  As stated in a comment in the library itself, redirecting a POST request is not strictly RFC compliant, but it's generally supported anyway.  The problem here being that our POST data is not also being redirected.  I ran into this issue when writing a web api wrapper in Python.

I'm submitting a small patch that fixes this issue:


--- /usr/lib/python2.7/urllib2.py	2011-10-04 16:07:28.000000000 -0500
+++ urllib2.py	2012-02-27 16:03:36.000000000 -0600
@@ -551,7 +551,11 @@
             newheaders = dict((k,v) for k,v in req.headers.items()
                               if k.lower() not in ("content-length", "content-type")
                              )
+            data = None
+            if req.has_data():
+                data = req.get_data()
             return Request(newurl,
+                           data=data,
                            headers=newheaders,
                            origin_req_host=req.get_origin_req_host(),
                            unverifiable=True)

----------
components: Extension Modules
files: urllib2.py.patch
keywords: patch
messages: 154516
nosy: crustymonkey
priority: normal
severity: normal
status: open
title: urllib2 HTTPRedirectHandler not handling POST data in redirect
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24665/urllib2.py.patch

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

From report at bugs.python.org  Tue Feb 28 04:13:03 2012
From: report at bugs.python.org (Griffin Smith)
Date: Tue, 28 Feb 2012 03:13:03 +0000
Subject: [New-bugs-announce] [issue14145] string.rfind() returns
	AttributeError: 'list' object has	no attribute 'rfind'
Message-ID: <1330398783.39.0.669167719061.issue14145@psf.upfronthosting.co.za>


New submission from Griffin Smith <wildgriffin45 at gmail.com>:

This occurs even when calling methods in modules (such as os.path.splitext), so I know it's not happening due to an error on my part

Win7 SP1

----------
components: Windows
messages: 154529
nosy: glittershark
priority: normal
severity: normal
status: open
title: string.rfind() returns AttributeError: 'list' object has no attribute 'rfind'
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 28 05:01:48 2012
From: report at bugs.python.org (Rich Rauenzahn)
Date: Tue, 28 Feb 2012 04:01:48 +0000
Subject: [New-bugs-announce] [issue14146] IDLE: source line in editor
	doesn't highlight when	debugging
Message-ID: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za>


New submission from Rich Rauenzahn <rrauenza at gmail.com>:

Using 64bit python for windows downloaded from python.org on 64bit windows 7.

Python Version 3.2.2
Tk version 8.5
IDLE version 3.2.2

When stepping through code the corresponding line in the editor does not highlight with the code steps.  The windows does update the contents, so it appears to be tracking, but just fails to highlight the line.

Double clicking on the line in the debugger will go ahead and highlight it.  My settings are all default, and I've double checked the color schemes in the "highlighting" dialog.

----------
components: IDLE
messages: 154533
nosy: Rich.Rauenzahn
priority: normal
severity: normal
status: open
title: IDLE: source line in editor doesn't highlight when debugging
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb 28 09:47:30 2012
From: report at bugs.python.org (lilei)
Date: Tue, 28 Feb 2012 08:47:30 +0000
Subject: [New-bugs-announce] [issue14147] print r"\" cause SyntaxError
Message-ID: <1330418850.42.0.159103996414.issue14147@psf.upfronthosting.co.za>


New submission from lilei <vbem at 163.com>:

$ python
Python 2.7.1 (r271:86832, Apr 16 2011, 23:27:12) 
[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print r'\'
  File "<stdin>", line 1
    print r'\'
             ^
SyntaxError: EOL while scanning string literal
>>> 

I just want to print a raw string r'\', however, SyntaxError.
What is the reason?

----------
components: None
messages: 154538
nosy: vbem
priority: normal
severity: normal
status: open
title: print r"\" cause SyntaxError
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 28 12:43:00 2012
From: report at bugs.python.org (Paul Moore)
Date: Tue, 28 Feb 2012 11:43:00 +0000
Subject: [New-bugs-announce] [issue14148] Option to kill "stuck" workers in
	a multiprocessing pool
Message-ID: <1330429380.32.0.0524478586738.issue14148@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

I have an application which fires off a number of database connections via a multiprocessing pool. Unfortunately, the database software occasionally gets "stuck" and a connection request hangs indefinitely. This locks up the whole process doing the connection, and cannot be interrupted except by killing the process.

It would be useful to have a facility to restart "stuck" workers in this case.

As an interface, I would suggest an additional argument to the AsyncResult.get method, kill_on_timeout. If this argument is true, and the get times out, the worker servicing the result will be killed and restarted.

Alternatively, provide a method on an AsyncResult to access the worker process that is servicing the request. I could then wait on the result and kill the worker manually if it does not respond in time.

Without a facility like this, there is a potential for the pool to get starved of workers if multiple connections hang.

----------
components: Library (Lib)
messages: 154549
nosy: pmoore
priority: normal
severity: normal
status: open
title: Option to kill "stuck" workers in a multiprocessing pool
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb 28 13:23:55 2012
From: report at bugs.python.org (Joseph Birr-Pixton)
Date: Tue, 28 Feb 2012 12:23:55 +0000
Subject: [New-bugs-announce] [issue14149] Argparse usage model requires
	argument names to be	python identifiers
Message-ID: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>


New submission from Joseph Birr-Pixton <jpixton at gmail.com>:

Say I have an argument with the name 'foo-bar'.  Argparse accepts and parses arguments, but Namespace does not allow me to access the value.

Yes, I can use getattr or Namespace.__dict__.  But that's ugly.
Yes, I can change the name of the argument, but that's not what I want in my help output.

I think it should either:
- Collapse names to valid python identifiers (optparse did this).
- Namespace should act like an object and dict.

----------
components: Library (Lib)
files: argparsetest.py
messages: 154550
nosy: Joseph.Birr-Pixton
priority: normal
severity: normal
status: open
title: Argparse usage model requires argument names to be python identifiers
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file24669/argparsetest.py

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

From report at bugs.python.org  Tue Feb 28 14:06:09 2012
From: report at bugs.python.org (=?utf-8?q?Jan_St=C3=BCrtz?=)
Date: Tue, 28 Feb 2012 13:06:09 +0000
Subject: [New-bugs-announce] [issue14150] AIX,
	crash loading shared module into another process than python
	like	operator.so results in 0509-130
Message-ID: <1330434369.23.0.116359457055.issue14150@psf.upfronthosting.co.za>


New submission from Jan St?rtz <stuertz at googlemail.com>:

AIX 5.2.0.0 with gcc 4.3.0:
Compiling a shared python:
with:
./configure --enable-shared --with-gcc --disable-ipv6 --with-system-ffi
make; make install

results in a working build.
But when I build mod_wsgi into apache with this python and run it I get the follwoing exception when importing e.g. cgi.

Traceback (most recent call last):
  File "/devel/js/src/trunk/cdb/wsgi/static.py", line 256, in application
    status, response_headers, output = resources(environ, path_info[1:])
  File "/devel/js/src/trunk/cdb/wsgi/static.py", line 238, in resources
    "/".join(path_info[1:]), (os.environ["CADDOK_BASE"], os.environ["CADDOK_HOME"]))
  File "/devel/js/src/trunk/cdb/wsgi/static.py", line 105, in _find_file
    import cgi
  File "/devel/js/src/trunk/aix5/debug/img/lib/python2.7/cgi.py", line 37, in 
    from operator import attrgetter
ImportError: 	0509-130 Die Symbolaufl?sung f?r /devel/js/src/trunk/aix5/debug/img/lib/python2.7/lib-dynload/operator.so ist fehlgeschlagen. Ursache:
	0509-136   Symbol _PyArg_NoKeywords (Nummer 1) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyArg_ParseTuple (Nummer 2) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyArg_UnpackTuple (Nummer 3) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyBool_FromLong (Nummer 4) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyCallable_Check (Nummer 5) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-136   Symbol PyErr_SetString (Nummer 6) wurde nicht von
		   abh?ngigem Modul httpd exportiert.
	0509-021 Es sind noch weitere Fehler aufgetreten, die aber nicht gemeldet wurden.
	0509-192 ?berpr?fen Sie die Symbole des Abschnitts .loader mit dem
		 Befehl 'dump -Tv'.

I stripped that problem down to a somewhat incorrect python.exp file for the linker.
Tis python.exp file is used as import file to the aix linker when linking the modules in lib-dynload.

So operator.so expects its Symbols like "_PyArg_NoKeywords" to appear in the main executable.

Looking with "dump -HTv" on operator.so results in:
dump -HTv lib/python2.7/lib-dynload/operator.so 

lib/python2.7/lib-dynload/operator.so:

                        ***Abschnitt f?r Ladeprogramm***
                      Header-Daten zum Ladeprogramm
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000060       0x000002c4       0x00000208       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000004       0x00002a50       0x00000700       0x00002c58       


                        ***Dateizeichenfolgen importieren***
INDEX  PFAD                          BASIS               MEMBER              
0      /devel/js/trunk_E017100_python27/aix5/debug/img/lib:/usr/local/lib:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/pthread:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../../pthread:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../../../powerpc-ibm-aix5.2.0.0/lib:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../..:/usr/lib:/lib                                         
1                                    libpthreads.a       shr_xpg5.o          
2                                    libc.a              shr.o               
3                                    .                                       

                        ***Informationen zur Symboltabelle des Ladeprogramms***
[Index]      Wert       Scn     IMEX Sclass   Typ            IMPid Name

[0]     0x20002338    .data              RW SECdef        [noIMid] __rtinit
[1]     0x00000000    undef      IMP     DS EXTref               . _PyArg_NoKeywords
[2]     0x00000000    undef      IMP     DS EXTref               . PyArg_ParseTuple
[3]     0x00000000    undef      IMP     DS EXTref               . PyArg_UnpackTuple
[4]     0x00000000    undef      IMP     DS EXTref               . PyBool_FromLong
[5]     0x00000000    undef      IMP     DS EXTref               . PyCallable_Check
[6]     0x00000000    undef      IMP     DS EXTref               . PyErr_SetString
[7]     0x00000000    undef      IMP     DS EXTref               . PyErr_WarnEx
[8]     0x00000000    undef      IMP     PR EXTref               . PyExc_DeprecationWarning
[9]     0x00000000    undef      IMP     PR EXTref               . PyExc_TypeError
[10]    0x00000000    undef      IMP     DS EXTref               . Py_InitModule4
[11]    0x00000000    undef      IMP     DS EXTref               . PyInt_FromSsize_t
[12]    0x00000000    undef      IMP     DS EXTref               . PyMapping_Check
[13]    0x00000000    undef      IMP     DS EXTref               . PyModule_AddObject
[14]    0x00000000    undef      IMP     PR EXTref               . _Py_NoneStruct
[15]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Absolute
[16]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Add
[17]    0x00000000    undef      IMP     DS EXTref               . PyNumber_And
[18]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Check
[19]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Divide
[20]    0x00000000    undef      IMP     DS EXTref               . PyNumber_FloorDivide
[21]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Index
[22]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceAdd
[23]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceAnd
[24]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceDivide
[25]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceFloorDivide
[26]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceLshift
[27]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceMultiply
[28]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceOr
[29]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlacePower
[30]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceRemainder
[31]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceRshift
[32]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceSubtract
[33]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceTrueDivide
[34]    0x00000000    undef      IMP     DS EXTref               . PyNumber_InPlaceXor
[35]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Invert
[36]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Lshift
[37]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Multiply
[38]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Negative
[39]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Or
[40]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Positive
[41]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Power
[42]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Remainder
[43]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Rshift
[44]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Subtract
[45]    0x00000000    undef      IMP     DS EXTref               . PyNumber_TrueDivide
[46]    0x00000000    undef      IMP     DS EXTref               . PyNumber_Xor
[47]    0x00000000    undef      IMP     DS EXTref               . PyObject_Call
[48]    0x00000000    undef      IMP     DS EXTref               . PyObject_DelItem
[49]    0x00000000    undef      IMP     DS EXTref               . PyObject_GC_Del
[50]    0x00000000    undef      IMP     DS EXTref               . _PyObject_GC_New
[51]    0x00000000    undef      IMP     DS EXTref               . PyObject_GC_Track
[52]    0x00000000    undef      IMP     DS EXTref               . PyObject_GC_UnTrack
[53]    0x00000000    undef      IMP     PR EXTref               . PyObject_GenericGetAttr
[54]    0x00000000    undef      IMP     DS EXTref               . PyObject_GetAttr
[55]    0x00000000    undef      IMP     DS EXTref               . PyObject_GetItem
[56]    0x00000000    undef      IMP     DS EXTref               . PyObject_IsTrue
[57]    0x00000000    undef      IMP     DS EXTref               . PyObject_Not
[58]    0x00000000    undef      IMP     DS EXTref               . PyObject_RichCompare
[59]    0x00000000    undef      IMP     DS EXTref               . PyObject_SetItem
[60]    0x00000000    undef      IMP     PR EXTref               . Py_Py3kWarningFlag
[61]    0x00000000    undef      IMP     DS EXTref               . PySequence_Check
[62]    0x00000000    undef      IMP     DS EXTref               . PySequence_Concat
[63]    0x00000000    undef      IMP     DS EXTref               . PySequence_Contains
[64]    0x00000000    undef      IMP     DS EXTref               . PySequence_Count
[65]    0x00000000    undef      IMP     DS EXTref               . PySequence_DelSlice
[66]    0x00000000    undef      IMP     DS EXTref               . PySequence_GetSlice
[67]    0x00000000    undef      IMP     DS EXTref               . PySequence_Index
[68]    0x00000000    undef      IMP     DS EXTref               . PySequence_InPlaceConcat
[69]    0x00000000    undef      IMP     DS EXTref               . PySequence_InPlaceRepeat
[70]    0x00000000    undef      IMP     DS EXTref               . PySequence_Repeat
[71]    0x00000000    undef      IMP     DS EXTref               . PySequence_SetSlice
[72]    0x00000000    undef      IMP     DS EXTref               . PyString_FromString
[73]    0x00000000    undef      IMP     DS EXTref               . PyString_FromStringAndSize
[74]    0x00000000    undef      IMP     PR EXTref               . _Py_TrueStruct
[75]    0x00000000    undef      IMP     DS EXTref               . PyTuple_GetSlice
[76]    0x00000000    undef      IMP     DS EXTref               . PyTuple_New
[77]    0x00000000    undef      IMP     DS EXTref               . PyType_Ready
[78]    0x00000000    undef      IMP     DS EXTref               . _PyUnicodeUCS2_AsDefaultEncodedString
[79]    0x00000000    undef      IMP     PR EXTref               . _Py_ZeroStruct
[80]    0x0000e008    undef      IMP     XO EXTref   libc.a(shr.o) ___memset
[81]    0x0000f000    undef      IMP     XO EXTref   libc.a(shr.o) ___memmove
[82]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) malloc
[83]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) realloc
[84]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) free
[85]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) calloc
[86]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) strlen
[87]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) strchr
[88]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) abort
[89]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_getspecific
[90]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_setspecific
[91]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_key_create
[92]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_once
[93]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_mutex_unlock
[94]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_mutex_lock
[95]    0x200023a8    .data EXPentPT     DS   Ldef        [noIMid] initoperator

But when I change the python Makefile right after configure, so that 
the first line of the python.exp (The !# line) looks this way:

old:
#!.
new:
#!libpython2.7.so

and rebuild every thing it works fine to me, because symbol resolution is fixed to use libpython.so.

So dump -HVtt looks that way:
-bash-2.05b$ dump -HTv lib/python2.7/lib-dynload/operator.so 

lib/python2.7/lib-dynload/operator.so:

                        ***Abschnitt f?r Ladeprogramm***
                      Header-Daten zum Ladeprogramm
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000060       0x000002c4       0x00000216       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000004       0x00002a50       0x00000700       0x00002c66       


                        ***Dateizeichenfolgen importieren***
INDEX  PFAD                          BASIS               MEMBER              
0      /devel/js/trunk_E017100_python27/aix5/debug/img/lib:/usr/local/lib:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/pthread:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../../pthread:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../../../powerpc-ibm-aix5.2.0.0/lib:/usr/local/contact/sdk/1.1/lib/gcc/powerpc-ibm-aix5.2.0.0/4.3.0/../../..:/usr/lib:/lib                                         
1                                    libpthreads.a       shr_xpg5.o          
2                                    libc.a              shr.o               
3                                    libpython2.7.so                         

                        ***Informationen zur Symboltabelle des Ladeprogramms***
[Index]      Wert       Scn     IMEX Sclass   Typ            IMPid Name

[0]     0x20002338    .data              RW SECdef        [noIMid] __rtinit
[1]     0x00000000    undef      IMP     DS EXTref libpython2.7.so _PyArg_NoKeywords
[2]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyArg_ParseTuple
[3]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyArg_UnpackTuple
[4]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyBool_FromLong
[5]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyCallable_Check
[6]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyErr_SetString
[7]     0x00000000    undef      IMP     DS EXTref libpython2.7.so PyErr_WarnEx
[8]     0x00000000    undef      IMP     PR EXTref libpython2.7.so PyExc_DeprecationWarning
[9]     0x00000000    undef      IMP     PR EXTref libpython2.7.so PyExc_TypeError
[10]    0x00000000    undef      IMP     DS EXTref libpython2.7.so Py_InitModule4
[11]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyInt_FromSsize_t
[12]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyMapping_Check
[13]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyModule_AddObject
[14]    0x00000000    undef      IMP     PR EXTref libpython2.7.so _Py_NoneStruct
[15]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Absolute
[16]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Add
[17]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_And
[18]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Check
[19]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Divide
[20]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_FloorDivide
[21]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Index
[22]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceAdd
[23]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceAnd
[24]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceDivide
[25]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceFloorDivide
[26]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceLshift
[27]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceMultiply
[28]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceOr
[29]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlacePower
[30]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceRemainder
[31]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceRshift
[32]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceSubtract
[33]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceTrueDivide
[34]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_InPlaceXor
[35]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Invert
[36]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Lshift
[37]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Multiply
[38]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Negative
[39]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Or
[40]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Positive
[41]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Power
[42]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Remainder
[43]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Rshift
[44]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Subtract
[45]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_TrueDivide
[46]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyNumber_Xor
[47]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_Call
[48]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_DelItem
[49]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GC_Del
[50]    0x00000000    undef      IMP     DS EXTref libpython2.7.so _PyObject_GC_New
[51]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GC_Track
[52]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GC_UnTrack
[53]    0x00000000    undef      IMP     PR EXTref libpython2.7.so PyObject_GenericGetAttr
[54]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GetAttr
[55]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_GetItem
[56]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_IsTrue
[57]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_Not
[58]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_RichCompare
[59]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyObject_SetItem
[60]    0x00000000    undef      IMP     PR EXTref libpython2.7.so Py_Py3kWarningFlag
[61]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Check
[62]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Concat
[63]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Contains
[64]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Count
[65]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_DelSlice
[66]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_GetSlice
[67]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Index
[68]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_InPlaceConcat
[69]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_InPlaceRepeat
[70]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_Repeat
[71]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PySequence_SetSlice
[72]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyString_FromString
[73]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyString_FromStringAndSize
[74]    0x00000000    undef      IMP     PR EXTref libpython2.7.so _Py_TrueStruct
[75]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyTuple_GetSlice
[76]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyTuple_New
[77]    0x00000000    undef      IMP     DS EXTref libpython2.7.so PyType_Ready
[78]    0x00000000    undef      IMP     DS EXTref libpython2.7.so _PyUnicodeUCS2_AsDefaultEncodedString
[79]    0x00000000    undef      IMP     PR EXTref libpython2.7.so _Py_ZeroStruct
[80]    0x0000e008    undef      IMP     XO EXTref   libc.a(shr.o) ___memset
[81]    0x0000f000    undef      IMP     XO EXTref   libc.a(shr.o) ___memmove
[82]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) malloc
[83]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) realloc
[84]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) free
[85]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) calloc
[86]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) strlen
[87]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) strchr
[88]    0x00000000    undef      IMP     DS EXTref   libc.a(shr.o) abort
[89]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_getspecific
[90]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_setspecific
[91]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_key_create
[92]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_once
[93]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_mutex_unlock
[94]    0x00000000    undef      IMP     DS EXTref libpthreads.a(shr_xpg5.o) pthread_mutex_lock
[95]    0x200023a8    .data EXPentPT     DS   Ldef        [noIMid] initoperator

But now im usnure how to implement this into the configure script and to provide a valid general patch for this.

----------
components: Build, Library (Lib)
messages: 154551
nosy: Jan.St?rtz
priority: normal
severity: normal
status: open
title: AIX, crash loading shared module into another process than python like operator.so results in 0509-130
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 28 14:51:38 2012
From: report at bugs.python.org (Popa Claudiu)
Date: Tue, 28 Feb 2012 13:51:38 +0000
Subject: [New-bugs-announce] [issue14151]
	multiprocessing.connection.Listener fails with invalid	address
Message-ID: <1330437098.57.0.315162934772.issue14151@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

In multiprocessing.connection, when using a Windows named pipe on a Unix platform, the following error will occur. This should not happen, the format of the address should be validated somehow before. The following error will occur because PipeListener is not defined under any platform different than win32. 

Python 3.2.2 (default, Oct 14 2011, 21:46:49)
[GCC 4.2.2 20070831 prerelease [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing.connection import Listener
>>> Listener(r'\\.\test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/multiprocessing/connection.py", line 130, in __init__
    self._listener = PipeListener(address, backlog)
NameError: global name 'PipeListener' is not defined
>>>


I've attached a small patch for this issue.

----------
components: Library (Lib)
files: connection.patch
keywords: patch
messages: 154552
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: multiprocessing.connection.Listener fails with invalid address
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file24671/connection.patch

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

From report at bugs.python.org  Tue Feb 28 18:00:07 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 28 Feb 2012 17:00:07 +0000
Subject: [New-bugs-announce] [issue14152] arraymodule: structmember.h
	dependency
Message-ID: <1330448407.18.0.666571284408.issue14152@psf.upfronthosting.co.za>


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

The arraymodule depends on "structmember.h". Patch attached.

----------
components: Build
files: arraymodule_deps.diff
keywords: patch
messages: 154556
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: arraymodule: structmember.h dependency
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file24673/arraymodule_deps.diff

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

From report at bugs.python.org  Tue Feb 28 18:03:50 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Feb 2012 17:03:50 +0000
Subject: [New-bugs-announce] [issue14153] Expose os.device_encoding() at the
	C level
Message-ID: <1330448630.79.0.296713458855.issue14153@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The _io module imports the os module purely for the use of os.device_encoding(). That function, though, is defined by posix and thus is already available to C code. To avoid this import dependency it would be better to simply expose the function somehow so that _io can just directly call the function.

Antoine has suggested Python/fileutils.c as a possible place, although I'm personally happy simply exposing the function from posix and making it a METH_O function so that as little code needs to change for _io to use it.

----------
components: Library (Lib)
messages: 154557
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose os.device_encoding() at the C level
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb 28 21:13:09 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 28 Feb 2012 20:13:09 +0000
Subject: [New-bugs-announce] [issue14154] reimplement the bigmem test memory
	watchdog as a	subprocess
Message-ID: <1330459989.98.0.769260493369.issue14154@psf.upfronthosting.co.za>


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

As suggested in http://bugs.python.org/msg154330, here's a rewrite of the test memory watchdog using subprocess instead of thread + faulthandler.

----------
components: Tests
files: mem_watchdog_subprocess.diff
keywords: needs review, patch
messages: 154570
nosy: neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: reimplement the bigmem test memory watchdog as a subprocess
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24674/mem_watchdog_subprocess.diff

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

From report at bugs.python.org  Wed Feb 29 03:12:20 2012
From: report at bugs.python.org (py.user)
Date: Wed, 29 Feb 2012 02:12:20 +0000
Subject: [New-bugs-announce] [issue14155] Deja vu in re's documentation
Message-ID: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>


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

This paragraph is redundant
http://docs.python.org/py3k/library/re.html#matching-vs-searching

a duplicate
http://docs.python.org/py3k/library/re.html#search-vs-match


the part about match() behavior in multiline mode could be described in note here:
http://docs.python.org/py3k/library/re.html#re.regex.match

----------
assignee: docs at python
components: Documentation
messages: 154592
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: Deja vu in re's documentation
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 29 12:01:11 2012
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 29 Feb 2012 11:01:11 +0000
Subject: [New-bugs-announce] [issue14156] argparse.FileType for '-' doesn't
	work for a mode of 'rb'
Message-ID: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>


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

If an argument of '-' is handled by argparse.FileType, it defaults to sys.stdin. However a mode of 'rb' is ignored, the returned file object does not work with raw bytes.

----------
components: Library (Lib)
messages: 154612
nosy: anacrolix
priority: normal
severity: normal
status: open
title: argparse.FileType for '-' doesn't work for a mode of 'rb'
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb 29 12:57:48 2012
From: report at bugs.python.org (Martin Morrison)
Date: Wed, 29 Feb 2012 11:57:48 +0000
Subject: [New-bugs-announce] [issue14157] time.strptime without a year fails
	on Feb 29
Message-ID: <1330516668.55.0.549591415618.issue14157@psf.upfronthosting.co.za>


New submission from Martin Morrison <martin.morrison at gmail.com>:

time.strptime without a year fails on Feb 29 with:

>>> time.strptime("Feb 29", "%b %d")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 454, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/usr/lib/python2.6/_strptime.py", line 440, in _strptime
    datetime_date(year, 1, 1).toordinal() + 1
ValueError: day is out of range for month

This is due to the use of "1900" as the default year when parsing. It would be nice to have an optional "defaults" keyword argument to the strptime function that can be used to override the defaults, thus allowing leap year dates to be parsed without specifying the date.

(Note: the code in question attempted to set the year *after* the parse so that ultimately there is a valid struct_time, but since the parse never succeeds, this can't work).

----------
components: Library (Lib)
messages: 154621
nosy: Martin.Morrison
priority: normal
severity: normal
status: open
title: time.strptime without a year fails on Feb 29
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 29 14:56:22 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 29 Feb 2012 13:56:22 +0000
Subject: [New-bugs-announce] [issue14158] test_mailbox fails if file or dir
	named by	support.TESTFN exists
Message-ID: <1330523782.18.0.210760102045.issue14158@psf.upfronthosting.co.za>


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

test_mailbox fails if another failed test leaves a file or directory with the name given by support.TESTFN. The attached patch rectifies this, and also uses existing stdlib functionality (shutil.rmtree) to remove a directory tree recursively on tearDown.

----------
components: Library (Lib)
files: test_mailbox.diff
keywords: patch
messages: 154630
nosy: petri.lehtinen, r.david.murray, vinay.sajip
priority: normal
severity: normal
status: open
title: test_mailbox fails if file or dir named by support.TESTFN exists
versions: Python 3.3
Added file: http://bugs.python.org/file24679/test_mailbox.diff

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

From report at bugs.python.org  Wed Feb 29 15:55:23 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 29 Feb 2012 14:55:23 +0000
Subject: [New-bugs-announce] [issue14159] __len__ method of weakset
Message-ID: <1330527323.97.0.52214771843.issue14159@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

WeakSet has a bug in its '__len__' method, where it performs iteration though 'self.data' without ensuring _IterationGuard.

This leads to some hard to catch errors with the following traceback:


  builtins.RuntimeError: Set changed size during iteration

    File /usr/lib64/python3.2/_weakrefset.py, line 66, in __len__
        return sum(x() is not None for x in self.data)
    File /usr/lib64/python3.2/_weakrefset.py, line 66, in <genexpr>
        return sum(x() is not None for x in self.data)

----------
components: Library (Lib)
files: weakset_len.patch
keywords: patch
messages: 154636
nosy: Yury.Selivanov, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: __len__ method of weakset
type: crash
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24681/weakset_len.patch

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

From report at bugs.python.org  Wed Feb 29 16:51:00 2012
From: report at bugs.python.org (Matthew Miller)
Date: Wed, 29 Feb 2012 15:51:00 +0000
Subject: [New-bugs-announce] [issue14160] Tarfile.extractfile fails to
	extract targets of	top-level relative symlinks
Message-ID: <1330530660.51.0.926091322087.issue14160@psf.upfronthosting.co.za>


New submission from Matthew Miller <mattdm at mattdm.org>:

I have a tarfile with relative paths. The tail of tar tvf looks like this:

-rw-r--r-T nobody/nobody  1356 2012-02-28 19:25 s/772
-rw-r--r-- nobody/nobody  1304 2012-02-28 19:25 s/773
-rw-r--r-- nobody/nobody  1304 2012-02-28 19:25 s/774
-rw-r--r-- nobody/nobody  1304 2012-02-28 19:25 s/775
lrw-r--r-- nobody/nobody     0 2012-02-28 19:25 final -> s/772

The docs say:

  TarFile.extractfile(member)

    Extract a member from the archive as a file object. member 
    may be a filename or a TarInfo object. If member is a regular
    file, a file-like object is returned. If member is a link, a 
    file-like object is constructed from the link?s target.

However, what I'm getting is this:

  KeyError: "linkname '/s/772' not found"


It's appending a "/". Why?

Well, in tarfile.py:

        if tarinfo.issym():
            # Always search the entire archive.
            linkname = os.path.dirname(tarinfo.name) + "/" + tarinfo.linkname
            limit = None


Here,  os.path.dirname(tarinfo.name) returns '', and then the "/" is appended, giving an incorrect result.

One solution would be:

   linkname = os.path.join(os.path.dirname(tarinfo.name),tarinfo.linkname)

but I don't think that works on platforms where os.sep is not "/", since tar will want "/" in any case. But that's the correct logic.

I'm filing this against 2.7, but the same issue exists in 3.2.

A work-around in end-user code is to call Tarfile.getmember(filename), check if the result issym(), and replace the result with Tarfile.getmember(tarinfo.linkname). But since the extractfile function is documented as following symlinks, that should not be necessary.

This bug isn't commonly encountered because by convention tarfiles usually contain a subdirectory and everything goes in that. But we should do the right thing.

----------
components: Library (Lib)
messages: 154643
nosy: Matthew.Miller
priority: normal
severity: normal
status: open
title: Tarfile.extractfile fails to extract targets of top-level relative symlinks
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 29 17:43:30 2012
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 29 Feb 2012 16:43:30 +0000
Subject: [New-bugs-announce] [issue14161] python2 file __repr__ does not
	escape filename
Message-ID: <1330533810.56.0.673512322833.issue14161@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

behaviour:
>>> name = 'woo\raa'
>>> open(name, 'w')
aa', mode 'w' at 0x295a8a0>

expected:
>>> name = 'woo\raa'
>>> open(name, 'w')
<open file 'woo\raa', mode 'w' at 0x295a8a0>

note:
don't ask why i tried this chunk of code in the first place

----------
messages: 154649
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: python2 file __repr__ does not escape filename
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Feb 29 19:05:04 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Feb 2012 18:05:04 +0000
Subject: [New-bugs-announce] [issue14162] Implementation of the PEP 416 (Add
	a builtin frozendict	type)
Message-ID: <1330538704.6.0.815931694291.issue14162@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Patch to implement the PEP 416.

----------
components: Interpreter Core
files: frozendict.patch
keywords: patch
messages: 154655
nosy: haypo
priority: normal
severity: normal
status: open
title: Implementation of the PEP 416 (Add a builtin frozendict type)
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file24684/frozendict.patch

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