From report at bugs.python.org  Tue Nov  1 09:55:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 01 Nov 2011 08:55:54 +0000
Subject: [New-bugs-announce] [issue13308] fix test_httpservers failures when
	run as root
Message-ID: <1320137754.01.0.106611498358.issue13308@psf.upfronthosting.co.za>


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

Here's a patch fixing test_httpservers failures when run as root (a couple buildbots are consistently failing on this, e.g. http://python.org/dev/buildbot/all/builders/x86 FreeBSD 7.2 3.x/builds/2282/steps/test/logs/stdio).
The test is failing for two reasons:
1) test_get does a chmod(0) on a directory, and checks that the server returns an error when requesting a file under this directory: unfortunately, filesystem permissions are ignored by root
2) CGI tests fail because they try to execute CGI scripts, created in a temporary directory: unfortunately, the temp directory is created as root with mkdtemp() (mode == 0700), and the http server changes to user "nobody" before running the scripts => EACCES

----------
components: Tests
files: test_httpserver_root.diff
keywords: needs review, patch
messages: 146762
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: fix test_httpservers failures when run as root
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23578/test_httpserver_root.diff

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

From report at bugs.python.org  Tue Nov  1 15:05:04 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 14:05:04 +0000
Subject: [New-bugs-announce] [issue13309] test_time fails: time data 'LMT'
	does not match format	'%Z'
Message-ID: <1320156304.27.0.1872899991.issue13309@psf.upfronthosting.co.za>


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

After changeset 55a3b563f0db the Gentoo buildbot is complaining.


======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 159, in test_strptime
    time.strptime(strf_output, format)
ValueError: time data 'LMT' does not match format '%Z'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 162, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with 'LMT' input.

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

----------
components: Tests
keywords: buildbot
messages: 146776
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: test_time fails: time data 'LMT' does not match format '%Z'
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  1 17:04:40 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 01 Nov 2011 16:04:40 +0000
Subject: [New-bugs-announce] [issue13310] asyncore handling of out-of-band
	data fails
Message-ID: <1320163480.19.0.535971932001.issue13310@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Add the following lines to test_handle_expt (this makes sense, a
dispatcher instance is supposed to implement handle_read and call recv
in order to detect that the remote end has closed the socket):

--- a/Lib/test/test_asyncore.py
+++ b/Lib/test/test_asyncore.py
@@ -677,6 +677,9 @@
             def handle_expt(self):
                 self.flag = True
 
+            def handle_read(self):
+                self.recv(1)
+
         class TestHandler(BaseTestHandler):
             def __init__(self, conn):
                 BaseTestHandler.__init__(self, conn)

With these lines added, the test now fails on linux with Python 3.3,
see the following backtrace: select (an poll) returns a read event and
an exceptional condition for the socket, but there is no normal data
to read, only out-of-band data.

The attached patch fixes the problem.


======================================================================
ERROR: test_handle_expt (test.test_asyncore.TestAPI_UseIPv4Poll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 690, in test_handle_expt
    self.loop_waiting_for_flag(client)
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 523, in loop_waiting_for_flag
    asyncore.loop(timeout=0.01, count=1, use_poll=self.use_poll)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 215, in loop
    poll_fun(timeout, map)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 196, in poll2
    readwrite(obj, flags)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 117, in readwrite
    obj.handle_error()
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 108, in readwrite
    obj.handle_read_event()
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 439, in handle_read_event
    self.handle_read()
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 681, in handle_read
    self.recv(1)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 379, in recv
    data = self.socket.recv(buffer_size)
BlockingIOError: [Errno 11] Resource temporarily unavailable

----------
components: Library (Lib)
files: handle_expt.diff
keywords: patch
messages: 146783
nosy: xdegaye
priority: normal
severity: normal
status: open
title: asyncore handling of out-of-band data fails
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23580/handle_expt.diff

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

From report at bugs.python.org  Tue Nov  1 17:08:30 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 01 Nov 2011 16:08:30 +0000
Subject: [New-bugs-announce] [issue13311] asyncore handle_read should call
	recv
Message-ID: <1320163710.5.0.667995234807.issue13311@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When the remote end disconnects, handle_close is only called if recv
is called (from handle_read). The default implementation of
handle_read does not call recv.

Not having the default implementation of handle_read call recv, has
the following drawbacks:

    an implementation of a subclass of dispatcher that only sends
    data, a logger for example, may believe that it does not have to
    implement handle_read since it does not expect any data and since
    there is no hint in the code or in the documentation that it
    should

    test_handle_expt currently succeeds when it should fail since the
    current handling of out-of-band data is broken (see issue 13310),
    but if the default implementation of handle_read had called recv,
    then test_handle_expt would have failed, allowing to detect the
    problem

The attached patch adds a call to recv in handle_read, updates the
documentation and adds a test case.

Note that when this patch is applied, test_handle_expt fails
as expected, issue 13310 should be fixed first.

----------
components: Library (Lib)
files: handle_read.diff
keywords: patch
messages: 146785
nosy: xdegaye
priority: normal
severity: normal
status: open
title: asyncore handle_read should call recv
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file23581/handle_read.diff

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

From report at bugs.python.org  Tue Nov  1 17:52:39 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 16:52:39 +0000
Subject: [New-bugs-announce] [issue13312] test_time fails: strftime('%Y',
	y) for negative year
Message-ID: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>


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

On builder "AMD64 FreeBSD 8.2 3.x" for the TIME_MINYEAR:


======================================================================
FAIL: test_negative (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 397, in test_negative
    return super().test_negative()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py", line 425, in test_negative
    self.assertEqual(self.yearstr(TIME_MINYEAR), str(TIME_MINYEAR))
AssertionError: '2147483648' != '-2147483648'
- 2147483648
+ -2147483648
? +

----------
components: Library (Lib)
keywords: buildbot
messages: 146793
nosy: belopolsky, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: test_time fails: strftime('%Y', y) for negative year
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  1 17:56:43 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 01 Nov 2011 16:56:43 +0000
Subject: [New-bugs-announce] [issue13313] test_time fails: tzset() do not
	change timezone
Message-ID: <1320166603.97.0.58939508903.issue13313@psf.upfronthosting.co.za>


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

On builder "x86 FreeBSD 7.2 3.x" :

======================================================================
FAIL: test_tzset (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_time.py", line 246, in test_tzset
    self.assertTrue(time.tzname[0] == 'AEST', str(time.tzname[0]))
AssertionError: False is not true : EST


(See also issue #13309 for tzname on Gentoo)

----------
components: Library (Lib)
keywords: buildbot
messages: 146794
nosy: belopolsky, flox
priority: normal
severity: normal
stage: test needed
status: open
title: test_time fails: tzset() do not change timezone
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  1 19:02:27 2011
From: report at bugs.python.org (Rob Bairos)
Date: Tue, 01 Nov 2011 18:02:27 +0000
Subject: [New-bugs-announce] [issue13314] ImportError ImportError: Import by
	filename, should be deferred until sys.meta_path hooks are processed
Message-ID: <1320170547.3.0.447612016778.issue13314@psf.upfronthosting.co.za>


New submission from Rob Bairos <rbairos at gmail.com>:

When adding hooks to sys.meta_path, to correctly deal with arbitrarily named non-disk module definitions, module names with slashes should still be processed.

As it stands when executing statements such as:

import my_module_123#/123
or
even
__import__('my_module_123#/123')

the following exception is raised:

ImportError: Import by filename is not supported.

This stops sys.meta_path from handling arbitrarily named modules.

Shouldn't the ImportError be raised *after* the meta_path processing, at which point, its safe to assume the name is a disk name, in which case slashes are relevant?

----------
components: Interpreter Core
messages: 146799
nosy: Rob.Bairos
priority: normal
severity: normal
status: open
title: ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  1 19:17:21 2011
From: report at bugs.python.org (Dave Flogeras)
Date: Tue, 01 Nov 2011 18:17:21 +0000
Subject: [New-bugs-announce] [issue13315] Unable to deal with large tarfile
Message-ID: <1320171441.51.0.618008041157.issue13315@psf.upfronthosting.co.za>


New submission from Dave Flogeras <dflogeras2 at gmail.com>:

I am trying to unpack boost_1_46_1.tar.bz2 (you can grab it here http://mirror.its.dal.ca/gentoo/distfiles/boost_1_46_1.tar.bz2) with the following code:

import tarfile
t = tarfile.open( "boost_1_46_1.tar.bz2" );
t.extractall()

On OSX (both Lion and Snow Leopard, so python 2.7.1 and 2.6.1 resp.) this works as a normal user, but not as root failing with:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2028, in extractall
    self.extract(tarinfo, path)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2065, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2157, in _extract_member
    self.chown(tarinfo, targetpath)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2269, in chown
    os.chown(targetpath, u, g)
OverflowError: signed integer is greater than maximum

I have confirmed that Python is running as a 64bit application on OSX.


On my 64bit Linux (gentoo) machine, this works both as a user and as root. I tried with Python 2.7.2 as well as downgrading to 2.7.1.

This could be related to 1215928

----------
messages: 146800
nosy: Dave.Flogeras
priority: normal
severity: normal
status: open
title: Unable to deal with large tarfile
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  1 22:22:20 2011
From: report at bugs.python.org (simohe)
Date: Tue, 01 Nov 2011 21:22:20 +0000
Subject: [New-bugs-announce] [issue13316] build_py_2to3 does not execute
	when there was an error	before
Message-ID: <1320182540.3.0.985799836702.issue13316@psf.upfronthosting.co.za>


New submission from simohe <simohe at besonet.ch>:

When I use build_py_2to3 and there is an error while converting a file with 2to3, convert is skipped on the next run.

The reason is that build_module in build_py_2to3 (in module distutils.command.build_py) only appends the file for converting when it is newly copied. Something safer should be used.
The simplest possibility is to always convert.

----------
components: Build
messages: 146807
nosy: simohe
priority: normal
severity: normal
status: open
title: build_py_2to3 does not execute when there was an error before
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Nov  1 22:32:13 2011
From: report at bugs.python.org (simohe)
Date: Tue, 01 Nov 2011 21:32:13 +0000
Subject: [New-bugs-announce] [issue13317] building with 2to3 generates wrong
	import paths because	build_ext is run after build_py
Message-ID: <1320183133.27.0.209500697705.issue13317@psf.upfronthosting.co.za>


New submission from simohe <simohe at besonet.ch>:

We need build_ext before build_py. Otherwise, when 2to3 is called (in build_py), it will not find ext modules, thinking that those modules are global and, consequently, making a mess, now that all module imports are global.

----------
components: 2to3 (2.x to 3.x conversion tool), Build
messages: 146808
nosy: simohe
priority: normal
severity: normal
status: open
title: building with 2to3 generates wrong import paths because build_ext is run after build_py

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

From report at bugs.python.org  Tue Nov  1 23:54:07 2011
From: report at bugs.python.org (Chris Piekarski)
Date: Tue, 01 Nov 2011 22:54:07 +0000
Subject: [New-bugs-announce] [issue13318] Shelve second tier array subscript
	"[ ]" key creation	doesn't work
Message-ID: <1320188047.41.0.331815392706.issue13318@psf.upfronthosting.co.za>


New submission from Chris Piekarski <chris at cpiekarski.com>:

Shelve object second tier array subscript key generation doesn't behave the same way dictionary object do.

>>> import shelve
>>> x = shelve.open("tst1.shelve")
>>> x["one"] = {}
>>> x
{'one': {}}
>>> x["one"]["two"] = 2
>>> x
{'one': {}}

Whereas with a dictionary it works:

>>> y = {}
>>> y["one"] = {}
>>> y["one"]["two"] = 2
>>> y
{'one': {'two': 2}}

----------
components: None
messages: 146816
nosy: cpiekarski
priority: normal
severity: normal
status: open
title: Shelve second tier array subscript "[ ]" key creation doesn't work
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  2 02:03:57 2011
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 02 Nov 2011 01:03:57 +0000
Subject: [New-bugs-announce] [issue13319] IDLE: Menu accelerator conflict
	between Format and	Options
Message-ID: <1320195837.58.0.031082649983.issue13319@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

This is a minor interface issue. The accelerator for opening the _Options menu in an editor conflicts with the F_ormat menu. 

I suggest changing the Options accelerator to "i" since Alt-t is for toggling tabs. (Perhaps the accelerator for <<toggle-tabs>> should be dropped, so that the options menu could be accessed by Alt-t.)

----------
components: IDLE
messages: 146819
nosy: serwy
priority: normal
severity: normal
status: open
title: IDLE: Menu accelerator conflict between Format and Options
type: feature request
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/issue13319>
_______________________________________

From report at bugs.python.org  Wed Nov  2 02:17:14 2011
From: report at bugs.python.org (Inverness)
Date: Wed, 02 Nov 2011 01:17:14 +0000
Subject: [New-bugs-announce] [issue13320] _remove_visual_c_ref in
	distutils.msvc9compiler causes	DLL load fail with embedded
	Python and multiple CRT versions
Message-ID: <1320196634.59.0.302796026714.issue13320@psf.upfronthosting.co.za>


New submission from Inverness <inverness910 at gmail.com>:

I am using a custom Python executable for an application I'm developing. I also build PYDs to extend this Python environment. I decided to upgrade them and my executable to use Visual C++ 10 while the Python DLL and other third party PYDs, specifically wxPython, continued to use Visual C++ 9. Doing this did not cause an issue in and of itself, however, my wxPython release, but not debug, PYDs were failing to load the VC9 CRT.

I discovered this is a result of MSVCCompiler._remove_visual_c_ref() being called in the module disutils.msvc9compiler. I had to comment out this line in order to rebuild wxPython and get my program running correctly.

I'm requesting this feature of the compiler be made optional.

----------
components: Library (Lib)
messages: 146821
nosy: Inverness
priority: normal
severity: normal
status: open
title: _remove_visual_c_ref in distutils.msvc9compiler causes DLL load fail with embedded Python and multiple CRT versions
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  2 05:04:12 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 02 Nov 2011 04:04:12 +0000
Subject: [New-bugs-announce] [issue13321] fstat doesn't accept an object
	with "fileno" method
Message-ID: <1320206652.2.0.972235455602.issue13321@psf.upfronthosting.co.za>


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

os.fstat doesn't not accept an object with the fileno() method.

Probably a bunch of other similar functions will not either.

In some parts of the standard library it's common practice to call PyObject_AsFileDescriptor on fd-wrapping arguments.

http://hg.python.org/cpython/file/d877d7f3b679/Modules/posixmodule.c#l7319
http://hg.python.org/cpython/file/d877d7f3b679/Objects/fileobject.c#l196

----------
components: Library (Lib)
messages: 146823
nosy: anacrolix
priority: normal
severity: normal
status: open
title: fstat doesn't accept an object with "fileno" method
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov  2 16:08:55 2011
From: report at bugs.python.org (sbt)
Date: Wed, 02 Nov 2011 15:08:55 +0000
Subject: [New-bugs-announce] [issue13322] buffered read() and write() does
	not raise	BlockingIOError
Message-ID: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>


New submission from sbt <shibturn at gmail.com>:

According to the the documentation, BufferedReader.read() and BufferedWriter.write() should raise io.BlockingIOError if the file is in non-blocking mode and the operation cannot succeed without blocking.

However, BufferedReader.read() returns None (which is what RawIOBase.read() is documented as doing), and BufferedWriter.write() raises IOError with a message like

    raw write() returned invalid length -1 (should have been 
    between 0 and 5904)

I tested this on Linux with Python 2.6, 2.7 and 3.x.

Attached is a unit test.

----------
files: blockingioerror.py
messages: 146841
nosy: sbt
priority: normal
severity: normal
status: open
title: buffered read() and write() does not raise BlockingIOError
Added file: http://bugs.python.org/file23590/blockingioerror.py

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

From report at bugs.python.org  Wed Nov  2 17:06:06 2011
From: report at bugs.python.org (David Fischer)
Date: Wed, 02 Nov 2011 16:06:06 +0000
Subject: [New-bugs-announce] [issue13323] urllib2 does not correctly handle
	multiple	www-authenticate headers in an HTTP response
Message-ID: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>


New submission from David Fischer <dfischer at ucsdmail.com>:

I ran into an application that responded with two www-authenticate challenges  to an HTTP request. First, it sends a standard Basic authentication challenge and then it also returns a www-authenticate header referencing another scheme. This looks legal to me according to rfc2617.

However, the regex in AbstractBasicAuthHandler that parses the www-authenticate header only grabs one of the challenges (the last one) and therefore urllib2 will not respond to the challenge with credentials.

----------
messages: 146842
nosy: dfischer
priority: normal
severity: normal
status: open
title: urllib2 does not correctly handle multiple www-authenticate headers in an HTTP response
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  2 17:51:14 2011
From: report at bugs.python.org (Alex Stewart)
Date: Wed, 02 Nov 2011 16:51:14 +0000
Subject: [New-bugs-announce] [issue13324] fcntl module doesn't support
	F_NOCACHE (OS X specific)	results in high 'inactive' memory
	performance issues
Message-ID: <1320252674.88.0.834289126042.issue13324@psf.upfronthosting.co.za>


New submission from Alex Stewart <alexs.mac at gmail.com>:

----------------------------
ISSUE DESCRIPTION: 
----------------------------
In 2.6.7, 2.7.2 and also HEAD (r 73301) the fcntl module does not support the F_NOCACHE OSX specific mode.  

The affect of this is that the default behaviour (data caching enabled) is used when parsing files etc.  When data caching is enabled, OSX caches the data parsed from a file by python, keeping it available as 'inactive memory' even when it has been freed by python.  In *theory*, this should be fine as OSX *should* recycle the inactive memory as it is required.  

Unfortunately, at least under OSX 10.6.8 (and it seems 10.7) the system will do almost anything to avoid recycling inactive memory, including swallowing up all 'pure' free memory and then paging manically to the disk.  The net affect of this is significantly degraded system performance.

For most users, operating with relatively small files and a large quantity of RAM this issue is probably not that obvious.  However, for various reasons I'm working with files of 5-125+GB and thus it rapidly becomes a major issue.

----------------------------
FIX
----------------------------
Very simply, all the attached patch does it add support for F_NOCACHE to fcntl just like F_FULLFSYNC (another fcntl OSX specific flag) - it's a trivial change that allows you to control whether OSX uses data caching on a file handle, e.g, the following turns OFF data caching for the specified file:

fcntl.fcntl(theFile.fileno(), fcntl.F_NOCACHE, 1)

With this patch in place the inactive memory on my system stays (low) and flat, without it it rises until it maxes out all available memory and then starts paging.

----------
components: Extension Modules
files: fcntlmodule.patch
keywords: patch
messages: 146846
nosy: Alex.Stewart, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: fcntl module doesn't support F_NOCACHE (OS X specific) results in high 'inactive' memory performance issues
type: resource usage
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file23592/fcntlmodule.patch

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

From report at bugs.python.org  Wed Nov  2 17:55:02 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 02 Nov 2011 16:55:02 +0000
Subject: [New-bugs-announce] [issue13325] no address in the representation
	of asyncore dispatcher	after connection established
Message-ID: <1320252902.0.0.0833758767698.issue13325@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When an asyncore dispatcher initiates a tcp connection, its
representation lacks the peer address. The output of the attached
script 'dispatcher_addr.py' gives on linux with Python 3.2:

call stack in handle_connect_event:
<module>->main->loop->poll->write->handle_write_event->handle_connect_event
self.addr after connection: None


The attached patch fixes the problem. The patch includes a test case.
The following comment in the patch:

    # EWOULDBLOCK may also be returned by winsock when calling connect
    # while the connection attempt is in progress

refers to the following statement in
http://msdn.microsoft.com/en-us/library/aa923167.aspx

"""
As a result, it is not recommended that applications use multiple
calls to connect to detect connection completion. If they do, they
must be prepared to handle WSAEINVAL and WSAEWOULDBLOCK error codes
the same way that they handle WSAEALREADY to ensure robust execution.
"""


Note that two consecutive calls to
socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) are made when
handle_write_event() is called and self.connected is False: one in
handle_write_event and the following right away in
handle_connect_event. This seems useless.

----------
components: Library (Lib)
messages: 146849
nosy: xdegaye
priority: normal
severity: normal
status: open
title: no address in the representation of asyncore dispatcher after connection established
type: behavior
versions: Python 3.2

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

From martin at v.loewis.de  Wed Nov  2 19:43:00 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 02 Nov 2011 19:43:00 +0100
Subject: [New-bugs-announce] [issue13323] urllib2 does not correctly
 handle multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
References: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <4EB18F34.3020009@v.loewis.de>

> I ran into an application that responded with two www-authenticate
> challenges  to an HTTP request. First, it sends a standard Basic
> authentication challenge and then it also returns a www-authenticate
> header referencing another scheme. 

What exactly do you mean by "then"? In HTTP, there is only a single
response to a single request, so in what way does the server send
two responses to a single request?

From report at bugs.python.org  Thu Nov  3 00:15:47 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 02 Nov 2011 23:15:47 +0000
Subject: [New-bugs-announce] [issue13326] make clean failed on OpenBSD
Message-ID: <1320275747.65.0.48370892093.issue13326@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hi,

"make clean" failed on OpenBSD with this error:

find: -exec: no terminating ";"
*** Error code 1 (ignored)

It seems that "-exec" with "+" is a GNU extension.

Are you OK with this diff which does the same and is multi-platform?
Modifications can only be done for __pycache__, what do you prefer?

Cheers,

Remi.

----------
files: python3_3_Makefile_pre_in
messages: 146882
nosy: pitrou, rpointel
priority: normal
severity: normal
status: open
title: make clean failed on OpenBSD
Added file: http://bugs.python.org/file23599/python3_3_Makefile_pre_in

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

From report at bugs.python.org  Thu Nov  3 00:46:32 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 02 Nov 2011 23:46:32 +0000
Subject: [New-bugs-announce] [issue13327] Update utime API to not require
	explicit None argument
Message-ID: <1320277592.58.0.341414975391.issue13327@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

os.utime currently requires an explicit `None` as the second argument in order to update to the current time. Other APIs would just have the second argument as optional in this case, operating with one argument.

Attached is a patch which changes the second argument to accept the time tuple, `None`, or literally nothing. Tested on Windows and Mac.

If this is acceptable, I'll make the same change for futimes, lutimes, and futimens.

----------
assignee: brian.curtin
components: Library (Lib)
files: utime.diff
keywords: needs review, patch
messages: 146884
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Update utime API to not require explicit None argument
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23600/utime.diff

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

From report at bugs.python.org  Thu Nov  3 01:03:17 2011
From: report at bugs.python.org (Arkadiusz Wahlig)
Date: Thu, 03 Nov 2011 00:03:17 +0000
Subject: [New-bugs-announce] [issue13328] pdb shows code from wrong module
Message-ID: <1320278597.67.0.4589054929.issue13328@psf.upfronthosting.co.za>


New submission from Arkadiusz Wahlig <arkadiusz.wahlig at gmail.com>:

If pdb is used to debug code using zipimport, it may end up displaying source code from wrong module. Python will execute the correct code but the source code lines displayed by pdb (including the "list" command) will come from an unrelated module.

Reason:

The pdb obtains lines of code using the linecache module. When used with zipimported modules, linecache requires the module's globals dict to be passed in along with the filename. The filename is then used as a cache key for future lookups.

A bug in pdb causes it to pass filename and globals from different modules when calling linecache thus polluting the cache with bogus data.

A patch for 2.7.2 is attached that fixes the problem.

The patch also fixes another problem:

When Bdb (Pdb parent class from bdb.py) calls linecache, it calls Bdb.canonic(filename) before passing the filename to it. It doesn't pass the module's globals though. This isn't a problem because the call is always made after Pdb has queried source lines for the same module (and it does pass the globals). However, because Pdb doesn't call Bdb.canonic() on the filename, the cache key is different and Bdb's call fails.

To fix this, the patch adds calls to Bdb.canonic(filename) whenever Pdb passes a filename to linecache.

----------
files: pdb.diff
keywords: patch
messages: 146885
nosy: yak
priority: normal
severity: normal
status: open
title: pdb shows code from wrong module
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23601/pdb.diff

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

From report at bugs.python.org  Thu Nov  3 04:22:14 2011
From: report at bugs.python.org (Nick Rowan)
Date: Thu, 03 Nov 2011 03:22:14 +0000
Subject: [New-bugs-announce] [issue13329] Runs normal as console script but
	falls as CGI
Message-ID: <1320290534.75.0.190110850785.issue13329@psf.upfronthosting.co.za>


New submission from Nick Rowan <nnrowan at gmail.com>:

There is a Python script that tries to print a message in Russian language. It's okay when script runs in console, but it causes DecodeUnicodeError if it invokes as CGI.

----------
components: Interpreter Core, Library (Lib), Unicode
files: Test.py
messages: 146893
nosy: Nick.Rowan, ezio.melotti
priority: normal
severity: normal
status: open
title: Runs normal as console script but falls as CGI
type: behavior
versions: 3rd party, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23602/Test.py

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

From report at bugs.python.org  Thu Nov  3 07:14:10 2011
From: report at bugs.python.org (Sean Fleming)
Date: Thu, 03 Nov 2011 06:14:10 +0000
Subject: [New-bugs-announce] [issue13330] Attempt full test coverage
	of	LocaleTextCalendar.formatweekday
Message-ID: <1320300850.58.0.556745870791.issue13330@psf.upfronthosting.co.za>


New submission from Sean Fleming <seanmtfleming at gmail.com>:

Patch includes new statements in test_localecalendars of CalendarTestCase such that coverage of LocaleTextCalendar.formatweekday should improve significantly. 

Feedback is appreciated.

----------
components: Tests
files: test_calendar.patch
keywords: patch
messages: 146895
nosy: Sean.Fleming
priority: normal
severity: normal
status: open
title: Attempt full test coverage of LocaleTextCalendar.formatweekday
versions: Python 3.4
Added file: http://bugs.python.org/file23603/test_calendar.patch

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

From report at bugs.python.org  Thu Nov  3 12:50:56 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 Nov 2011 11:50:56 +0000
Subject: [New-bugs-announce] [issue13331] Packaging cannot install resource
	directory trees	specified in setup.cfg
Message-ID: <1320321056.38.0.167356334613.issue13331@psf.upfronthosting.co.za>


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

If setup.cfg contains a line such as

[files]
resources =
    mydata/** = {purelib}

and the project contains a directory tree more than one level deep under mydata, e.g.

mydata
 |
 +-mydata1
 |   |
 |   +-data1.dat
 |
 +-mydata2
     |
     +-data2.dat

then the parsing correctly identifies all the things to copy, but the install_data step fails because it does not try to create intermediate directories for mydata1, mydata2 but tries to copy them as files using copy_file.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 146917
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: high
severity: normal
status: open
title: Packaging cannot install resource directory trees specified in setup.cfg
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov  3 13:11:32 2011
From: report at bugs.python.org (Sven Marnach)
Date: Thu, 03 Nov 2011 12:11:32 +0000
Subject: [New-bugs-announce] [issue13332] execfile fixer produces code that
	does not close the file
Message-ID: <1320322292.48.0.851588051991.issue13332@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

The execfile fixer of the 2to3 script replaces the 2.x code

    execfile("a.py")

by

    exec(compile(open("a.py").read(), "a.py", 'exec'))

The new code does not explicitly close the file.  This is not usually a problem in CPython, but

 1. the code will throw a RessourceWarnings if enabled and

 2. other Python implementation don't close the file immediately.

(I think the 2to3 script should be as implementation-independent as possible.)

The obvious fix would be to use a with-statement:

    with open("a.py") as new_name:
        exec(compile(new_name.read(), "a.py", 'exec'))

If this is to be changed, I'd be happy to prepare a patch.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 146918
nosy: smarnach
priority: normal
severity: normal
status: open
title: execfile fixer produces code that does not close the file
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  3 13:13:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Nov 2011 12:13:47 +0000
Subject: [New-bugs-announce] [issue13333] utf-7 inconsistent with surrogates
Message-ID: <1320322427.22.0.464090396955.issue13333@psf.upfronthosting.co.za>


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

The utf-7 codec happily encodes lone surrogates, but it won't decode them:

>>> "\ud801".encode("utf-7")
b'+2AE-'
>>> "\ud801\ud801".encode("utf-7")
b'+2AHYAQ-'
>>> "\ud801".encode("utf-7").decode("utf-7")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/encodings/utf_7.py", line 12, in decode
    return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-4: second surrogate missing at end of shift sequence
>>> "\ud801\ud801".encode("utf-7").decode("utf-7")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/encodings/utf_7.py", line 12, in decode
    return codecs.utf_7_decode(input, errors, True)
UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-6: second surrogate missing


I don't know which behaviour is better but round-tripping is certainly a desirable property of any codec.

----------
components: Interpreter Core, Unicode
messages: 146919
nosy: ezio.melotti, loewis, pitrou
priority: normal
severity: normal
status: open
title: utf-7 inconsistent with surrogates
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  3 13:50:02 2011
From: report at bugs.python.org (david)
Date: Thu, 03 Nov 2011 12:50:02 +0000
Subject: [New-bugs-announce] [issue13334] Erroneous Size check in
Message-ID: <1320324602.51.0.635021711304.issue13334@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

The _PyString_Resize function in stringobject.c[0] takes in a PyObject ** and a Py_ssize_t newsize. Where Py_ssize_t is often a typedef for ssize_t(a signed version of size_t). As such the newsize parameter could be negative. 
The code checks for when the newsize is negative like so:

 int
_PyString_Resize(PyObject **pv, Py_ssize_t newsize)
{
...
    if (!PyString_Check(v) || Py_REFCNT(v) != 1 || newsize < 0 ||
        PyString_CHECK_INTERNED(v)) {
        *pv = 0;
        Py_DECREF(v);
        PyErr_BadInternalCall();
        return -1;
    }

Unfortunately, a few lines below it does the following:
 *pv = (PyObject *)
        PyObject_REALLOC((char *)v, PyStringObject_SIZE + newsize);

so now if PyStringObject_SIZE + newsize is enough to wrap around then realloc through python will end up allocating insufficient space for the 'new' string. The python interpreter is likely to crash on this line --> 

    sv->ob_sval[newsize] = '\0';

 
I haven't tried to reproduce this in the python interpreter. 
IMHO the code should be checking that newline + PyStringObject_SIZE is non-negative. 


[0] - http://svn.python.org/projects/python/trunk/Objects/stringobject.c

----------
messages: 146927
nosy: db
priority: normal
severity: normal
status: open
title: Erroneous Size check in

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

From report at bugs.python.org  Thu Nov  3 13:53:49 2011
From: report at bugs.python.org (Chandra Sekhar Reddy)
Date: Thu, 03 Nov 2011 12:53:49 +0000
Subject: [New-bugs-announce] [issue13335] Service application hang in
	python25.dll
Message-ID: <1320324829.1.0.613797933132.issue13335@psf.upfronthosting.co.za>


New submission from Chandra Sekhar Reddy <sanch09 at ca.com>:

Service application hanged in python25.dll, below are the environment details.

Operating System : Windows server 2008 R2 (Virtual Machine) Application Type : Service Application

We have got the process dump from the customer environment and after analyzing the dump using the Windbg tool.

Below is the status of the 4 running threads.
 
 Last error for thread 0:
 LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
 LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
 
 Last error for thread 1:
 LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
 LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
 
 Last error for thread 2:
 LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
 LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0

Last error for thread 3:
 LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
 LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
 
 But as part of the hang analysis the command "!analyze -hang" shows
 some problem with thread 1
 
 Probably caused by : python25.dll ( python25!PyList_New+62 )
 
 03dff250 1e072c5b python25!PyFuture_FromAST+0x873
 03dff25c 1e073307 python25!PyFuture_FromAST+0xbcb
 03dff264 1e07332e python25!PyObject_GC_Malloc+0x67
 03dff270 1e081502 python25!PyObject_GC_New+0xe
 00000000 00000000 python25!PyList_New+0x62

Thanks,
-Chandra

----------
components: Windows
messages: 146928
nosy: chandra
priority: normal
severity: normal
status: open
title: Service application hang in python25.dll
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Thu Nov  3 19:06:37 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 Nov 2011 18:06:37 +0000
Subject: [New-bugs-announce] [issue13336]
	packaging.command.Command.copy_file doesn't
	implement	preserve_mode and preserve_times
Message-ID: <1320343597.32.0.412564968356.issue13336@psf.upfronthosting.co.za>


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

The packaging.command.Command.copy_file method does not honour the preserve_mode and preserve_times keyword arguments.

Likewise, packaging.command.Command.copy_tree does not honour the preserve_mode, preserve_times and preserve_symlinks keyword arguments.

----------
assignee: tarek
components: Distutils2, Library (Lib)
messages: 146957
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: normal
severity: normal
status: open
title: packaging.command.Command.copy_file doesn't implement preserve_mode and preserve_times
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov  3 20:03:20 2011
From: report at bugs.python.org (Gerald Dalley)
Date: Thu, 03 Nov 2011 19:03:20 +0000
Subject: [New-bugs-announce] [issue13337] IGNORE_CASE doctest option flag
Message-ID: <1320347000.37.0.62477718357.issue13337@psf.upfronthosting.co.za>


New submission from Gerald Dalley <dalleyg at alum.mit.edu>:

It would be helpful to have a doctest flag that makes the test case insensitive.

Use case: nan values are printed as "nan" with typical Linux implementations, but as "NaN" on other operating systems like Solaris.

In a naive implementation, the core change to doctest.OutputChecker.check_output is:

+        if optionflags & IGNORE_CASE:
+            got        = got.lower()
+            want       = want.lower()
+            true_line  = "true\n"
+            false_line = "false\n"
+        else:
+            true_line  = "True\n"
+            false_line = "False\n"
+
         # Handle the common case first, for efficiency:
         # if they're string-identical, always return true.
         if got == want:
             return True

         # The values True and False replaced 1 and 0 as the return
         # value for boolean comparisons in Python 2.3.
         if not (optionflags & DONT_ACCEPT_TRUE_FOR_1):
-            if (got,want) == ("True\n", "1\n"):
+            if (got,want) == (true_line, "1\n"):
                 return True
-            if (got,want) == ("False\n", "0\n"):
+            if (got,want) == (false_line, "0\n"):
                 return True

----------
components: Library (Lib)
messages: 146961
nosy: Gerald.Dalley
priority: normal
severity: normal
status: open
title: IGNORE_CASE doctest option flag
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/issue13337>
_______________________________________

From report at bugs.python.org  Fri Nov  4 01:24:44 2011
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 04 Nov 2011 00:24:44 +0000
Subject: [New-bugs-announce] [issue13338] Not all enumerations used in
	_Py_ANNOTATE_MEMORY_ORDER
Message-ID: <1320366284.3.0.0625863072508.issue13338@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

Hi,

When compiling using gcc and -Werror=switch-enum the compilation fails, e.g. while compiling an extension module:

In file included from /usr/include/python3.2mu/Python.h:52:0,
                 from src/util.c:27:
/usr/include/python3.2mu/pyatomic.h: In function ?_Py_ANNOTATE_MEMORY_ORDER?:
/usr/include/python3.2mu/pyatomic.h:61:5: error: enumeration value ?_Py_memory_order_relaxed? not handled in switch [-Werror=switch-enum]
/usr/include/python3.2mu/pyatomic.h:61:5: error: enumeration value ?_Py_memory_order_acquire? not handled in switch [-Werror=switch-enum]
/usr/include/python3.2mu/pyatomic.h:70:5: error: enumeration value ?_Py_memory_order_relaxed? not handled in switch [-Werror=switch-enum]
/usr/include/python3.2mu/pyatomic.h:70:5: error: enumeration value ?_Py_memory_order_release? not handled in switch [-Werror=switch-enum]

This could be easily resolved without any drawbacks by simply listing the missing enumeration items together with the default.  And that would enable extensions to be built using -Werror=switch-enum again.

Regards,
Floris

----------
components: Interpreter Core
messages: 146993
nosy: flub
priority: normal
severity: normal
status: open
title: Not all enumerations used in _Py_ANNOTATE_MEMORY_ORDER
type: compile error
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov  4 05:34:24 2011
From: report at bugs.python.org (Robert Xiao)
Date: Fri, 04 Nov 2011 04:34:24 +0000
Subject: [New-bugs-announce] [issue13339] Missing semicolon at
	Modules/posixsubprocess.c:4511
Message-ID: <1320381264.57.0.354485296745.issue13339@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

Line 4511 of Modules/posixsubprocess.c is missing a semicolon, so it would not compile successfully if the relevant build flags were enabled (PYOS_OS2).

Trivial patch:
@@ -4508,7 +4508,7 @@
 static PyObject *
 posix_spawnvpe(PyObject *self, PyObject *args)
 {
-    PyObject *opath
+    PyObject *opath;
     char *path;
     PyObject *argv, *env;
     char **argvlist;

No tests needed since it's a compile error.

----------
components: Extension Modules
messages: 146995
nosy: nneonneo
priority: normal
severity: normal
status: open
title: Missing semicolon at Modules/posixsubprocess.c:4511
type: compile error
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  4 10:23:04 2011
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Fri, 04 Nov 2011 09:23:04 +0000
Subject: [New-bugs-announce] [issue13340] list.index does not accept None as
	start or stop
Message-ID: <1320398584.03.0.145013152611.issue13340@psf.upfronthosting.co.za>


New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:

The list.index method does not accept None as start and stop, which makes the error message quite confusing:

>>> [1, 2, 3].index(2, None, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method

I checked this in 3.2.2 and 2.7.2. Seems similar to #12163.

----------
messages: 147000
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: list.index does not accept None as start or stop
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Nov  4 14:20:14 2011
From: report at bugs.python.org (Ilya Novoselov)
Date: Fri, 04 Nov 2011 13:20:14 +0000
Subject: [New-bugs-announce] [issue13341] Incorrect documentation for "u"
	PyArg_Parse format unit
Message-ID: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za>


New submission from Ilya Novoselov <ilya.novoselov at gmail.com>:

Documentation states that u format unit returns "buffer of 16-bit Unicode (UTF-16) data" while it returns pointer to internal buffer of unicode data, which is either UCS-16 or UCS-32

http://docs.python.org/c-api/arg.html

----------
assignee: docs at python
components: Documentation, Unicode
messages: 147002
nosy: Ilya.Novoselov, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: Incorrect documentation for "u" PyArg_Parse format unit
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov  4 15:37:14 2011
From: report at bugs.python.org (stefanholek)
Date: Fri, 04 Nov 2011 14:37:14 +0000
Subject: [New-bugs-announce] [issue13342] input() builtin always uses
	"strict" error handler
Message-ID: <1320417434.92.0.472252310596.issue13342@psf.upfronthosting.co.za>


New submission from stefanholek <stefan at epy.co.at>:

The input builtin always uses "strict" error handling for Unicode conversions. This means that when I enter a latin-1 string in a utf-8 environment, input breaks with a UnicodeDecodeError. Now don't tell me not to do that, I have a valid use-case. ;-)

While "strict" may be a good default choice, it is clearly not sufficient. I would like to propose an optional 'errors' argument to input, similar to the 'errors' argument the decode and encode methods have.

I have in fact implemented such an input method for my own use:
https://github.com/stefanholek/rl/blob/surrogate-input/rl/input.c

While this solves my immediate needs, the fact that my implementation is basically just a copy of bltinmode.input with one additional argument, makes me think that this could be fixed in Python proper.

There cannot be a reason input() should be confined to "strict", or can there? ;-)

----------
components: Unicode
messages: 147005
nosy: ezio.melotti, stefanholek
priority: normal
severity: normal
status: open
title: input() builtin always uses "strict" error handler
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  4 20:37:32 2011
From: report at bugs.python.org (Joshua Landau)
Date: Fri, 04 Nov 2011 19:37:32 +0000
Subject: [New-bugs-announce] [issue13343] Lambda keyword-only argument not
	updating co_freevars
Message-ID: <1320435452.65.0.656040815575.issue13343@psf.upfronthosting.co.za>


New submission from Joshua Landau <joshua.landau.ws at gmail.com>:

When setting defaults to keyword-only arguments in lambdas which are inside non-global scopes, cPython doesn't push the name to it's closure's co_freevars.

EXAMPLE:
global_variable = None
(lambda: (lambda *, keyword_only=global_variable: None))()

Because the inner lambda hasn't told the outer lambda to put global_variable in co_freevars, it fails to create the default to keyword_only. This only happens if the inner function is a lambda and you are setting a keyword_only variable.

It does not cause a crash if global_variable is local to the outer lambda, as the opcode LOAD_FAST is still created properly (as opposed to LOAD_NAME).

It does not crash if global_variable is used elsewhere in the outer function as co_freevars will be updated with it, allowing LOAD_NAME to retrieve it.



I've never done a bug here before and I'm unsure what to say, so please be nice and correct me if I'm doing it wrong.

----------
components: Interpreter Core
messages: 147026
nosy: Joshua.Landau
priority: normal
severity: normal
status: open
title: Lambda keyword-only argument not updating co_freevars
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov  4 22:14:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Nov 2011 21:14:46 +0000
Subject: [New-bugs-announce] [issue13344] closed sockets don't raise EBADF
	anymore
Message-ID: <1320441286.92.0.465148592312.issue13344@psf.upfronthosting.co.za>


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

This decrepancy between 2.x and 3.x is witnessed under Windows:

Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.create_connection(("www.python.org", 80))
>>> sock.close()
>>> sock.send(b"x")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python27\lib\socket.py", line 170, in _dummy
    raise error(EBADF, 'Bad file descriptor')
socket.error: [Errno 9] Bad file descriptor

Python 3.2.1 (default, Jul 10 2011, 20:02:51) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket(); sock.connect(("www.python.org", 80))
>>> sock.close()
>>> sock.send(b"x")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: [Errno 10038] An operation was attempted on something that is not
a socket


I'm not sure this is worth fixing, though.

----------
components: Library (Lib)
messages: 147039
nosy: exarkun, pitrou
priority: low
severity: normal
status: open
title: closed sockets don't raise EBADF anymore
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov  4 23:15:48 2011
From: report at bugs.python.org (Jon Bryan)
Date: Fri, 04 Nov 2011 22:15:48 +0000
Subject: [New-bugs-announce] [issue13345] Invisible Files in Windows 7
Message-ID: <1320444948.85.0.183506060307.issue13345@psf.upfronthosting.co.za>


New submission from Jon Bryan <jrbryan at sandia.gov>:

Running 32-bit Python in 64-bit Windows 7 Enterprise.  I am very much a Python noob.

A .dll in c:\Windows\System32 that I need to access can't be found by ctypes.WinDLL().  Upon further investigation I have found that the file, along with many others, doesn't show up in an os.listdir() either.  Within IDLE the files don't appear in the drop-down autocomplete list.

I don't have this problem on either of the Windows XP machines I've tried it on, but in Win7 I see the same behavior in both 2.7 and 3.2.

----------
components: IDLE, Windows, ctypes
messages: 147052
nosy: jrbryan
priority: normal
severity: normal
status: open
title: Invisible Files in Windows 7
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Nov  5 03:46:36 2011
From: report at bugs.python.org (Alan Grow)
Date: Sat, 05 Nov 2011 02:46:36 +0000
Subject: [New-bugs-announce] [issue13346] re.split() should behave like
	string.split() for	maxsplit=0 and maxsplit=-1
Message-ID: <1320461196.01.0.560612390683.issue13346@psf.upfronthosting.co.za>


New submission from Alan Grow <alangrow+pythonbugs at gmail.com>:

If you split a string in a maximum of zero places, you should get the original string back. "".split(s,0) behaves this way. But re.split(r,s,0) performs an unlimited number of splits in this case.

To get an unlimited number of splits, "".split(s,-1) is a sensible choice. But in this case re.split(r,s,-1) performs zero splits.

Where's the sense in this?

>>> import string, re
>>> string.split("foo bar baz"," ",0)
['foo bar baz']
>>> re.split("\s+","foo bar baz",0)
['foo', 'bar', 'baz']
>>> string.split("foo bar baz"," ",-1)
['foo', 'bar', 'baz']
>>> re.split("\s+","foo bar baz",-1)
['foo bar baz']

----------
components: Library (Lib)
messages: 147066
nosy: acg
priority: normal
severity: normal
status: open
title: re.split() should behave like string.split() for maxsplit=0 and maxsplit=-1
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Nov  5 08:51:58 2011
From: report at bugs.python.org (Kaleb702)
Date: Sat, 05 Nov 2011 07:51:58 +0000
Subject: [New-bugs-announce] [issue13347] .py extension not auto added
Message-ID: <1320479518.35.0.248470834603.issue13347@psf.upfronthosting.co.za>


New submission from Kaleb702 <ronneymichelle at gmail.com>:

Python IDLE does not auto add the .py extension when saving a file.

----------
components: IDLE
messages: 147072
nosy: Kaleb702
priority: normal
severity: normal
status: open
title: .py extension not auto added

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

From report at bugs.python.org  Sat Nov  5 11:58:02 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 05 Nov 2011 10:58:02 +0000
Subject: [New-bugs-announce] [issue13348] test_unicode_file fails:
	shutil.copy2 says "same file"
Message-ID: <1320490682.69.0.905628343655.issue13348@psf.upfronthosting.co.za>


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

I stopped on this error on buildbot x86 Tiger 3.2.
It looks strange.

test_single_files (test.test_unicode_file.TestUnicodeFiles) ... ERROR

======================================================================
ERROR: test_single_files (test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/test/test_unicode_file.py", line 120, in test_single_files
    self._test_single(TESTFN_UNICODE)
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/test/test_unicode_file.py", line 113, in _test_single
    self._do_single(filename)
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/test/test_unicode_file.py", line 40, in _do_single
    self._do_copyish(filename, filename)
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/test/test_unicode_file.py", line 75, in _do_copyish
    shutil.copy2(filename1, filename2 + ".new")
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/shutil.py", line 144, in copy2
    copyfile(src, dst)
  File "/Users/db3l/buildarea/3.2.bolen-tiger/build/Lib/shutil.py", line 85, in copyfile
    raise Error("`%s` and `%s` are the same file" % (src, dst))
shutil.Error: `@test_19432_tmp-?????` and `@test_19432_tmp-?????.new` are the same file

----------------------------------------------------------------------
Ran 2 tests in 0.013s

FAILED (errors=1)


http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.2/builds/637/steps/test/logs/stdio

----------
keywords: buildbot
messages: 147079
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: test_unicode_file fails: shutil.copy2 says "same file"
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Nov  5 21:49:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 05 Nov 2011 20:49:37 +0000
Subject: [New-bugs-announce] [issue13349] Uninformal error message in
	index() and remove()	functions
Message-ID: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za>


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

For example:

>>> (1, 2, 3).index(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: tuple.index(x): x not in tuple

The "x not in tuple" error message should be replaced with "4 is not in tuple". list.index() already does this (see #7252):

>>> [1, 2, 3].index(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: 4 is not in list

Although in #7252 it was claimed that no other place in stdlib has this error message, I found many occurences:

Modules/_collectionsmodule.c:    PyErr_SetString(PyExc_ValueError, "deque.remove(x): x not in deque"
Modules/_elementtree.c:            "list.remove(x): x not in list"
Modules/_elementtree.c:            "list.remove(x): x not in list"
Modules/arraymodule.c:    PyErr_SetString(PyExc_ValueError, "array.index(x): x not in list");
Modules/arraymodule.c:    PyErr_SetString(PyExc_ValueError, "array.remove(x): x not in list");
Objects/abstract.c:                    "sequence.index(x): x not in sequence");
Objects/listobject.c:    PyErr_SetString(PyExc_ValueError, "list.remove(x): x not in list");
Objects/tupleobject.c:    PyErr_SetString(PyExc_ValueError, "tuple.index(x): x not in tuple");

There's also documentation and tests that depend on this actual error message:

Doc/library/doctest.rst:   ValueError: list.remove(x): x not in list
Lib/test/test_xml_etree.py:    ValueError: list.remove(x): x not in list

#7252 was fixed in r76058, and it's quite a lot of code. I think it could be done more easily using PyUnicode_FromFormat() and the %R format.

----------
messages: 147109
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: Uninformal error message in index() and remove() functions

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

From report at bugs.python.org  Sat Nov  5 22:30:35 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 05 Nov 2011 21:30:35 +0000
Subject: [New-bugs-announce] [issue13350] Use PyUnicode_FromFomat instead of
	PyUnicode_Format for	fixed formats
Message-ID: <1320528635.6.0.850267932355.issue13350@psf.upfronthosting.co.za>


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

A code simplification suggested by a comment in issue13349:
Replace most usages of PyUnicode_Format (a.k.a. str.__mod__) by PyUnicode_FromFormat, which is easier to use from C:
no need to build a tuple, and the format accept both C strings (%s) and Python strings (%S or %R)

----------
files: FromFormat.diff
keywords: patch
messages: 147112
nosy: amaury.forgeotdarc, petri.lehtinen
priority: normal
severity: normal
status: open
title: Use PyUnicode_FromFomat instead of PyUnicode_Format for fixed formats
versions: Python 3.3
Added file: http://bugs.python.org/file23614/FromFormat.diff

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

From report at bugs.python.org  Sun Nov  6 00:56:42 2011
From: report at bugs.python.org (Jonas LM)
Date: Sat, 05 Nov 2011 23:56:42 +0000
Subject: [New-bugs-announce] [issue13351] Strange time complexity when
	creating nested lists
Message-ID: <1320537402.3.0.127960683982.issue13351@psf.upfronthosting.co.za>


New submission from Jonas LM <quakes0 at gmail.com>:

Consider the following snippets:

def lists(n):
    start_time = time.time()
    lists = [None]*n
    for i in xrange(n):
            lists[i] = [None]*n
            for j in xrange(n):
                    lists[i][j] = []
    print time.time() - start_time

def simple_lists(n):
    start_time = time.time()
    lists = [None]*n
    for i in xrange(n):
            lists[i] = [None]*n
            for j in xrange(n):
                    lists[i][j] = False
    print time.time() - start_time

Both of these snippets seem like they should run in O(n^2), right?

Observe the following test runs:

>>> for i in [4000, 8000, 16000]: simple_lists(i)
2.11170578003
8.67467808723
34.0958559513
>>> for i in [1000, 2000, 4000]: lists(i)
1.13742399216
7.39806008339
78.0808939934

While simple_lists() seem to run roughly in O(n^2), it seems like lists() runs in upwards of O(n^3) or worse! Something funky is going on, and I have no idea what.

----------
components: None
messages: 147126
nosy: quakes
priority: normal
severity: normal
status: open
title: Strange time complexity when creating nested lists
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov  6 04:21:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 06 Nov 2011 03:21:38 +0000
Subject: [New-bugs-announce] [issue13352] tutorial section 9.3.3
	documentation problem
Message-ID: <1320549698.37.0.353874550901.issue13352@psf.upfronthosting.co.za>


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

User report on the docs@ list:

-----

http://docs.python.org/tutorial/classes.html#instance-objects

I think the "counter" attribute is mentioned for the first time in the
example code, not "in Instance of MyClass created above", i.e. class
MyClass does not contain "counter" attribute.

"x.counter = 1
while x.counter < 10:
   x.counter = x.counter * 2
print x.counter
del x.counter"

Best Regards,
Jussi Peltonen

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 147137
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: tutorial section 9.3.3 documentation problem
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  6 04:24:02 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 06 Nov 2011 03:24:02 +0000
Subject: [New-bugs-announce] [issue13353] documentation problem
	in	logging.handlers.TimedRotatingFileHandler for 2.7
Message-ID: <1320549842.11.0.772766831495.issue13353@psf.upfronthosting.co.za>


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

User (Yoann Roman) report on docs@ maillist:

----

The docs for logging.handlers.TimedRotatingFileHandler in Python 2.7 say that the "utc" keyword argument was added in 2.7:
http://docs.python.org/library/logging.handlers.html#timedrotatingfilehandler

This isn't correct, however, since it was available as of 2.6 (I verified the source as well):
http://docs.python.org/release/2.6/library/logging.html#timedrotatingfilehandler

It did appear to change to True/False in 2.7 instead of 0/1 in 2.6. I'd recommend changing it to indicate this or removing the fact that this was added in 2.7 altogether.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 147138
nosy: docs at python, eli.bendersky
priority: low
severity: normal
status: open
title: documentation problem in logging.handlers.TimedRotatingFileHandler for 2.7
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  6 10:10:11 2011
From: report at bugs.python.org (Bas Wijnen)
Date: Sun, 06 Nov 2011 09:10:11 +0000
Subject: [New-bugs-announce] [issue13354] tcpserver should document
	non-threaded long-living	connections
Message-ID: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>


New submission from Bas Wijnen <wijnen at debian.org>:

http://docs.python.org/py3k/library/socketserver.html says:

The solution is to create a separate process or thread to handle each request; the ForkingMixIn and ThreadingMixIn mix-in classes can be used to support asynchronous behaviour.

There is another way, which doesn't bring multi-threading hell over you: keep a copy of the file descriptor and use it when events occur. I recall that this suggestion used to be in the documentation as well, but I can't find it anymore. It would be good to add this suggestion to the documentation.

However, there is a thing you must know before you can use this approach: tcpserver calls shutdown() on the socket when handle() returns. This means that the network connection is closed. Even dup2() doesn't keep it open (it lets you keep a file descriptor, but it returns EOF). The solution for this is to override shutdown_request of your handler to only call close_request (or not call anything at all) for sockets which must remain open. That way, as long as there is a reference to the socket, the network connection will not be shut down. Optionally the socket can be shutdown() explicitly when you're done with the connection.

Something like the paragraph above would be useful in the documentation IMO.

----------
assignee: docs at python
components: Documentation
messages: 147147
nosy: docs at python, shevek
priority: normal
severity: normal
status: open
title: tcpserver should document non-threaded long-living connections
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov  6 11:56:56 2011
From: report at bugs.python.org (Mark)
Date: Sun, 06 Nov 2011 10:56:56 +0000
Subject: [New-bugs-announce] [issue13355] random.triangular error when low =
	mode
Message-ID: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>


New submission from Mark <mhughes108 at gmail.com>:

When low and mode are the same in random.triangular it gives the following error:


<type 'exceptions.ZeroDivisionError'>: float division
      args = ('float division',)
      message = 'float division' 


When high and mode are the same there is no problem.

----------
components: Extension Modules
messages: 147148
nosy: mark108
priority: normal
severity: normal
status: open
title: random.triangular error when low = mode
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov  6 18:53:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Nov 2011 17:53:01 +0000
Subject: [New-bugs-announce] [issue13356] test_logging warning on 2.7
Message-ID: <1320601981.59.0.630588677402.issue13356@psf.upfronthosting.co.za>


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

$ ./python -Wd -3 -m test.regrtest -v test_logging
== CPython 2.7.2+ (2.7:39573be48b4a, Nov 6 2011, 17:13:44) [GCC 4.6.1]
==   Linux-3.0.0-12-generic-i686-with-debian-wheezy-sid little-endian
==   /home/wolf/dev/py/wide-2.7/build/test_python_6508
Testing with flags: sys.flags(debug=0, py3k_warning=1, division_warning=1, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=1, verbose=0, unicode=0, bytes_warning=0)
test_logging
[...]
test_listen_config_10_ok (test.test_logging.ConfigDictTest) ... /home/wolf/dev/py/wide-2.7/Lib/logging/config.py:599: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  if name in existing:
ok
[...]

----------------------------------------------------------------------
Ran 43 tests in 2.328s

OK
1 test OK.

----------
assignee: vinay.sajip
components: Library (Lib)
messages: 147165
nosy: ezio.melotti, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging warning on 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  6 20:09:06 2011
From: report at bugs.python.org (Michael Brooks)
Date: Sun, 06 Nov 2011 19:09:06 +0000
Subject: [New-bugs-announce] [issue13357] HTMLParser parses attributes
	incorrectly.
Message-ID: <1320606546.64.0.752508532419.issue13357@psf.upfronthosting.co.za>


New submission from Michael Brooks <firealwaysworks at gmail.com>:

Open the attached file "red_test.html" in a browser.  The "bad" elements are blue because the style tag isn't parsed by any known browser.   However,  the HTMLParser library will incorrectly recognize them.

----------
components: Library (Lib)
files: red_test.html
messages: 147169
nosy: Michael.Brooks
priority: normal
severity: normal
status: open
title: HTMLParser parses attributes incorrectly.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23618/red_test.html

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

From report at bugs.python.org  Sun Nov  6 20:48:25 2011
From: report at bugs.python.org (Michael Brooks)
Date: Sun, 06 Nov 2011 19:48:25 +0000
Subject: [New-bugs-announce] [issue13358] HTMLParser incorrectly handles
	cdata elements.
Message-ID: <1320608905.33.0.994524216308.issue13358@psf.upfronthosting.co.za>


New submission from Michael Brooks <firealwaysworks at gmail.com>:

The HTML tag at the bottom of this page correctly identified has having cdata like properties and trigger set_cdata_mode().  Due to the cdata properties of this tag,  the only way to end the data segment is with a closing </script> tag, NO OTHER tag can close this data segment.  Currently in cdata mode the HTMLParser will use this regular expression to close this script tag: re.compile(r'<(/|\Z)'),  however this script tag is setting a variable with data that contains "</b>" which will terminate this script tag prematurely.

I have written and tested the following patch on my system:
#used to terminate cdata elements
endtagfind_script = re.compile('(?i)</\s*script\s*>')
endtagfind_style = re.compile('(?i)</\s*style\s*>')

class html_patch(HTMLParser.HTMLParser):
    # Internal -- sets the proper tag terminator based on cdata element type
    def set_cdata_mode(self, tag):
        #We check if the script is either a style or a script
        #based on self.CDATA_CONTENT_ELEMENTS
        if tag=="style":
            self.interesting = endtagfind_style
        elif tag=="script":
            self.interesting = endtagfind_script
        else:
            self.error("Unknown cdata type:"+tag) # should never happen
        self.cdata_tag = tag 


This cdata tag isn't parsed properly by HTMLParser,  but it works fine in a browser:
<script>
pwa.setup(
pwa.searchview,
'lhid_searchheader',
'lhid_content',
'lhid_trayhandle',
'lhid_tray',
{'query': 'test',
'tagQuery': '',
'searchScope': '',
'owner': '',
'doCrowding': false,
'isOwner': false,
'albumId': ''
,'experimentalsearchquality': true},
'firealwaysworks'
,
{feedUrl: 'https://picasaweb.google.com/data/feed/tiny/all?alt=jsonm&amp;kind=photo&amp;access=public&amp;filter=1&amp;q=test',
feedPreload: null},
{NEW_HOMEPAGE:1,NEW_ONE_BAR:1,fr:1,tags:1,search:1,globalsearch:1,globalsearchpromo:1,newfeatureslink:1,cart:1,contentcaching:1,developerlink:1,payments:1,newStrings:1,cccquota:1,signups:1,flashSlideshow:1,URL_SHORTENER_VISIBILITY:1,emailupload:1,photopickeralbumview:1,PWA_NEWUI:1,WILDCARD_QUERY_FEED:1,recentphotos:1,editinpicasa:1,imagesearch:1,froptin:1,FR_CONTINUOUS_CLUSTERING:1,asyncUploads:1,PERFORMANCE_EXPERIMENTS:1,BAKED_PRELOAD_FEEDS:1,albumviewlimit:1,HQ_VIDEOS:1,VIDEO_INFO_DISPLAY:1,CSI:1,EXPERIMENTAL_SEARCH_QUALITY:1,COMMENT_TRANSLATION:1,NEW_COMMENT_STYLE:1,ENABLE_NEW_FLAG_ABUSE_FORM:1,QRCODE:1,CHINA:1,GWS_URL_REDIRECTION:1,FEATURED_PHOTOS:1,COMMENT_SUBSCRIPTION:1,COMMENT_SUBSCRIPTION_SETTING:1,PICASA_MAC:1,AD_ON_SEARCHPAGE:1,API_AUTO_ACCOUNTS:1,FOCUS_GROUP_ACL:1,PHOTOSTREAM:1,BACKEND_ACL:1,ADVANCED_SEARCH:1,FACE_SEARCH:1,CAMERA_SEARCH:1,NOTIFICATION:1,PIXELATED_PREVIEW:1,TRANSPARENT_PIXELATED_PREVIEW:1,NEW_SETTINGS_PAGE:1,VIEW_STARRERS:1,FR_FOCUS_MERGE:1,AD_ON_SEARCH_ONEUP:1,GALLERY_COMMENTS:1,COMMENT_ABUSE_BLOCKING:1,FAVORITE_NOTIFICATION:1,IMAGE_ONLY_LINK:1,RECENT_PHOTOS_SLIDESHOW:1,HEART:1,SMALLER_IMAGE:1,FAST_SLIDESHOW:1,VIEW_CONTACTS:1,COLLABORATIVE_ALBUMS:1,PRINT_MARKETPLACE:1,PRINT_MARKETPLACE_REPLACEMENT:1,VIEW_COUNT:1,POST_TO:1,GAPLUS:1,PICASA_PROMO:1,DOUBLECLICK_PREMIUM_ADS:1,DOUBLECLICK_EXPLORE_MAIN:1,DOUBLECLICK_MYPHOTOS:1,DOUBLECLICK_PUBLIC_GALLERY:1,DOUBLECLICK_USER_ALBUM:1,DOUBLECLICK_USER_PHOTO:1,DOUBLECLICK_VISITOR_ADS:1,PRODUCTION:1,NOSCRIPT:1,UNLISTED_GALLERY:1,GA_TRACKING:1,UNLIMITED_GALLERY:1,PICNIK_EDIT:1,MICROSCOPE_ZOOM:1,FR_V2:1,FAVORITE_SUGGESTION:1,FAVORITE_UPDATE:1,MERGED_PROFILES_SOFTLAUNCH:1,MERGED_PROFILES:1,MERGED_PROFILES_ASYNC:1,NEW_FR_UI:1,GAPLUS_UNMERGED_SOCIALIZATION:1,OPTOUT_ACL_NOTIFICATION:1,HTTPS_VISIBILITY:1,DEFAULT_HTTPS:1,EXTENDED_EXIF:1,DOUBLECLICK_MULTISLOT:1,ONEPICK:1,PER_ALBUM_GEO_VISIBILITY:1,FOCUS_MERGE_LINK_DIALOG_VISIBILITY:1,SHAREBOX_VISIBILITY:1,AUTO_DOWNSIZE:1,BULK_ALBUM_EDITOR_VISIBILITY:1,PROFILE_NAME_CHECK:1,COLLABORATIVE_NAMETAGS:1,NOT_FOUND_404:1,REDIRECT_TO_PLUS:1},
{
'gdataVersion': '4.0',
'updateCartPath': '\x2Flh\x2FupdateCart?rtok=b8S9ibYqrTMF',
'editCaptionsPath': '',
'albumMapPath': '',
'albumKmlUrl': '',
'selectedPhotosPath': '\x2Flh\x2FselectedPhotos?tok=QUI1UGxRYk9fNmw1Q2tVeS1DWnY3UlFoTTY1RzRNNWphdzoxMzIwNjAyMzA3NDYx',
'setLicensePath': '',
'setStarPath': '\x2Flh\x2FsetStar?tok=QUI1UGxRWW4zY1ZKb3U0TzROZU5tUHhIV3hhRW9HcUYwQToxMzIwNjAyMzA3NDYx',
'peopleManagerPath': '',
'peopleSearchPath': '',
'clusterViewPath': '',
'frOptStatus': 'OptedIn',
'isNameTagsVisible': '','authUserIsPhotosUser': true,
'authUserNickname': 'Some Nickname',
'authUserPortraitUrl': 'https:\x2F\x2Flh4.googleusercontent.com\x2F-UI9ZfIFfyQI\x2FAAAAAAAAAAI\x2FAAAAAAAAAAA\x2Fm0enLvZXYbI\x2Fs32-c\x2Ffirealwaysworks.jpg',
'authUserProfileUrl':'https:\x2F\x2Fprofiles.google.com\x2F115162402406836485912', 'authUser':{name:'firealwaysworks',isProfileUser:1,isLoggedIn:1,user:1,isOwner:1
,'showGeo': 0
},
'foreignNickname': '',
'subjects': [
]
,
'owner': {name:'firealwaysworks',nickname:'Michael Brooks',portrait:'https:\x2F\x2Flh4.googleusercontent.com\x2F-UI9ZfIFfyQI\x2FAAAAAAAAAAI\x2FAAAAAAAAAAA\x2Fm0enLvZXYbI\x2Fs32-c\x2Ffirealwaysworks.jpg',link:'https:\x2F\x2Fpicasaweb.google.com\x2F115162402406836485912',defaultalbumnametagsvisibility:'2'
,isnewstorageuser:false},
'album': {id:'',link:'',name:'',title:'',titleshort:'',kmlLink:'',mapLink:'',showGeo:0},
'picnikHandlerUrl': 'https:\x2F\x2Fpicasaweb.google.com\x2Flh\x2FpicnikHandler?tok=QUI1UGxRYWJYZVVueTE2SjJJLTBjRUliWVlaaU42S0NRQToxMzIwNjAyMzA3NDYx',
'picnikCloseUrl': 'https:\x2F\x2Fpicasaweb.google.com\x2Flh\x2FpicnikClose',
'picnikLocale': 'en_US',
'authUserIsProfileUser': true,
'ownerIsEsUser': false,
'profileServerUrl': '',
'profileSignupUrl': 'https:\x2F\x2Fplus.google.com\x2Fup\x2F?type=st',
'profileName': 'Google+'
});
function google_afs_request_done(google_ads) {
var google_num_ads = google_ads.length;
if (google_num_ads <= 0)
      return;

    var wideAds = '<table width="100%" cellspacing="0" cellpadding="8"' +
        'border="0" class="lhcl_search_ad_tbl"><tbody><tr>';
for(var i = 0; i < google_num_ads; i++){
      if (google_ads[i].type=="text/wide"){
        wideAds += '<td>';
wideAds += '<table width="100%" cellspacing="0" ' +
          'cellpadding="0" border="0"><tbody><tr><td>';
wideAds+='<a href="' + google_ads[i].url + '" ' +
        'onmouseout="window.status=\'\';return true" ' +
        'onmouseover="window.status=\'go to ' +
        google_ads[i].visible_url + '\';return true" ' +
        'style="text-decoration:none">' +
'<span style="text-decoration:underline">' +
'<b>' + google_ads[i].line1 + '</b><br></span>' +
'<span style="color:#000000">' +
google_ads[i].line2 + '<br></span>' +
'<span style="color:#008000">' +
google_ads[i].visible_url + '</span></a><BR>';
wideAds += '</td>';
if (i == google_num_ads - 1) {
wideAds += '<td valign="top">' +
'<div id="lhid_search_ad_spl">Sponsored Links</div></td>';
}
wideAds += '</tr></tbody></table>';
wideAds += '</td>';
}
}
wideAds += '</tr></tbody></table>';
document.getElementById("lhid_search_ad_unit").innerHTML = wideAds;
}
google_afs_query = 'test';
google_afs_ad = 'w3'; // specify the number of ads you are requesting
google_afs_client = 'google-picasa_js'; // substitute your client ID
// google_afs_channel = ''; // enter your comma-separated channel IDs
google_afs_ie = 'utf8'; // select input encoding scheme
google_afs_oe = 'utf8'; // select output encoding scheme
google_afs_adsafe = 'high'; // specify level for filtering non-family-safe ads
google_afs_adtest = 'off'; // ** set parameter to off before launch to production
document.write('<' +
    'script src="https://www.google.com/afsonline/show_afs_ads.js"></' +
    'script>');
</script>

----------
components: Library (Lib)
messages: 147175
nosy: Michael.Brooks
priority: normal
severity: normal
status: open
title: HTMLParser incorrectly handles cdata elements.
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  6 21:13:47 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Sun, 06 Nov 2011 20:13:47 +0000
Subject: [New-bugs-announce] [issue13359] urllib2 doesn't escape spaces in
	http requests
Message-ID: <1320610427.07.0.982938376676.issue13359@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

urllib2.urlopen('http://foo/url and spaces') will send a HTTP request line like this to the server:

GET /url and spaces HTTP/1.1

which the server obviously does not understand. This contrasts with urllib's behaviour which replaces the spaces (' ') in the url with '%20'.

Related: #918368 #1153027

----------
components: Library (Lib)
messages: 147180
nosy: davide.rizzo, orsenthil
priority: normal
severity: normal
status: open
title: urllib2 doesn't escape spaces in http requests
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Nov  6 21:22:12 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 20:22:12 +0000
Subject: [New-bugs-announce] [issue13360] UnicodeWarning raised on dict()
	and set()
Message-ID: <1320610932.39.0.0241525481536.issue13360@psf.upfronthosting.co.za>


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

The UnicodeWarning is raised on some dict or set operations.
It is not very helpful, and sometimes annoying.
And it is somewhat inconsistent.


# ** warning not raised **

$ python2.7 -c "print u'd\xe9' in {'foo', 'bar'}"
False
$ python2.7 -c "print 'd\xe9' in {u'foo', u'bar'}"
False
$ python2.7 -c "print 'd\xc3\xa9' in {u'foo', u'd\xe9'}"
False


# ** warning raised **

$ python2.7 -c "print 'd\xe9' in {u'foo', u'd\xe9'}"
-c:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False
$ python2.7 -c "print u'd\xe9' in {'foo', 'd\xe9'}"
-c:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
False

----------
components: Unicode
messages: 147181
nosy: ezio.melotti, flox
priority: normal
severity: normal
status: open
title: UnicodeWarning raised on dict() and set()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  7 00:46:25 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 06 Nov 2011 23:46:25 +0000
Subject: [New-bugs-announce] [issue13361] getLogger does not check its
	argument
Message-ID: <1320623185.48.0.617067061365.issue13361@psf.upfronthosting.co.za>


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

>>> import logging
>>> log = logging.getLogger(any)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "./Lib/logging/__init__.py", line 1730, in getLogger
    return Logger.manager.getLogger(name)
  File "./Lib/logging/__init__.py", line 1114, in getLogger
    self._fixupParents(rv)
  File "./Lib/logging/__init__.py", line 1142, in _fixupParents
    i = name.rfind(".")
AttributeError: 'builtin_function_or_method' object has no attribute 'rfind'
>>> log = logging.getLogger(any)
>>> log.error("It should not create this logger")
It should not create this logger
>>>

----------
components: Library (Lib)
messages: 147196
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: getLogger does not check its argument
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov  7 04:03:50 2011
From: report at bugs.python.org (skreft)
Date: Mon, 07 Nov 2011 03:03:50 +0000
Subject: [New-bugs-announce] [issue13362] Many PEP 8 errors
Message-ID: <1320635030.75.0.479982438805.issue13362@psf.upfronthosting.co.za>


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

Hi all, I was reading Python's source code and was surprised to find many PEP 8 errors.

The file that I found specially non PEP8 compliant is Lib/encodings/punnycode.py, but there are many others that are not compliant.

I think that this issue should be addressed, since Python's source code should be the model for good Pythonic code.

I would love to contribute on this topic. But since many files would be modified I don't know how to proceed. I see two things that could help to reduce the non compliance of the code. One is to have a website showing the non compliances of each file. And the one I like the most is to have a special test that checks the compliance of the code. The only problem is that it would rely on the external tool pep8 (http://pypi.python.org/pypi/pep8).

Let me know what you think.

Sebastian

----------
messages: 147197
nosy: skreft
priority: normal
severity: normal
status: open
title: Many PEP 8 errors
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Nov  7 04:11:56 2011
From: report at bugs.python.org (skreft)
Date: Mon, 07 Nov 2011 03:11:56 +0000
Subject: [New-bugs-announce] [issue13363] Many usages of dict.keys(),
	dict.values(), dict.items() when the iter version could be used
Message-ID: <1320635516.59.0.95929031171.issue13363@psf.upfronthosting.co.za>


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

In Python 2.7, there are many patterns of the form

for x in mapping.(keys()|values()|items()):
    #code
when the iterator version of those method could be used.
Is there any reason for using those methods?

I see that in some other parts of the code the iterator version is used. Here is the summary:

       Non iter version Iter version
Keys   160              21 
Values 35               23
Items  249              79

I sued the following command

$ egrep -R "for.*[.]iterkeys\(\)" . | wc -l 


What's the position about this? Does it worth it to fix this?

----------
messages: 147199
nosy: skreft
priority: normal
severity: normal
status: open
title: Many usages of dict.keys(), dict.values(), dict.items() when the iter version could be used
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  7 06:14:44 2011
From: report at bugs.python.org (skreft)
Date: Mon, 07 Nov 2011 05:14:44 +0000
Subject: [New-bugs-announce] [issue13364] Duplicated Code
Message-ID: <1320642884.85.0.545330791342.issue13364@psf.upfronthosting.co.za>


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

By using tools like clonedigger is possible to spot some repeated code.
One file that caught my attention is Lib/decimal.py. It has many portions of duplicated code. 

Here is an example:
def logical_or(self, other, context=None):
        """Applies an 'or' operation between self and other's digits."""
        if context is None:
            context = getcontext()

        other = _convert_other(other, raiseit=True)

        if not self._islogical() or not other._islogical():
            return context._raise_error(InvalidOperation)

        # fill to context.prec
        (opa, opb) = self._fill_logical(context, self._int, other._int)

        # make the operation, and clean starting zeroes
        result = "".join([str(int(a)|int(b)) for a,b in zip(opa,opb)])
        return _dec_from_triple(0, result.lstrip('0') or '0', 0)

    def logical_xor(self, other, context=None):
        """Applies an 'xor' operation between self and other's digits."""
        if context is None:
            context = getcontext()

        other = _convert_other(other, raiseit=True)

        if not self._islogical() or not other._islogical():
            return context._raise_error(InvalidOperation)

        # fill to context.prec
        (opa, opb) = self._fill_logical(context, self._int, other._int)

        # make the operation, and clean starting zeroes
        result = "".join([str(int(a)^int(b)) for a,b in zip(opa,opb)])
        return _dec_from_triple(0, result.lstrip('0') or '0', 0)


What's the posture about this? Should this be fixed?

ps: Even more duplicated code is found in python 2.7.

----------
messages: 147201
nosy: skreft
priority: normal
severity: normal
status: open
title: Duplicated Code
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Nov  7 15:23:05 2011
From: report at bugs.python.org (John Feuerstein)
Date: Mon, 07 Nov 2011 14:23:05 +0000
Subject: [New-bugs-announce] [issue13365] str.expandtabs documentation is
	wrong
Message-ID: <1320675785.8.0.972158739581.issue13365@psf.upfronthosting.co.za>


New submission from John Feuerstein <john at feurix.com>:

The documentation for str.expandtabs([tabsize]) is wrong:
 
"Return a copy of the string where all tab characters are replaced by one or more spaces, depending on the current column and the given tab size. [...]"

This should read "zero or more spaces":

>>> 'a\tb'.expandtabs(0)
'ab'
>>> 'a\tb'.expandtabs(-1)
'ab'

The description in Objects/unicodeobject.c does not include this error.

----------
assignee: docs at python
components: Documentation
files: expandtabs_doc.diff
keywords: patch
messages: 147222
nosy: docs at python, john.feuerstein
priority: normal
severity: normal
status: open
title: str.expandtabs documentation is wrong
versions: Python 3.3
Added file: http://bugs.python.org/file23625/expandtabs_doc.diff

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

From report at bugs.python.org  Mon Nov  7 20:02:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Nov 2011 19:02:02 +0000
Subject: [New-bugs-announce] [issue13366] test_pep277 failures under WIndows
Message-ID: <1320692522.11.0.733588257728.issue13366@psf.upfronthosting.co.za>


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

The 3.x Windows buildbots all fail in test_pep277.



======================================================================
FAIL: test_open (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\6_\u306b\u307d\u3093\\*.*' != '@test_2416_tmp\\6_\u306b\u307d\u3093'
- @test_2416_tmp\6_\u306b\u307d\u3093\*.*
?                     ----
+ @test_2416_tmp\6_\u306b\u307d\u3093
 : Function 'listdir('@test_2416_tmp\\6_\u306b\u307d\u3093') failed with bad filename in the exception: '@test_2416_tmp\\6_\u306b\u307d\u3093\\*.*'

======================================================================
FAIL: test_open (test.test_pep277.UnicodeNFCFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\10_\u0385?\\*.*' != '@test_2416_tmp\\10_\u0385?'
- @test_2416_tmp\10_\u0385?\*.*
?                     ----
+ @test_2416_tmp\10_\u0385?
 : Function 'listdir('@test_2416_tmp\\10_\u0385\xb4') failed with bad filename in the exception: '@test_2416_tmp\\10_\u0385\xb4\\*.*'

======================================================================
FAIL: test_open (test.test_pep277.UnicodeNFDFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\9_\u66e8\u05e9\u3093\u0434\u0393?\\*.*' != '@test_2416_tmp\\9_\u66e8\u05e9\u3093\u0434\u0393?'
- @test_2416_tmp\9_\u66e8\u05e9\u3093\u0434\u0393?\*.*
?                        ----
+ @test_2416_tmp\9_\u66e8\u05e9\u3093\u0434\u0393?
 : Function 'listdir('@test_2416_tmp\\9_\u66e8\u05e9\u3093\u0434\u0393\xdf') failed with bad filename in the exception: '@test_2416_tmp\\9_\u66e8\u05e9\u3093\u0434\u0393\xdf\\*.*'

======================================================================
FAIL: test_open (test.test_pep277.UnicodeNFKCFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\17_   A\\*.*' != '@test_2416_tmp\\17_   A'
- @test_2416_tmp\17_   A\*.*
?                       ----
+ @test_2416_tmp\17_   A
 : Function 'listdir('@test_2416_tmp\\17_   A') failed with bad filename in the exception: '@test_2416_tmp\\17_   A\\*.*'

======================================================================
FAIL: test_open (test.test_pep277.UnicodeNFKDFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 125, in test_open
    self._apply_failure(os.listdir, name, NotADirectoryError)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_pep277.py", line 105, in _apply_failure
    (fn.__name__, filename, exc_filename))
AssertionError: '@test_2416_tmp\\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308\\*.*' != '@test_2416_tmp\\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308'
- @test_2416_tmp\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308\*.*
?                          ----
+ @test_2416_tmp\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308
 : Function 'listdir('@test_2416_tmp\\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308') failed with bad filename in the exception: '@test_2416_tmp\\11_ \u0308\u0301\u03a5\u0301\u03a5\u0308\\*.*'

----------
components: Interpreter Core, Tests
messages: 147248
nosy: ezio.melotti, haypo, loewis, pitrou
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: test_pep277 failures under WIndows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  8 03:54:58 2011
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 08 Nov 2011 02:54:58 +0000
Subject: [New-bugs-announce] [issue13367] PyCapsule_New's argument *must*
	not a NULL.
Message-ID: <1320720898.69.0.766220401845.issue13367@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/c-api/capsule.html?highlight=capsule#PyCapsule_New

> The pointer argument may not be NULL.

I think "must not" is correct.

----------
assignee: docs at python
components: Documentation
messages: 147269
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: PyCapsule_New's argument *must* not a NULL.
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  8 04:23:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 08 Nov 2011 03:23:14 +0000
Subject: [New-bugs-announce] [issue13368] Possible problem in documentation
	of module subprocess, method send_signal
Message-ID: <1320722594.89.0.739080107592.issue13368@psf.upfronthosting.co.za>


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

docs@ list report by Daniel Dieterle:

in the documentation (http://docs.python.org/library/subprocess.html#subprocess.Popen.send_signal) is a bug.

CTRL_C_EVENT can not be sent to processes started with a creationflags parameter which includes CREATE_NEW_PROCESS_GROUP. Why can be read in the msdn documentation http://msdn.microsoft.com/en-us/library/windows/desktop/ms683155%28v=vs.85%29.aspx .

A workaround using CTRL_C_EVENT nevertheless is described here:
http://stackoverflow.com/questions/7085604/sending-c-to-python-subprocess-objects-on-windows/7980368#7980368 

--

I do not know why the subprocess.CREATE_NEW_PROCESS_GROUP parameter was introduced. But it is useless for terminating a process with os.kill() in combination with signal.SIGTERM, which corresponds to a CTRL-C-EVENT.
A CTRL-C-EVENT is only forwarded to the process if the process group is zero. Therefore the Note in the documentation on Popen.send_signal() is wrong.

----------
assignee: docs at python
components: Documentation
messages: 147272
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: Possible problem in documentation of module subprocess, method send_signal
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  8 10:57:56 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 08 Nov 2011 09:57:56 +0000
Subject: [New-bugs-announce] [issue13369] timeout with exit code 0 while
	re-running failed tests
Message-ID: <1320746276.61.0.134506088825.issue13369@psf.upfronthosting.co.za>


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

Seen on Windows 7 builder.

http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/3949

This build is considered <green> by buildbot.
Actually, the exit code should not be 0.


(...)
[360/360/4] test_descr
324 tests OK.
4 tests failed:
    test_distutils test_logging test_packaging test_pep277
6 tests altered the execution environment:
    test_multiprocessing test_site test_ssl test_subprocess
    test_sysconfig test_tcl
26 tests skipped:
    test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_epoll
    test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue
    test_nis test_openpty test_ossaudiodev test_pipes test_poll
    test_posix test_pty test_pwd test_readline test_resource
    test_syslog test_threadsignals test_wait3 test_wait4
    test_zipfile64
2 skips unexpected on win32:
    test_gdb test_readline
Re-running failed tests in verbose mode
(...)
test_additional_fixers (packaging.tests.test_mixin2to3.Mixin2to3TestCase) ... ok
test_convert_code_only (packaging.tests.test_mixin2to3.Mixin2to3TestCase) ... program finished with exit code 0
elapsedTime=7325.264000

----------
components: Tests
keywords: buildbot
messages: 147280
nosy: flox
priority: low
severity: normal
stage: needs patch
status: open
title: timeout with exit code 0 while re-running failed tests
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov  8 15:11:14 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Nov 2011 14:11:14 +0000
Subject: [New-bugs-announce] [issue13370] test_ctypes fails on osx 10.7
Message-ID: <1320761474.93.0.268896325495.issue13370@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

test_ctypes fails when building and testing on OSX 10.7 (Lion).

This is likely caused by changes in the compiler w.r.t. the calling convention.  I've worked around this problem in PyObjC, and will try to port that workaround to ctypes.

BTW. Using --with-system-ffi does not fix the issue for me

----------
assignee: ronaldoussoren
components: Macintosh, ctypes
messages: 147299
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ctypes fails on osx 10.7
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Nov  8 15:28:25 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Nov 2011 14:28:25 +0000
Subject: [New-bugs-announce] [issue13371] Some Carbon extensions don't build
	on OSX 10.7
Message-ID: <1320762505.71.0.135818589622.issue13371@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

A number of Carbon wrapper modules don't build on OSX 10.7:

$ make
...

Failed to build these modules:
_Fm                _Qd                _Qdoffs         

This is with '--with-universal-archs=intel', which worked fine on OSX 10.6.

A short part of the compiler output:


/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:26: error: expected ?)? before ?*? token
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_GetFontName?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: ?GetFontName? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: (Each undeclared identifier is reported only once
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:60: error: for each function it appears in.)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:65: warning: implicit declaration of function ?GetFontName?
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_GetFNum?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:78: error: ?GetFNum? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:83: warning: implicit declaration of function ?GetFNum?
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_RealFont?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:97: error: ?RealFont? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:103: warning: implicit declaration of function ?RealFont?
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_SetFScaleDisable?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:115: error: ?SetFScaleDisable? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:120: warning: implicit declaration of function ?SetFScaleDisable?
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c: In function ?Fm_FontMetrics?:
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:129: error: ?FMetricRec? undeclared (first use in this function)
/Users/ronald/Projects/python/rw/2.7/Mac/Modules/fm/_Fmmodule.c:129: error: expected ?;? before ?theMetrics?


Given the modules and failure it seems that a number of (long) deprecated Carbon functions got removed from Apple's header files.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 147304
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Some Carbon extensions don't build on OSX 10.7
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  8 18:32:13 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 08 Nov 2011 17:32:13 +0000
Subject: [New-bugs-announce] [issue13372] handle_close called twice in poll2
Message-ID: <1320773533.14.0.440579615875.issue13372@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When use_poll is True, test_handle_close in test_asyncore.py invokes
twice the handle_close() method.

The attached patch:

    modifies test_handle_close so that it fails when handle_close() is
    called more than once

    includes a fix that makes readwrite() behave like poll(): check
    that the dispatcher instance is still in the socket map, before
    calling the handle_xxx methods

----------
components: Library (Lib)
files: handle_close.diff
keywords: patch
messages: 147311
nosy: giampaolo.rodola, josiahcarlson, neologix, stutzbach, xdegaye
priority: normal
severity: normal
status: open
title: handle_close called twice in poll2
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23634/handle_close.diff

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

From report at bugs.python.org  Tue Nov  8 23:11:28 2011
From: report at bugs.python.org (Arnaud Ysmal)
Date: Tue, 08 Nov 2011 22:11:28 +0000
Subject: [New-bugs-announce] [issue13373] Unexpected blocking call to
	multiprocessing.Queue.get	with a timeout
Message-ID: <1320790288.25.0.363329173413.issue13373@psf.upfronthosting.co.za>


New submission from Arnaud Ysmal <stacktic at netbsd.org>:

Using get(timeout=1) on a multiprocessing.Queue sometimes leads to a blocking get.

It seems that there is no check whether the timeout has expired after acquiring the lock but before the time.time(), which can cause a call to poll() with a negative timeout.

(patch attached)

----------
components: Library (Lib)
files: multiprocessing_queues.patch
keywords: patch
messages: 147319
nosy: stacktic
priority: normal
severity: normal
status: open
title: Unexpected blocking call to multiprocessing.Queue.get with a timeout
type: behavior
Added file: http://bugs.python.org/file23638/multiprocessing_queues.patch

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

From report at bugs.python.org  Wed Nov  9 01:10:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Nov 2011 00:10:06 +0000
Subject: [New-bugs-announce] [issue13374] Deprecate usage of the Windows
	ANSI API in the nt module
Message-ID: <1320797406.95.0.49629588961.issue13374@psf.upfronthosting.co.za>


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

Attached patch deprecates the Windows ANSI API (bytes API) in the nt module. Use Unicode filenames instead of bytes filenames to not depend on the ANSI code page anymore and to support any Unicode filename.

The patch changes also os.link(), os.rename() and os.symlink() to not accept two filenames of different types: require two Unicode filenames or two bytes filenames. It is an expected change, it did it to simplify the source code. I change it if necessary.

----------
components: Library (Lib)
files: deprecate_win_bytes_api.patch
keywords: patch
messages: 147323
nosy: haypo
priority: normal
severity: normal
status: open
title: Deprecate usage of the Windows ANSI API in the nt module
versions: Python 3.3
Added file: http://bugs.python.org/file23640/deprecate_win_bytes_api.patch

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

From report at bugs.python.org  Wed Nov  9 08:22:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Nov 2011 07:22:38 +0000
Subject: [New-bugs-announce] [issue13375] Provide a namedtuple style
	interface for os.walk values
Message-ID: <1320823358.89.0.0610537790817.issue13375@psf.upfronthosting.co.za>


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

The 3-tuple values yielded by os.walk could be made easier to work with in some use cases by offering a namedtuple style interface (similar to what is done with sys.float_info).

for dirinfo in os.walk(base_dir):
    print(dirinfo.path)
    print(dirinfo.subdirs)
    print(dirinfo.files)

----------
messages: 147334
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Provide a namedtuple style interface for os.walk values

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

From report at bugs.python.org  Wed Nov  9 08:59:15 2011
From: report at bugs.python.org (Sam Cates)
Date: Wed, 09 Nov 2011 07:59:15 +0000
Subject: [New-bugs-announce] [issue13376] readline: pre_input_hook not
	getting called
Message-ID: <1320825555.41.0.989618903693.issue13376@psf.upfronthosting.co.za>


New submission from Sam Cates <python.org at samcates.com>:

OS: Mac 10.7.2
Python: 2.7.1

Setting a pre input hook in readline has no effect.  This simple example illustrates the problem:

#!/usr/bin/python

import readline

def hook():
        readline.insert_text(' from pre_input_hook')
        readline.redisplay()

readline.set_pre_input_hook(hook)

while True:
        line = raw_input('Prompt ("stop" to quit): ')
        if line == 'stop':
                break
        print 'ENTERED: "%s"' % line


The hook never gets called, thus "from pre_input_hook" is never displayed.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 147336
nosy: ronaldoussoren, scates
priority: normal
severity: normal
status: open
title: readline: pre_input_hook not getting called
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  9 09:44:01 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 09 Nov 2011 08:44:01 +0000
Subject: [New-bugs-announce] [issue13377] test_codecs "Segmentation fault"
	on Windows
Message-ID: <1320828241.01.0.210282714487.issue13377@psf.upfronthosting.co.za>


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

test_codecs has started failing on Windows: I can't tell if the problem is in the tests.

== CPython 3.3.0a0 (default, Nov 8 2011, 22:34:51) [MSC v.1500 32 bit (Intel)]
==   Windows-7-6.1.7600 little-endian
==   c:\Users\Vinay\Projects\cpython\build\test_python_2612
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0)
[1/1] test_codecs
test_badbom (test.test_codecs.UTF32Test) ... ok
test_bug1098990_a (test.test_codecs.UTF32Test) ... ok
test_bug1098990_b (test.test_codecs.UTF32Test) ... ok
test_bug1175396 (test.test_codecs.UTF32Test) ... ok
test_decoder_state (test.test_codecs.UTF32Test) ... ok
test_errors (test.test_codecs.UTF32Test) ... ok
test_handlers (test.test_codecs.UTF32Test) ... ok
test_issue8941 (test.test_codecs.UTF32Test) ... ok
test_only_one_bom (test.test_codecs.UTF32Test) ... ok
test_partial (test.test_codecs.UTF32Test) ... ok
test_readline (test.test_codecs.UTF32Test) ... ok
test_readlinequeue (test.test_codecs.UTF32Test) ... ok
test_bug1098990_a (test.test_codecs.UTF32LETest) ... ok
test_bug1098990_b (test.test_codecs.UTF32LETest) ... ok
test_bug1175396 (test.test_codecs.UTF32LETest) ... ok
test_errors (test.test_codecs.UTF32LETest) ... ok
test_issue8941 (test.test_codecs.UTF32LETest) ... ok
test_partial (test.test_codecs.UTF32LETest) ... ok
test_readline (test.test_codecs.UTF32LETest) ... ok
test_readlinequeue (test.test_codecs.UTF32LETest) ... ok
test_simple (test.test_codecs.UTF32LETest) ... ok
test_bug1098990_a (test.test_codecs.UTF32BETest) ... ok
test_bug1098990_b (test.test_codecs.UTF32BETest) ... ok
test_bug1175396 (test.test_codecs.UTF32BETest) ... ok
test_errors (test.test_codecs.UTF32BETest) ... ok
test_issue8941 (test.test_codecs.UTF32BETest) ... ok
test_partial (test.test_codecs.UTF32BETest) ... ok
test_readline (test.test_codecs.UTF32BETest) ... ok
test_readlinequeue (test.test_codecs.UTF32BETest) ... ok
test_simple (test.test_codecs.UTF32BETest) ... ok
test_badbom (test.test_codecs.UTF16Test) ... ok
test_bug1098990_a (test.test_codecs.UTF16Test) ... ok
test_bug1098990_b (test.test_codecs.UTF16Test) ... ok
test_bug1175396 (test.test_codecs.UTF16Test) ... ok
test_bug691291 (test.test_codecs.UTF16Test) ... ok
test_decoder_state (test.test_codecs.UTF16Test) ... ok
test_errors (test.test_codecs.UTF16Test) ... ok
test_handlers (test.test_codecs.UTF16Test) ... ok
test_only_one_bom (test.test_codecs.UTF16Test) ... ok
test_partial (test.test_codecs.UTF16Test) ... ok
test_readline (test.test_codecs.UTF16Test) ... ok
test_readlinequeue (test.test_codecs.UTF16Test) ... ok
test_bug1098990_a (test.test_codecs.UTF16LETest) ... ok
test_bug1098990_b (test.test_codecs.UTF16LETest) ... ok
test_bug1175396 (test.test_codecs.UTF16LETest) ... ok
test_errors (test.test_codecs.UTF16LETest) ... ok
test_nonbmp (test.test_codecs.UTF16LETest) ... ok
test_partial (test.test_codecs.UTF16LETest) ... ok
test_readline (test.test_codecs.UTF16LETest) ... ok
test_readlinequeue (test.test_codecs.UTF16LETest) ... ok
test_bug1098990_a (test.test_codecs.UTF16BETest) ... ok
test_bug1098990_b (test.test_codecs.UTF16BETest) ... ok
test_bug1175396 (test.test_codecs.UTF16BETest) ... ok
test_errors (test.test_codecs.UTF16BETest) ... ok
test_nonbmp (test.test_codecs.UTF16BETest) ... ok
test_partial (test.test_codecs.UTF16BETest) ... ok
test_readline (test.test_codecs.UTF16BETest) ... ok
test_readlinequeue (test.test_codecs.UTF16BETest) ... ok
test_bug1098990_a (test.test_codecs.UTF8Test) ... ok
test_bug1098990_b (test.test_codecs.UTF8Test) ... ok
test_bug1175396 (test.test_codecs.UTF8Test) ... ok
test_decoder_state (test.test_codecs.UTF8Test) ... ok
test_lone_surrogates (test.test_codecs.UTF8Test) ... ok
test_partial (test.test_codecs.UTF8Test) ... ok
test_readline (test.test_codecs.UTF8Test) ... ok
test_readlinequeue (test.test_codecs.UTF8Test) ... ok
test_surrogatepass_handler (test.test_codecs.UTF8Test) ... ok
test_bom (test.test_codecs.UTF8SigTest) ... ok
test_bug1098990_a (test.test_codecs.UTF8SigTest) ... ok
test_bug1098990_b (test.test_codecs.UTF8SigTest) ... ok
test_bug1175396 (test.test_codecs.UTF8SigTest) ... ok
test_bug1601501 (test.test_codecs.UTF8SigTest) ... ok
test_partial (test.test_codecs.UTF8SigTest) ... ok
test_readline (test.test_codecs.UTF8SigTest) ... ok
test_readlinequeue (test.test_codecs.UTF8SigTest) ... ok
test_stream_bare (test.test_codecs.UTF8SigTest) ... ok
test_stream_bom (test.test_codecs.UTF8SigTest) ... ok
test_bug1098990_a (test.test_codecs.CP65001Test) ... ok
test_bug1098990_b (test.test_codecs.CP65001Test) ... ok
test_bug1175396 (test.test_codecs.CP65001Test) ... ok
test_decode (test.test_codecs.CP65001Test) ... Fatal Python error: Segmentation fault

Current thread 0x00000a20:
  File "c:\Users\Vinay\Projects\cpython\lib\linecache.py", line 81 in updatecache
  File "c:\Users\Vinay\Projects\cpython\lib\linecache.py", line 41 in getlines
  File "c:\Users\Vinay\Projects\cpython\lib\linecache.py", line 15 in getline
  File "c:\Users\Vinay\Projects\cpython\lib\traceback.py", line 100 in extract_tb
  File "c:\Users\Vinay\Projects\cpython\lib\traceback.py", line 75 in format_tb
  File "c:\Users\Vinay\Projects\cpython\lib\traceback.py", line 186 in format_exception
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\result.py", line 160 in _exc_info_to_string
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\result.py", line 121 in addFailure
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\result.py", line 17 in inner
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\runner.py", line 75 in addFailure
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\case.py", line 452 in run
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\case.py", line 492 in __call__
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\suite.py", line 105 in run
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\suite.py", line 67 in __call__
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\suite.py", line 105 in run
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\suite.py", line 67 in __call__
  File "c:\Users\Vinay\Projects\cpython\lib\unittest\runner.py", line 168 in run
  File "c:\Users\Vinay\Projects\cpython\lib\test\support.py", line 1368 in _run_suite
  File "c:\Users\Vinay\Projects\cpython\lib\test\support.py", line 1402 in run_unittest
  File "c:\Users\Vinay\Projects\cpython\lib\test\test_codecs.py", line 2031 in test_main
  File "../lib/test/regrtest.py", line 1203 in runtest_inner
  File "../lib/test/regrtest.py", line 917 in runtest
  File "../lib/test/regrtest.py", line 709 in main
  File "../lib/test/regrtest.py", line 1780 in <module>

----------
components: Library (Lib), Tests, Windows
messages: 147339
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: test_codecs "Segmentation fault" on Windows
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov  9 23:17:51 2011
From: report at bugs.python.org (Nekmo)
Date: Wed, 09 Nov 2011 22:17:51 +0000
Subject: [New-bugs-announce] [issue13378] Change the variable "nsmap" from
	global to instance	(xml.etree.ElementTree)
Message-ID: <1320877071.09.0.895123668254.issue13378@psf.upfronthosting.co.za>


New submission from Nekmo <nintux at gmail.com>:

Currently, the mapping of namespaces is global and can cause failures if multiple instances are used or in multithreading. The variable is in xml.etree.ElementTree._namespace_map. I ask it to be switched to xml.etree._Element instance.

----------
components: XML
messages: 147378
nosy: Nekmo
priority: normal
severity: normal
status: open
title: Change the variable "nsmap" from global to instance (xml.etree.ElementTree)
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 10 00:24:23 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 09 Nov 2011 23:24:23 +0000
Subject: [New-bugs-announce] [issue13379] Wrong Unicode version in
	unicodedata docstring
Message-ID: <1320881063.48.0.160068391122.issue13379@psf.upfronthosting.co.za>


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

The unicodedata docstring says "5.2" multiple times.


Modules/unicodedata.c:   unicodedata -- Provides access to the Unicode 5.2 data base.
Modules/unicodedata.c:   Data was extracted from the Unicode 5.2 UnicodeData.txt file.
Modules/unicodedata.c:5.2.0 which is publically available from ftp://ftp.unicode.org/.\n\
Modules/unicodedata.c:UnicodeData File Format 5.2.0 (see\n\


However:

>>> import unicodedata
>>> unicodedata.unidata_version
'6.0.0'

----------
components: Unicode
keywords: easy
messages: 147381
nosy: ezio.melotti, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: Wrong Unicode version in unicodedata docstring
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov 10 06:22:41 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 10 Nov 2011 05:22:41 +0000
Subject: [New-bugs-announce] [issue13380] ctypes: add an internal function
	for reseting the ctypes	caches
Message-ID: <1320902561.22.0.487865927239.issue13380@psf.upfronthosting.co.za>


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

Currently it is possible to somewhat easily get false positives for reference leaks when running the ctypes regression tests with -R.  See issue13250 for an example where I got tripped up.  The reason is that the ctypes caches are not cleared in between test runs like they are with some of the other modules that cache objects.

The attached patch adds an internal function for reseting the ctypes caches.  regrtest.py is then fixed up to use it.  Finally, two tests
that previously relied on the caching being present to work in back-to-back runs have been fixed.  In particular, the tests were written to do something like:

# Global
dll = CDLL(_ctypes_test.__file__)

# Local to test
f = dll._testfunc_callback_i_if
f.restype = c_int

MyCallback = CFUNCTYPE(c_int, c_int)

def callback(value)
    return value

cb = MyCallback(callback)
result = f(-10, cb)

f.argtypes = [c_int, MyCallback]
cb = MyCallback(callback)
result = f(-10, cb)

Thus when run in back-to-back runs where caching is cleared in between you effectively get:

# Global
dll = CDLL(_ctypes_test.__file__)

# Local to test
f = dll._testfunc_callback_i_if
f.restype = c_int

MyCallback = CFUNCTYPE(c_int, c_int)

def callback(value):
    return value

cb = MyCallback(callback)
result = f(-10, cb)

f.argtypes = [c_int, MyCallback]
cb = MyCallback(callback)
result = f(-10, cb)

_reset_cache()

f = dll._testfunc_callback_i_if
f.restype = c_int

MyCallback = CFUNCTYPE(c_int, c_int)

cb = MyCallback(callback)
result = f(-10, cb)

which causes:

types.ArgumentError: argument 2: <class 'TypeError'>: expected CFunctionType instance instead of CFunctionType

because the final MyCallback instance passed to f is not of the same type as the MyCallback type saved in f.argtypes.  The fix is to set f.argtypes to None at the beginning of each test.

I would also like to commit this to 2.7 and 3.2.  It will make fixing true reference leaks in those branches easier.

OK?

----------
assignee: meador.inge
components: ctypes
files: ctypes-reset-cache.patch
keywords: patch
messages: 147394
nosy: amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
stage: patch review
status: open
title: ctypes: add an internal function for reseting the ctypes caches
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23651/ctypes-reset-cache.patch

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

From report at bugs.python.org  Thu Nov 10 10:51:07 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Thu, 10 Nov 2011 09:51:07 +0000
Subject: [New-bugs-announce] [issue13381] compile fails to compile a ast
	module object giving a	incomprehensible error
Message-ID: <1320918667.91.0.713083174884.issue13381@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

$ python3.2  -c 'import ast;compile(ast.parse(open("testing/test_keymap.py").read()), "test", "exec")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: AST string must be of type str

note that just compiling the source works fine

----------
files: test_keymap.py
messages: 147401
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: compile fails to compile a ast module object giving a incomprehensible error
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23652/test_keymap.py

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

From report at bugs.python.org  Fri Nov 11 00:41:01 2011
From: report at bugs.python.org (Bill Meng)
Date: Thu, 10 Nov 2011 23:41:01 +0000
Subject: [New-bugs-announce] [issue13382] completions in IDLE
Message-ID: <1320968461.58.0.0904951665186.issue13382@psf.upfronthosting.co.za>


New submission from Bill Meng <avorus at charter.net>:

I'm running Python 2.7 on a Mac OS 10.4
When I select Edit/completions from the menu, only the first 10 appear with a slider to the right. But the slider does not move to see the rest of the list.

----------
components: IDLE
messages: 147414
nosy: cpat
priority: normal
severity: normal
status: open
title: completions in IDLE
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 11 12:49:12 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 11 Nov 2011 11:49:12 +0000
Subject: [New-bugs-announce] [issue13383] UnicodeDecodeError in
	distutils.core.setup when version	is unicode
Message-ID: <1321012152.18.0.159938975919.issue13383@psf.upfronthosting.co.za>


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

If the version or name passed to distutils.core.setup is unicode, this results in a UnicodeDecodeError. Consider this setup.py:

from distutils.core import setup
setup(
        name=u'issue13381',
        version=u'1.0',
        modules=['setup.py'],
)

Run it with python2.7 setup.py sdist --format gztar and you'll get the following:

C:\Python\lib\distutils\dist.py:267: UserWarning: Unknown distribution option: 'modules'
  warnings.warn(msg)
running sdist
running check
warning: check: missing required meta-data: url

warning: check: missing meta-data: either (author and author_email) or (maintainer and maintainer_email) must be supplied

warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)

warning: sdist: standard file not found: should have one of README, README.txt

writing manifest file 'MANIFEST'
copying files to foo-1.0...
copying setup.py -> foo-1.0
Creating tar archive
Traceback (most recent call last):
  File "C:\Users\jaraco\bugs\setup.py", line 6, in <module>
    modules=['setup.py'],
  File "C:\Python\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python\lib\distutils\dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "C:\Python\lib\distutils\dist.py", line 972, in run_command
    cmd_obj.run()
  File "C:\Python\lib\distutils\command\sdist.py", line 168, in run
    self.make_distribution()
  File "C:\Python\lib\distutils\command\sdist.py", line 451, in make_distribution
    owner=self.owner, group=self.group)
  File "C:\Python\lib\distutils\cmd.py", line 392, in make_archive
    owner=owner, group=group)
  File "C:\Python\lib\distutils\archive_util.py", line 237, in make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "C:\Python\lib\distutils\archive_util.py", line 101, in make_tarball
    tar = tarfile.open(archive_name, 'w|%s' % tar_compression[compress])
  File "C:\Python\lib\tarfile.py", line 1687, in open
    _Stream(name, filemode, comptype, fileobj, bufsize),
  File "C:\Python\lib\tarfile.py", line 431, in __init__
    self._init_write_gz()
  File "C:\Python\lib\tarfile.py", line 459, in _init_write_gz
    self.__write(self.name + NUL)
  File "C:\Python\lib\tarfile.py", line 475, in __write
    self.buf += s
UnicodeDecodeError: 'ascii' codec can't decode byte 0x8b in position 1: ordinal not in range(128)


Since tarfile doesn't support unicode filenames, distutils should encode the generated filename. issue8396 suggests encoding using sys.getfilesystemencoding().

----------
assignee: tarek
components: Distutils
messages: 147427
nosy: eric.araujo, jason.coombs, tarek
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in distutils.core.setup when version is unicode
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 11 16:19:46 2011
From: report at bugs.python.org (Robert Xiao)
Date: Fri, 11 Nov 2011 15:19:46 +0000
Subject: [New-bugs-announce] [issue13384] Unnecessary __future__ import in
	random module
Message-ID: <1321024786.01.0.759110473236.issue13384@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

Lib/random.py in Python 3.2 contains the line

from __future__ import division

even though it is no longer necessary, as true float division is the default in Python 3.

Trivial patch:

--- lib/python3.2/random.py	2011-09-03 20:32:05.000000000 -0400
+++ lib/python3.2/random.py	2011-11-11 11:11:11.000000000 -0400
@@ -36,7 +36,6 @@
 
 """
 
-from __future__ import division
 from warnings import warn as _warn
 from types import MethodType as _MethodType, BuiltinMethodType as _BuiltinMethodType
 from math import log as _log, exp as _exp, pi as _pi, e as _e, ceil as _ceil

----------
components: Library (Lib)
messages: 147437
nosy: nneonneo
priority: normal
severity: normal
status: open
title: Unnecessary __future__ import in random module
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 11 20:39:16 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 11 Nov 2011 19:39:16 +0000
Subject: [New-bugs-announce] [issue13385] Add an explicit re.NOFLAGS flag
	value to the re module
Message-ID: <1321040356.1.0.483749785774.issue13385@psf.upfronthosting.co.za>


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

The flags 're' accept are numeric underneath, and the current value of "no flags" is just 0, which is also specified in the documentation as the default value. However, using raw numeric values is not a good programming practice. 

The suggestion is to add a simple re.NOFLAGS constant to the 're' module with the value of 0, and use it in the documentation instead of plain 0. It's a simple change that won't break anything and may provide better readability for some code, as well as remove the need for plain integer references in the documentation.

See also issues #11957 and #12875.

Adding to nosy people taking part in discussion of the aforementioned issue. If you're not interested, please remove yourself - I apologize in advance.

----------
components: Library (Lib), Regular Expressions
messages: 147443
nosy: eli.bendersky, eric.araujo, eric.smith, ezio.melotti, terry.reedy
priority: normal
severity: normal
status: open
title: Add an explicit re.NOFLAGS flag value to the re module
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov 12 07:08:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Nov 2011 06:08:41 +0000
Subject: [New-bugs-announce] [issue13386] Document documentation conventions
	for optional args
Message-ID: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>


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

AFAIU the conventions for optional argument in the doc are as follow:

If a function has optional arguments and it accepts keyword arguments, the "func(arg=default)" notation should be used, for example:
  str.splitlines(keepends=False)

If a function has optional arguments but it doesn't accept keyword arguments, the "func([arg1])" notation is used instead.  This should apply only to some C functions, for example:
  str.strip([chars])

The notation "func([arg=default])" should never be used, and "func([arg])" should be used only when keyword args are not accepted.

These rules apply to both Python 2 and Python 3.

A thing that is still not clear is what to do in case the default value is a placeholder (like object(), None, -1) and the actual value is then computed in the function.

----------
assignee: docs at python
components: Documentation
messages: 147469
nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: Document documentation conventions for optional args
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Nov 12 13:43:22 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 12 Nov 2011 12:43:22 +0000
Subject: [New-bugs-announce] [issue13387] add exact_type argument to
	assertIsInstance
Message-ID: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>


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

Sometimes we want to check the exact type of an object.
The method assertIsInstance could be misleading in such case.

The current workaround is:
assertIs(type(obj), some_class)

However we can add an argument to the method to keep the benefit of  having a nice failure message.

Examples:
  assertIsInstance(stdobj, dict, exact_type=True)
  assertIsInstance(myobj, dict, exact_type=MyDict)

----------
components: Tests
messages: 147480
nosy: flox, georg.brandl, michael.foord
priority: normal
severity: normal
status: open
title: add exact_type argument to assertIsInstance
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov 12 19:46:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 12 Nov 2011 18:46:30 +0000
Subject: [New-bugs-announce] [issue13388] document hg commit hooks in the
	devguide
Message-ID: <1321123590.65.0.736191202752.issue13388@psf.upfronthosting.co.za>


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

----
Our Hg repo has some useful hooks on commit messages that allow to
specify which issue to notify for commits, and which issue to close.
AFAIU, it's currently documented only in the code of the hook
(http://hg.python.org/hooks/file/tip/hgroundup.py).

I think adding a short description into the devguide would be a good
idea, probably here:
http://docs.python.org/devguide/committing.html#commit-messages-and-news-entries
----

+1d by Brett and Georg on pydev. I'll prepare a patch.

----------
assignee: eli.bendersky
components: Devguide
messages: 147520
nosy: brett.cannon, eli.bendersky, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: document hg commit hooks in the devguide

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

From report at bugs.python.org  Sun Nov 13 00:17:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:17:14 +0000
Subject: [New-bugs-announce] [issue13389] Clear lists freelist in
	gc.collect()
Message-ID: <1321139834.96.0.0231630453756.issue13389@psf.upfronthosting.co.za>


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

Complete gc collections currently clear all freelists, except for the freelist of list objects. Attached patch fixes the omission.

----------
components: Interpreter Core
files: listfreelist.patch
keywords: patch
messages: 147530
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Clear lists freelist in gc.collect()
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23670/listfreelist.patch

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

From report at bugs.python.org  Sun Nov 13 00:24:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Nov 2011 23:24:29 +0000
Subject: [New-bugs-announce] [issue13390] Hunt memory allocations in
	addition to reference leaks
Message-ID: <1321140269.61.0.335726830367.issue13390@psf.upfronthosting.co.za>


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

This patch adds a counting of the number of allocated memory blocks (through the PyObject_Malloc API). Together with -R, it can help chase those memory leaks which aren't reference leaks (see c6dafa2e2594).

The sys.getallocedblocks() function is also available in non-debug mode. This is meant to help 3rd party extension writers, who rarely have access to debug builds.

To avoid too many false positives, issue13389 is a prerequisite (at least for the "test -R" part of the patch). Even after it, there are still a couple "test -R" failures; we'd have to investigate them.

----------
components: Interpreter Core, Tests
files: debugblocks.patch
keywords: patch
messages: 147531
nosy: ncoghlan, pitrou, tim_one
priority: normal
severity: normal
stage: patch review
status: open
title: Hunt memory allocations in addition to reference leaks
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23671/debugblocks.patch

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

From report at bugs.python.org  Sun Nov 13 01:45:22 2011
From: report at bugs.python.org (Dave Mankoff)
Date: Sun, 13 Nov 2011 00:45:22 +0000
Subject: [New-bugs-announce] [issue13391] string.strip Does Not Remove
	Zero-Width-Space (ZWSP)
Message-ID: <1321145122.08.0.463222804165.issue13391@psf.upfronthosting.co.za>


New submission from Dave Mankoff <mankyd at gmail.com>:

Title pretty much says it all. Simple test case:

>>> len(u' \t\r\n\u200B'.strip())
1

Should be zero.

Same problem in Python3:

>>> len(' \t\r\n\u200B'.strip())
1

----------
components: Unicode
messages: 147538
nosy: ezio.melotti, mankyd
priority: normal
severity: normal
status: open
title: string.strip Does Not Remove Zero-Width-Space (ZWSP)
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Nov 13 02:20:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 01:20:52 +0000
Subject: [New-bugs-announce] [issue13392] Writing a pyc file is not atomic
	under Windows
Message-ID: <1321147252.88.0.159545157159.issue13392@psf.upfronthosting.co.za>


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

#13146 solved the issue of writing pyc files under POSIX. Under Windows, the problem still exists, as the following buildbot failure shows:

[317/360] test_multiprocessing
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 373, in main
    prepare(preparation_data)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 499, in prepare
    '__parents_main__', file, path_name, etc
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\regrtest.py", line 175, in <module>
    import packaging.command
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\command\__init__.py", line 4, in <module>
    from packaging.util import resolve_name
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\util.py", line 5, in <module>
    import csv
EOFError: EOF read where not expected
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 373, in main
    prepare(preparation_data)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\forking.py", line 499, in prepare
    '__parents_main__', file, path_name, etc
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\regrtest.py", line 175, in <module>
    import packaging.command
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\command\__init__.py", line 4, in <module>
    from packaging.util import resolve_name
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\util.py", line 5, in <module>
    import csv
EOFError: EOF read where not expected
[etc.]

(from http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5551/steps/test/logs/stdio)

Attached patch uses MoveFileEx to perform a (hopefully atomic) rename from a temporary file when creating the pyc file.
The same strategy cannot be created for importlib since MoveFileEx isn't exposed at the Python level (we could delete the tmp file if renaming fails, though; it simply means another process beat us to it, which shouldn't be a problem here).

----------
components: Interpreter Core
files: winimport.patch
keywords: patch
messages: 147540
nosy: brett.cannon, haypo, ncoghlan, neologix, pitrou, python-dev, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Writing a pyc file is not atomic under Windows
versions: Python 3.3
Added file: http://bugs.python.org/file23674/winimport.patch

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

From report at bugs.python.org  Sun Nov 13 05:15:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Nov 2011 04:15:01 +0000
Subject: [New-bugs-announce] [issue13393] Improve BufferedReader.read1()
Message-ID: <1321157701.74.0.443809978111.issue13393@psf.upfronthosting.co.za>


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

The main current user of BufferedReader.read1() is TextIOWrapper. In this context, read1() is used to signal that we want to bypass binary buffering as much as possible, since TextIOWrapper does its own buffering. The current read1() implementation is therefore suboptimal: it copies data around, and limits the number of bytes that you're allowed to get in one call (even if the raw stream would satisfy more).

Attached patch improves read1() in this respect. Also, a separate modification of TextIOWrapper is needed to take advantage of it, which I will attach in another patch.

----------
components: IO, Library (Lib)
files: bufioread1.patch
keywords: patch
messages: 147549
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Improve BufferedReader.read1()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23675/bufioread1.patch

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

From report at bugs.python.org  Sun Nov 13 08:34:19 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 13 Nov 2011 07:34:19 +0000
Subject: [New-bugs-announce] [issue13394] Patch to increase aifc lib test
	coverage with couple of	minor fixes
Message-ID: <1321169659.12.0.870815067565.issue13394@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

I've increased coverage of aifc.py by test_aifc.py:

before:
[1/1] test_aifc
lines   cov%   module   (path)
  560    63%   aifc   (/Users/family/Documents/code/python/repo/Lib/aifc.py)
...

after:
[1/1] test_aifc
lines   cov%   module   (path)
  561    82%   aifc   (/Users/family/Documents/code/python/repo/Lib/aifc.py)
...

I have also encountered couple of problems in aifc.py:
1. When using setmark() with string name to write to aiff file, you get Exception TypeError: "'str' does not support the buffer interface".
2. When using close() of Aifc_write object, it attempts to close it again in __del__() which ends with ValueError: write to closed file.

I propose following solutions to above problems in patch attached:
1. Use bytes type for mark names, because entire aifc library already uses bytes anyway.
2. Make file pointer check in close() and reset it after actually closing the file.

I don't think that these fixes will cause major backward compatibility problems, because with current version of aifc there is no way to write markers at all anyway.

I plan to increase test coverage of aifc.py further in subsequent patches. Just want to make it in several small steps :-)

Please provide any feedback regarding to what should I do to make this patch committed.

Thanks!

----------
components: Library (Lib), Tests
files: test_aifc.patch
keywords: patch
messages: 147550
nosy: Oleg.Plakhotnyuk
priority: normal
severity: normal
status: open
title: Patch to increase aifc lib test coverage with couple of minor fixes
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file23677/test_aifc.patch

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

From report at bugs.python.org  Sun Nov 13 09:26:23 2011
From: report at bugs.python.org (Hugo Silva)
Date: Sun, 13 Nov 2011 08:26:23 +0000
Subject: [New-bugs-announce] [issue13395] Python ISO-8859-1 encoding problem
Message-ID: <1321172783.32.0.41912586077.issue13395@psf.upfronthosting.co.za>


New submission from Hugo Silva <hugoslv at gmail.com>:

Hi all,

I'm facing a huge encoding problem in Python when dealing with ISO-8859-1 / Latin-1 character set.

When using os.listdir to get the contents of a folder I'm getting the strings encoded in ISO-8859-1 (ex: ''Ol\xe1 Mundo''), however in the Python interpreter the same string is encoded to a different charset:

In : 'Ol? Mundo'.decode('latin-1')
Out: u'Ol\xa0 Mundo'

How can I force Python to decode the string to the same format. I've seen that os.listdir is returning the strings correctly encoded but the interpreter is not ('?' character corresponds to '\xe1' in ISO-8859-1, not to '\xa0'):

http://en.wikipedia.org/wiki/ISO/IEC_8859-1

This is happening 

Any thoughts on how to overcome ?

Regards,

----------
components: Unicode
messages: 147552
nosy: Hugo.Silva, ezio.melotti
priority: normal
severity: normal
status: open
title: Python ISO-8859-1 encoding problem
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 13 17:43:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 13 Nov 2011 16:43:41 +0000
Subject: [New-bugs-announce] [issue13396] new method random.getrandbytes()
Message-ID: <1321202621.61.0.74333018382.issue13396@psf.upfronthosting.co.za>


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

I noticed that several usages of random.getrandbits() actually need bytes.  A few examples:
- Lib/test/test_zlib.py calls "random.getrandbits(8 * _1M).to_bytes()"
- Twisted uses the %x format and then call .decode('hex')
Another examples found with Code Search:
- struct.pack("Q", random.getrandbits(64))
- for i in range(8): ClientChallenge+= chr(random.getrandbits(8))
- key = sha1(str(random.getrandbits(8*20))).digest()

random.getrandbits() itself is not a cheap call: it ends with a call to _PyLong_FromByteArray, and transformation to bytes will involve more copy, conversions from 30bit digits (or 15bit digits) to bytes, or worse.

This patch adds random.getrandbytes(), which creates a bytes string directly from calls to genrand_int32().

----------
files: getrandbytes.patch
keywords: patch
messages: 147557
nosy: amaury.forgeotdarc, rhettinger
priority: normal
severity: normal
status: open
title: new method random.getrandbytes()
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23679/getrandbytes.patch

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

From report at bugs.python.org  Sun Nov 13 22:00:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2011 21:00:30 +0000
Subject: [New-bugs-announce] [issue13397] Option for XMLRPC clients to
	automatically transform	Fault exceptions into standard exceptions
Message-ID: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>


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

Currently, an XMLRPC client communicating with a server running Python can make Python style calls but exceptions get collapsed into a standard FaultException making it difficult to program in a Pythonic style:

proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
try:
    value = proxy.lookup('somekey')
except xmlrpc.client.Fault as err:
    if err.faultCode == 1 and 'KeyError' in err.faultString:
        k = re.search(r":.(\w+)' not found$", err.faultString).groups(1)
        raise KeyError(k)
 
It would be better if we could do this automatically (search for a pure python exception of the same name and raise it instead of a Fault):

proxy = xmlrpc.client.ServerProxy("http://localhost:8000/", python_exceptions=True)

try:
   value = proxy.lookup('somekey')
except KeyError as e:
   ...

----------
messages: 147572
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Option for XMLRPC clients to automatically transform Fault exceptions into standard exceptions
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 14 00:16:56 2011
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Sun, 13 Nov 2011 23:16:56 +0000
Subject: [New-bugs-announce] [issue13398] _cursesmodule missing Python.h on
	Solaris
Message-ID: <1321226216.89.0.228790993845.issue13398@psf.upfronthosting.co.za>


New submission from Maciej Blizi?ski <maciej.blizinski at gmail.com>:

Compilation of Python 3.2.2 fails on Solaris 9 as follows:

/opt/SUNWspro/bin/cc  -xcode=pic32 -xO3 -m32 -xarch=v8 -I/opt/csw/include  -c ./Modules/_cursesmodule.c -o Modules/_cursesmodule.o
"./Modules/_cursesmodule.c", line 105: cannot find include file: "Python.h"
"./Modules/_cursesmodule.c", line 117: cannot find include file: "py_curses.h"
"./Modules/_cursesmodule.c", line 130: warning: no explicit type given
"./Modules/_cursesmodule.c", line 130: syntax error before or at: attr_t
"./Modules/_cursesmodule.c", line 130: warning: old-style declaration or incorrect type for: attr_t
"./Modules/_cursesmodule.c", line 139: warning: no explicit type given
"./Modules/_cursesmodule.c", line 139: syntax error before or at: *
(...)

The problem seems to be a missing -I flag for the compiler, pointing at the Include directory in Python sources.

----------
components: Build
messages: 147578
nosy: automatthias
priority: normal
severity: normal
status: open
title: _cursesmodule missing Python.h on Solaris
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 14 15:34:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 14:34:28 +0000
Subject: [New-bugs-announce] [issue13399] Don't print traceback for
	recognized options in packaging
Message-ID: <1321281268.02.0.339671708656.issue13399@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ python3.3 setup.py build --some-option
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --some-option not recognized
$ pysetup3.3 run build --some-option
option --some-option not recognized
Traceback (most recent call last):
  File "/usr/lib64/python3.3/packaging/fancy_getopt.py", line 239, in getopt
    opts, args = getopt.getopt(args, short_opts, self.long_opts)
  File "/usr/lib64/python3.3/getopt.py", line 93, in getopt
    opts, args = do_longs(opts, args[0][2:], longopts, args[1:])
  File "/usr/lib64/python3.3/getopt.py", line 157, in do_longs
    has_arg, opt = long_has_args(opt, longopts)
  File "/usr/lib64/python3.3/getopt.py", line 174, in long_has_args
    raise GetoptError(_('option --%s not recognized') % opt, opt)
getopt.GetoptError: option --some-option not recognized

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.3/packaging/run.py", line 653, in main
    return dispatcher()
  File "/usr/lib64/python3.3/packaging/run.py", line 642, in __call__
    return func(self, self.args)
  File "/usr/lib64/python3.3/packaging/run.py", line 91, in wrapper
    return f(*args, **kwargs)
  File "/usr/lib64/python3.3/packaging/run.py", line 271, in _run
    args = dispatcher._parse_command_opts(parser, args)
  File "/usr/lib64/python3.3/packaging/run.py", line 491, in _parse_command_opts
    args, opts = parser.getopt(args[1:])
  File "/usr/lib64/python3.3/packaging/fancy_getopt.py", line 241, in getopt
    raise PackagingArgError(msg)
packaging.errors.PackagingArgError: option --some-option not recognized

----------
assignee: tarek
components: Distutils2
keywords: easy
messages: 147599
nosy: Arfrever, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Don't print traceback for recognized options in packaging
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 14 15:40:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 14:40:23 +0000
Subject: [New-bugs-announce] [issue13400] packaging: build command should
	accept --compile, --no-compile and --optimize options
Message-ID: <1321281623.21.0.854677924579.issue13400@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

build command of packaging should accept --compile, --no-compile and --optimize options and pass them to build_py command.

----------
assignee: tarek
components: Distutils2
keywords: easy
messages: 147600
nosy: Arfrever, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: packaging: build command should accept --compile, --no-compile and --optimize options
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 14 16:20:11 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 14 Nov 2011 15:20:11 +0000
Subject: [New-bugs-announce] [issue13401] test_argparse fails with root
	permissions
Message-ID: <1321284011.15.0.976219743674.issue13401@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ python3.3 -B -m test.test_argparse
...
======================================================================
FAIL: test_failures_many_groups_listargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_many_groups_sysargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_listargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_no_groups_sysargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_listargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

======================================================================
FAIL: test_failures_one_group_sysargs (__main__.TestFileTypeW)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_argparse.py", line 216, in wrapper
    test_func(self)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 235, in test_failures
    raises(ArgumentParserError, parser.parse_args, args)
AssertionError: ArgumentParserError not raised by parse_args

----------------------------------------------------------------------
Ran 1611 tests in 8.405s

FAILED (failures=6)
Traceback (most recent call last):
  File "/usr/lib64/python3.3/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib64/python3.3/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/usr/lib64/python3.3/test/test_argparse.py", line 4773, in <module>
    test_main()
  File "/usr/lib64/python3.3/test/test_argparse.py", line 4765, in test_main
    support.run_unittest(__name__)
  File "/usr/lib64/python3.3/test/support.py", line 1402, in run_unittest
    _run_suite(suite)
  File "/usr/lib64/python3.3/test/support.py", line 1377, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

----------
components: Tests
keywords: easy
messages: 147602
nosy: Arfrever, bethard
priority: normal
severity: normal
status: open
title: test_argparse fails with root permissions
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 14 17:50:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Nov 2011 16:50:37 +0000
Subject: [New-bugs-announce] [issue13402] Document absoluteness of
	sys.executable
Message-ID: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>


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

I wanted to know if sys.executable was always an absolute path but the doc does not talk about that.

(My use case is that I?d like to reload a process and I wonder if I can call os.execve or if I need to use os.execvpe.)

----------
assignee: docs at python
components: Documentation
messages: 147609
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: Document absoluteness of sys.executable
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 14 18:29:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Nov 2011 17:29:27 +0000
Subject: [New-bugs-announce] [issue13403] Option for XMLPRC Server to
	support HTTPS
Message-ID: <1321291767.37.0.486686259371.issue13403@psf.upfronthosting.co.za>


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

The xmlrpc.client module supports secure transport using https; however, the xmlrpc.server does not have an https option.

Adding this support isn't difficult.  Here's an example of how to it could be implemented:  http://code.activestate.com/recipes/496786-simple-xml-rpc-server-over-https/

----------
components: Library (Lib)
messages: 147622
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Option for XMLPRC Server to support HTTPS
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 14 18:33:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Nov 2011 17:33:42 +0000
Subject: [New-bugs-announce] [issue13404] Add support for
	system.methodSignature() to XMLRPC Server
Message-ID: <1321292022.85.0.26720578121.issue13404@psf.upfronthosting.co.za>


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

Currently, the server has a stub method that returns: 'signatures not supported'.

Using the inspect module, it shouldn't be difficult to provide function/method signatures for over-the-wire introspection.

----------
components: Library (Lib)
messages: 147623
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add support for system.methodSignature() to XMLRPC Server
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 14 20:42:06 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 14 Nov 2011 19:42:06 +0000
Subject: [New-bugs-announce] [issue13405] Add DTrace probes
Message-ID: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

I want this to 3.3. I will concentrate in DTrace under Solaris and derivatives, for now. No SystemTap.

Original details, useful for context: issue4111.

My reference is going to be Solaris/OpenIndiana patches for Python DTrace support.

----------
assignee: jcea
components: Interpreter Core
messages: 147627
nosy: jcea
priority: normal
severity: normal
status: open
title: Add DTrace probes
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov 15 00:12:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Nov 2011 23:12:00 +0000
Subject: [New-bugs-announce] [issue13406] Deprecation warnings when running
	the test suite
Message-ID: <1321312320.0.0.525763918067.issue13406@psf.upfronthosting.co.za>


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

Now that the unicode-internal codec is deprecated, the test suite spouts some warning (in test_codecs, test_codeccallbacks and test_unicode). Example:

[344/361] test_codecs
/home/antoine/cpython/default/Lib/test/test_codecs.py:1024: DeprecationWarning: unicode_internal codecs has been deprecated
  self.assertEqual(uni, internal.decode("unicode_internal"))
/home/antoine/cpython/default/Lib/unittest/case.py:135: DeprecationWarning: unicode_internal codecs has been deprecated
  callable_obj(*args, **kwargs)
/home/antoine/cpython/default/Lib/test/test_codecs.py:1047: DeprecationWarning: unicode_internal codecs has been deprecated
  ab = "ab".encode("unicode_internal").decode()
/home/antoine/cpython/default/Lib/test/test_codecs.py:1050: DeprecationWarning: unicode_internal codecs has been deprecated
  "UnicodeInternalTest")
/home/antoine/cpython/default/Lib/test/test_codecs.py:1034: DeprecationWarning: unicode_internal codecs has been deprecated
  b"\x00\x00\x00\x00\x00\x11\x11\x00".decode("unicode_internal")
/home/antoine/cpython/default/Lib/test/test_codecs.py:1056: DeprecationWarning: unicode_internal codecs has been deprecated
  self.assertEqual(encoder("a")[1], 1)
/home/antoine/cpython/default/Lib/test/test_codecs.py:1057: DeprecationWarning: unicode_internal codecs has been deprecated
  self.assertEqual(encoder("\xe9\u0142")[1], 2)
/home/antoine/cpython/default/Lib/test/test_codecs.py:1515: DeprecationWarning: unicode_internal codecs has been deprecated
  (b, size) = codecs.getencoder(encoding)(s)
/home/antoine/cpython/default/Lib/test/test_codecs.py:1517: DeprecationWarning: unicode_internal codecs has been deprecated
  (chars, size) = codecs.getdecoder(encoding)(b)

----------
components: Tests
keywords: easy
messages: 147637
nosy: ezio.melotti, haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecation warnings when running the test suite
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov 15 11:29:21 2011
From: report at bugs.python.org (sengels)
Date: Tue, 15 Nov 2011 10:29:21 +0000
Subject: [New-bugs-announce] [issue13407] tarfile.getmembers misses members
	again
Message-ID: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>


New submission from sengels <ps_ml at gmx.de>:

This bug seems to be related to http://bugs.python.org/issue13158

When I try to run the following code:

import tarfile

tf = tarfile.open("kdelibs-4.7.3.tar.bz2", "r")
print(len(tf.getnames()))

against this tarball: http://www.winkde.org/pub/kde/ports/win32/repository/other/kdelibs-4.7.3.tar.bz2 it will output 150 members. This is not enough and other tools like 7zip or bsdtar report a lot more (should be around 9237).

----------
messages: 147663
nosy: sengels
priority: normal
severity: normal
status: open
title: tarfile.getmembers misses members again
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Nov 15 14:02:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Nov 2011 13:02:27 +0000
Subject: [New-bugs-announce] [issue13408] Rename packaging.resources back to
	datafiles
Message-ID: <1321362147.83.0.710071986655.issue13408@psf.upfronthosting.co.za>


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

The code dealing with the new resources subsystem used to be called datafiles (module distutils2.datafiles, file dist-info/DATAFILES, etc.).  I believe it is a better name and we should use it again:

- it would make clear that it?s an evolution of distutils? data_files
- it would make clear that it?s related to install_data and data_files

?resources? is overly vague and ambiguous.  It can refer to natural resources, computer resources, links to more information, etc.  ?data files? is less vague and less abstract: it refers to files that are not modules, scripts or C files.

----------
assignee: tarek
components: Distutils2
messages: 147665
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Rename packaging.resources back to datafiles
versions: 3rd party, Python 3.3

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

From report at bugs.python.org  Tue Nov 15 20:01:14 2011
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Le=C5=9Bniewski?=)
Date: Tue, 15 Nov 2011 19:01:14 +0000
Subject: [New-bugs-announce] [issue13409] Invalid expression error if a
	regex ends with a backslash
Message-ID: <1321383674.07.0.558206383571.issue13409@psf.upfronthosting.co.za>


New submission from Micha? Le?niewski <mlesniew at gmail.com>:

If a regular expression ends with a backslash, an exception is raised. Of course, the backslash has to be escaped. The simplest example, that causes the error is a regular expression, that should match only a single backslash:

    import re
    r = re.compile("\\")

----------
components: Regular Expressions
messages: 147696
nosy: ezio.melotti, mlesniew
priority: normal
severity: normal
status: open
title: Invalid expression error if a regex ends with a backslash
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov 15 23:04:50 2011
From: report at bugs.python.org (Jayanth Raman)
Date: Tue, 15 Nov 2011 22:04:50 +0000
Subject: [New-bugs-announce] [issue13410] String formatting bug in
	interactive mode
Message-ID: <1321394690.57.0.254973831289.issue13410@psf.upfronthosting.co.za>


New submission from Jayanth Raman <raman.jayanth at gmail.com>:

With file xx.py:

class Foo(object):
    def __init__(self, x):
        self.x = x
    def __long__(self):
        return long(self.x)
    def __float__(self):
        return float(self.x)
y = Foo(22)
print '%d' % y
print '%d' % y


Interactive mode:

$ python -V
Python 2.6.7
$ python -i xx.py
22
22
>>>
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'
>>> '%d' % y
'22'
>>> '%d' % y
TypeError: int() argument must be a string or a number, not 'Foo'

It alternates between printing '22' and print a TypeError message.  Expected it to be consistent.

Also, the first carraige-return (with no input) results in an error message.  Did not expect an error message.  In fact, typing pretty much anything (e.g. an undefined variable or raise(Exception())) results in the same error message.

On Mac OS X Darwin Kernel Version 10.8.0
Python 2.6.7 (r267:88850, Jul  6 2011, 13:57:37) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

Thanks.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 147711
nosy: jayanth, ronaldoussoren
priority: normal
severity: normal
status: open
title: String formatting bug in interactive mode
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Nov 15 23:20:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Nov 2011 22:20:43 +0000
Subject: [New-bugs-announce] [issue13411] Hashable memoryviews
Message-ID: <1321395643.62.0.259606214561.issue13411@psf.upfronthosting.co.za>


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

This patch allows hashing of memoryviews, as discussed on python-dev.

----------
components: Interpreter Core
files: memhash.patch
keywords: patch
messages: 147714
nosy: ncoghlan, pitrou, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Hashable memoryviews
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23697/memhash.patch

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

From report at bugs.python.org  Tue Nov 15 23:36:42 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Tue, 15 Nov 2011 22:36:42 +0000
Subject: [New-bugs-announce] [issue13412] No knowledge of symlinks on Windows
Message-ID: <1321396602.6.0.583941827853.issue13412@psf.upfronthosting.co.za>


New submission from Alex Regueiro <alexreg at gmail.com>:

Python 2.7 has no knowledge of directory symlinks on Windows 7. Listing a directory symlink does not work, nor does accessing a file within one. This is quite a notable missing feature on Windows 7, where symlinks are becoming increasingly prevalent.

----------
components: IO
messages: 147715
nosy: alexreg
priority: normal
severity: normal
status: open
title: No knowledge of symlinks on Windows
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 16 08:49:24 2011
From: report at bugs.python.org (Dmitry Balabanov)
Date: Wed, 16 Nov 2011 07:49:24 +0000
Subject: [New-bugs-announce] [issue13413] time.daylight incorrect behavior
	in linux glibc
Message-ID: <1321429764.54.0.0162746927464.issue13413@psf.upfronthosting.co.za>


New submission from Dmitry Balabanov <dimonb at gmail.com>:

In Europe/Moscow timezone:
>> import time
>> time.daylight
1
>>> time.timezone
-10800

But if compile and run attached program result would be:
timezone: -14400, daylight: 0

Daylight is not applicable in Europe/Moscow timezone from this winter. But python detect daylight flag as differences between January and July localtime. 

Why not tzset()?

----------
files: daylight.c
messages: 147752
nosy: dimonb
priority: normal
severity: normal
status: open
title: time.daylight incorrect behavior in linux glibc
type: behavior
Added file: http://bugs.python.org/file23704/daylight.c

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

From report at bugs.python.org  Wed Nov 16 10:45:11 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 16 Nov 2011 09:45:11 +0000
Subject: [New-bugs-announce] [issue13414] test_strftime failed on OpenBSD
Message-ID: <1321436711.11.0.148655032298.issue13414@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hello,

I was running test_datetime.py and it failed on OpenBSD.
I have tested with Python 2.7, Python 3.2 and Python 3.3.

Python 2.7:
test_datetime.py: ok
test_srtftime.py: failed (see attached file: test_strftime_python27.log)

Have a lot of:
Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth):
  Expected 011, but got 3y
Strftime test, platform: openbsd5, Python version: 2.7.1
strftime test for Sat Jul 24 21:56:24 2010
Supports nonstandard '%c' format (near-asctime() format)
Supports nonstandard '%x' format (%m/%d/%y %H:%M:%S)
Supports nonstandard '%Z' format (time zone name)
Supports nonstandard '%D' format (mm/dd/yy)
Supports nonstandard '%e' format (day of month as number, blank padded ( 0-31))
Supports nonstandard '%h' format (abbreviated month name)
Supports nonstandard '%k' format (hour, blank padded ( 0-23))
Supports nonstandard '%n' format (newline character)
Supports nonstandard '%r' format (%I:%M:%S %p)
Supports nonstandard '%R' format (%H:%M)
Supports nonstandard '%s' format (seconds since the Epoch in UCT)
Supports nonstandard '%t' format (tab character)
Supports nonstandard '%T' format (%H:%M:%S)


Python 3.2:
test_datetime.py: failed (see attached file: test_datetime_python32.log)
======================================================================
FAIL: test_zones (test.datetimetester.TestTimeTZ_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-3.2.2/Python-3.2.2/Lib/test/datetimetester.py", line 2506, in test_zones
    "07:47:00 %Z=EST %z=-0500")
AssertionError: '07:47:00 Z=EST z=-0500' != '07:47:00 %Z=EST %z=-0500'
- 07:47:00 Z=EST z=-0500
+ 07:47:00 %Z=EST %z=-0500
?          +      +


======================================================================
FAIL: test_zones (test.datetimetester.TestTimeTZ_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-3.2.2/Python-3.2.2/Lib/test/datetimetester.py", line 2506, in test_zones
    "07:47:00 %Z=EST %z=-0500")
AssertionError: '07:47:00 Z=EST z=-0500' != '07:47:00 %Z=EST %z=-0500'
- 07:47:00 Z=EST z=-0500
+ 07:47:00 %Z=EST %z=-0500
?          +      +

test_strftime.py: failed (see attached file: test_strftime_python32.log)

======================================================================
FAIL: test_strftime (__main__.StrftimeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_strftime.py", line 67, in test_strftime
    self.strftest1(now)
  File "Lib/test/test_strftime.py", line 124, in strftest1
    % (e[0], e[2]))
AssertionError: strftime does not support standard '%%' format (single percent sign)

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


Python 3.3:
test_datetime.py: failed (see attached file: test_datetime_python33.log)
Same output than Python 3.2.

test_strftime.py: failed (see attached file: test_strftime_python33.log)
Same output than Python 3.2.


I write a small program in C to verify strftime, and it seems to correcly works:
source:
(void)strftime(buf, sizeof(buf) - 1, "%H:%M:%S %%Z=%Z %%z=%z", localtime(&startt));
printf("%s\n", buf);
buf[0] = '\0';
(void)strftime(buf, sizeof(buf) - 1, "07:47:00 %Z=EST %z=-0500", localtime(&startt));
printf("%s\n", buf);

run:
01:00:00 %Z=CET %z=+0100
07:47:00 CET=EST +0100=-0500



Is my test correct ? Don't hesitate if you need more informations.

Thanks for your help, 

Remi.

----------
files: test_datetime_python32.log
messages: 147758
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_strftime failed on OpenBSD
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23705/test_datetime_python32.log

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

From report at bugs.python.org  Wed Nov 16 23:14:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Nov 2011 22:14:47 +0000
Subject: [New-bugs-announce] [issue13415] os.unsetenv() on Windows should
	not use UTF-8
Message-ID: <1321481687.96.0.070295281604.issue13415@psf.upfronthosting.co.za>


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

os.unsetenv(name) encodes name to UTF-8. I think that the ANSI code page (or another code page?) should be used.

----------
components: Unicode, Windows
messages: 147773
nosy: ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: os.unsetenv() on Windows should not use UTF-8
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov 16 23:48:13 2011
From: report at bugs.python.org (Nebelhom)
Date: Wed, 16 Nov 2011 22:48:13 +0000
Subject: [New-bugs-announce] [issue13416] Python Tutorial, Section 3,
	Minor PEP 8 adjustment
Message-ID: <1321483693.18.0.17340985314.issue13416@psf.upfronthosting.co.za>


New submission from Nebelhom <nebelhom at googlemail.com>:

Python Tutorial 3.3a

3. An informal introduction to python

example:

-------------------------------------------------------------
# this is the first comment
SPAM = 1                 # and this is the second comment
                         # ... and now a third!
STRING = "# This is not a comment."
-------------------------------------------------------------

Comment: It is probably best to use PEP 8 straight from the start.
Therefore variable names should be all lowercase with connecting underscores (if necessary)

i.e. spam = 1 and string = "#This is not a comment." instead of all uppercase.

----------
assignee: docs at python
components: Documentation
messages: 147777
nosy: Nebelhom, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Python Tutorial, Section 3, Minor PEP 8 adjustment
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 16 23:49:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Nov 2011 22:49:41 +0000
Subject: [New-bugs-announce] [issue13417] faster utf-8 decoding
Message-ID: <1321483781.85.0.24668666063.issue13417@psf.upfronthosting.co.za>


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

PEP 393 and the need for a two-pass decoding process has made utf-8 decoding much slower, especially with the current generic implementation. Attached patch makes utf-8 more than twice faster, which means we're around 10-20% slower than 3.2 on non-trivial cases.

----------
components: Interpreter Core
files: utf8lib2.patch
keywords: patch
messages: 147778
nosy: haypo, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: faster utf-8 decoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23712/utf8lib2.patch

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

From report at bugs.python.org  Thu Nov 17 01:57:33 2011
From: report at bugs.python.org (Asesh)
Date: Thu, 17 Nov 2011 00:57:33 +0000
Subject: [New-bugs-announce] [issue13418] Embedded Python memory leak
Message-ID: <1321491453.86.0.929770076277.issue13418@psf.upfronthosting.co.za>


New submission from Asesh <aseshshres at gmail.com>:

Well I just finished embedding Python in my application but even after calling Py_Finalize the debugger shows tons of memory leak. I just called Py_Initialize and then Py_Finalize then after exiting the application, the Visual C++ debugger shows tons of memory leaks and Python is to be blamed:

Detected memory leaks!
Dumping objects ->
{3478} normal block at 0x00000000026343E0, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3476} normal block at 0x0000000002633DA0, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3474} normal block at 0x000000000261AC70, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3472} normal block at 0x000000000261A620, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3471} normal block at 0x000000000261B540, 912 bytes long.
 Data: <       po       > 00 00 00 00 00 00 03 70 6F FB FB FB FB FB FB FB 
{3470} normal block at 0x00000000025C66B0, 800 bytes long.
 Data: <        m       > 00 00 00 00 00 00 03 00 6D FB FB FB FB FB FB FB 
... // Skipped posting more memory leaks
...

{63} normal block at 0x0000000001D927D0, 108 bytes long.
 Data: <C : \ U s e r s > 43 00 3A 00 5C 00 55 00 73 00 65 00 72 00 73 00 
Object dump complete.
The program '[6696] cScripting.exe: Native' has exited with code 0 (0x0).

Upon Googling, seems like am not the only one. I have attached a small project that demonstrates it. It's a x64 build and you'll have to adjust the path of the lib folder

----------
files: cScripting.zip
messages: 147785
nosy: Asesh
priority: normal
severity: normal
status: open
title: Embedded Python memory leak
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23715/cScripting.zip

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

From report at bugs.python.org  Thu Nov 17 03:32:59 2011
From: report at bugs.python.org (Alex Regueiro)
Date: Thu, 17 Nov 2011 02:32:59 +0000
Subject: [New-bugs-announce] [issue13419] import does not recognise
	SYMLINKDs on Windows 7
Message-ID: <1321497179.79.0.443731710828.issue13419@psf.upfronthosting.co.za>


New submission from Alex Regueiro <alexreg at gmail.com>:

Python 2.7 normally inputs directory-modules fine on Windows 7. The notable exception however is symbolically-linked directories on the filesystem, which are ignored (not thought to exist) by the Python `import` statement. (Note that the Python interpreter normally has no problem with symlinks on Win7 with its file I/O features.)

----------
messages: 147789
nosy: alexreg
priority: normal
severity: normal
status: open
title: import does not recognise SYMLINKDs on Windows 7
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 17 12:23:58 2011
From: report at bugs.python.org (David Amian)
Date: Thu, 17 Nov 2011 11:23:58 +0000
Subject: [New-bugs-announce] [issue13420] newer() function in dep_util.py
	discard changes in the	same second
Message-ID: <1321529038.98.0.0841934486822.issue13420@psf.upfronthosting.co.za>


New submission from David Amian <damian at emergya.com>:

Hi, I had a problem making deb packages with distutils and cdbs. Looking for any solution, I found Issue 11933 and saw that the newer() method has been changed, using [ST_MTIME] instead of st_mtime. This commit is to solve Issue 10148 that describes a bug when copying files with python, it depends on the filesystem.

In these changes, modification time of files are checked as a integer, discarding the millisec. It makes the issue.

For example, I've a file that is modified with an installation prefix. CDBS runs the build step and after the install step. In build step, the prefix is '/usr/local' because the prefix argument isn't supported, immediately the install step runs with prefix='/usr', so the file that contains a variable with project path modified with the prefix is not copied by distutils, it runs in a different millisec but in the same second.

Then when install my app, it crashes because the variable with project path is '/usr/local' instead of '/usr' and this variable is used in the source.

To solve this problem I made ??some modifications on file_util.py and dep_util.py files, I revert the changes of the issue 11933, but rounding all times returned by stat() with two decimals. With that changes, distutils is not affected by the Issue 10148 and if any file is modified in the same second, but in different millisec, distutils will compare it and it wil copy the file.

----------
assignee: tarek
components: Distutils
files: fix_mtime.diff
keywords: patch
messages: 147794
nosy: d.amian, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: newer() function in dep_util.py discard changes in the same second
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23716/fix_mtime.diff

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

From report at bugs.python.org  Thu Nov 17 19:14:43 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 17 Nov 2011 18:14:43 +0000
Subject: [New-bugs-announce] [issue13421] PyCFunction_* are not documented
	anywhere
Message-ID: <1321553683.63.0.825049607384.issue13421@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Functions PyCFunction_* are not documented. Searching online I found http://www.gossamer-threads.com/lists/python/dev/738662 , so I am actually opening the issue and assigning to Georg :).

----------
assignee: georg.brandl
components: Documentation
messages: 147817
nosy: georg.brandl, jcea
priority: normal
severity: normal
status: open
title: PyCFunction_* are not documented anywhere

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

From report at bugs.python.org  Thu Nov 17 21:35:43 2011
From: report at bugs.python.org (Felix Steffenhagen)
Date: Thu, 17 Nov 2011 20:35:43 +0000
Subject: [New-bugs-announce] [issue13422] Subprocess: children hang due to
	open pipes
Message-ID: <1321562143.65.0.570707046808.issue13422@psf.upfronthosting.co.za>


New submission from Felix Steffenhagen <felix at sutus.com>:

subprocess.Popen.communicate() hangs for daemonized subprocesses that leave a pipe open. The python caller, invoking the daemon subprocess, runs as long as the daemon process. This happens on POSIX platforms with python 2.7 as well as 3.2. 

Please find attached a simple python daemon, which leaves stderr pipe open. It runs for 10 sec and then exits.

To reproduce the problem run the following start script:
##################
# startpydaemon.py
import subprocess

cmd = 'python pydaemon.py'
print("Starting daemon that runs for 10 sec")
daemon = subprocess.Popen(cmd, 
                          stdout=subprocess.PIPE,
                          stderr=subprocess.PIPE,
                          shell=True)
stdout, stderr = daemon.communicate()
print("Stdout:")
print(stdout)
print("Stderr:")
print(stderr)
##################

Expected Behavior:
------------------
Daemon starter should exit immediately after the daemon process is initialized.

Actual Behavior:
----------------
Daemon starter waits for daemon process to be finished due to left open error pipe. 

Workaround:
-----------
One workaround is to not capture output from the left-open pipe. This way.

----------
components: Library (Lib)
files: pydaemon.py
messages: 147820
nosy: fsteffenhagen
priority: normal
severity: normal
status: open
title: Subprocess: children hang due to open pipes
versions: Python 2.6, Python 3.2
Added file: http://bugs.python.org/file23719/pydaemon.py

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

From report at bugs.python.org  Fri Nov 18 10:36:58 2011
From: report at bugs.python.org (Chase Albert)
Date: Fri, 18 Nov 2011 09:36:58 +0000
Subject: [New-bugs-announce] [issue13423] Ranges cannot be meaningfully
	compared for equality or	hashed
Message-ID: <1321609018.8.0.880546307397.issue13423@psf.upfronthosting.co.za>


New submission from Chase Albert <thaoeuns at gmail.com>:

My expectation was that range(2,5) == range(2,5), and that they should hash the same. This is not the case.

----------
messages: 147838
nosy: rob.anyone
priority: normal
severity: normal
status: open
title: Ranges cannot be meaningfully compared for equality or hashed
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov 18 10:52:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Nov 2011 09:52:13 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_o?=
 =?utf-8?q?pen=E2=80=99s_new_opener_argument?=
Message-ID: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>


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

The new opener argument to open and TextIOWrapper closed two bugs on this tracker: using O_CLOEXEC and replacing the unofficial 'c' mode (O_CREATE).  I think it?d be nice to have these as examples (maybe not in the docs of TextIOWrapper which are already huge, but for example in the os docs after the O_* constants).

----------
assignee: docs at python
components: Documentation
messages: 147840
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: Add examples for open?s new opener argument
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov 18 12:03:50 2011
From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Jankowski?=)
Date: Fri, 18 Nov 2011 11:03:50 +0000
Subject: [New-bugs-announce] [issue13425]
	http.client.HTTPMessage.getallmatchingheaders() always	returns []
Message-ID: <1321614230.59.0.764469605478.issue13425@psf.upfronthosting.co.za>


New submission from Stanis?aw Jankowski <stach.jankowski at gmail.com>:

http.client.HTTPMessage.getallmatchingheaders() always returns []

Python 3.2.2:
Calling the code below does not give the expected result.

sjankowski at sjankowski:~$ python3
Python 3.2.2rc1 (default, Aug 14 2011, 18:43:44) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.request import urlopen
>>> fp = urlopen('http://www.python.org/')
>>> fp.headers.getallmatchingheaders('Content-Type')
[]

At Python 2.7.2 returns the result.

sjankowski at sjankowski:~$ python
Python 2.7.2+ (default, Aug 16 2011, 09:23:59) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib import urlopen
>>> fp = urlopen('http://www.python.org/')
>>> fp.headers.getallmatchingheaders('Content-Type')
['Content-Type: text/html\r\n']

----------
components: Library (Lib)
messages: 147849
nosy: stachjankowski
priority: normal
severity: normal
status: open
title: http.client.HTTPMessage.getallmatchingheaders() always returns []
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov 18 12:29:59 2011
From: report at bugs.python.org (Nebelhom)
Date: Fri, 18 Nov 2011 11:29:59 +0000
Subject: [New-bugs-announce] [issue13426] The Python Standard Library >> 11.
	Data Persistence
Message-ID: <1321615799.02.0.0403291741181.issue13426@psf.upfronthosting.co.za>


New submission from Nebelhom <nebelhom at googlemail.com>:

------------------------------
Python v3.3a0 documentation >> The Python Standard Library >> 11. Data
Persistence

Section 11.1 pickle module

#1
11.1.3. Module Interface

exception pickle.UnpicklingError

   Error raised when there a problem unpickling an object, such as a data corruption or a security violation.
   It inherits PickleError.

TYPO: Error raised when there IS a problem unpickling an object

------------------------------
#2
11.1.3. Module Interface

persistent_load(pid)

   Raise an UnpickingError by default.

TYPO: Should be "Unpick"l"ingError" as wrtten earlier in the section

--------------------------------
#3
11.1.4 What can be pickled and unpickled

Note that functions (built-in and user-defined) are pickled by >>fully
qualified<< name reference, not by value.
This means that only the function name is pickled, along with the name of module the function is defined in.

TYPO: along with the name of "THE" module the function is defined in.

--------------------------------
#4
11.1.5.1. Persistence of External Objects

In Windows XP SP3, example does not work out of the box as sqlite3 is not included when compiling python3.3a following the Getting Set Up directions in the Developer's Guide

Is this an issue?

Code works in Ubuntu 10.04 lucid.

When run from Terminal, it gives the following output:

Pickled records:
[MemoRecord(key=1, task='give food to fish'),
 MemoRecord(key=2, task='prepare group meeting'),
 MemoRecord(key=3, task='fight with a zebra')]
Unpickled records:
[MemoRecord(key=1, task='learn italian'),
 MemoRecord(key=2, task='prepare group meeting'),
 MemoRecord(key=3, task='fight with a zebra')]


 Should that not be given afterwards as a reference to the user, so that
(s)he knows, that the code is right?

--------------------------------
#5
11.1.6 Restricting Globals

Thus it is possible to either forbid completely globals

NOTE: should be "either completely forbid globals"

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

----------
assignee: docs at python
components: Documentation
messages: 147851
nosy: Nebelhom, docs at python
priority: normal
severity: normal
status: open
title: The Python Standard Library >> 11. Data Persistence
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov 18 12:43:55 2011
From: report at bugs.python.org (Alan Beccati)
Date: Fri, 18 Nov 2011 11:43:55 +0000
Subject: [New-bugs-announce] [issue13427] string comparison with ==
Message-ID: <1321616635.73.0.844704371256.issue13427@psf.upfronthosting.co.za>


New submission from Alan Beccati <alan.beccati at gmail.com>:

Hello,
did I discover a python string comparison bug or is this behaviour expected and I am doing something wrong?

This is the code I run:
for line in lines[4:]:
	currColl=line.split(":")[1].strip()
	print "'",currColl,"'","==","'",collName,"'"
	if currColl == collName :
		return True
	else:
		print "not equal"

where currColl is a method parameter and lines is built from subprocess Popen like:
p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
lines=[]
for line in p.stdout.readlines():
	lines.append(line)
	
The output of the abovementioned code is:
' utm ' == ' utm10 '
not equal
' utm1000 ' == ' utm10 '
not equal
' utm100 ' == ' utm10 '
not equal
' utm10 ' == ' utm10 '
not equal
' utm1 ' == ' utm10 '
not equal

as you can see the fourth comparison should return True while it gives a "not equal" as the others.

Python info:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2

----------
messages: 147854
nosy: Alan.Beccati
priority: normal
severity: normal
status: open
title: string comparison with ==
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 18 12:58:55 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 18 Nov 2011 11:58:55 +0000
Subject: [New-bugs-announce] [issue13428] PyUnicode_FromFormatV: support
	width and precision for	string codes, e.g %S and %R
Message-ID: <1321617535.12.0.0988297561958.issue13428@psf.upfronthosting.co.za>


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

Currently, the width and precision information for string codes are accepted but ignored. They should be used to pad short strings (width) and truncate long ones (precision), just like printf() (only in terms of code points rather than bytes, since those codes work with Unicode text).

----------
components: Interpreter Core
messages: 147858
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV: support width and precision for string codes, e.g %S and %R
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov 18 16:46:58 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 18 Nov 2011 15:46:58 +0000
Subject: [New-bugs-announce] [issue13429] provide __file__ to extension init
	function
Message-ID: <1321631218.51.0.537222078649.issue13429@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

In Python modules, the top-level module code sees the __file__ variable and can use it to refer to resources in package subdirectories, for example. This is not currently possible in extension modules, because __file__ is only set after running the module init function, and the module has no way to find out its runtime location.

CPython should set __file__ directly in PyModule_Create2(), based on information provided by the shared library loader. This would let PyModule_GetFilenameObject() work immediately with the newly created module object.

The relevant python-dev thread is here:

http://mail.python.org/pipermail/python-dev/2011-November/114476.html

A patch will follow soon.

----------
components: Extension Modules, Interpreter Core
messages: 147881
nosy: scoder
priority: normal
severity: normal
status: open
title: provide __file__ to extension init function
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov 18 17:01:34 2011
From: report at bugs.python.org (Marko Nervo)
Date: Fri, 18 Nov 2011 16:01:34 +0000
Subject: [New-bugs-announce] [issue13430] Add a curry function to the
	functools module
Message-ID: <1321632094.44.0.291753245781.issue13430@psf.upfronthosting.co.za>


New submission from Marko Nervo <marko at python.it>:

I think it would be very usefull to add a curry function to the functools module. It should be like this.


def curry(func, *args, **kwargs):

    if (len(args) + len(kwargs)) >= func.__code__.co_argcount:

        return func(*args, **kwargs)

    return (lambda *x, **y: curry(func, *(args + x), **dict(kwargs, **y)))


This function allows you to create curried functions or methods in two main ways:


(1)


>>> def adder(x, y, z):
...     return (x + y + z)
>>> adder = curry(adder)


(2)


>>> @curry
... def adder(x, y, z):
...     return (x + y + z)


Curried functions could be used as follow.


>>> adder(2, 3, 4)
>>> adder(2, 3)(4)
>>> adder(2)(3)(4)
>>> adder(z = 4)(2, 3)  # etc, etc, etc...


Best regards,
Marco.

----------
components: Library (Lib)
messages: 147882
nosy: collinwinter, eric.araujo, gregory_p, markonervo, rhettinger, serprex
priority: normal
severity: normal
status: open
title: Add a curry function to the functools module
type: feature request
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sat Nov 19 10:16:48 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 19 Nov 2011 09:16:48 +0000
Subject: [New-bugs-announce] [issue13431] Pass context information into the
	extension module init	function
Message-ID: <1321694208.82.0.599594610804.issue13431@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

This is a follow-up to issue 13429, which deals with setting __file__ on newly created extension modules earlier than it is currently the case.

Currently, the module init function of extension modules lacks a way to find out the context in which it is being imported, e.g. its package path or its location in the file system. This makes it tricky for extension modules to do things like loading package resources or using relative imports at init time.

This can be fixed by allowing the init function to take a context struct as argument, which would contain object pointers to the FQ package name and file path, and potentially other information.

I think this would be backwards compatible to existing code, because C should allow the caller of the init function to pack additional arguments on the stack that the called function simply doesn't care about. From CPython 3.3 on, however, new and updated code could benefit from this feature.

----------
components: Extension Modules, Interpreter Core
messages: 147931
nosy: scoder
priority: normal
severity: normal
status: open
title: Pass context information into the extension module init function
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov 19 12:35:12 2011
From: report at bugs.python.org (kxroberto)
Date: Sat, 19 Nov 2011 11:35:12 +0000
Subject: [New-bugs-announce] [issue13432] Encoding alias "unicode"
Message-ID: <1321702512.61.0.807104309131.issue13432@psf.upfronthosting.co.za>


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

"unicode" seems not to be an official unicode encoding name alias.
Yet it is quite frequent on the web - and obviously means UTF-8. 
(search '"text/html; charset=unicode"' in Google)
Chrome and IE display it as UTF-8.  (Mozilla as ASCII, thus mixed up chars).

Should it be added in to aliases.py ?

--- ./aliases.py
+++ ./aliases.py
@@ -511,6 +511,7 @@
     'utf8'               : 'utf_8',
     'utf8_ucs2'          : 'utf_8',
     'utf8_ucs4'          : 'utf_8',
+    'unicode'            : 'utf_8',
 
     # uu_codec codec
     'uu'                 : 'uu_codec',

----------
messages: 147936
nosy: kxroberto
priority: normal
severity: normal
status: open
title: Encoding alias "unicode"

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

From report at bugs.python.org  Sat Nov 19 14:01:32 2011
From: report at bugs.python.org (Christian Iversen)
Date: Sat, 19 Nov 2011 13:01:32 +0000
Subject: [New-bugs-announce] [issue13433] String format documentation
	contains error regarding %g
Message-ID: <1321707692.58.0.601543510069.issue13433@psf.upfronthosting.co.za>


New submission from Christian Iversen <ci at sikkerhed.org>:

The documentation for string format options state that both %f, %g and %e default to 6 digits after the decimal point. In fact, %g always seems to use 5 digits by default:

>>> "%g" % 2.1234567
'2.12346'
>>> "%f" % 2.1234567
'2.123457'
>>> "%e" % 2.1234567
'2.123457e+00'

But something much more insidious is wrong, because even when explicitly told how many digits to have, %g is one off:

>>> "%.6g" % 2.1234567
'2.12346'
>>> "%.6f" % 2.1234567
'2.123457'
>>> "%.6e" % 2.1234567
'2.123457e+00'

This can't be right?

----------
assignee: docs at python
components: Documentation
messages: 147940
nosy: Christian.Iversen, docs at python
priority: normal
severity: normal
status: open
title: String format documentation contains error regarding %g
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Nov 19 16:44:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Nov 2011 15:44:46 +0000
Subject: [New-bugs-announce] [issue13434] time.xmlrpc.com dead
Message-ID: <1321717486.33.0.411354256352.issue13434@psf.upfronthosting.co.za>


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

time.xmlrpc.com seems dead (no DNS entry), which leads to failures on one of the stable buildbots (redirecting DNS catchall?):

======================================================================
ERROR: test_current_time (test.test_xmlrpc_net.CurrentTimeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_xmlrpc_net.py", line 19, in test_current_time
    t0 = server.currentTime.getCurrentTime()
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/client.py", line 1089, in __call__
    return self.__send(self.__name, args)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/client.py", line 1420, in __request
    verbose=self.__verbose
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/client.py", line 1131, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/xmlrpc/client.py", line 1163, in single_request
    dict(resp.getheaders())
xmlrpc.client.ProtocolError: <ProtocolError for time.xmlrpc.com/RPC2: 303 See Other>

----------
components: Tests
messages: 147948
nosy: flox, loewis, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: time.xmlrpc.com dead
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Nov 19 18:42:23 2011
From: report at bugs.python.org (Robert Lehmann)
Date: Sat, 19 Nov 2011 17:42:23 +0000
Subject: [New-bugs-announce] [issue13435] Copybutton does not hide tracebacks
Message-ID: <1321724543.66.0.854276029391.issue13435@psf.upfronthosting.co.za>


New submission from Robert Lehmann <lehmannro at gmail.com>:

The recently added copybutton.js (r18bbfed9aafa) does not work with the 2.7 docs since they are deployed with JQuery 1.2 (which is shipped with Sphinx 0.6).

Copybutton is an unobtrusive Javascript feature which adds a little button to all doctests that removes the interactive prompts in order to copy the code as-is into Python scripts.  I think that feature could well be ported to Sphinx itself.

In line 44 and 51 of Doc/tools/sphinxext/static/copybutton.js the code uses jQuery.nextUntil(), which is new in JQuery 1.4.  That results in tracebacks being only partially hidden.  Reproduce the error at http://docs.python.org/tutorial/errors.html#exceptions for example.

The Python 3.2+ documentation is not affected as it is built with Sphinx 1.0, which ships with JQuery 1.4.  JQuery Untils are available as a separate plugin (http://benalman.com/projects/jquery-untils-plugin/).

----------
assignee: docs at python
components: Documentation
messages: 147962
nosy: docs at python, ezio.melotti, lehmannro
priority: normal
severity: normal
status: open
title: Copybutton does not hide tracebacks
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 20 01:04:39 2011
From: report at bugs.python.org (=?utf-8?q?Janosch_Gr=C3=A4f?=)
Date: Sun, 20 Nov 2011 00:04:39 +0000
Subject: [New-bugs-announce] [issue13436] compile() doesn't work on
	ImportFrom with level=None
Message-ID: <1321747479.31.0.688458511993.issue13436@psf.upfronthosting.co.za>


New submission from Janosch Gr?f <janosch.graef at gmx.net>:

The documentation for ast says that arguments that are marked with a '?' in the abstract grammar are optional and can therefore be None.
When I try to compile a Module node which contains an ImportFrom node with attribute level=None compile() throws an exception:

Module(body=[ImportFrom(module='time', names=[alias(name='sleep', asname=None), alias(name='time', asname=None)], level=None, lineno=0, col_offset=0)])

Traceback (most recent call last):
  File "g0.py", line 423, in <module>
    p.main()
  File "g0.py", line 65, in main
    self.reproduce("g1.pyc")
  File "g0.py", line 85, in reproduce
    co = self.generate_bytecode(st, genome)
  File "g0.py", line 243, in generate_bytecode
    co = compile(st, id, "exec")
ValueError: invalid integer value: ????????

So, I tried to set level=0:
Module(body=[ImportFrom(module='time', names=[alias(name='sleep', asname=None), alias(name='time', asname=None)], level=0, lineno=0, col_offset=0)])

and everything worked fine.

BTW: The unprintable bytes in the error message are:
ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd ef bf bd

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 147972
nosy: Janosch.Gr?f, docs at python
priority: normal
severity: normal
status: open
title: compile() doesn't work on ImportFrom with level=None
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sun Nov 20 01:29:31 2011
From: report at bugs.python.org (Julian Berman)
Date: Sun, 20 Nov 2011 00:29:31 +0000
Subject: [New-bugs-announce] [issue13437] Provide links to the source code
	for every module in the	documentation
Message-ID: <1321748971.83.0.182041155467.issue13437@psf.upfronthosting.co.za>


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

The documentation occasionally contains a link to the source code for a module in the stdlib. See for instance http://docs.python.org/library/urlparse.html and http://docs.python.org/library/collections.html , or many others.

With a quick perusal, I couldn't immediately guess as to which ones managed to have one and which ones don't, but it'd be convenient to have a link in as many places as possible, which is certainly more than we have now. (See e.g. http://docs.python.org/library/json.html and http://docs.python.org/library/itertools.html and many others for examples of pages that lack a link).

Perhaps putting it in a more conspicuous but still consistent location would be reasonable (the sidebar?).

----------
assignee: docs at python
components: Documentation
messages: 147973
nosy: Julian, docs at python
priority: normal
severity: normal
status: open
title: Provide links to the source code for every module in the documentation
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Nov 20 15:51:30 2011
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 20 Nov 2011 14:51:30 +0000
Subject: [New-bugs-announce] [issue13438] "Delete patch set" review action
	doesn't work
Message-ID: <1321800690.51.0.854492831277.issue13438@psf.upfronthosting.co.za>


New submission from Oleg Plakhotnyuk <olegus8 at gmail.com>:

I got following error when trying to delete outdated patch set:


Environment:

Request Method: POST
Request URL: http://bugs.python.org/review/13394/patchset/3680/delete
Django Version: 1.1.1 SVN-17047
Python Version: 2.5.2
Installed Applications:
['django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 'gae2django',
 'rietveld_helper',
 'codereview']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'roundup_helper.middleware.LookupRoundupUser',
 'gae2django.middleware.FixRequestUserMiddleware',
 'rietveld_helper.middleware.AddUserToRequestMiddleware',
 'django.middleware.doc.XViewMiddleware')


Traceback:
File "/home/roundup/trackers/tracker/rietveld/django/core/handlers/base.py" in get_response
  88.                 response = middleware_method(request, callback, callback_args, callback_kwargs)
File "/home/roundup/trackers/tracker/rietveld/rietveld_helper/middleware.py" in process_view
  21.         response = view_func(request, *view_args, **view_kwargs)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in post_wrapper
  557.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in login_wrapper
  569.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in issue_wrapper
  643.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in patchset_wrapper
  706.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in patchset_owner_wrapper
  718.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in xsrf_wrapper
  597.     return func(request, *args, **kwds)
File "/home/roundup/trackers/tracker/rietveld/codereview/views.py" in delete_patchset
  1669.   for patchset in patchsets_after:
File "/home/roundup/trackers/tracker/rietveld/django/db/models/query.py" in _result_iter
  106.                 self._fill_cache()
File "/home/roundup/trackers/tracker/rietveld/django/db/models/query.py" in _fill_cache
  692.                     self._result_cache.append(self._iter.next())
File "/home/roundup/trackers/tracker/rietveld/django/db/models/query.py" in iterator
  238.         for row in self.query.results_iter():
File "/home/roundup/trackers/tracker/rietveld/django/db/models/sql/query.py" in results_iter
  287.         for rows in self.execute_sql(MULTI):
File "/home/roundup/trackers/tracker/rietveld/django/db/models/sql/query.py" in execute_sql
  2369.         cursor.execute(sql, params)
File "/home/roundup/trackers/tracker/rietveld/django/db/backends/util.py" in execute
  19.             return self.cursor.execute(sql, params)

Exception Type: ProgrammingError at /review/13394/patchset/3680/delete
Exception Value: schema "datetime" does not exist


Last trace frame's local vars exploration revealed this:
'SELECT "codereview_patchset"."id", "codereview_patchset"."gae_key", "codereview_patchset"."gae_parent_ctype_id", "codereview_patchset"."gae_parent_id", "codereview_patchset"."gae_ancestry", "codereview_patchset"."issue_id", "codereview_patchset"."message", "codereview_patchset"."data", "codereview_patchset"."url", "codereview_patchset"."owner_id", "codereview_patchset"."created", "codereview_patchset"."modified", "codereview_patchset"."n_comments" FROM "codereview_patchset" WHERE "codereview_patchset"."issue_id" = 13394 AND created > datetime.datetime(2011, 11, 20, 11, 36, 4, 343046)'

I believe that it should look something like this:
'SELECT ... AND created > %s' % datetime.datetime(2011, 11, 20, 11, 36, 4, 343046)

I'm not sure where should I post this issue. I didn't find "rietveld/django/db/backends/util.py" in sources at rietveld.googlecode.com, therefore I posted it here.

----------
messages: 147994
nosy: Oleg.Plakhotnyuk
priority: normal
severity: normal
status: open
title: "Delete patch set" review action doesn't work
type: behavior

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

From report at bugs.python.org  Sun Nov 20 16:15:24 2011
From: report at bugs.python.org (Christopher Smith)
Date: Sun, 20 Nov 2011 15:15:24 +0000
Subject: [New-bugs-announce] [issue13439] turtle docstring for onkeyrelease
	references onkey, not onkeyrelease
Message-ID: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>


New submission from Christopher Smith <smichr at users.sourceforge.net>:

The docstring example is written using onkey instead of onkeyrelease.

----------
components: Library (Lib)
messages: 147995
nosy: smichr
priority: normal
severity: normal
status: open
title: turtle docstring for onkeyrelease references onkey, not onkeyrelease
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 21 00:54:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Nov 2011 23:54:44 +0000
Subject: [New-bugs-announce] [issue13440] Explain the "status quo wins a
	stalemate" principle in	the devguide
Message-ID: <1321833284.75.0.438515825131.issue13440@psf.upfronthosting.co.za>


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

I've linked http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html in response to enough tracker issues and python-ideas threads now, that I'm convinced it (or at least something along those lines) belongs in the devguide.

It wouldn't hurt to also include something along the lines of:
http://www.boredomandlaziness.org/2011/02/justifying-python-language-changes.html

----------
components: Devguide
messages: 148016
nosy: ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Explain the "status quo wins a stalemate" principle in the devguide

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

From report at bugs.python.org  Mon Nov 21 00:58:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Nov 2011 23:58:16 +0000
Subject: [New-bugs-announce] [issue13441] TestEnUSCollation.test_strxfrm()
	fails on Solaris
Message-ID: <1321833496.0.0.544021070577.issue13441@psf.upfronthosting.co.za>


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

I added a test in _PyUnicode_CheckConsistency() (in debug mode) to ensure that all characters of a string are in the range U+0000-U+10FFFF. Locale tests are now failing on Solaris:

-----------------------------------
[ 28/361] test__locale
Assertion failed: maxchar <= 0x10FFFF, file Objects/unicodeobject.c, line 408
Fatal Python error: Aborted

Current thread 0x00000001:
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 134 in test_float_parsing
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 385 in _executeTestPart
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 440 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/case.py", line 492 in __call__
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/suite.py", line 105 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/suite.py", line 105 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/unittest/runner.py", line 168 in run
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1368 in _run_suite
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 1402 in run_unittest
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test__locale.py", line 139 in test_main
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 1203 in runtest_inner
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 906 in runtest
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/regrtest.py", line 709 in main
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/__main__.py", line 13 in <module>
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/runpy.py", line 73 in _run_code
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 134
-----------------------------------

The problem is that strxfrm() and wcsxfrm() return strange results for the string "a" and the english locale (e.g. en_US.UTF-8).

strxfrm(buffer, "a\0", 100) returns 21 (bytes) but only 2 bytes are written ("\x01\x00"). The next bytes are unchanged.

wcsxfrm(buffer, L"a\0", 100) returns 7 (characters), the 7 characters are written but they are in range U+1010101..U+1010163, whereas the maximum character of Unicode 6.0 is U+10FFFF (U+101xxxx vs U+10xxxx).

Output of the attached program, strxfrm.c, on OpenSolaris:
-----------------------------------
strxfrm: len=21
0x01
0x00
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff
0xff

wcsxfrm: len=7
U+1010163
U+1010101
U+1010103
U+1010101
U+1010103
U+1010101
U+1010101
-----------------------------------

I don't know if it's normal that wcsxfrm() writes characters in the range U+1010101..U+1010163.

Is Python supposed to support characters outside U+0000-U+10FFFF range? chr(0x10FFFF+1) raises a ValueError.

----------
components: Unicode
files: strxfrm.c
messages: 148017
nosy: ezio.melotti, haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: TestEnUSCollation.test_strxfrm() fails on Solaris
versions: Python 3.3
Added file: http://bugs.python.org/file23741/strxfrm.c

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

From report at bugs.python.org  Mon Nov 21 02:22:48 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 21 Nov 2011 01:22:48 +0000
Subject: [New-bugs-announce] [issue13442] Better support for pipe I/O
	encoding in subprocess
Message-ID: <1321838568.9.0.683093502178.issue13442@psf.upfronthosting.co.za>


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

Currently, pipes in the subprocess module work strictly with bytes I/O, *unless* you set "universal newlines=True". In that case, it assumes an output encoding of UTF-8 for stdout and stderr and applies universal newlines process.

When stdin/out/err are remapped to ordinary I/O streams then 'encoding' and 'errors' can be specified as usual, but it is currently challenging to do this for pipes. Since they're created internally by the subprocess module, user code doesn't get the opportunity to wrap them when using the convenience APIs. When using Popen objects, you have to create the object, then wrap each stream individually (rebinding the attributes as you go).

My suggestion is that we add a new option for the stdin/out/err arguments:

    class TextPipe:
        def __init__(self, encoding, errors='strict'):
            self.encoding = encoding
            self.errors = errors

So to read UTF-8 encoded data from a subprocess, you could just do:

    data = check_stdout(cmd, stdout=TextPipe('utf-8'), stderr=STDOUT)

There are at least a couple of other alternatives here:

- separate out the pipe creation logic from the Popen logic so it is possible to create and wrap the pipe objects explicitly and then pass the wrapped pipe object to the subprocess invocation APIs. 'TextPipe' would then actually be such a wrapped pipe, rather than merely instructions to tell Popen what kind of pipe to create.
- instead of adding 'TextPipe', just re-use the PIPE name (with the class itself still being used as a marker constant to request implicit creation of a binary PIPE)

----------
assignee: docs at python
components: Documentation
messages: 148022
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Better support for pipe I/O encoding in subprocess
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 21 05:40:04 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 21 Nov 2011 04:40:04 +0000
Subject: [New-bugs-announce] [issue13443] wrong links and examples in the
	functional HOWTO
Message-ID: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>


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

Micha? Cha?upczak reported in this docs@ list that the links to IBM developerworks articles are wrong.

>From some additional observation, the code samples on the 3.x page use the external `functional` module, which was not ported to Python 3 at all.

I wonder whether it makes sense to use external modules in official Python documentation, since these are not guaranteed to be ported. This issue is a good example of this happening.

The HOWTO should be probably rewritten to use only the stdlib. The links to IBM developerworks should be, IMHO, removed, since they point to articles written in 2001 and have code samples that won't work on Python 3.x

----------
assignee: docs at python
components: Documentation
messages: 148030
nosy: akuchling, docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: wrong links and examples in the functional HOWTO
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 21 16:18:20 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Mon, 21 Nov 2011 15:18:20 +0000
Subject: [New-bugs-announce] [issue13444] closed stdout causes error on
	stderr when the	interpreter unconditionally flushes on shutdown
Message-ID: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

not sure if this is to be considered a bug,
but python3.2 tries to flush sys.stdout on shutdown, even if its closed

$ python3.2 -c 'import sys;sys.stdout.close()'
Exception ValueError: 'I/O operation on closed file.' in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='ANSI_X3.4-1968'> ignored

its related to how Issue #5319 was fixed

----------
components: Interpreter Core
messages: 148055
nosy: Ronny.Pfannschmidt, georg.brandl, mkc, pitrou, terry.reedy
priority: normal
severity: normal
status: open
title: closed stdout causes error on stderr when the interpreter unconditionally flushes on shutdown
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 21 17:55:15 2011
From: report at bugs.python.org (Lauren Foutz)
Date: Mon, 21 Nov 2011 16:55:15 +0000
Subject: [New-bugs-announce] [issue13445] Enable linking the module pysqlite
	with Berkeley DB SQL	instead of SQLite
Message-ID: <1321894515.42.0.740720237959.issue13445@psf.upfronthosting.co.za>


New submission from Lauren Foutz <lauren.foutz at gmail.com>:

Before the pysqlite module was made standard it could be edited to link with Berkeley DB SQL instead of SQLite.  I am requesting that the Python build add the ability to link with BDBSQL instead of SQLite.

----------
components: Build
messages: 148058
nosy: Lauren.Foutz
priority: normal
severity: normal
status: open
title: Enable linking the module pysqlite with Berkeley DB SQL instead of SQLite
type: feature request

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

From report at bugs.python.org  Mon Nov 21 18:04:19 2011
From: report at bugs.python.org (Charalampos Nikolaou)
Date: Mon, 21 Nov 2011 17:04:19 +0000
Subject: [New-bugs-announce] [issue13446] imaplib,
	fetch: improper behaviour on read-only selected mailboxes
Message-ID: <1321895059.52.0.840142009955.issue13446@psf.upfronthosting.co.za>


New submission from Charalampos Nikolaou <char.nikolaou at gmail.com>:

I would like to report a misbehaviour on the fetch command of imaplib when used with mailboxes that have been opened as read-only. In such cases, when you fetch a message (using for instance RFC822), the mail is not marked as read (i.e., the flag of the respective message is not set to 'seen'). I have only tested with IMAP over SSL with the server of my organization on which I don't have administration permissions and gmail.

System details
----------------
Python: 2.5, 2.6, 2.7.2, 3.0, 3.1, 3.2
Server: Cyrus IMAP4 v2.1.18 and imap.gmail.com

Pseudocode to reproduce the problem:
---------------------------------------
imap = imaplib.IMAP4_SSL(imap_server)
imap.connect(user, pass)
imap.select(mailbox, readonly=True)
imap.search(None, 'Unseen')
imap.fetch(mid, 'RFC822')
imap.close()
imap.logout()

After executing the above code, the message with id mid will not have been marked as read, while it should have been.

Other relevant information:
-----------------------------
Access List for my readonly mailbox: group:1 lrsw group:2 p group:3 lrsp group:4 lrswip group:5 lrswipd group:6 lrswipd group:7 lrsw group:8 lrsw group:9 p group:10 p group:11 lrsp group:12 lrsp group:13 lrswip group:14 lrswip group:15 lrswipd group:16 lrswipd group:17 lrswipd group:18 lrswipd

I have to mention that the above access list is the same with the one of another mailbox which is read/write. I mention this just to make clear that the access list does not play any role in this problem.

Hope I haven't forgotten anything. In any case, ask me.

----------
components: Library (Lib)
messages: 148060
nosy: char.nikolaou
priority: normal
severity: normal
status: open
title: imaplib, fetch: improper behaviour on read-only selected mailboxes
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/issue13446>
_______________________________________

From report at bugs.python.org  Mon Nov 21 18:08:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Nov 2011 17:08:04 +0000
Subject: [New-bugs-announce] [issue13447] Add tests for
	Tools/scripts/reindent.py
Message-ID: <1321895284.05.0.389852057258.issue13447@psf.upfronthosting.co.za>


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

When people find bugs in reindent.py (#12930 is a recent one), we have to try to reproduce the bug manually, apply a fix and test manually again.  The alternative is to only read the code and trust that it works.  I find both of these positions unsatisfactory and propose to add unit tests for the script.  I?m opening this report to gather votes, and if they?re positive I?ll proceed with a patch and other bug reports for the other most used scripts (we have a number of reports for pygettext and msgfmt for example; I am not proposing adding tests for all, or even most, scripts).

Even if these scripts are not part of the stdlib and not officially documented or supported, we do ship them and use them (reindent from patchcheck and Mercurial hooks for example), so I really think we need unit tests to know that they work as intended.  Then we?ll be able to commit fixes and other changes serenely.

Implementation idea: The tests would go in Tools/scripts/tests/test_reindent.py and a short file in Lib/test/test_scripts.py would run them as part of the test suite if they exist (so that running tests from an installed Python without Tools dir just skips test_scripts).  For scripts that are in another Tools subdir, like Tools/i18n/pygettext.py, I?d put them in Tools/i18n/tests/test_pygettext.py.

----------
components: Demos and Tools, Tests
messages: 148062
nosy: eric.araujo
priority: normal
severity: normal
status: open
title: Add tests for Tools/scripts/reindent.py
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 21 21:53:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Nov 2011 20:53:50 +0000
Subject: [New-bugs-announce] [issue13448] PEP 3155 implementation
Message-ID: <1321908830.82.0.349913947268.issue13448@psf.upfronthosting.co.za>


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

Here is an issue covering PEP 3155 implementation. Hopefully a "review" link will appear in front of the hg repo URL.

----------
components: Interpreter Core
hgrepos: 91
messages: 148087
nosy: ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: PEP 3155 implementation
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov 22 01:19:43 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Nov 2011 00:19:43 +0000
Subject: [New-bugs-announce] [issue13449] sched - provide an "async"
	argument for run() method
Message-ID: <1321921183.77.0.944975657865.issue13449@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

If True it would run the scheduled functions due to expire soonest (if any) and then return.
This would make sched module usable into asynchronous applications.

----------
messages: 148095
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: sched - provide an "async" argument for run() method
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov 22 01:42:36 2011
From: report at bugs.python.org (akira)
Date: Tue, 22 Nov 2011 00:42:36 +0000
Subject: [New-bugs-announce] [issue13450] fix ''.format_map test
Message-ID: <1321922556.51.0.541780569618.issue13450@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

It seems that some assertions in Lib/test/test_unicode.py:UnicodeTest.test_format_map do not implement their intent e.g.,

        self.assertRaises(TypeError, '{'.format_map)
        self.assertRaises(TypeError, '}'.format_map)
        self.assertRaises(TypeError, 'a{'.format_map)
        self.assertRaises(TypeError, 'a}'.format_map)
        self.assertRaises(TypeError, '{a'.format_map)
        self.assertRaises(TypeError, '}a'.format_map)

The intent might be to test:

  >>> '{'.format_map({})
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ValueError: Single '{' encountered in format string

But it actually tests:

  >>> '{'.format_map()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: format_map() takes exactly one argument (0 given)

Provided correct-assertions-in-test_format_map.patch contains additional assertions e.g.,

      self.assertRaises(ValueError, '{'.format_map, {})

Old assertions might be useful so they're left untouched.

----------
components: Tests
files: correct-assertions-in-test_format_map.patch
keywords: patch
messages: 148096
nosy: akira
priority: normal
severity: normal
status: open
title: fix ''.format_map test
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23747/correct-assertions-in-test_format_map.patch

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

From report at bugs.python.org  Tue Nov 22 02:03:42 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Nov 2011 01:03:42 +0000
Subject: [New-bugs-announce] [issue13451] sched.py: speedup cancel() method
Message-ID: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

<snippet>
# bench.py
import sched, time
events = []
scheduler = sched.scheduler(time.time, time.sleep)
for x in range(4000):
    scheduler.enter(1, 1, lambda: None, ())
t = time.time()
for x in scheduler._queue:
    scheduler.cancel(x)
print(time.time() - t)
</snippet>

Before the patch:
9.433167934417725

After the patch:
1.3120810985565186


I have another approach in mind, which avoids removing the element from the queue immediately, and which should be an order of magnitude faster, but I'll provide that as a separate patch since it poses questions about API and backward compatibility.

----------
files: sched-cancel-speedup.patch
keywords: patch
messages: 148103
nosy: giampaolo.rodola, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: sched.py: speedup cancel() method
versions: Python 3.3
Added file: http://bugs.python.org/file23750/sched-cancel-speedup.patch

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

From report at bugs.python.org  Tue Nov 22 13:24:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 12:24:49 +0000
Subject: [New-bugs-announce] [issue13452] PyUnicode_EncodeDecimal: reject
	error handlers different	than strict
Message-ID: <1321964689.08.0.0221252575292.issue13452@psf.upfronthosting.co.za>


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

Error handling of PyUnicode_EncodeDecimal() is broken by design. The caller cannot know the size of the output buffer because each error handler produce a variable output, whereas the caller has to allocate 
this buffer and it is not possible to specify the size of the output buffer.

I propose to raise a ValueError if the error handler is different than "strict" and do this change in Python 2.7, 3.2 and 3.3.

In Python 2.7 code base, PyUnicode_EncodeDecimal() is always called with 
errors=NULL. In Python 3.x, the function is no more called.

Attached patch is for Python 3.2.

See also the issue #13093.

----------
components: Unicode
files: encode_decimal_errors.patch
keywords: patch
messages: 148111
nosy: ezio.melotti, haypo, loewis, skrah
priority: normal
severity: normal
status: open
title: PyUnicode_EncodeDecimal: reject error handlers different than strict
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23754/encode_decimal_errors.patch

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

From report at bugs.python.org  Tue Nov 22 14:16:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Nov 2011 13:16:53 +0000
Subject: [New-bugs-announce] [issue13453] Tests and network timeouts
Message-ID: <1321967813.33.0.280179416852.issue13453@psf.upfronthosting.co.za>


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

A lot of tests using the network are failing sometimes. They look like timeout or network failure.

Example:

======================================================================
ERROR: test_storlines (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_ftplib.py", line 582, in test_storlines
    self.client.storlines('stor', f)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/ftplib.py", line 824, in storlines
    conn.unwrap()
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/ssl.py", line 448, in unwrap
    s = self._sslobj.shutdown()
socket.timeout: The read operation timed out

----------
components: Tests
messages: 148116
nosy: haypo
priority: normal
severity: normal
status: open
title: Tests and network timeouts
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Nov 22 17:10:45 2011
From: report at bugs.python.org (Pyry Pakkanen)
Date: Tue, 22 Nov 2011 16:10:45 +0000
Subject: [New-bugs-announce] [issue13454] crash when deleting one pair from
	tee()
Message-ID: <1321978245.14.0.0332901316698.issue13454@psf.upfronthosting.co.za>


New submission from Pyry Pakkanen <frostburn at suomi24.fi>:

Running the following results in a Segmentation fault on Ubuntu 11.10 64-bit with both python and python3.

from itertools import *
c = count()
a,b = tee(c)
for i in range(10000000):
 next(a)
del(b)

----------
messages: 148124
nosy: PyryP
priority: normal
severity: normal
status: open
title: crash when deleting one pair from tee()
type: crash
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Nov 22 18:55:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Nov 2011 17:55:54 +0000
Subject: [New-bugs-announce] [issue13455] Reorganize tracker docs in the
	devguide
Message-ID: <1321984554.54.0.834071786299.issue13455@psf.upfronthosting.co.za>


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

The documentation about the bug tracker is sparse in a few different places.  The devguide contains 4 pages:
 1. http://docs.python.org/devguide/helptriage.html
 2. http://docs.python.org/devguide/devrole.html
 3. http://docs.python.org/devguide/triaging.html
 4. http://docs.python.org/devguide/languishing.html

There are two wiki pages:
 5. http://wiki.python.org/moin/SubmittingBugs
 6. http://wiki.python.org/moin/TrackerDocs/

And an additional page in the official docs:
 7. http://docs.python.org/dev/py3k/bugs.html

Some content is duplicated, 5 and 7 are similar, and 6 has the same content of 3 and 2.

The idea is to have 2 pages about the tracker in the devguide:
 * A new "tracker.rst" page that includes all the information about the tracker except the description of the fields;
 * The old "triaging.rst", that only describes the meaning of the fields.

The attached patch groups this information in the new page, removing the old pages (1, 2, 4) and updating the index and toc.

The content of the wiki pages (5 and 6) should be deleted and a pointer to the devguide should be added instead.
The bugs page in the docs (7) should not contain all the steps necessary to register and open an issue IMHO, but just a short description and a link to the devguide.

Currently the structure of the new page is:
tracker.rst
  +-- Using the Issue Tracker
  |     +-- Checking if a bug already exists
  |     +-- Reporting an issue
  |
  +-- Helping Triage Issues
  |     +-- Classifying Reports
  |     +-- Reviewing Patches
  |     +-- Finding an Issue You Can Help With
  |     +-- Gaining the "Developer" Role on the Issue Tracker
  |
  +-- The Meta Tracker

I mostly copy/pasted from other pages (e.g. "Using the Issue Tracker" is copied from 7), so this should be reorganized a bit.
The things I would like to include here are:
 * how to search issues
 * how to report a new issue
 * how to classify issues
 * how to make reviews
 * how to find interesting issues
 * how to get the developer role
 * how to use the keyboard shortcuts

It might be better to just list all these things, or group them in "basic" (searching/reporting) and "advanced" (everything else), or keep a step by step "how to report a bug" separate and just describe specific tasks here (like "how to register/login/report").

----------
assignee: ezio.melotti
components: Devguide
files: issue13455.diff
keywords: patch
messages: 148131
nosy: brett.cannon, eli.bendersky, eric.araujo, ezio.melotti, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Reorganize tracker docs in the devguide
Added file: http://bugs.python.org/file23757/issue13455.diff

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

From report at bugs.python.org  Tue Nov 22 20:02:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Nov 2011 19:02:13 +0000
Subject: [New-bugs-announce] [issue13456] Providing a custom HTTPResponse
	class to HTTPConnection
Message-ID: <1321988533.96.0.72454390842.issue13456@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The doc string for HTTPConnection.getresponse mentions (in broken English) that the instance's response_class attribute determines what class gets instantiated for a response.  The docs do not mention this attribute, nor any other way to control what class is used.

Since this attribute already exists and is mentioned in the doc string, can we consider this a doc error and just document it?

----------
assignee: docs at python
components: Documentation
messages: 148136
nosy: docs at python, orsenthil, r.david.murray
priority: normal
severity: normal
status: open
title: Providing a custom HTTPResponse class to HTTPConnection
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Nov 22 21:28:56 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 22 Nov 2011 20:28:56 +0000
Subject: [New-bugs-announce] [issue13457] Display module name as string in
	`ImportError`
Message-ID: <1321993736.11.0.640426182551.issue13457@psf.upfronthosting.co.za>


New submission from Ram Rachum <ram at rachum.com>:

Recently I was confronted with a mysterious error:

    ImportError: No module named datetime

Firther investigation revealed that the cause was a pickling problem that ran `__import__('datetime\r')`.

If `ImportError` would have shown the module name as a string, there would be no ambiguity:

    ImportError: No module named 'datetime\r'

----------
components: Interpreter Core
messages: 148140
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Display module name as string in `ImportError`
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 23 00:46:25 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 22 Nov 2011 23:46:25 +0000
Subject: [New-bugs-announce] [issue13458] _ssl memory leak in
	_get_peer_alt_names
Message-ID: <1322005585.35.0.144896453023.issue13458@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

_ssl.c has a memory leak in _get_peer_alt_names.

The `names' object is initialized here:

Modules/_ssl.c:601:
        if (method->it)
            names = (GENERAL_NAMES*)
              (ASN1_item_d2i(NULL,
                             &p,
                             ext->value->length,
                             ASN1_ITEM_ptr(method->it)));
        else
            names = (GENERAL_NAMES*)
              (method->d2i(NULL,
                           &p,
                           ext->value->length));

However, `names' is not freed after use, so it simply leaks.

Trivial patch:

--- a/Modules/_ssl.c	2011-09-03 12:16:46.000000000 -0400
+++ b/Modules/_ssl.c	2011-11-22 19:41:12.000000000 -0400
@@ -679,6 +679,8 @@
             }
             Py_DECREF(t);
         }
+
+        sk_GENERAL_NAME_pop_free(names, GENERAL_NAME_free);
     }
     BIO_free(biobuf);
     if (peer_alt_names != Py_None) {


I tested this with a private certificate containing a subjectAltName field, and the following code:

import ssl, socket
sock = ssl.wrap_socket(socket.socket(), cert_reqs=ssl.CERT_REQUIRED)
sock.connect(('localhost', 443))
for i in range(100000):
    x=sock._sslobj.peer_certificate()

Before this change, Python's memory usage would continually increase to about 45MB at the end of the loop. After this change, the memory usage stays constant at around 6MB.

----------
components: Library (Lib)
messages: 148154
nosy: nneonneo
priority: normal
severity: normal
status: open
title: _ssl memory leak in _get_peer_alt_names
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov 23 02:17:33 2011
From: report at bugs.python.org (Mike Fogel)
Date: Wed, 23 Nov 2011 01:17:33 +0000
Subject: [New-bugs-announce] [issue13459] logger.propagate=True behavior
	clarification
Message-ID: <1322011053.76.0.547589220073.issue13459@psf.upfronthosting.co.za>


New submission from Mike Fogel <mike at fogel.ca>:

Hi, there's been a fair amount of confusion over the interaction between logger.propagate and the ancestor logger's handlers and level.

http://bugs.python.org/issue7535
http://bugs.python.org/issue8327
http://bugs.python.org/issue9606

I think most this confusion could be avoided if the documentation for logger.propagate were expanded to explain clearly what happens when propagate evaluates to True - right now it just explains clearly what happens when it evaluates to False.

Attached is a documentation patch that does this.

Thanks for your consideration!

----------
assignee: docs at python
components: Documentation
files: logger_propagate_doc.diff
keywords: patch
messages: 148164
nosy: docs at python, mfogel, vinay.sajip
priority: normal
severity: normal
status: open
title: logger.propagate=True behavior clarification
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file23761/logger_propagate_doc.diff

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

From report at bugs.python.org  Wed Nov 23 02:34:37 2011
From: report at bugs.python.org (Tyler Starke)
Date: Wed, 23 Nov 2011 01:34:37 +0000
Subject: [New-bugs-announce] [issue13460] urllib methods should demand
	unicode, instead demand str
Message-ID: <1322012077.59.0.596577613585.issue13460@psf.upfronthosting.co.za>


New submission from Tyler Starke <prof.ebral at gmail.com>:

It seems bad practice for urllib methods to demand a str instance and they should demand a unicode instance. By demanding a str instance the default behavior is too demanding, for the web space it is being used, for the English language. We would want Python to extend beyond English when it uses urllib

Currently I am encoding the unicode passed with 'utf-8' and that works.

----------
components: Library (Lib), Unicode
messages: 148165
nosy: Tyler.Starke, ezio.melotti
priority: normal
severity: normal
status: open
title: urllib methods should demand unicode, instead demand str
type: behavior

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

From report at bugs.python.org  Wed Nov 23 15:02:38 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 23 Nov 2011 14:02:38 +0000
Subject: [New-bugs-announce] [issue13461] Error on test_issue_1395_5 with
	Python 2.7 and VS2010
Message-ID: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I am trying to get Python working when compiled with Visual Studio 2010 (cf issue 13210).

When running the tests with the python 2.7 branch compiled with VS2010, the "test_issue_1395_5" in test_io.py will cause Python to eat the whole memory within a few seconds and make the server completely unresponsive.

----------
components: IO
messages: 148184
nosy: sable
priority: normal
severity: normal
status: open
title: Error on test_issue_1395_5 with Python 2.7 and VS2010
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 23 17:39:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 16:39:01 +0000
Subject: [New-bugs-announce] [issue13462] Improve code and tests for
	Mixin2to3
Message-ID: <1322066341.39.0.436349182896.issue13462@psf.upfronthosting.co.za>


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

Currently distutils2 has two classes and one function to perform 2to3 conversion in the build_py and build_scripts commands.  The code is a bit messy and also lack tests, for example for the conversion of doctests in text files.  I?ve started revamping it so that it?s only one class that does the work, and I will also add many tests.

Benjamin: For Python 2.4 and 2.5, should the functionality just be unavailable or is there an official release of lib2to3 on PyPI?  I only found two2three, an old copy from the Subversion sandbox done by 3to2?s Joe Amenta, so I?m not sure I can be compatible with that (or if it?s even useful to try to convert 2.4 code to 3.x).

----------
assignee: eric.araujo
components: Distutils2
messages: 148188
nosy: alexis, benjamin.peterson, eric.araujo
priority: release blocker
severity: normal
status: open
title: Improve code and tests for Mixin2to3
type: behavior
versions: 3rd party, Python 3.3

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

From report at bugs.python.org  Wed Nov 23 18:13:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Nov 2011 17:13:53 +0000
Subject: [New-bugs-announce] [issue13463] Fix parsing of package_data
Message-ID: <1322068433.36.0.783240091616.issue13463@psf.upfronthosting.co.za>


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

In 288640098ea8, Jeremy fixed a bug in distutils2.config that prevented d2?s own setup.py script from working.  I had to revert that change because it caused tests to fail.  The bug needs to be identified exactly, then a test for it is needed, and finally an sdist should be created to check that all files are included.

As I want to release 1.0a4 very soon, I?ll work on this today or tomorrow.

----------
assignee: eric.araujo
components: Distutils2
messages: 148194
nosy: alexis, eric.araujo
priority: release blocker
severity: normal
stage: test needed
status: open
title: Fix parsing of package_data
type: behavior
versions: 3rd party, Python 3.3

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

From report at bugs.python.org  Wed Nov 23 19:14:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Nov 2011 18:14:22 +0000
Subject: [New-bugs-announce] [issue13464] HTTPResponse is missing an
	implementation of readinto
Message-ID: <1322072062.06.0.738377139897.issue13464@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

HTTPResponse subclasses RawIOBase, but does not provide an implementation of readinto, only read.  This means that it is not conforming to the IO spec, and so it cannot be wrapped in a BufferedIOBase when using the C version of io.

----------
components: Library (Lib)
keywords: easy
messages: 148199
nosy: orsenthil, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: HTTPResponse is missing an implementation of readinto
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov 23 19:46:55 2011
From: report at bugs.python.org (Frank Wierzbicki)
Date: Wed, 23 Nov 2011 18:46:55 +0000
Subject: [New-bugs-announce] [issue13465] A Jython section in the dev guide
	would be great
Message-ID: <1322074015.2.0.311635199294.issue13465@psf.upfronthosting.co.za>


New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:

Nick suggested this as a comment on a blog post of mine -- I'll come up with some content, but I wanted to log the bug straight away so I wouldn't forget.

----------
components: Devguide
messages: 148200
nosy: brett.cannon, ezio.melotti, fwierzbicki, ncoghlan
priority: normal
severity: normal
status: open
title: A Jython section in the dev guide would be great
type: feature request

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

From report at bugs.python.org  Wed Nov 23 21:00:48 2011
From: report at bugs.python.org (Aleksey)
Date: Wed, 23 Nov 2011 20:00:48 +0000
Subject: [New-bugs-announce] [issue13466] new timezones
Message-ID: <1322078448.54.0.772868924392.issue13466@psf.upfronthosting.co.za>


New submission from Aleksey <shitsu16 at gmail.com>:

Hi Guys,
Since 31 august 2011 in Russian Federation always DST time.
http://worldtimezone.net/dst_news/dst_news_russia36.html

But
>>> time.tzname
('MSK', 'MSK')
>>> time.localtime().tm_isdst
0
>>> time.timezone
-10800
>>> time.altzone
-14400

i think tm_isdst must be always 1 for my zone, or timezone must be equal altzone

----------
messages: 148204
nosy: Rioky
priority: normal
severity: normal
status: open
title: new timezones
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 24 03:38:26 2011
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 24 Nov 2011 02:38:26 +0000
Subject: [New-bugs-announce] [issue13467] Typo in doc for library/sysconfig
Message-ID: <1322102306.14.0.426447482004.issue13467@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/library/sysconfig.html#sysconfig.get_path

> If scheme is provided, it must be a value from the list returned by get_path_names().

s/get_path_names/get_scheme_names/

----------
assignee: docs at python
components: Documentation
messages: 148223
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Typo in doc for library/sysconfig
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov 24 04:49:55 2011
From: report at bugs.python.org (Tom Dignan)
Date: Thu, 24 Nov 2011 03:49:55 +0000
Subject: [New-bugs-announce] [issue13468] Python 2.7.1 SegmentationFaults
	when given high	recursion limit
Message-ID: <1322106595.12.0.230558460851.issue13468@psf.upfronthosting.co.za>


New submission from Tom Dignan <tom at adeptdev.com>:

On my system, the magic number to make this segfault seems to be 26200:

tom at tralfamadore ~/Downloads $ python recur1.py  26199
160164968

tom at tralfamadore ~/Downloads $ python recur1.py  26200
Segmentation fault

Here's the source:

#!/usr/bin/python
import sys

if len(sys.argv) < 2:
    print "usage %r <number>" % sys.argv[0]
    sys.exit(1)

number = int(sys.argv[1])

sys.setrecursionlimit(number + 2)

f = (lambda n: (f(n - 1) if n > 0 else 0) + 
    (n if n % 3 == 0 or n % 5 == 0 else 0))

print f(number)

sys.exit(0)

----------
components: None
messages: 148226
nosy: tdignan
priority: normal
severity: normal
status: open
title: Python 2.7.1 SegmentationFaults when given high recursion limit
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 24 08:10:39 2011
From: report at bugs.python.org (Jussi Eronen)
Date: Thu, 24 Nov 2011 07:10:39 +0000
Subject: [New-bugs-announce] [issue13469] TimedRotatingFileHandler fails to
	handle intervals of	several weeks correctly
Message-ID: <1322118639.78.0.741046011353.issue13469@psf.upfronthosting.co.za>


New submission from Jussi Eronen <exec at iki.fi>:

When specifying a time period of several weeks, say when w0 and interval 4, the rollover still happens weekly instead of every 4 weeks. The log file names are as though the rollover happens every 4 weeks, which furthers the confusion. 

In the file system, it looks like this:

-rw-r----- 1 x x  94189100 2011-10-24 23:59 x.log.2011-09-27
-rw-r----- 1 x x  51059765 2011-11-01 00:59 x.log.2011-10-04

This seems to be the result of computeRollover not handling multiple weeks at all.

----------
components: Library (Lib)
messages: 148230
nosy: exec
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler fails to handle intervals of several weeks correctly
versions: Python 2.6

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

From report at bugs.python.org  Thu Nov 24 08:26:00 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 24 Nov 2011 07:26:00 +0000
Subject: [New-bugs-announce] [issue13470] A user may need ... when she has
	...
Message-ID: <1322119560.63.0.526352282157.issue13470@psf.upfronthosting.co.za>


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

http://docs.python.org/library/sys.html#sys.setrecursionlimit
http://docs.python.org/dev/library/sys.html#sys.setrecursionlimit

Doc for Python 2.7 says:
"A user may need to set the limit higher when she has ..."

Doc for Python 3.3 says:
"A user may need to set the limit higher when they have ..."


IMHO "she" and "they" are not right here.
Is it an initiative of the "Python diversity" group :-)

----------
assignee: docs at python
components: Documentation
messages: 148231
nosy: docs at python, flox
priority: low
severity: normal
stage: needs patch
status: open
title: A user may need ... when she has ...
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov 24 14:49:27 2011
From: report at bugs.python.org (Thorsten Simons)
Date: Thu, 24 Nov 2011 13:49:27 +0000
Subject: [New-bugs-announce] [issue13471] setting access time beyond Jan.
	2038 on remote share	failes on Win7 x64
Message-ID: <1322142567.98.0.834575465366.issue13471@psf.upfronthosting.co.za>


New submission from Thorsten Simons <th at snomis.de>:

Using Python '3.2.2 (default, Sep  4 2011, 09:07:29) [MSC v.1500 64 bit (AMD64)]' on Windows 7 Professional SP1:

If you set an access time for a file beyond Jan. 2038 on a file stored in a local NTFS filesystem, all's well:

>>> os.utime('c:\\temp_target\\ulp', (3433232323, 3433232323))
>>> os.stat('c:\\temp_target\\ulp')
nt.stat_result(st_mode=33206, st_ino=2251799813820060, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=3433232323, st_mtime=3433232323, st_ctime=1322133855)
>>> time.ctime(3433232323)
'Mon Oct 17 13:38:43 2078'

If you try to do this on a remote share (mounted as y:), provided by a Linux x64 box running Samba x64, things are different:

>>> os.utime('y:\\temp_target2\\ulp', (3433232323, 3433232323))
>>> os.stat('y:\\temp_target2\\ulp')
nt.stat_result(st_mode=33206, st_ino=67150103, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=0, st_atime=910692730085, st_mtime=910692730085, st_ctime=1322133629)
>>> time.ctime(910692730085)
Traceback (most recent call last):
  File "<pyshell#22>", line 1, in <module>
    time.ctime(910692730085)
ValueError: unconvertible time

So, setting of access/modification time does not work - assumeably, we run into a 32-bit boundary somewhere...

Interestingly, if you set the respective access time from a Linux x64 box, you can see the right access time within Windows 7 via Explorer/Properties...

----------
components: Windows
messages: 148248
nosy: Thorsten.Simons
priority: normal
severity: normal
status: open
title: setting access time beyond Jan. 2038 on remote share failes on Win7 x64
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 24 14:52:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 13:52:49 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue13472=5D_Quick_Start_in_dev?=
 =?utf-8?q?guide_doesn=E2=80=99t_mention_build_dependencies?=
Message-ID: <1322142769.6.0.687458451697.issue13472@psf.upfronthosting.co.za>


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

The Quick Start section in the devguide does not tell people what they need to install in order to compile Python.  A short mention or a link to a section with all info should be added.

I can contribute info for Debian and derivative systems: ?aptitude build-dep pythonX.Y?

----------
messages: 148249
nosy: eric.araujo, ezio.melotti
priority: normal
severity: normal
status: open
title: Quick Start in devguide doesn?t mention build dependencies

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

From report at bugs.python.org  Thu Nov 24 15:45:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Nov 2011 14:45:11 +0000
Subject: [New-bugs-announce] [issue13473] Add tests for files byte-compiled
	by distutils[2]
Message-ID: <1322145911.61.0.528651769931.issue13473@psf.upfronthosting.co.za>


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

I recently changed packaging.util.byte_compile, the function used by the build_py and install_lib commands, so that it can create .pyc and/or .pyo files independently of the calling?s Python -O or -B flags (dad02a080bbc), but I think I introduced a bug.  To check that bug and fully test byte_compile before I further simplify the function and backport the whole fix to distutils, I wanted to add tests that load a .pyc or .pyo file and make sure that the right optimization level is used (nothing for --compile, level one for --optimize=1, level 2 for --optimize=2).

In the attached patch, I run a Python with -O, -OO or no flag in a subprocess to import a module that prints different things depending on the optimization level.  The .pyc or .pyo file is already created by packaging, but I have no check that makes sure that they are not recreated (which I don?t want) and I don?t know if the optimizations in compile.c are applied during byte-compilation or after import (which would make my tests not exercise what I want).

(I tried to use imp.load_module at first but it?s not very friendly.  Other ideas that I had after the patch was done: Use subprocess + imp so that I can import pyc or pyo as I wish; use open + dis module.)

So, could you import experts review the functions added in packaging.tests.support and tell me if they exercise what I want?

----------
assignee: eric.araujo
components: Distutils, Distutils2
files: p7g-tests-bytecompiled-files.diff
keywords: patch
messages: 148258
nosy: alexis, brett.cannon, eric.araujo, ncoghlan, tarek
priority: normal
severity: normal
stage: commit review
status: open
title: Add tests for files byte-compiled by distutils[2]
versions: 3rd party, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23768/p7g-tests-bytecompiled-files.diff

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

From report at bugs.python.org  Thu Nov 24 21:10:58 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 24 Nov 2011 20:10:58 +0000
Subject: [New-bugs-announce] [issue13474] Mention of "-m" Flag Missing From
	Doc on Execution Model
Message-ID: <1322165458.97.0.989343856998.issue13474@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The doc on code execution[1] leaves out mention of the -m flag.  Seems like it belongs there too.

[1] Doc/reference/executionmodel.rst

----------
assignee: docs at python
components: Documentation
messages: 148288
nosy: docs at python, eric.snow
priority: normal
severity: normal
status: open
title: Mention of "-m" Flag Missing From Doc on Execution Model
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov 25 01:46:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Nov 2011 00:46:34 +0000
Subject: [New-bugs-announce] [issue13475] Add '-p'/'--path0' command line
	option to override	sys.path[0] initialisation
Message-ID: <1322181994.22.0.955887054946.issue13475@psf.upfronthosting.co.za>


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

PEP 395 spends a lot of time discussing ways that the current automatic initialisation of sys.path[0] can go wrong, and even the proposed improvements in that PEP don't claim to fix the default behaviour for every possible scenario (just many of the most common ones).

The unittest module gets around similar problems with test autodiscovery by providing an explicit "-t" (for 'toplevel') command line option.

While '-t' is not available for the main interpreter executable (and nor is '-d' for directory), '-p' for "path0" is a possibility.

Directory execution (for example) would then be equivalent to:

  python -p dirname dirname/__main__.py

A separate '--nopath0' option could also be provided to explicitly disable path initialisation based on the script being executed (see http://lists.debian.org/debian-python/2011/11/msg00058.html)

----------
messages: 148295
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add '-p'/'--path0' command line option to override sys.path[0] initialisation

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

From report at bugs.python.org  Fri Nov 25 02:57:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Nov 2011 01:57:03 +0000
Subject: [New-bugs-announce] [issue13476] Simple exclusion filter for
	unittest autodiscovery
Message-ID: <1322186223.31.0.112270498917.issue13476@psf.upfronthosting.co.za>


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

unittest autodiscovery is very nice, but a '-x' option to specify directory patterns *not* to search could be a nice enhancement.

(In my specific case, I want to run most of my tests, but one batch are Django tests and it would be nice to have an easy way to tell unittest to ignore them)

----------
components: Library (Lib)
messages: 148299
nosy: michael.foord, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Simple exclusion filter for unittest autodiscovery
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov 25 04:11:05 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Fri, 25 Nov 2011 03:11:05 +0000
Subject: [New-bugs-announce] [issue13477] tarfile module should have a
	command line
Message-ID: <1322190665.85.0.356467902383.issue13477@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes <brandon at rhodesmill.org>:

The tarfile module should have a simple command line that allows it to be executed with "-m" ? even if its only ability was to take a filename and extract it to the current directory, it could be a lifesaver on Windows machines where Python has been installed but nothing else. Would such a patch be welcome if I could write one up?

----------
messages: 148300
nosy: brandon-rhodes
priority: normal
severity: normal
status: open
title: tarfile module should have a command line

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

From report at bugs.python.org  Fri Nov 25 09:13:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 25 Nov 2011 08:13:35 +0000
Subject: [New-bugs-announce] [issue13478] No documentation for
	timeit.default_timer
Message-ID: <1322208815.17.0.598781679655.issue13478@psf.upfronthosting.co.za>


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

Hello,
timeit documentation doesn't mention default_timer, while the module exposes it publicly and there's code snippets on the web using it. It should be documented then.


ps: adding Georg to nosy as per Experts list

----------
assignee: docs at python
components: Documentation
messages: 148307
nosy: docs at python, georg.brandl, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: No documentation for timeit.default_timer
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov 25 10:02:43 2011
From: report at bugs.python.org (kxroberto)
Date: Fri, 25 Nov 2011 09:02:43 +0000
Subject: [New-bugs-announce] [issue13479] pickle to picky on re-defined
	classes
Message-ID: <1322211763.06.0.781568755806.issue13479@psf.upfronthosting.co.za>


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

When a class definition was re-executed (reload, exec ..) , pickling of existing instances fails for to picky reason (class object id mismatch). Solved by the one liner patch below.

Rational: Python is dynamic. Like with any normal attribute lookup: When its the same module/..name  this class is really meant - no matter about its id. 
(During unpickling its another id anyway, the code may have evolved years ...)


diff -ur --strip _orig/pickle.py ./pickle.py
--- _orig/pickle.py	2008-09-08 10:58:32 +0000
+++ ./pickle.py	2011-11-24 15:47:11 +0000
@@ -747,7 +747,7 @@
                 "Can't pickle %r: it's not found as %s.%s" %
                 (obj, module, name))
         else:
-            if klass is not obj:
+            if klass.__name__ != obj.__name__:
                 raise PicklingError(
                     "Can't pickle %r: it's not the same object as %s.%s" %
                     (obj, module, name))

----------
components: Library (Lib)
messages: 148311
nosy: kxroberto
priority: normal
severity: normal
status: open
title: pickle to picky on re-defined classes
type: crash
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/issue13479>
_______________________________________

From report at bugs.python.org  Fri Nov 25 15:51:35 2011
From: report at bugs.python.org (Asa Dawson)
Date: Fri, 25 Nov 2011 14:51:35 +0000
Subject: [New-bugs-announce] [issue13480] range exits loop without action
	when start is higher	than end
Message-ID: <1322232695.49.0.811038839727.issue13480@psf.upfronthosting.co.za>


New submission from Asa Dawson <sunderphon at googlemail.com>:

range has an odd behavior in which it assumes (regardless of start/end) that it should be counting up. Attempting something such as:

for i in range(10,0):
    print i

This loop simply runs through without doing anything, because start is larger than end.

I'm putting forward the proposition that when end is lower than start, range should count downwards rather than upwards.

----------
components: None
messages: 148315
nosy: Asa.Dawson
priority: normal
severity: normal
status: open
title: range exits loop without action when start is higher than end
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Nov 26 01:02:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 00:02:01 +0000
Subject: [New-bugs-announce] [issue13481] Use an accurate clock in timeit
Message-ID: <1322265721.78.0.0567796730825.issue13481@psf.upfronthosting.co.za>


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

This patch uses an accurate POSIX clock if possible in the timeit module.

----------
components: Library (Lib)
files: timeit_clock.patch
keywords: patch
messages: 148369
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Use an accurate clock in timeit
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23783/timeit_clock.patch

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

From report at bugs.python.org  Sat Nov 26 09:50:05 2011
From: report at bugs.python.org (Martin Unzner)
Date: Sat, 26 Nov 2011 08:50:05 +0000
Subject: [New-bugs-announce] [issue13482] _tkinter.TclError: invalid command
	name "tixDirSelectBox"
Message-ID: <1322297405.04.0.473643719264.issue13482@psf.upfronthosting.co.za>


New submission from Martin Unzner <abmelden22 at gmx.de>:

Hi all,

while executing the following piece of code:

import tkinter
import tkinter.tix

if __name__=='__main__':
    root = tkinter.Tk()
    dirlist = tkinter.tix.DirSelectBox(root)
    dirlist.pack()
    root.mainloop()

the following error occurred:

Traceback (most recent call last):
  File "<...>", line 6, in <module>
    dirlist = tkinter.tix.DirSelectBox(root)
  File "C:\Python32\lib\tkinter\tix.py", line 712, in __init__
    TixWidget.__init__(self, master, 'tixDirSelectBox', ['options'], cnf, kw)
  File "C:\Python32\lib\tkinter\tix.py", line 322, in __init__
    self.tk.call(widgetName, self._w, *extra)
_tkinter.TclError: invalid command name "tixDirSelectBox"

Thanks!

Martin

----------
components: Tkinter
messages: 148384
nosy: Martin.Unzner
priority: normal
severity: normal
status: open
title: _tkinter.TclError: invalid command name "tixDirSelectBox"
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov 26 14:12:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Nov 2011 13:12:42 +0000
Subject: [New-bugs-announce] [issue13483] Use VirtualAlloc to allocate
	memory arenas
Message-ID: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za>


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

Similar to issue #11849, this patch proposes to use VirtualAlloc/VirtualFree to allocate the Python allocator's memory arenas (rather than malloc() / free()). It might help release more memory if there is some fragmentation, although I don't know how Microsoft's malloc() works.

----------
components: Interpreter Core, Windows
files: va.patch
keywords: patch
messages: 148399
nosy: brian.curtin, neologix, pitrou, tim.golden
priority: low
severity: normal
status: open
title: Use VirtualAlloc to allocate memory arenas
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file23784/va.patch

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

From report at bugs.python.org  Sat Nov 26 16:38:08 2011
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 26 Nov 2011 15:38:08 +0000
Subject: [New-bugs-announce] [issue13484] mail rejected: tutor@python.org
Message-ID: <1322321888.72.0.32483398033.issue13484@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

I sent this question to tutor at python.org as advertised at
http://mail.python.org/mailman/listinfo/tutor
The message was returned, and we still need an answer to the question.  I'll post it as a separate bug.
Thank you, Dave.


From: 	David Ward Lambert <b49P23TIvg at stny.rr.com>
To: 	tutor at python.org
Subject: 	tkinter question I have not been able to resolve.
Date: 	Mon, 21 Nov 2011 22:15:23 -0500


http://forums.devshed.com/python-programming-11/setting-tkinter-checkbox-default-graphical-state-865148.html

Summary: Trouble initiating button in "checked" state.

If you answer to me, I'll post the answer at the devshed forum.
If you answer at the forum I'll probably find it.

Thank you, Dave Lambert
also known as b49P23TIvg

----------
components: None
messages: 148414
nosy: LambertDW
priority: normal
severity: normal
status: open
title: mail rejected: tutor at python.org

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

From report at bugs.python.org  Sat Nov 26 16:58:59 2011
From: report at bugs.python.org (David W. Lambert)
Date: Sat, 26 Nov 2011 15:58:59 +0000
Subject: [New-bugs-announce] [issue13485] tcl question
Message-ID: <1322323139.8.0.0736428803132.issue13485@psf.upfronthosting.co.za>


New submission from David W. Lambert <b49P23TIvg at stny.rr.com>:

I was unable to solve this question.

http://forums.devshed.com/python-programming-11/setting-tkinter-checkbox-default-graphical-state-865148.html
        
        Summary: Trouble initiating button in "checked" state.
        
        If you answer to me, I'll post the answer at the devshed forum.
        If you answer at the forum I'll probably find it.
        
  
I doubt this is a python bug.  I doubt this is a tcl bug.  I think the proper forum would be the "How do I use tcl?" forum.  Sorry, I've posed the question here.

        Thank you, Dave Lambert
        also known as b49P23TIvg

----------
components: Library (Lib)
messages: 148415
nosy: LambertDW
priority: normal
severity: normal
status: open
title: tcl question

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

From report at bugs.python.org  Sat Nov 26 22:59:43 2011
From: report at bugs.python.org (Jahangir)
Date: Sat, 26 Nov 2011 21:59:43 +0000
Subject: [New-bugs-announce] [issue13486] msvc9compiler.py doesn't properly
	generate manifest	files.
Message-ID: <1322344783.33.0.460870481781.issue13486@psf.upfronthosting.co.za>


New submission from Jahangir <j4hangir at yahoo.com>:

msvc9compiler.py aims to generate a manifestation file but it will always fail as MSVC (cl.exe) needs a second /MANIFEST parameter to do so.

This makes the subsequent 'linking' processes fail with the following error:

general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified.


http://msdn.microsoft.com/en-us/library/f2c0w594.aspx (default value is NO)

----------
assignee: tarek
components: Distutils
files: msvc9compiler.py.diff
keywords: patch
messages: 148424
nosy: Jahangir, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: msvc9compiler.py doesn't properly generate manifest files.
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file23787/msvc9compiler.py.diff

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

From report at bugs.python.org  Sun Nov 27 04:06:49 2011
From: report at bugs.python.org (Erik Tollerud)
Date: Sun, 27 Nov 2011 03:06:49 +0000
Subject: [New-bugs-announce] [issue13487] inspect.getmodule fails when
	module imports change	sys.modules
Message-ID: <1322363209.24.0.0935380803772.issue13487@psf.upfronthosting.co.za>


New submission from Erik Tollerud <erik.tollerud at gmail.com>:

The inspect.getmodule function crashes if packages are installed that futz with sys.modules while they are being tested for module status or the like.  I'm not actually sure which packages are doing this, but the symptom is the for loop over sys.modules raises an Exception because it is modified while the loop is running.

This is *not* a problem in Python 2.x because sys.modules.items() returns a copy of the dictionary instead of an iterator, and 3.x changes that behavior.  The comment above the for loop makes it clear that the expected behavior is a copy rather than an iterator, so the attached patch corrects the problem by simply wrapping the items() call in list().

----------
components: Library (Lib)
files: getmodulefix.patch
keywords: patch
messages: 148438
nosy: Erik.Tollerud
priority: normal
severity: normal
status: open
title: inspect.getmodule fails when module imports change sys.modules
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23790/getmodulefix.patch

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

From report at bugs.python.org  Sun Nov 27 05:15:32 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 27 Nov 2011 04:15:32 +0000
Subject: [New-bugs-announce] [issue13488] Some old preprocessors have
	problem with "#define" not	in the first colum
Message-ID: <1322367332.5.0.427316218308.issue13488@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

While working in dtrace probes, I have discovered that some old C preprocessors don't recognize "#define" if not in the first column.

File "Include/dynamic_annotations.h" has quite a few indented "#define". This is neither necessary neither regular practice in other files.

I delete the extra unneeded spaces.

----------
assignee: jcea
messages: 148440
nosy: jcea
priority: normal
severity: normal
status: open
title: Some old preprocessors have problem with "#define" not in the first colum
type: compile error
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Nov 27 06:01:50 2011
From: report at bugs.python.org (Shawn Ligocki)
Date: Sun, 27 Nov 2011 05:01:50 +0000
Subject: [New-bugs-announce] [issue13489] collections.Counter doc does not
	list added version
Message-ID: <1322370110.24.0.847856523325.issue13489@psf.upfronthosting.co.za>


New submission from Shawn Ligocki <sligocki at gmail.com>:

collections.Counter doc does not list added version:

http://docs.python.org/library/collections.html

It appears to only have been added in 2.7 (while the rest of the doc says it is valid since 2.4)

----------
assignee: docs at python
components: Documentation
messages: 148443
nosy: docs at python, sligocki
priority: normal
severity: normal
status: open
title: collections.Counter doc does not list added version
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Nov 27 10:24:22 2011
From: report at bugs.python.org (holger krekel)
Date: Sun, 27 Nov 2011 09:24:22 +0000
Subject: [New-bugs-announce] [issue13490] broken downloads counting on
	pypi.python.org
Message-ID: <1322385862.72.0.235563901981.issue13490@psf.upfronthosting.co.za>


New submission from holger krekel <holger.krekel at gmail.com>:

Seems like pypi.python.org does not properly maintain download counters anymore, at least for a few packages i looked at like pytest,execnet,tox,nose.

----------
components: None
messages: 148447
nosy: hpk
priority: normal
severity: normal
status: open
title: broken downloads counting on pypi.python.org
type: behavior

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

From report at bugs.python.org  Sun Nov 27 11:33:47 2011
From: report at bugs.python.org (Nebelhom)
Date: Sun, 27 Nov 2011 10:33:47 +0000
Subject: [New-bugs-announce] [issue13491] sqlite3 code adjustments
Message-ID: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>


New submission from Nebelhom <nebelhom at googlemail.com>:

The code examples for the sqlite3 library were in some cases non-functional.

With the help of Petri Lehtinen from core-mentorship, the following fixes are suggested.

NOTE: Last issue is not resolved yet, but suggestions have been made. Could you please review and decide what to do. The remaining issues have suggested fixes in the patch.

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

Connection.create_function(name, num_params, func)

    Creates a user-defined function that you can later use from within SQL statements under the function name name. num_params is the number of parameters the function accepts, and func is a Python callable that is called as the SQL function.

    The function can return any of the types supported by SQLite: bytes, str, int, float and None.

    Example:

    import sqlite3
    import hashlib

    def md5sum(t):
        return hashlib.md5(t).hexdigest()

    con = sqlite3.connect(":memory:")
    con.create_function("md5", 1, md5sum)
    cur = con.cursor()
    cur.execute("select md5(?)", ("foo",))
    print(cur.fetchone()[0])

This script raises error:

Traceback (most recent call last):
  File "sqlexample.py", line 12, in <module>
    cur.execute("select md5(?)", ("foo",))
sqlite3.OperationalError: user-defined function raised exception

When md5sum is then run separately, the following traceback is given

>>> md5sum(("foo",))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "sqlexample.py", line 7, in md5sum
    return hashlib.md5(t).hexdigest()
TypeError: object supporting the buffer API required


Suggested fix:

Change ("foo") to (b"foo")

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

Connection.text_factory?

    Using this attribute you can control what objects are returned for the TEXT data type. By default, this attribute is set to str and the sqlite3 module will return Unicode objects for TEXT. If you want to return bytestrings instead, you can set it to bytes.

    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.

    You can also set it to any other callable that accepts a single bytestring parameter and returns the resulting object.

    See the following example code for illustration:

    import sqlite3

    con = sqlite3.connect(":memory:")
    cur = con.cursor()

    # Create the table
    con.execute("create table person(lastname, firstname)")

    AUSTRIA = "\xd6sterreich"

    # by default, rows are returned as Unicode
    cur.execute("select ?", (AUSTRIA,))
    row = cur.fetchone()
    assert row[0] == AUSTRIA

    # but we can make sqlite3 always return bytestrings ...
    con.text_factory = str
    cur.execute("select ?", (AUSTRIA,))
    row = cur.fetchone()
    assert type(row[0]) == str
    # the bytestrings will be encoded in UTF-8, unless you stored garbage in the
    # database ...
    assert row[0] == AUSTRIA.encode("utf-8")

    # we can also implement a custom text_factory ...
    # here we implement one that will ignore Unicode characters that cannot be
    # decoded from UTF-8
    con.text_factory = lambda x: str(x, "utf-8", "ignore")
    cur.execute("select ?", ("this is latin1 and would normally create errors" +
                             "\xe4\xf6\xfc".encode("latin1"),))
    row = cur.fetchone()
    assert type(row[0]) == str

    # sqlite3 offers a built-in optimized text_factory that will return bytestring
    # objects, if the data is in ASCII only, and otherwise return unicode objects
    con.text_factory = sqlite3.OptimizedUnicode
    cur.execute("select ?", (AUSTRIA,))
    row = cur.fetchone()
    assert type(row[0]) == str

    cur.execute("select ?", ("Germany",))
    row = cur.fetchone()
    assert type(row[0]) == str

The code example returns the following error traceback

Traceback (most recent call last):
  File "sqlexample.py", line 23, in <module>
    assert row[0] == AUSTRIA.encode("utf-8")
AssertionError

Suggested fixes:
- #Create table... -> removed as not used
- all "assert type ... str" changed to "assert type ... bytes"
- # we can also implement... code block removed
- add ":meth:`[parameters]` needs to be a bytes type otherwise a TypeError will be raised." to the doc

-----------------------------------------------------------------------------
Cursor.executemany(sql, seq_of_parameters)

    Executes an SQL command against all parameter sequences or mappings found in the sequence sql. The sqlite3 module also allows using an iterator yielding parameters instead of a sequence.

    Here?s a shorter example using a generator:

    import sqlite3

    def char_generator():
        import string
        for c in string.letters[:26]:
            yield (c,)

    con = sqlite3.connect(":memory:")
    cur = con.cursor()
    cur.execute("create table characters(c)")

    cur.executemany("insert into characters(c) values (?)", char_generator())

    cur.execute("select c from characters")
    print(cur.fetchall())

Traceback (most recent call last):
  File "sqlexample.py", line 12, in <module>
    cur.executemany("insert into characters(c) values (?)", char_generator())
  File "sqlexample.py", line 5, in char_generator
    for c in string.letters[:26]:
AttributeError: 'module' object has no attribute 'letters'

suggested fixes
- import string outside function
- string.letters changed to string.ascii_letters_lowercase

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

11.6.5.3. Converting SQLite values to custom Python types?

Writing an adapter lets you send custom Python types to SQLite. But to make it really useful we need to make the Python to SQLite to Python roundtrip work.

Enter converters.

Let?s go back to the Point class. We stored the x and y coordinates separated via semicolons as strings in SQLite.

First, we?ll define a converter function that accepts the string as a parameter and constructs a Point object from it.

Note

Converter functions always get called with a string, no matter under which data type you sent the value to SQLite.

def convert_point(s):
    x, y = map(float, s.split(";"))
    return Point(x, y)

Now you need to make the sqlite3 module know that what you select from the database is actually a point. There are two ways of doing this:

    * Implicitly via the declared type
    * Explicitly via the column name

Both ways are described in section Module functions and constants, in the entries for the constants PARSE_DECLTYPES and PARSE_COLNAMES.

The following example illustrates both approaches.

import sqlite3

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y

    def __repr__(self):
        return "(%f;%f)" % (self.x, self.y)

def adapt_point(point):
    return "%f;%f" % (point.x, point.y)

def convert_point(s):
    x, y = list(map(float, s.split(";")))
    return Point(x, y)

# Register the adapter
sqlite3.register_adapter(Point, adapt_point)

# Register the converter
sqlite3.register_converter("point", convert_point)

p = Point(4.0, -3.2)

#########################
# 1) Using declared types
con = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_DECLTYPES)
cur = con.cursor()
cur.execute("create table test(p point)")

cur.execute("insert into test(p) values (?)", (p,))
cur.execute("select p from test")
print("with declared types:", cur.fetchone()[0])
cur.close()
con.close()

#######################
# 1) Using column names
con = sqlite3.connect(":memory:", detect_types=sqlite3.PARSE_COLNAMES)
cur = con.cursor()
cur.execute("create table test(p)")

cur.execute("insert into test(p) values (?)", (p,))
cur.execute('select p as "p [point]" from test')
print("with column names:", cur.fetchone()[0])
cur.close()
con.close()

The given code gives the following error:

Traceback (most recent call last):
  File "sqlexample.py", line 32, in <module>
    cur.execute("select p from test")
  File "sqlexample.py", line 14, in convert_point
    x, y = list(map(float, s.split(";")))
TypeError: Type str doesn't support the buffer API

suggested fixes:

def adapt_point(point):
   return ("%f;%f" % (point.x, point.y)).encode('ascii')

def convert_point(s):
   x, y = list(map(float, s.split(b";")))
   return Point(x, y)

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

11.6.7.2. Accessing columns by name instead of by index?

One useful feature of the sqlite3 module is the built-in sqlite3.Row class designed to be used as a row factory.

Rows wrapped with this class can be accessed both by index (like tuples) and case-insensitively by name:

import sqlite3

con = sqlite3.connect("mydb")
con.row_factory = sqlite3.Row

cur = con.cursor()
cur.execute("select name_last, age from people")
for row in cur:
    assert row[0] == row["name_last"]
    assert row["name_last"] == row["nAmE_lAsT"]
    assert row[1] == row["age"]
    assert row[1] == row["AgE"]

Gives following error:

Traceback (most recent call last):
  File "sqlexample.py", line 7, in <module>
    cur.execute("select name_last, age from people")
sqlite3.OperationalError: no such table: people

"Same error in 11.6.3 Cursor.execute() description"

Suggested fixes:
- None yet. I feel these should be standalone examples out of the box. the sqlite3 includes have a "createdb.py" file which would create the tablem but it is not referenced in the documentary. I do not know the reasoning behind this, but I would like to have standalone examples in these cases.

----------
assignee: docs at python
components: Documentation
files: sqlite_code_update.patch
keywords: patch
messages: 148448
nosy: Nebelhom, docs at python
priority: normal
severity: normal
status: open
title: sqlite3 code adjustments
versions: Python 3.3
Added file: http://bugs.python.org/file23793/sqlite_code_update.patch

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

From report at bugs.python.org  Mon Nov 28 10:24:31 2011
From: report at bugs.python.org (Michael Kraus)
Date: Mon, 28 Nov 2011 09:24:31 +0000
Subject: [New-bugs-announce] [issue13492] ./configure
	--with-system-ffi=LIBFFI-PATH
Message-ID: <1322472271.69.0.0807066602711.issue13492@psf.upfronthosting.co.za>


New submission from Michael Kraus <krausmichel at gmail.com>:

It would be very helpful to have the ability to specify a LIBFFI-PATH during Python configuration via

./configure --with-system-ffi=LIBFFI-PATH

We are using the Intel compiler to build Python, NumPy, SciPy, and Cython on a SuSE Linux Enterprise Server. Libffi uses some 128bit int type which is not defined by the Intel compiler, thus can't be build with it. 

Unfortunately, the ./configure script, if run with --with-system-ffi looks for the ffi includes only in the standard directories (/usr/include, etc.). On our cluster, we are not allowed to install into the main system, we can only add modules. As there is no libffi coming with SLES and we cannot install it into the standard directories, the configure script won't find it. Thus the above request.

Best regards,
Michael

----------
components: Build
messages: 148472
nosy: michael.kraus
priority: normal
severity: normal
status: open
title: ./configure --with-system-ffi=LIBFFI-PATH
type: feature request
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/issue13492>
_______________________________________

From report at bugs.python.org  Mon Nov 28 12:29:13 2011
From: report at bugs.python.org (python_hu)
Date: Mon, 28 Nov 2011 11:29:13 +0000
Subject: [New-bugs-announce] [issue13493] using python embed on AIX 6.1,
	Modules import error!
Message-ID: <1322479753.88.0.634847584065.issue13493@psf.upfronthosting.co.za>


New submission from python_hu <nari_hu at 163.com>:

Using python api embed on AIX 6.1,Modules import error,need help!!!!!
I have compile Python2.5.5 on Aix 6.1 using condigure:
 ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6 AR="ar -X64"
when i run Python,and import math module,it works well:

ibm1:python2.5>python
Python 2.5.5 (r255:77872, Nov 28 2011, 13:32:10) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> 

But when i using in my C++ program,it works erro,the follow is mt code :
//{{C++

#include <stdio.h>
#include "Python.h"
#include <dlfcn.h> 

int main( int argc, char **argv )
{
             Py_Main(argc, argv); 
}

//}}

When i run this code.it has erro like that:
ibm1:pytest>pytest
Python 2.5.5 (r255:77872, Nov 28 2011, 13:32:10) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
_PyImport_GetDynLoadFunc142:/usr/local/lib/python2.5/lib-dynload/math.so,flags=2_____
_PyImport_GetDynLoadFunc_erro:/usr/local/lib/python2.5/lib-dynload/math.so
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError:    0509-130 Symbol resolution failed /usr/local/lib/python2.5/lib-dynload/math.so because:
        0509-136   Symbol PyArg_Parse (number 0) is not exported from
                   dependent module pytest.
        0509-136   Symbol PyArg_ParseTuple (number 1) is not exported from
                   dependent module pytest.
        0509-136   Symbol Py_BuildValue (number 2) is not exported from
                   dependent module pytest.
        0509-136   Symbol PyDict_GetItemString (number 3) is not exported from
                   dependent module pytest.
        0509-136   Symbol PyErr_NoMemory (number 4) is not exported from
                   dependent module pytest.
        0509-136   Symbol PyErr_Occurred (number 5) is not exported from
                   dependent module pytest.
        0509-021 Additional errors occurred but are not reported.
        0509-192 Examine .loader section symbols with the
                 'dump -Tv' command.
                
>>>

----------
components: None
messages: 148474
nosy: python_hu
priority: normal
severity: normal
status: open
title: using python embed on AIX 6.1,Modules import error!
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Nov 28 15:01:08 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 28 Nov 2011 14:01:08 +0000
Subject: [New-bugs-announce] [issue13494] 'cast' any value to a Boolean?
Message-ID: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Docs nit:  at http://docs.python.org/dev/library/stdtypes.html#boolean-values we have

"""
The built-in function bool() can be used to cast any value to a Boolean ...
"""

It's a little unusual to talk about casting in Python.  Any objections to replacing 'cast' with 'convert'?

----------
assignee: docs at python
components: Documentation
messages: 148480
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: 'cast' any value to a Boolean?
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 28 20:56:58 2011
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 28 Nov 2011 19:56:58 +0000
Subject: [New-bugs-announce] [issue13495] IDLE: Regression - Two
	ColorDelegator instances loaded
Message-ID: <1322510218.36.0.927250562508.issue13495@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

Two instances of ColorDelegator are in the percolator chain. This is a regression from 2.x.

The problem can be found in __init__ of EditorWindow in EditorWindow.py.

Calling "io.loadfile" eventually calls "filename_change_hook" (See IOBinding.py's "set_filename"). The "filename_change_hook" calls "ResetColorizer" which brings up an instance of ColorDelegator. Then, the self.color reference is overwritten by a new ColorDelegator instance and added to the percolator chain.

The attached patch fixes the problem.

----------
components: IDLE
files: colorbug.patch
keywords: patch
messages: 148513
nosy: ned.deily, serwy
priority: normal
severity: normal
status: open
title: IDLE: Regression - Two ColorDelegator instances loaded
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23798/colorbug.patch

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

From report at bugs.python.org  Mon Nov 28 23:34:32 2011
From: report at bugs.python.org (Daniel Sturm)
Date: Mon, 28 Nov 2011 22:34:32 +0000
Subject: [New-bugs-announce] [issue13496] bisect module: Overflow at index
	computation
Message-ID: <1322519672.22.0.173147243777.issue13496@psf.upfronthosting.co.za>


New submission from Daniel Sturm <voodoon42 at gmail.com>:

The mid index computation in _bisectmodule.c in both internal_bisect_right and internal_bisect_left is done with:

mid = (lo + hi) / 2; // all three variables Py_ssize_t

which is  susceptible to overflows for large arrays, which would lead to undefined behavior (and in practice almost certainly a crash with a negative index)

The fix is trivial - mid = lo + (hi - lo) / 2; - but since I'm just starting to look into the code base I may be missing some undocumented assertions that guarantee this can't happen.

----------
components: Extension Modules
messages: 148517
nosy: Voo
priority: normal
severity: normal
status: open
title: bisect module: Overflow at index computation
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 29 12:29:15 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 29 Nov 2011 11:29:15 +0000
Subject: [New-bugs-announce] [issue13497] Fix for broken nice test on
	non-broken platforms with	pedantic compilers
Message-ID: <1322566155.29.0.23147421321.issue13497@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

Was poking around config.log and I saw that gcc was complaining of some undefined built-in symbols for the broken nice test in configure. This patch fixes that.

----------
files: configure-fix-broken-broken-nice-test.patch
keywords: patch
messages: 148554
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Fix for broken nice test on non-broken platforms with pedantic compilers
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file23804/configure-fix-broken-broken-nice-test.patch

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

From report at bugs.python.org  Tue Nov 29 14:42:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Nov 2011 13:42:03 +0000
Subject: [New-bugs-announce] [issue13498] os.makedirs exist_ok documentation
	is incorrect, as is some of the behavior
Message-ID: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The documentation for os.makedirs says:

  If the target directory with the same mode as specified already exists, raises an OSError exception if exist_ok is False, otherwise no exception is raised.

This is not correct.  If the file exists but the mode is different than that specified (or defaulted) after applying the umask, then an error is raised regardless of the value of exist_ok.  The above wording also implies that if the directory exists but has a different mode, that the mode will be changed.  Again, this is not what the code does.

It's not clear how useful this raise behavior is, but reading the original issue that added this option it is clearly intentional.  The documented behavior does seem useful, but if it actually reset the mode that would be a fairly significant behavior change, and would not be a good idea if the user had not specified a mode.  However, at the very least exists_ok should not raise if no mode was specified in the call.

The error message raised is also wrong in this case, since it says that the error is that the file already exists when we've said that that is OK.  A custom error message for this case would be better.

----------
assignee: docs at python
components: Documentation, Library (Lib)
keywords: easy
messages: 148564
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: os.makedirs exist_ok documentation is incorrect, as is some of the behavior
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Nov 29 15:13:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 29 Nov 2011 14:13:36 +0000
Subject: [New-bugs-announce] [issue13499] uuid documentation example uses
	invalid REPL/doctest	syntax
Message-ID: <1322576016.96.0.843898665466.issue13499@psf.upfronthosting.co.za>


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

See http://docs.python.org/library/uuid.html#example.

Comments are output lines, i.e. not prefixed with >>>, which breaks the ">>>" button that makes the example copy-pasteable.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 148571
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
status: open
title: uuid documentation example uses invalid REPL/doctest syntax
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Nov 29 15:56:41 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 29 Nov 2011 14:56:41 +0000
Subject: [New-bugs-announce] [issue13500] Hitting EOF gets cmd.py into a
	infinite EOF on return	loop
Message-ID: <1322578601.01.0.207872314852.issue13500@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

Pressing <enter> produces no output with cmd.py whenever ^D has been entered in; after I enter in ^D it gets into an infinite loop spewing out messages via cmd.Cmd.default() about EOF because self.lastcmd isn't being reset properly.

The attached patch fixes that usability nit to be more intuitive (I debated about changing 'EOF' to 0x10, but that's probably less intuitive..).

----------
components: Library (Lib)
files: python-cmd-reset-lastcmd-on-EOF.patch
keywords: patch
messages: 148575
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Hitting EOF gets cmd.py into a infinite EOF on return loop
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file23805/python-cmd-reset-lastcmd-on-EOF.patch

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

From report at bugs.python.org  Tue Nov 29 16:19:02 2011
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 29 Nov 2011 15:19:02 +0000
Subject: [New-bugs-announce] [issue13501] Make libedit support more generic;
	port readline / libedit to FreeBSD
Message-ID: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>


New submission from Garrett Cooper <yanegomi at gmail.com>:

The attached patch enables libedit support in a generic way via configure.in, so I can pass in --with-readline=editline, --with-readline=readline, --with-readline=yes, or --with[out]-readline[=no] and it will do one of the following:

1. Enable editline support.
2. Enable readline support.
3. Enable default OS support (editline on OSX, readline otherwise).
4. Explicitly disable readline support.

Tested functional via cmd.py and with basic poking around via the readline module.

The attached patch was created against the 2.7 branch, but I'll produce a patch against 'trunk' sometime later on this week.

PS. The only quirk I found was the fact that FreeBSD 9's libedit lied when it reports the number of available history items. Hrmmm..

----------
components: Library (Lib)
files: python-port-readline-module-to-libedit-on-freebsd.patch
keywords: patch
messages: 148577
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Make libedit support more generic; port readline / libedit to FreeBSD
type: feature request
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file23806/python-port-readline-module-to-libedit-on-freebsd.patch

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

From report at bugs.python.org  Tue Nov 29 21:45:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Nov 2011 20:45:16 +0000
Subject: [New-bugs-announce] [issue13502] Documentation for Event.wait
	return value is either	wrong or incomplete
Message-ID: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The documentation for Event.wait says:

  This method returns the internal flag on exit, so it will always return True except if a timeout is given and the operation times out.

In fact, however, if the thread that sets the flag immediately clears it, wait will return False.  Antoine looking at the code says that this appears to be intentional, and that would make sense since originally wait returned no value.

My use case is one thread waiting on another to complete a work loop.  Normally the worker thread goes to sleep after clearing the flag, but sometimes it immediately starts a new work loop.  In either case I want the monitoring loop to take an action when the work loop completes, and raise an error if the wait times out.  It looked to me like Event.wait would work in the scenario.

----------
assignee: docs at python
components: Documentation
messages: 148604
nosy: docs at python, pitrou, r.david.murray, tim_one
priority: normal
severity: normal
stage: needs patch
status: open
title: Documentation for Event.wait return value is either wrong or incomplete
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov 30 01:09:16 2011
From: report at bugs.python.org (Irmen de Jong)
Date: Wed, 30 Nov 2011 00:09:16 +0000
Subject: [New-bugs-announce] [issue13503] improved efficiency of bytearray
	pickling by using bytes	type instead of str
Message-ID: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za>


New submission from Irmen de Jong <irmen at razorvine.net>:

Pickling of bytearrays is quite inefficient right now, because bytearray's __reduce__ encodes the bytes of the bytearray into a str. A pickle made from a bytearray is quite a bit larger than necessary because of this, and it also takes a lot more processing to create it and to convert it back into the actual bytearray when unpickling (because it uses bytearray's str based initializer with encoding).

I've attached a patch (both for the default 3.x branch and the 2.7 branch) that changes this to use the bytes type instead. A pickle made from a bytearray with this patch applied now utilizes the BINBYTES/BINSTRING pickle opcodes which are a lot more efficient than BINUNICODE that is used now. The reconstruction of the bytearray now uses bytearray's initializer that takes a bytes object.

I don't think additional unit tests are needed because test_bytes already performs pickle tests on bytearrays.

A bit more info can be found in my recent post on comp.lang.python about this, see http://mail.python.org/pipermail/python-list/2011-November/1283668.html

----------
components: Interpreter Core
files: bytearray3x.patch
keywords: easy, needs review, patch
messages: 148627
nosy: alexandre.vassalotti, irmen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: improved efficiency of bytearray pickling by using bytes type instead of str
type: performance
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23812/bytearray3x.patch

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

From report at bugs.python.org  Wed Nov 30 01:31:23 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Nov 2011 00:31:23 +0000
Subject: [New-bugs-announce] [issue13504] Meta-issue for "Invent with
	Python" IDLE feedback
Message-ID: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>


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

This is a meta-issue for the following blog post: http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/

There are a bunch of good ideas there that should be split out into a number of separate bug reports and feature requests. This meta-bug is just a quick and dirty way to suggest doing so, and giving people a place to collaborate on the task.

----------
components: IDLE
messages: 148629
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Meta-issue for "Invent with Python" IDLE feedback
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 30 03:21:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Nov 2011 02:21:47 +0000
Subject: [New-bugs-announce] [issue13505] Bytes objects pickled in 3.x with
	protocol <=2 are	unpickled incorrectly in 2.x
Message-ID: <1322619707.99.0.479265394652.issue13505@psf.upfronthosting.co.za>


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

In Python 3.2:

>>> pickle.dumps(b'xyz', protocol=2)
b'\x80\x02c__builtin__\nbytes\nq\x00]q\x01(KxKyKze\x85q\x02Rq\x03.'

In Python 2.7:

>>> pickle.loads(b'\x80\x02c__builtin__\nbytes\nq\x00]q\x01(KxKyKze\x85q\x02Rq\x03.')
'[120, 121, 122]'

The problem is that the bytes() constructor argument is a list of ints, which gives a different result when reconstructed under 2.x where bytes is an alias of str:

>>> pickletools.dis(pickle.dumps(b'xyz', protocol=2))
    0: \x80 PROTO      2
    2: c    GLOBAL     '__builtin__ bytes'
   21: q    BINPUT     0
   23: ]    EMPTY_LIST
   24: q    BINPUT     1
   26: (    MARK
   27: K        BININT1    120
   29: K        BININT1    121
   31: K        BININT1    122
   33: e        APPENDS    (MARK at 26)
   34: \x85 TUPLE1
   35: q    BINPUT     2
   37: R    REDUCE
   38: q    BINPUT     3
   40: .    STOP
highest protocol among opcodes = 2

Bytearray objects use a different trick: they pass a (unicode string, encoding) pair which has the same constructor semantics under 2.x and 3.x. Additionally, such encoding is statistically more efficient: a list of 1-byte ints will take 2 bytes per encoded char, while a latin1-to-utf8 transcoded string (BINUNICODE uses utf-8) will take on average 1.5 bytes per encoded char (assuming a 50% probability of higher-than-127 bytes).

>>> pickletools.dis(pickle.dumps(bytearray(b'xyz'), protocol=2))
    0: \x80 PROTO      2
    2: c    GLOBAL     '__builtin__ bytearray'
   25: q    BINPUT     0
   27: X    BINUNICODE 'xyz'
   35: q    BINPUT     1
   37: X    BINUNICODE 'latin-1'
   49: q    BINPUT     2
   51: \x86 TUPLE2
   52: q    BINPUT     3
   54: R    REDUCE
   55: q    BINPUT     4
   57: .    STOP
highest protocol among opcodes = 2

----------
components: Library (Lib)
messages: 148635
nosy: alexandre.vassalotti, irmen, pitrou
priority: high
severity: normal
status: open
title: Bytes objects pickled in 3.x with protocol <=2 are unpickled incorrectly in 2.x
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov 30 03:51:05 2011
From: report at bugs.python.org (Marco Scataglini)
Date: Wed, 30 Nov 2011 02:51:05 +0000
Subject: [New-bugs-announce] [issue13506] IDLE sys.path does not contain
	Current Working Directory
Message-ID: <1322621465.07.0.137768445913.issue13506@psf.upfronthosting.co.za>


New submission from Marco Scataglini <atlantide at gmx.com>:

The IDLE shell sys.path does not contains any entry for the Current Working Directory ('' or '.' or '.\'); without it, when changing the CWD with os.chdir(), the shell cannot find, execute or import scripts or module in it.

I can start the standard Python interactive shell and os.chdir to any dev or test directories and import or call scripts and modules, or I can cd first to any of those directories from any shell (sh, batch, cmd.com), then start Python interactive shell and import or call scripts and modules, because there is the CWD available in the sys.path as ''.

I tried to manually add it to IDLE:

from cli by calling idle.py or idle.pyw with "-cimport sys;sys.path.insert(0,"");del sys"

or by making a IDLESTARTUP.py script

import sys
sys.path.insert(0,"")
del sys

and setting the IDLESTARTUP env var pointing at it

but these work in adding the CWD to sys.path only for the first run (start) of IDLE shell; but when it get restarted (ex.: the Shell/Restart Shell toolbar option) the CWD get reset without the CWD entry, and again it has the same problem

I also tried to cd from shell (sh, bash, cmd.com) first and then start IDLE and it worked for importing and calling modules and scripts in the specific dev/test directory, but it failed to import or call other standard scripts that actually are in the sys.path (ex.: win32ui).

This is needed to use IDLE to develop and test new scripts and modules not yet ready to be included into the standard libraries and paths, so momentarily modifying the path as above that also does not survive restarts made within the application, or permanently modifying the path statically to include any dev and test dir by adding the absolute path(s ) to env var PYTHONPATH are both not correct way.

And anyway it is not consistent with the behavior of the standard Python interactive shell that includes the CWD in sys.path (as '' right at the beginning), therefore os.chdir('to any non in sys.path dirs') works correctly in contrast with IDLE shell behavior... and who knows what else it breaks.

I am not an expert on python environment, but I have 20+ years professional experience in many other high profile QA dev and testing project (just Google me), so I just thing it should be fixed, since I see this problem since 2008 and I know others that have the same issue for long time before that.
I assure you inconsistency in IDLE and Python like that separate production products from hack toys and I know for a fact are alienating both novices and veterans, because first it makes it difficult to use IDLE for basic learning and second, because it get you skeptical to trust the rest of Python will behave differently and correctly for main development, since its main IDE distributed with the language does not.

If there is anything that I don't see just let me know,
thanks.

----------
components: IDLE
messages: 148636
nosy: MarcoScataglini
priority: normal
severity: normal
status: open
title: IDLE sys.path does not contain Current Working Directory
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 30 11:07:59 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Nov 2011 10:07:59 +0000
Subject: [New-bugs-announce] [issue13507] Modify OS X installer builds to
	package liblzma for the	new lzma module
Message-ID: <1322647679.29.0.297920473861.issue13507@psf.upfronthosting.co.za>


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

Since AFAIK Apple does not currently ship a version of liblzma with Mac OS X, the OS X installer build script should be modified to build and link a version in support of the new lzma module (Issue6715).

Mac/BuildScript/build-installer.py

http://tukaani.org/xz/

----------
assignee: ned.deily
components: Build, Macintosh
messages: 148646
nosy: nadeem.vawda, ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Modify OS X installer builds to package liblzma for the new lzma module
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 30 15:54:33 2011
From: report at bugs.python.org (=?utf-8?q?Lo=C3=AFc_Minier?=)
Date: Wed, 30 Nov 2011 14:54:33 +0000
Subject: [New-bugs-announce] [issue13508] ctypes' find_library breaks with
	ARM ABIs
Message-ID: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za>


New submission from Lo?c Minier <lool at dooz.org>:

Hi,

This bug was originally reported at 
https://bugs.launchpad.net/bugs/898172

ctypes/utils.py provides a find_library function which amongst other things will scan the ldconfig -p output on linux to find libraries by name.  It applies some logic to filter out incompatible libraries, however the logic is mainly based on uname output which is incorrect.

We noticed because the new Debian/Ubuntu armhf ports have a slightly different ldconfig -p output than the armel ports; one gets ",hard-float" in the output, e.g.:
        ld-linux.so.3 (libc6,hard-float) => /lib/arm-linux-gnueabihf/ld-linux.so.3

there's provision in find_library to allow for certain strings when uname returns certain names:
             mach_map = {
                 'x86_64-64': 'libc6,x86-64',
                 'ppc64-64': 'libc6,64bit',
                 'sparc64-64': 'libc6,64bit',
                 's390x-64': 'libc6,64bit',
                 'ia64-64': 'libc6,IA-64',

but this is incorrect for multiple reasons:
a) this requires setting utsname properly before running a 32-bits python on a 64-bits kernel (e.g. "linux32 ./foo.py" instead of just "./foo.py"); this shouldn't be needed and breaks 32-bits userspace installations with a 64-bits kernel
b) uname output can be anything really, e.g. i486, i586, i686 etc. on 32-bits x86, or armv5l, armv6l, armv7l etc. on ARM
c) uname output doesn't indicate userspace ABI, a single kernel can support multiple ABIs; for instance ARM kernels can support EABI and OABI (old ABI) syscall ABIs at the same time, and even with the same syscall ABI like EABI the userspace calling conventions might allow for multiple ABIs to be present on the filesystem -- for instance soft-float and hard-float userspace calling conventions

I've attached a patch to ctypes/utils.py in the Launchpad bug which I'll also attach here.  It will work for either soft-float or hard-float, but not if "ldconfig -p" lists both types of libraries (as will be the case with biarch or multiarch systems).

It is extremely hard to reproduce correct glibc semantics in find_library, and a linux implementation would necessarily become extremely glibc and linux specific.  One possible way is to look at /proc/$pid/maps output to find information about the ABI of the currently running program, and then ask the runtime linker (ld.so) to check whether a given library is compatible or not (--verify).  Another way would be to run ldd on sys.executable to find the runtime linker or libc.  This is all extremely fragile and linux andglibc specific, and will likely fail in special cases.

Finally, one needs to wonder whether offering "find_library" as an API isn't calling for trouble; dlopen() requires one to state which SOVER should be used, e.g. dlopen("libmagic.so.1"), not dlopen("magic").  Allowing the first SOVER to be used means that the behavior is not determinstic and also means that people wont think of binary compatibility when implementing ctypes-based bindings.  I would personally prefer if this API was deprecated and if we recommended for upstreams to use ctypes.cdll.LoadLibrary("libmagic.so.1") constructs.

Cheers,

----------
components: ctypes
messages: 148656
nosy: lool
priority: normal
severity: normal
status: open
title: ctypes' find_library breaks with ARM ABIs
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Nov 30 17:40:10 2011
From: report at bugs.python.org (Jason Roberts)
Date: Wed, 30 Nov 2011 16:40:10 +0000
Subject: [New-bugs-announce] [issue13509] On uninstallation,
	distutils bdist_wininst fails to run post install script
Message-ID: <1322671210.14.0.984491104845.issue13509@psf.upfronthosting.co.za>


New submission from Jason Roberts <jason.roberts at duke.edu>:

Historically (i.e. Python 2.6.1 and earlier) bdist_wininst would run the post install script at both installation and uninstallation. The script would be invoked with a -install argument on installation and a -remove argument on uninstallation. This stopped working in Python 2.6.2 and has not worked since.

This regression appears to have been introduced in r69094. That checkin rewrote Run_RemoveScript and associated functions in PC/bdist_wininst/install.c. The rewrite changed how the Python DLL was loaded during the remove scenario.

Previously Run_RemoveScript itself called Win32 LoadLibrary on the DLL name parsed from the wininst log file. Now Run_RemoveScript calls run_installscript instead, which ultimately calls LoadPythonDll, which calls LoadLibrary on the pythondll global variable. But nothing initializes that variable during the remove scenario and LoadLibrary fails. Ultimately run_installscript silently fails and the removal proceeds to uninstall files and registry keys, with no notification to the user that the post install script was not run.

A possible solution is to initialize pythondll in Run_RemoveScript to the DLL name parsed from the wininst log file, e.g. by inserting the following code prior to the call to run_installscript:

        strncpy(pythondll, dllname, scriptname - 1 - dllname);
        pythondll[scriptname - 1 - dllname] = '\0';

I tested this and it seemed to work fine.

I believe this problem affects all Python releases following and including 2.6.2. The version history seems to show that r69094 was propagated to all of those releases. Presumably nobody found it because post install scripts on removal are not widely used. They are, however, critical for my application (at least if I want it to clean up properly on removal) so I would appreciate this being fixed. As it stands, I have to build a private patched copy of wininst-9.0.exe to work around this problem.

----------
assignee: tarek
components: Distutils
messages: 148672
nosy: eric.araujo, jasonjroberts, mhammond, tarek
priority: normal
severity: normal
status: open
title: On uninstallation, distutils bdist_wininst fails to run post install script
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/issue13509>
_______________________________________

From report at bugs.python.org  Wed Nov 30 18:42:29 2011
From: report at bugs.python.org (Peter Otten)
Date: Wed, 30 Nov 2011 17:42:29 +0000
Subject: [New-bugs-announce] [issue13510] Clarify that readlines() is not
	needed to iterate over a	file
Message-ID: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>


New submission from Peter Otten <__peter__ at web.de>:

I've been looking at code on the tutor mailing list for some time, and

for line in file.readlines(): ...

is a common idiom there. I suppose this is because the readlines() method is easily discoverable while the proper way (iterate over the file object directly) is not.

A note added to the readlines() documentation might help:

"""
You don't need the readlines() method to loop over the lines of a file.
for line in file: process(line)
consumes less memory and is often faster.
"""

----------
assignee: docs at python
components: Documentation
messages: 148679
nosy: docs at python, potten
priority: normal
severity: normal
status: open
title: Clarify that readlines() is not needed to iterate over a file
type: feature request

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

From report at bugs.python.org  Wed Nov 30 21:07:41 2011
From: report at bugs.python.org (Ray)
Date: Wed, 30 Nov 2011 20:07:41 +0000
Subject: [New-bugs-announce] [issue13511] ./configure --includedir,
	--libdir accept multiple
Message-ID: <1322683661.17.0.138081414237.issue13511@psf.upfronthosting.co.za>


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

For ./configure, --includedir and --libdir both cannot handle multiple packages. 

e.g. 

/configure --includedir=/home/user/.local/sqlite3-3.7.9/include --includedir=/home/user/.local/readline-6.2/include --libdir=/home/user/.local/sqlite3-3.7.9/lib --libdir=/home/user/.local/readline-6.2/lib

and 

/configure --includedir="/home/user/.local/sqlite3-3.7.9/include /home/user/.local/readline-6.2/include" --libdir="/home/user/.local/sqlite3-3.7.9/lib /home/user/.local/readline-6.2/lib"

The only way I could get the desired functionality was to set CFLAGS and LDFLAGS:

export CFLAGS="-I/home/user/.local/readline-6.2/include/ -I/home/user/.local/sqlite3-3.7.9/include/" && export LDFLAGS="-L/home/user/.local/readline-6.2/lib/ -L/home/user/.local/sqlite3-3.7.9/lib/"

----------
assignee: ronaldoussoren
components: Build, Installation, Macintosh
messages: 148681
nosy: ronaldoussoren, rpq
priority: normal
severity: normal
status: open
title: ./configure --includedir, --libdir accept multiple
type: behavior
versions: Python 2.7

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