From report at bugs.python.org  Tue May  1 03:35:24 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 01 May 2012 01:35:24 +0000
Subject: [New-bugs-announce] [issue14703] Update PEP metaprocesses to
	describe PEP czar role
Message-ID: <1335836124.46.0.0512543168568.issue14703@psf.upfronthosting.co.za>


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

The PEP czar role isn't yet described in the relevant meta PEPs.

We should fix that, as well as updating the PEP metadata to include the named czar where relevant.

----------
components: None
messages: 159740
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Update PEP metaprocesses to describe PEP czar role
type: enhancement

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

From report at bugs.python.org  Tue May  1 20:56:30 2012
From: report at bugs.python.org (David M. Rogers)
Date: Tue, 01 May 2012 18:56:30 +0000
Subject: [New-bugs-announce] [issue14704] NameError Issue in Multiprocessing
Message-ID: <1335898590.74.0.306368822304.issue14704@psf.upfronthosting.co.za>


New submission from David M. Rogers <dmroge at sandia.gov>:

Python Devs,

  There is an issue relating to variable lookup using exec from within multiprocessing's fork()-ed process.  I'm attempting to use the forked process as a generic remote python shell, but exec is unable to reach variables from within functions.  This issue makes it impossible to define a function which uses un-passed variables defined in the remote process.

  The simplest way to reproduce the error is:

--- err.py ---
from multiprocessing import Process, Pipe

def run_remote(con, name):
  my_name = name
  for i in range(2):
    code = con.recv()
    exec code

me, he = Pipe()
p = Process(target=run_remote,
            args=(he, "Sono Inglese de Gerrards Cross."))
p.start()

me.send("print my_name") # works

me.send("""
def show_name():
  print my_name
show_name() # doesn't work
""")
--- end err.py ---

This program prints:
$ python2.6 err.py
Sono Inglese de Gerrards Cross.
Process Process-1:
Traceback (most recent call last):
  File "/sw/lib/python2.6/multiprocessing/process.py", line 232, in _bootstrap
    self.run()
  File "/sw/lib/python2.6/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "err.py", line 7, in run_remote
    exec code
  File "<string>", line 4, in <module>
  File "<string>", line 3, in show_name
NameError: global name 'my_name' is not defined

I'm using Mac OSX (10.6.8) and
Python 2.6.5 (r265:79063, Sep 23 2010, 14:05:02) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

The issue (with the same traceback) also occurs for:
Python 2.7 (r27:82500, Sep 29 2010, 15:34:46) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin


Using exactly the same set of exec calls locally results in the correct behavior.

--- noerr.py ---
my_name = "Sono Inglese de Gerrards Cross."
exec "print my_name"

exec """
def show_name():
  print my_name
show_name()
"""
--- end noerr.py ---

----------
components: None
messages: 159764
nosy: frobnitzem
priority: normal
severity: normal
status: open
title: NameError Issue in Multiprocessing
versions: Python 2.6

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

From report at bugs.python.org  Wed May  2 11:29:19 2012
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 02 May 2012 09:29:19 +0000
Subject: [New-bugs-announce] [issue14705] Add 'bool' format character to
	PyArg_ParseTuple*
Message-ID: <1335950959.73.0.615702363048.issue14705@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Currently functions that parse their arguments with the PyArg_ParseTuple family which want to take a boolean-ish parameter face two choices:
  * take an "int", then test whether or not the int is 0, or
  * take an "object", then call PyObject_IsTrue themselves.

The former is foolish; though it works with ints and bools, it doesn't work with any other type (float, str, list, etc) which strictly speaking are valid for boolean fields.  And this is common enough that the latter should not be necessary.

I propose to add support for a new format character to the PyArg_ParseTuple family: 'b', which specifies 'boolean'.  Its
implementation would be much the same as that of 'd' except:
  * the output type would be "int" instead of "double",
  * it would check for a -1 instead of calling PyErr_Occured, and
  * it would call PyObject_IsTrue instead of PyFloat_AsDouble.


If we cared, I could also add 'B', which would only accept
either Py_True or Py_False.  But I see no reason why we'd ever want
to strictly enforce the type... do you?  (I can see MvL's argument now:
"We've lived this long without it.  YAGNI.")


If there's interest I'll knock out a patch.  I expect it to be less than ten lines not counting documentation and test.  (Less than twenty if
folks actually want 'B'.)

----------
assignee: larry
components: Interpreter Core
messages: 159781
nosy: larry
priority: normal
severity: normal
status: open
title: Add 'bool' format character to PyArg_ParseTuple*
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed May  2 12:57:25 2012
From: report at bugs.python.org (Adi Roiban)
Date: Wed, 02 May 2012 10:57:25 +0000
Subject: [New-bugs-announce] [issue14706] Inconsistent os.access os.X_OK on
	Solaris and AIX when	running as root
Message-ID: <1335956245.89.0.218192392031.issue14706@psf.upfronthosting.co.za>


New submission from Adi Roiban <adi at roiban.ro>:

The return value of os.access(FILE, os.X_OK) is not consistent across operating system when executed as "root"

I have tested with Python 2.5 on Linux and Solaris, but there is a bug in python-nose reporting the same behavior with Python 2.6 on Solaris and AIX.
http://code.google.com/p/python-nose/issues/detail?id=423

-------

On Solaris:

$ ls -al 
-rw-rw-r--   1 buildslave other       1079 May  1 16:25 nose_runner.py

$ ./bin/python 
Python 2.5.6 (r256:88840, Nov  1 2011, 12:19:05) 
[GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath)] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.access('nose_runner.py', os.X_OK)
False

$ sudo ./bin/python 
Python 2.5.6 (r256:88840, Nov  1 2011, 12:19:05) 
[GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath)] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.access('nose_runner.py', os.X_OK)
True

------

On Linux:

$ ls -al 
-rw-rw-r-- 1 adi adi  1079 2012-05-02 11:25 nose_runner.py

$ ./bin/python 
Python 2.5.5 (r255:77872, Sep 14 2010, 16:22:46) 
[GCC 4.4.5] on linux2
>>> import os
>>> os.access('nose_runner.py', os.X_OK)
False

$ sudo ./bin/python 
Python 2.5.5 (r255:77872, Sep 14 2010, 16:22:46) 
[GCC 4.4.5] on linux2
>>> import os
>>> os.access('nose_runner.py', os.X_OK)
False

----------
messages: 159784
nosy: adiroiban
priority: normal
severity: normal
status: open
title: Inconsistent os.access os.X_OK on Solaris and AIX when running as root
type: behavior

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

From report at bugs.python.org  Wed May  2 18:15:16 2012
From: report at bugs.python.org (Daniel543)
Date: Wed, 02 May 2012 16:15:16 +0000
Subject: [New-bugs-announce] [issue14707] extend() puzzled me.
Message-ID: <1335975316.5.0.356302155228.issue14707@psf.upfronthosting.co.za>


New submission from Daniel543 <superplayer_dan at 163.com>:

Python 2.7.3 (default, Apr 20 2012, 22:44:07) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = ['1']
>>> b = []
>>> c = a
>>> b.append(a)
>>> a
['1']
>>> b
[['1']]
>>> c
['1']
>>> a = ['2']
>>> c.extend(a)
>>> b
[['1', '2']]
>>> c
['1', '2']
>>> a
['2']
>>> 

Is this wrong? I think the "b" should not change.

----------
components: None
messages: 159807
nosy: Daniel543
priority: normal
severity: normal
status: open
title: extend() puzzled me.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May  3 05:10:44 2012
From: report at bugs.python.org (jamesf)
Date: Thu, 03 May 2012 03:10:44 +0000
Subject: [New-bugs-announce] [issue14708] distutils's checking for MSVC
	compiler
Message-ID: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za>


New submission from jamesf <54740235 at qq.com>:

I am using python 2.7.2 installed via the pre-built installer package, and my SDK version is v7.1.

1) The MSSdk environment variable is not set by lastest SDK's SetEnv.cmd anymore, but distutils still check for it.

2) I have also install MSVC 2010 Express Edition, and its vcvarsall.bat
can't be found.

Off-side question:
a) Can i use different version of MSVC from which python is built for extension development ?
b) Can i use mingw compiler to develop extension for the pre-built windows binary python ?

----------
messages: 159833
nosy: jwfang
priority: normal
severity: normal
status: open
title: distutils's checking for MSVC compiler
type: behavior
versions: Python 2.7

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

From martin at v.loewis.de  Thu May  3 08:23:37 2012
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Thu, 03 May 2012 08:23:37 +0200
Subject: [New-bugs-announce] [issue14708] distutils's checking for MSVC
 compiler
In-Reply-To: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za>
References: <1336014644.9.0.503289751284.issue14708@psf.upfronthosting.co.za>
Message-ID: <20120503082337.Horde.JeRTP6GZi1VPoiRpY1STROA@webmail.df.eu>

> I am using python 2.7.2 installed via the pre-built installer  
> package, and my SDK version is v7.1.
>
> 1) The MSSdk environment variable is not set by lastest SDK's  
> SetEnv.cmd anymore, but distutils still check for it.

This is intentional. Older SDKs still set the variable, so there
is nothing wrong with checking it.

> 2) I have also install MSVC 2010 Express Edition, and its vcvarsall.bat
> can't be found.

MSVC 2010 is not supported for building Python 2.7 extension modules.

>
> a) Can i use different version of MSVC from which python is built  
> for extension development ?

No. Because of the way the MSVCRT works, this can cause crashes.

> b) Can i use mingw compiler to develop extension for the pre-built  
> windows binary python ?

Yes.


From report at bugs.python.org  Thu May  3 12:31:38 2012
From: report at bugs.python.org (=?utf-8?q?Tobias_Steinr=C3=BCcken?=)
Date: Thu, 03 May 2012 10:31:38 +0000
Subject: [New-bugs-announce] [issue14709] http.client fails sending
	read()able Object
Message-ID: <1336041098.08.0.116585068152.issue14709@psf.upfronthosting.co.za>


New submission from Tobias Steinr?cken <ts at mausbrand.de>:

It seems that http.client's send() function lacks an else/return statement in Line 772.
If this method is called with an read()able Object, it jumps into 

L 750: if hasattr( data,"read"):

processes this data correctly, but then falls through (due to missing else ) to

L 773: try:
L 774:     self.socket.sendall(data)

where finally an TypeError raises.

----------
components: None
messages: 159845
nosy: Tobias.Steinr?cken
priority: normal
severity: normal
status: open
title: http.client fails sending read()able Object
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu May  3 12:45:41 2012
From: report at bugs.python.org (Pavel Aslanov)
Date: Thu, 03 May 2012 10:45:41 +0000
Subject: [New-bugs-announce] [issue14710] pkgutil.get_loader is broken
Message-ID: <1336041941.32.0.315196686397.issue14710@psf.upfronthosting.co.za>


New submission from Pavel Aslanov <asl.pavel at gmail.com>:

if module was marked as not existing by setting sys.modules [fullname] to None, then pkgutil.get_loader (fullname) will throw AttributeError.

Example:
#! /usr/bin/evn python
import unittest
import pkgutil

def main ():
    pkgutil.get_loader ('unittest.functools')

if __name__ == '__main__':
    main ()

Patch is attached

----------
components: Library (Lib)
files: python_pkgutil_bug.patch
keywords: patch
messages: 159848
nosy: Pavel.Aslanov
priority: normal
severity: normal
status: open
title: pkgutil.get_loader is broken
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25442/python_pkgutil_bug.patch

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

From report at bugs.python.org  Thu May  3 15:26:28 2012
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 03 May 2012 13:26:28 +0000
Subject: [New-bugs-announce] [issue14711] Remove os.stat_float_times
Message-ID: <1336051588.91.0.440090520788.issue14711@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Is there a specific reason this is still around?  Originally that was to make it possible to upgrade to Python 2.3 or whenever that was introduced.  I don't think anyone still uses that.

----------
messages: 159859
nosy: aronacher
priority: normal
severity: normal
status: open
title: Remove os.stat_float_times
versions: Python 3.4

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

From report at bugs.python.org  Thu May  3 17:34:31 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 May 2012 15:34:31 +0000
Subject: [New-bugs-announce] [issue14712] Integrate PEP 405
Message-ID: <1336059271.86.0.0525487031192.issue14712@psf.upfronthosting.co.za>


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

This issue will track implementation of PEP 405 functionality.

----------
assignee: vinay.sajip
messages: 159863
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: Integrate PEP 405
versions: Python 3.3

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

From report at bugs.python.org  Thu May  3 17:42:21 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 May 2012 15:42:21 +0000
Subject: [New-bugs-announce] [issue14713] PEP 414 installation hook fails
	with an AssertionError
Message-ID: <1336059741.48.0.751323304263.issue14713@psf.upfronthosting.co.za>


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

I'm not sure if I've done something wrong, but I get an AssertionError when trying to run the tokenizer on a Python file from the Django source. The gist at https://gist.github.com/1977558 has the files concerned:

1. test_tokenize.py - the script which fails
2. tokenize_example.py - the file being tokenized and untokenized. This is from the Django source: django/extras/csrf_migration_helper.py
3. tokenizer.py - your tokenize module, I renamed it because I was working in /tmp and didn't want to import the Python 3.2 stdlib's tokenize.py
4. The test output shows that the tokenize_example module imports OK in Python 2.7.2, but running the test_tokenize script on it with Python3.2 fails with an AssertionError.

I did some more testing, there are 131 failures in the Django source tree (all look like the same AssertionError).

N.B. I posted this to your GitHub repo where you published the hook.

----------
messages: 159864
nosy: aronacher, vinay.sajip
priority: normal
severity: normal
status: open
title: PEP 414 installation hook fails with an AssertionError

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

From report at bugs.python.org  Thu May  3 17:43:51 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 May 2012 15:43:51 +0000
Subject: [New-bugs-announce] [issue14714] PEp 414 tokenizing hook does not
	preserve tabs
Message-ID: <1336059831.47.0.0507292871504.issue14714@psf.upfronthosting.co.za>


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

Tabs in Python source are a no-no for me and lots of other people, but some people do use them. The tokenizer seems to not preserve tabs in its output. There are some tabs in the Django source, for example tests/regressiontests/localflavor/pl/tests.py.

N.B. I posted this to your GitHub repo where you published the hook.

----------
messages: 159865
nosy: aronacher, vinay.sajip
priority: normal
severity: normal
status: open
title: PEp 414 tokenizing hook does not preserve tabs
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu May  3 23:04:29 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 03 May 2012 21:04:29 +0000
Subject: [New-bugs-announce] [issue14715] test.support.DirsOnSysPath should
	be replaced by	importlib.test.util.import_state
Message-ID: <1336079069.84.0.625762752869.issue14715@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

DirsOnSysPath doesn't clear sys.path_importer_cache, so it seems you'd always want to use import_state, which does clear it.

We might also want to modify import_state to remember the original objects, not just their values. DirsOnSysPath does do this, for sys.path.

If we do this, we should probably move import_state to test.support.

Also, couldn't import_state do with sys.modules what DirsOnSysPath does with sys.path? It could restore both the object and its contents.

----------
messages: 159873
nosy: barry, brett.cannon, eric.smith, jason.coombs
priority: normal
severity: normal
status: open
title: test.support.DirsOnSysPath should be replaced by importlib.test.util.import_state
versions: Python 3.3

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

From report at bugs.python.org  Fri May  4 00:08:16 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 May 2012 22:08:16 +0000
Subject: [New-bugs-announce] [issue14716] Use unicode_writer API for
	str.format()
Message-ID: <1336082896.6.0.108889213788.issue14716@psf.upfronthosting.co.za>


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

I just added a new "unicode_writer" API for the issue #14687 (Optimize str%tuple for the PEP 393) which helps to make "str%tuple" between 25% and 30% faster.

Attached patch replaces PyAccu API with the unicode_writer API for str.format().

Python 3.2:

1000000 loops, best of 3: 0.198 usec per loop
100000 loops, best of 3: 11.3 usec per loop
10000000 loops, best of 3: 0.167 usec per loop
1000000 loops, best of 3: 0.494 usec per loop

Python 3.3:

1000000 loops, best of 3: 0.293 usec per loop
10000 loops, best of 3: 20.2 usec per loop
1000000 loops, best of 3: 0.219 usec per loop
1000000 loops, best of 3: 0.909 usec per loop

Python 3.3 + patch (speed up of the patch):

1000000 loops, best of 3: 0.226 usec per loop (-22%)
100000 loops, best of 3: 14.8 usec per loop (-26%)
1000000 loops, best of 3: 0.219 usec per loop (0%)
1000000 loops, best of 3: 0.658 usec per loop (-27%)

----------
components: Interpreter Core
files: unicode_format_writer.patch
keywords: patch
messages: 159879
nosy: haypo, kristjan.jonsson, loewis, pitrou, python-dev, storchaka
priority: normal
severity: normal
status: open
title: Use unicode_writer API for str.format()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25445/unicode_format_writer.patch

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

From report at bugs.python.org  Fri May  4 00:18:35 2012
From: report at bugs.python.org (py.user)
Date: Thu, 03 May 2012 22:18:35 +0000
Subject: [New-bugs-announce] [issue14717] In generator's .close() docstring
	there is one argument
Message-ID: <1336083515.09.0.187983865633.issue14717@psf.upfronthosting.co.za>


New submission from py.user <bugzilla-mail-box at yandex.ru>:

>>> g
<generator object f at 0xb74d257c>
>>> print(g.close.__doc__)
close(arg) -> raise GeneratorExit inside generator.
>>> g.close(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: close() takes no arguments (1 given)
>>>

----------
assignee: docs at python
components: Documentation
messages: 159882
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In generator's .close() docstring there is one argument
versions: Python 3.2

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

From report at bugs.python.org  Fri May  4 00:22:23 2012
From: report at bugs.python.org (py.user)
Date: Thu, 03 May 2012 22:22:23 +0000
Subject: [New-bugs-announce] [issue14718] In the generator's try/finally
	statement a runtime error	occurs when the generator is not exhausted
Message-ID: <1336083743.08.0.117486073655.issue14718@psf.upfronthosting.co.za>


New submission from py.user <bugzilla-mail-box at yandex.ru>:

http://www.python.org/dev/peps/pep-0342/
" 6. Allow "yield" to be used in try/finally blocks, since garbage
       collection or an explicit close() call would now allow the
       finally clause to execute."

"New syntax: yield allowed inside try-finally

    The syntax for generator functions is extended to allow a
    yield-statement inside a try-finally statement."


>>> def f():
...   try:
...     yield 1
...     yield 2
...     yield 3
...   finally:
...     yield 4
... 
>>> g = f()
>>> next(g)
1
>>> next(g)
2
>>> g = f()
Exception RuntimeError: 'generator ignored GeneratorExit' in <generator object f at 0xb74d2504> ignored
>>>

----------
components: Interpreter Core
messages: 159883
nosy: py.user
priority: normal
severity: normal
status: open
title: In the generator's try/finally statement a runtime error occurs when the generator is not exhausted
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri May  4 06:13:42 2012
From: report at bugs.python.org (Darrell Long)
Date: Fri, 04 May 2012 04:13:42 +0000
Subject: [New-bugs-announce] [issue14719] Lists: [[0]*N]*N != [[0 for _ in
	range(N)] for __ in	range(N)]
Message-ID: <1336104822.52.0.958479666589.issue14719@psf.upfronthosting.co.za>


New submission from Darrell Long <darrell at cs.ucsc.edu>:

N = 5
board_1 = [[0 for _ in range(N)] for __ in range(N)]

is not the same as:

board_2= [[0]*N]*N

One makes a proper list of lists (the first), the second makes a new kind of animal were board_2[1][1] = 99 changes a whole column.

Oddly, testing board_1 == board_2 is True!

I'm teaching Python to non-majors, and this is a tough one to explain.

----------
components: Interpreter Core
files: Screen Shot 2012-05-03 at 9.05.59 PM.png
messages: 159899
nosy: darrell
priority: normal
severity: normal
status: open
title: Lists: [[0]*N]*N != [[0 for _ in range(N)] for __ in range(N)]
versions: Python 2.7
Added file: http://bugs.python.org/file25450/Screen Shot 2012-05-03 at 9.05.59 PM.png

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

From report at bugs.python.org  Fri May  4 08:31:06 2012
From: report at bugs.python.org (Frank Millman)
Date: Fri, 04 May 2012 06:31:06 +0000
Subject: [New-bugs-announce] [issue14720] sqlite3 microseconds
Message-ID: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>


New submission from Frank Millman <frank at chagford.com>:

sqlite3/dbapi2.py contains the following - 

    def convert_timestamp(val): 
        datepart, timepart = val.split(b" ")
        timepart_full = timepart.split(b".")
        [...] 
        if len(timepart_full) == 2: 
            microseconds = int(timepart_full[1]) 
        else: 
            microseconds = 0 

It assumes that 'timepart_full[1]' is a string containing 6 digits. 

I have a situation where the string containing 3 digits, so it gives the wrong result. For example, if the string is '456', this represents 456000 microseconds, but sqlite3 returns 456 microseconds.

I think that it should right-zero-fill the string to 6 digits before converting to an int, like this - 

    microseconds = int('{:0<6}'.format(timepart_full[1]))

----------
components: Library (Lib)
messages: 159905
nosy: frankmillman
priority: normal
severity: normal
status: open
title: sqlite3 microseconds
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri May  4 12:06:43 2012
From: report at bugs.python.org (Arve Knudsen)
Date: Fri, 04 May 2012 10:06:43 +0000
Subject: [New-bugs-announce] [issue14721] httplib doesn't specify
	content-length header for POST	requests without data
Message-ID: <1336126003.87.0.468277340816.issue14721@psf.upfronthosting.co.za>


New submission from Arve Knudsen <arve.knudsen at gmail.com>:

httplib doesn't specify the HTTP header 'content-length' for POST requests without data. Conceptually this makes sense, considering the empty content. However, IIS (7.5) servers don't accept such requests and respond with a 411 status code. See this question on StackOverflow for reference: http://stackoverflow.com/questions/5915131/can-i-send-an-empty-http-post-webrequest-object-from-c-sharp-to-iis.

See also issue #223 of the Requests project, https://github.com/kennethreitz/requests/issues/223, which regards this problem in the context of the requests Python library.

The following code makes a data-less POST request to the HTTP sniffer Fiddler running on localhost:
import httplib
conn = httplib.HTTPConnection("localhost", 8888)
conn.request("POST", "/post", "", {})
conn.close()

Fiddler reports that it receives the following headers for the POST request, as you can see 'content-length' is not included:
POST http://localhost:8888/post HTTP/1.1
Host: localhost:8888
Accept-Encoding: identity

----------
components: Library (Lib)
messages: 159915
nosy: Arve.Knudsen
priority: normal
severity: normal
status: open
title: httplib doesn't specify content-length header for POST requests without data
versions: Python 2.7

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

From report at bugs.python.org  Fri May  4 16:37:17 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 May 2012 14:37:17 +0000
Subject: [New-bugs-announce] [issue14722] Overflow in parsing 'float'
	parameters in	PyArg_ParseTuple*
Message-ID: <1336142237.23.0.0183531993231.issue14722@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

In function convertsimple() in Python/getargs.c possible converting out of float range value from double to float.

Fortunately, 'f' format character is not used in CPython source code. But it can be used in the extensions.

Tests will be later.

----------
components: Interpreter Core
files: getargs_float_overflow.patch
keywords: patch
messages: 159937
nosy: storchaka
priority: normal
severity: normal
status: open
title: Overflow in parsing 'float' parameters in PyArg_ParseTuple*
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25454/getargs_float_overflow.patch

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

From report at bugs.python.org  Fri May  4 20:21:12 2012
From: report at bugs.python.org (Mark Theisen)
Date: Fri, 04 May 2012 18:21:12 +0000
Subject: [New-bugs-announce] [issue14723] Misleading error message for
	str.format()
Message-ID: <1336155672.66.0.579561581196.issue14723@psf.upfronthosting.co.za>


New submission from Mark Theisen <mark.theisen at digitecinc.com>:

When I run this code: '{0:i}'.format(None)

I get this error:
ValueError: Unknown format code 'i' for object of type 'str'

This seems misleading because None is of Type 'NoneType'. I was expecting the error to say something to the effect of:
Unknown format code 'i' for object of type 'NoneType'

----------
components: Interpreter Core
messages: 159955
nosy: theisenm
priority: normal
severity: normal
status: open
title: Misleading error message for str.format()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri May  4 22:48:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 May 2012 20:48:31 +0000
Subject: [New-bugs-announce] [issue14724] kill imp.load_dynamic's third
	argument
Message-ID: <1336164511.78.0.519044801225.issue14724@psf.upfronthosting.co.za>


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

imp.load_dynamic's third optional argument doesn't seem used in the wild, and I don't think it's correctly implemented by the current code.
It would seem reasonable to kill it.

----------
components: Interpreter Core, Library (Lib)
messages: 159971
nosy: brett.cannon, eric.smith, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: kill imp.load_dynamic's third argument
versions: Python 3.3

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

From report at bugs.python.org  Sat May  5 00:54:01 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 May 2012 22:54:01 +0000
Subject: [New-bugs-announce] [issue14725] test_multiprocessing failure under
	Windows
Message-ID: <1336172041.91.0.79006187387.issue14725@psf.upfronthosting.co.za>


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

There was this failure on one of the XP buildbots:


Process Process-269:
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\process.py", line 258, in _bootstrap
    self.run()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\process.py", line 95, in run
    self._target(*self._args, **self._kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py", line 1980, in _listener
    new_conn = l.accept()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 444, in accept
    c = self._listener.accept()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 624, in accept
    ov = _winapi.ConnectNamedPipe(handle, overlapped=True)
BrokenPipeError: [Error 232] The pipe is being closed

======================================================================
ERROR: test_pickling (test.test_multiprocessing.WithProcessesTestPicklingConnections)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 308, in _recv_bytes
    nread, err = ov.GetOverlappedResult(True)
BrokenPipeError: [Error 109] The pipe has been ended

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_multiprocessing.py", line 2030, in test_pickling
    new_conn = lconn.recv()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 252, in recv
    buf = self._recv_bytes()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 317, in _recv_bytes
    raise EOFError
EOFError


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

----------
components: Library (Lib), Tests, Windows
messages: 159973
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing failure under Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat May  5 03:14:08 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 May 2012 01:14:08 +0000
Subject: [New-bugs-announce] [issue14726] Lib/email/*.py use an EMPTYSTRING
	global instead of ''
Message-ID: <1336180448.33.0.0155133571187.issue14726@psf.upfronthosting.co.za>


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

Lib/email/*.py are fond of using

EMPTYSTRING = ''

and within the code:

    EMPTYSTRING.join(...)

instead of just writing:

    ''.join(...)

They should just do the latter.  It'll avoid a name lookup and look less silly to people reading the code.  ;)

----------
messages: 159974
nosy: gregory.p.smith
priority: low
severity: normal
status: open
title: Lib/email/*.py use an EMPTYSTRING global instead of ''
versions: Python 3.3

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

From report at bugs.python.org  Sat May  5 11:13:35 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 May 2012 09:13:35 +0000
Subject: [New-bugs-announce] [issue14727] test_multiprocessing failure under
	Linux
Message-ID: <1336209215.05.0.989780505108.issue14727@psf.upfronthosting.co.za>


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

I've recently started seeing this failure repeatably on Linux (Ubuntu Jaunty):

[195/364] test_multiprocessing
Process Process-133:
Traceback (most recent call last):
  File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/home/vinay/projects/python/default/Lib/multiprocessing/process.py", line 95, in run
    self._target(*self._args, **self._kwargs)
  File "/home/vinay/projects/python/default/Lib/test/test_multiprocessing.py", line 2005, in _remote
    client.connect(address)
ConnectionRefusedError: [Errno 111] Connection refused
/home/vinay/projects/python/default/Lib/multiprocessing/process.py:274: ResourceWarning: unclosed <socket.socket object, fd=15, family=2, type=1, proto=0>
  traceback.print_exc()

----------
components: Tests
messages: 159981
nosy: sbt, vinay.sajip
priority: normal
severity: normal
status: open
title: test_multiprocessing failure under Linux
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat May  5 12:43:45 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 05 May 2012 10:43:45 +0000
Subject: [New-bugs-announce] [issue14728] trace function not set,
	causing some Pdb commands to fail
Message-ID: <1336214625.48.0.950841547459.issue14728@psf.upfronthosting.co.za>


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

The issue 13183 raises the problem that when the trace function is not
set in the caller frame, the step command fails at a return statement.

This new issue raises the point that, for the same reason:

    * the next, until and return statements fail also at a return
      statement when the caller frame does not have a trace function

    * when the user runs the up and down commands at any line in a
      frame to select a new frame, then the next, until or return
      commands fail when the selected frame does not have a trace
      function

The attached patch fixes all those problems (by first removing the
changes made in bdb.py at issue 13183).

After the patch, the implementation ensures now that self.stopframe is
either None, or belongs to the stack frame in the interval
[self.botframe, self._curframe] and that it is set to self.botframe
when the debugging session terminates. This allows removing the while
loop in stop_here with an improvement in the performance of Pdb (since
stop_here may be called at each line, even when no breakpoint is set
in the function).

The patch applies to the default branch and includes 5 new test cases.
A patch for 2.7 will be submitted later.

----------
components: Library (Lib)
files: pdb.patch
keywords: patch
messages: 159985
nosy: xdegaye
priority: normal
severity: normal
status: open
title: trace function not set, causing some Pdb commands to fail
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25459/pdb.patch

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

From report at bugs.python.org  Sat May  5 12:44:35 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 May 2012 10:44:35 +0000
Subject: [New-bugs-announce] [issue14729] test_faulthandler test is too
	specific to work on Windows
Message-ID: <1336214675.26.0.0531566496861.issue14729@psf.upfronthosting.co.za>


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

In test_faulthandler.test_check_fatal_error, the test expects a response which matches

"""
^Fatal Python error: {name}

{header}:
  File "<string>", line {lineno} in <module>$
""".strip()

On Windows, some more information is appended to the end of the message, so the match fails because of the trailing $. I propose to remove this $, so that the match succeeds just on the basis of the prefix.

Patch attached; I'll apply it soon, assuming you don't object.

----------
components: Tests
files: test_faulthandler.diff
keywords: patch
messages: 159986
nosy: haypo, vinay.sajip
priority: normal
severity: normal
status: open
title: test_faulthandler test is too specific to work on Windows
versions: Python 3.3
Added file: http://bugs.python.org/file25460/test_faulthandler.diff

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

From report at bugs.python.org  Sat May  5 16:31:46 2012
From: report at bugs.python.org (Paul Colomiets)
Date: Sat, 05 May 2012 14:31:46 +0000
Subject: [New-bugs-announce] [issue14730] Implementation of the PEP 419
Message-ID: <1336228306.65.0.183212928475.issue14730@psf.upfronthosting.co.za>


New submission from Paul Colomiets <paul at colomiets.name>:

Attached patch is a partial implementation of PEP 419, it lacks inspect module functions and requires more unit tests.

----------
components: Interpreter Core
files: cleanuphook.patch
keywords: patch
messages: 159994
nosy: tailhook
priority: normal
severity: normal
status: open
title: Implementation of the PEP 419
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25461/cleanuphook.patch

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

From report at bugs.python.org  Sat May  5 20:14:47 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 05 May 2012 18:14:47 +0000
Subject: [New-bugs-announce] [issue14731] Enhance Policy framework in
	preparation for adding	"eamil6" policy as provisional
Message-ID: <1336241687.85.0.143639170714.issue14731@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

As discussed in my email to python-dev, I'm planning to add the new header parsing to Python 3.3 as a provisional extension, by adding a (set) of policies that are clearly marked provisional in the documentation.  In order for this to work, I first need to make certain enhancements to the Policy framework that I previously committed to default.

When reviewing the patch, please start with the 'architecture.rst' file in the Lib/email directory, which provides an overview of the changes and the plan.

The primary changes are to add some new policy hooks that feedparser, message, and generator call.  These hooks are then implemented on the renamed default policy (now called 'compat32') in such a way as to replicate the behavior of Python 3.2.  The other significant change is that Message objects now have a policy.  In order to accommodate this, this patch adds 'policy propagation' logic.  That is, if you pass a policy to feedparser, then all the Message objects it creates get that policy.  And when you flatten a message with a Generator, it uses the policy attached to the message unless you explicitly override it.

I also factored policy into _basepolicy.py and policy.py.  This doesn't mean much for this patch, but when the new policies land they go in policy.py, while the default policy is imported from _policybase.  This means that if a Python 3.3 program does not explicitly use a policy, it will not import any of the new code.

The remaining changes in the patch are some test reorganization.  Since the goal is now 100% backward compatibility with Python 3.2 (including bugs in some cases), the patch removes some tests that were previously added to test.test_email.test_email and puts them into module specific test files (test_generator, test_parser, test_policy).  Additional tests are also added.

The end result of the test refactoring is that if you diff test_email.py after this patch against the 3.2 test_email.py, you should find a few places where the scaffolding is changed and the addition of some tests for bug fixes in the 3.2 code.  Otherwise the tests should be identical to 3.2, with all the policy related tests moving into test_policy.

The longer term plan for this is to replicate all of the test_email.py tests in appropriate module-specific test files (I've already marked a few such tests that got replicated in test_policy).  By the time we get to Python4 the plan is for all the tests to be replicated, so that we can at that point drop compat32 by removing the policy and the test_email.py test file, as well as the code that will be at that point obsolete.

The primary review here should be to make sure I am in fact producing 100% backward compatibility.  Any other review comments will be welcome, of course.

PS: I also changed the 'must_be_7bit' policy control, whose name I never liked, to be 'cte_type', which can be '7bit' or '8bit'.  As noted in the architecture.rst file, the extra motivation for this is that there will eventually be a 'cte_type=unicode' which will support unicode display of formatted messages and, perhaps even more important, rfc 5335.

----------
hgrepos: 121
messages: 160015
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Enhance Policy framework in preparation for adding "eamil6" policy as provisional
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat May  5 21:47:18 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sat, 05 May 2012 19:47:18 +0000
Subject: [New-bugs-announce] [issue14732] PEP 3121 Refactoring applied to
	_csv module
Message-ID: <1336247238.98.0.79082288942.issue14732@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

This patch presents my first try to apply the proposed Refactoring of PEP3121 to the csv module. I have identified three mutable global variables inside the module, two of which are references to PyObjects. I have wrapped all of them inside a dedicated struct, which is traversed by the gc after "freeing" the module. I also defined some macros, to hide functions calls that are now needed because of the newly introduced indirections.

----------
components: Extension Modules
files: csv_pep3121.patch
keywords: patch
messages: 160032
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121 Refactoring applied to _csv module
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25473/csv_pep3121.patch

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

From report at bugs.python.org  Sat May  5 21:54:58 2012
From: report at bugs.python.org (Janusz Lewandowski)
Date: Sat, 05 May 2012 19:54:58 +0000
Subject: [New-bugs-announce] [issue14733] Custom commands don't work
Message-ID: <1336247698.3.0.601415993059.issue14733@psf.upfronthosting.co.za>


New submission from Janusz Lewandowski <lew21 at xtreeme.org>:

Running (by pysetup run cmdname) custom commands doesn't work, because setup.cfg is parsed after command handling.

I've attached a patch to fix this behavior.

----------
assignee: eric.araujo
components: Distutils2
files: fix-custom-commands.patch
keywords: patch
messages: 160035
nosy: LEW21, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Custom commands don't work
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25476/fix-custom-commands.patch

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

From report at bugs.python.org  Sat May  5 22:17:42 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 05 May 2012 20:17:42 +0000
Subject: [New-bugs-announce] [issue14734] Use binascii.b2a_qp/a2b_qp in
	email package header	handling?
Message-ID: <1336249062.57.0.661119787724.issue14734@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Currently the email package uses its own custom quoted printable encode/decode implementation for handling header quoted printable CTE encoding and decoding.  It could be that using binascii would work, and be more performant.  Or it might not be, but it seems like it might be worth investigating.

----------
assignee: r.david.murray
messages: 160038
nosy: r.david.murray
priority: low
severity: normal
status: open
title: Use binascii.b2a_qp/a2b_qp in email package header handling?
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Sat May  5 23:15:01 2012
From: report at bugs.python.org (Ed Wodrich)
Date: Sat, 05 May 2012 21:15:01 +0000
Subject: [New-bugs-announce] [issue14735] Version 3.2.3 IDLE CTRL-Z plus
	Carriage Return to end	does not work
Message-ID: <1336252501.23.0.54042826511.issue14735@psf.upfronthosting.co.za>


New submission from Ed Wodrich <ewodrich1 at rainbowhaven.net>:

Greetings,

I am a brand new user attempting to learn Python.  I downloaded and installed the .msi installer version 3.2.3 on May 5, 2012.  I am running Windows XP SP2 32-bit on a Pentium 4.  I opted to load all features of the program.  Installation finished without any errors.

Admittedly, despite previous programming experience with other languages, I have a lot to learn.  What I saw when I tried using the IDLE was that it would not end with ctrl-Z followed by carriage return.  Using either quit() and replying to the dialog or using ctrl-d followed by carriage return worked.  I am submitting this because the GUI interface and what documentation I have seen so far states that ctrl-z followed by carriage return is the method to use in Windows.  

IMHO possible fix options (presuming this is not something weird because I don't know what I am doing yet) would be to update the documentation for consistency or to change the behavior of the IDLE?

Thank you, in advance, for your efforts with regard to this issue.

Best Regards,

Ed

----------
components: IDLE
messages: 160042
nosy: ewodrich
priority: normal
severity: normal
status: open
title: Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun May  6 03:08:03 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 06 May 2012 01:08:03 +0000
Subject: [New-bugs-announce] [issue14736] Add {encode,
	decode}_filter_properties() functions to lzma module
Message-ID: <1336266483.84.0.291030499892.issue14736@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

Patch attached. Reviews welcome.

----------
components: Extension Modules
files: lzma-properties.diff
keywords: patch
messages: 160051
nosy: nadeem.vawda
priority: normal
severity: normal
stage: patch review
status: open
title: Add {encode,decode}_filter_properties() functions to lzma module
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25478/lzma-properties.diff

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

From report at bugs.python.org  Sun May  6 13:43:35 2012
From: report at bugs.python.org (ganges master)
Date: Sun, 06 May 2012 11:43:35 +0000
Subject: [New-bugs-announce] [issue14737] subprocess.Popen pipes not working
Message-ID: <1336304615.86.0.376011401786.issue14737@psf.upfronthosting.co.za>


New submission from ganges master <gangesmaster at users.sourceforge.net>:

Attempting to read from stdout of a running process seems broken on Python3.2. I've been able to reproduce this on Ubuntu 11.4 and Windows 7 (with /bin/sh installed as part of git for windows)

Python 3.2 (r32:88445, Dec  8 2011, 15:26:51) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE)
>>> p.stdin.write(b"echo hello\n")
11
>>> p.stdout.readline()
<stuck>

>>> from subprocess import Popen, PIPE
>>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE)
>>> p.stdin.write(b"echo hello\n")
11
>>> p.stdout.read(2)
<stuck>


For comparison, on python 2.7 (again, linux and windows:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> p=Popen(["/bin/sh"], stdin=PIPE, stderr=PIPE, stdout=PIPE)
>>> p.stdin.write(b"echo hello\n")
>>> p.stdout.readline()
'hello\n'
>>>

----------
components: Library (Lib)
messages: 160075
nosy: gangesmaster
priority: normal
severity: normal
status: open
title: subprocess.Popen pipes not working
versions: Python 3.2

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

From report at bugs.python.org  Sun May  6 20:00:54 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 May 2012 18:00:54 +0000
Subject: [New-bugs-announce] [issue14738] Amazingly faster UTF-8 decoding
Message-ID: <1336327254.8.0.865225437508.issue14738@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

I propose a complex patch, which significantly speeds up UTF-8 decoding. Now decoder faster even decoder in 3.2 (except in a few unreal patological cases).

Also the decoder code reduced and simplified (formerly decoding code was repeated in at least three places).

As a side effect ASCII decoding now faster on some platforms (issue14419).

Related issues:
[issue4868] Faster utf-8 decoding
[issue13417] faster utf-8 decoding
[issue14419] Faster ascii decoding
[issue14624] Faster utf-16 decoder
[issue14625] Faster utf-32 decoder
[issue14654] Faster utf-8 decoding


Here are the results of benchmarking (numbers is speed in MB/s).

On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz:

                                          3.2           3.3(vanilla)  patched

utf-8     'A'*10000                       1199 (+69%)   1721 (+18%)   2032
utf-8         'A'*9999+'\x80'             1189 (+25%)   996 (+49%)    1488
utf-8         'A'*9999+'\u0100'           1192 (-25%)   887 (+1%)     894
utf-8         'A'*9999+'\u8000'           1178 (-24%)   888 (+0%)     890
utf-8         'A'*9999+'\U00010000'       1177 (-29%)   872 (-4%)     837
utf-8     '\x80'*10000                    220 (+74%)    172 (+122%)   382
utf-8       '\x80'+'A'*9999               1192 (+5%)    376 (+232%)   1250
utf-8         '\x80'*9999+'\u0100'        220 (+54%)    160 (+112%)   339
utf-8         '\x80'*9999+'\u8000'        220 (+54%)    160 (+112%)   339
utf-8         '\x80'*9999+'\U00010000'    221 (+49%)    176 (+88%)    330
utf-8     '\u0100'*10000                  220 (+74%)    163 (+134%)   382
utf-8       '\u0100'+'A'*9999             1177 (+4%)    382 (+219%)   1220
utf-8       '\u0100'+'\x80'*9999          220 (+74%)    163 (+134%)   382
utf-8         '\u0100'*9999+'\u8000'      220 (+74%)    163 (+134%)   382
utf-8         '\u0100'*9999+'\U00010000'  220 (+50%)    180 (+83%)    330
utf-8     '\u8000'*10000                  261 (+66%)    191 (+126%)   432
utf-8       '\u8000'+'A'*9999             1197 (+1%)    384 (+216%)   1212
utf-8       '\u8000'+'\x80'*9999          216 (+77%)    163 (+134%)   382
utf-8       '\u8000'+'\u0100'*9999        215 (+77%)    164 (+132%)   381
utf-8         '\u8000'*9999+'\U00010000'  261 (+46%)    201 (+89%)    380
utf-8     '\U00010000'*10000              248 (+44%)    198 (+80%)    357
utf-8       '\U00010000'+'A'*9999         1192 (-5%)    383 (+196%)   1135
utf-8       '\U00010000'+'\x80'*9999      220 (+73%)    180 (+111%)   380
utf-8       '\U00010000'+'\u0100'*9999    220 (+73%)    180 (+111%)   380
utf-8       '\U00010000'+'\u8000'*9999    261 (+54%)    201 (+100%)   403

ascii     'A'*10000                       233 (+971%)   1876 (+33%)   2496

On 32-bit Linux, Intel Atom N570 @ 1.66GHz:

                                          3.2           3.3(vanilla)  patched

utf-8     'A'*10000                       345 (+81%)    596 (+5%)     623
utf-8         'A'*9999+'\x80'             335 (+41%)    303 (+56%)    474
utf-8         'A'*9999+'\u0100'           336 (-23%)    123 (+110%)   258
utf-8         'A'*9999+'\u8000'           337 (-24%)    123 (+108%)   256
utf-8         'A'*9999+'\U00010000'       336 (-24%)    261 (-3%)     254
utf-8     '\x80'*10000                    88 (+66%)     65 (+125%)    146
utf-8       '\x80'+'A'*9999               334 (+8%)     124 (+190%)   360
utf-8         '\x80'*9999+'\u0100'        88 (+43%)     65 (+94%)     126
utf-8         '\x80'*9999+'\u8000'        88 (+43%)     65 (+94%)     126
utf-8         '\x80'*9999+'\U00010000'    89 (+40%)     65 (+92%)     125
utf-8     '\u0100'*10000                  88 (+85%)     65 (+151%)    163
utf-8       '\u0100'+'A'*9999             336 (+2%)     77 (+345%)    343
utf-8       '\u0100'+'\x80'*9999          88 (+86%)     65 (+152%)    164
utf-8         '\u0100'*9999+'\u8000'      88 (+86%)     65 (+152%)    164
utf-8         '\u0100'*9999+'\U00010000'  88 (+57%)     65 (+112%)    138
utf-8     '\u8000'*10000                  98 (+79%)     69 (+154%)    175
utf-8       '\u8000'+'A'*9999             339 (+3%)     77 (+353%)    349
utf-8       '\u8000'+'\x80'*9999          89 (+84%)     66 (+148%)    164
utf-8       '\u8000'+'\u0100'*9999        88 (+86%)     65 (+152%)    164
utf-8         '\u8000'*9999+'\U00010000'  98 (+58%)     69 (+125%)    155
utf-8     '\U00010000'*10000              104 (+46%)    79 (+92%)     152
utf-8       '\U00010000'+'A'*9999         339 (-5%)     124 (+160%)   323
utf-8       '\U00010000'+'\x80'*9999      88 (+84%)     68 (+138%)    162
utf-8       '\U00010000'+'\u0100'*9999    88 (+83%)     68 (+137%)    161
utf-8       '\U00010000'+'\u8000'*9999    98 (+63%)     72 (+122%)    160

ascii     'A'*10000                       132 (+499%)   758 (+4%)     791

----------
components: Interpreter Core
files: decode_utf8_4.patch
keywords: patch
messages: 160103
nosy: Arfrever, haypo, jcea, loewis, pitrou, storchaka
priority: normal
severity: normal
status: open
title: Amazingly faster UTF-8 decoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25484/decode_utf8_4.patch

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

From report at bugs.python.org  Mon May  7 11:35:09 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 07 May 2012 09:35:09 +0000
Subject: [New-bugs-announce] [issue14739] Add PyArg_Parse format unit like
	O& but providing context
Message-ID: <1336383309.79.0.581336532675.issue14739@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

If you write a PyArg_Parse "converter", and your conversion hits an error, you must raise an exception and error out.  But, since your converter has no context about the parameter, it can't provide any helpful information in the error.

For example, PyUnicode_FSConverter attempts to convert a PyUnicode object to a PyBytes object; if it gets back some other kind of object, it calls
     PyErr_SetString(PyExc_TypeError, "encoder failed to return bytes");
What parameter did this happen with?  When calling what function?  The hapless programmer is forced to guess.

In practice, the argument parser generally knows the name of the function and the name of the parameter.  It'd be nice to encode those values in the error.  But that information isn't passed in to the converter.

I propose adding a new format unit, let's call it 'O%', which is identical to 'O&' except for the signature of the converter function:

    int converter(PyObject *o, void *p, PyConverterContext_t *context);

where PyConverterContext_t is defined as

    typedef struct {
        char *function_name;
        char *parameter_name;
    } PyConverterContext_t;

If the function name or parameter name is not known, it will be NULL.

----------
messages: 160125
nosy: larry
priority: normal
severity: normal
status: open
title: Add PyArg_Parse format unit like O& but providing context

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

From report at bugs.python.org  Mon May  7 15:36:33 2012
From: report at bugs.python.org (Bob Glickstein)
Date: Mon, 07 May 2012 13:36:33 +0000
Subject: [New-bugs-announce] [issue14740] get_payload(n, True) returns None
Message-ID: <1336397793.0.0.246147056664.issue14740@psf.upfronthosting.co.za>


New submission from Bob Glickstein <bob.glickstein at gmail.com>:

Passing both a value for i and decode=True to email.message.Message.get_payload(), when self is a multipart, returns None when it should return a string.  The reason is that an is_multipart() test is done on self when it should instead be done on the selected payload part.  Here's a patch that fixes this:


--- /usr/lib64/python2.7/email/message.py	2011-10-26 18:40:36.000000000 -0700
+++ /home/bobg/tmp/message.py	2012-05-07 06:34:28.579401481 -0700
@@ -192,9 +192,9 @@
         else:
             payload = self._payload[i]
         if decode:
-            if self.is_multipart():
+            if payload.is_multipart():
                 return None
-            cte = self.get('content-transfer-encoding', '').lower()
+            cte = payload.get('content-transfer-encoding', '').lower()
             if cte == 'quoted-printable':
                 return utils._qdecode(payload)
             elif cte == 'base64':

----------
components: Library (Lib)
messages: 160144
nosy: Bob.Glickstein
priority: normal
severity: normal
status: open
title: get_payload(n, True) returns None
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon May  7 18:18:43 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 May 2012 16:18:43 +0000
Subject: [New-bugs-announce] [issue14741] parser module doesn't support
	Ellipsis.
Message-ID: <1336407523.58.0.0696113570093.issue14741@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Here's a simple patch.  With this and other recent patches to the parser module, we can now correctly roundtrip all the (valid) Python files in Lib/ and Lib/test/.

----------
assignee: mark.dickinson
components: Library (Lib)
files: parser_ellipsis.patch
keywords: patch
messages: 160157
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: parser module doesn't support Ellipsis.
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25487/parser_ellipsis.patch

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

From report at bugs.python.org  Mon May  7 21:45:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 May 2012 19:45:15 +0000
Subject: [New-bugs-announce] [issue14742] test_tools very slow
Message-ID: <1336419915.88.0.52212163456.issue14742@psf.upfronthosting.co.za>


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

Apparently test_unparse goes a bit overboard. test_compiler in 2.x had a more reasonable approach: it only compiled all files with -uall, otherwise it would choose 10 at random.

----------
components: Tests
messages: 160165
nosy: mark.dickinson, pitrou
priority: normal
severity: normal
status: open
title: test_tools very slow
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Mon May  7 21:48:31 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 07 May 2012 19:48:31 +0000
Subject: [New-bugs-announce] [issue14743] on terminating, Pdb debugs itself
Message-ID: <1336420111.44.0.550150061213.issue14743@psf.upfronthosting.co.za>


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

All the problems raised in this issue are caused by self.botframe
being set in a Pdb frame.

In the following pdb session run with python 3.2.2, the first two
frames in the printed stack are Pdb frames, this is wrong. And the
second step command steps incorrectly into the exec() frame that is
called by the Bdb run() method. What prevents the third step command
to step into the run() frame, is that this frame does not have a trace
function setup initially.
===   foo.py    =================================
i = 1
=================================================
$ python3 -m pdb foo.py
> path_to/foo.py(1)<module>()
-> i = 1
(Pdb) import sys; print(sys.version)
3.2.2 (default, Dec 27 2011, 17:35:55) 
[GCC 4.3.2]
(Pdb) where
  /usr/local/lib/python3.2/bdb.py(392)run()
-> exec(cmd, globals, locals)
  <string>(1)<module>()
> path_to/foo.py(1)<module>()
-> i = 1
(Pdb) step
--Return--
> path_to/foo.py(1)<module>()->None
-> i = 1
(Pdb) step
--Return--
> <string>(1)<module>()->None
(Pdb) step
The program finished and will be restarted
> path_to/foo.py(1)<module>()
-> i = 1
(Pdb) quit
=================================================


In the following pdb session run with python built from the default
branch (i.e. after issue 13183 has been fixed) the third step command
steps into the run() method of Bdb and the backtrace printed after the
quit command shows duplicate entries. Pdb is trying to debug itself !
Pdb steps in the run() method because after the fix in issue 13183,
Pdb knows now how to step when returning into the caller frame with no
trace function.
===   foo.py    =================================
i = 1
=================================================
$ python -m pdb foo.py 
> path_to/foo.py(1)<module>()
-> i = 1
(Pdb) step
--Return--
> path_to/foo.py(1)<module>()->None
-> i = 1
(Pdb) step
--Return--
> <string>(1)<module>()->None
(Pdb) step
> path_to/cpython/Lib/bdb.py(409)run()
-> self.quitting = True
(Pdb) quit
Traceback (most recent call last):
  File "path_to/cpython/Lib/pdb.py", line 1651, in main
    pdb._runscript(mainpyfile)
  File "path_to/cpython/Lib/pdb.py", line 1532, in _runscript
    self.run(statement)
  File "path_to/cpython/Lib/bdb.py", line 409, in run
    self.quitting = True
  File "path_to/cpython/Lib/bdb.py", line 409, in run
    self.quitting = True
  File "path_to/cpython/Lib/bdb.py", line 47, in trace_dispatch
    return self.dispatch_line(frame)
  File "path_to/cpython/Lib/bdb.py", line 66, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> path_to/cpython/Lib/bdb.py(66)dispatch_line()
-> if self.quitting: raise BdbQuit
(Pdb) quit
Post mortem debugger finished. The foo.py will be restarted
> path_to/foo.py(1)<module>()
-> i = 1
(Pdb) quit
=================================================


In the following pdb session run with python 3.2.2, the session is
interrupted with <Ctl-C>. The same problems occur as in the previous
case.
=================================================
import time
i = 1
while i:
    time.sleep(.100)
i = 0
=================================================
$ python3 -m pdb foo.py
> path_to/foo.py(1)<module>()
-> import time
(Pdb) import sys; print(sys.version)
3.2.2 (default, Dec 27 2011, 17:35:55) 
[GCC 4.3.2]
(Pdb) continue
^C
Program interrupted. (Use 'cont' to resume).
> path_to/foo.py(3)<module>()
-> while i:
(Pdb) !i=0
(Pdb) step
> path_to/foo.py(5)<module>()
-> i = 0
(Pdb) step
--Return--
> path_to/foo.py(5)<module>()->None
-> i = 0
(Pdb) step
--Return--
> <string>(1)<module>()->None
(Pdb) step
> /usr/local/lib/python3.2/bdb.py(396)run()
-> self.quitting = True
(Pdb) quit
Traceback (most recent call last):
  File "/usr/local/lib/python3.2/pdb.py", line 1556, in main
    pdb._runscript(mainpyfile)
  File "/usr/local/lib/python3.2/pdb.py", line 1437, in _runscript
    self.run(statement)
  File "/usr/local/lib/python3.2/bdb.py", line 396, in run
    self.quitting = True
  File "/usr/local/lib/python3.2/bdb.py", line 396, in run
    self.quitting = True
  File "/usr/local/lib/python3.2/bdb.py", line 46, in trace_dispatch
    return self.dispatch_line(frame)
  File "/usr/local/lib/python3.2/bdb.py", line 65, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /usr/local/lib/python3.2/bdb.py(65)dispatch_line()
-> if self.quitting: raise BdbQuit
(Pdb) quit
Post mortem debugger finished. The foo.py will be restarted
> path_to/foo.py(1)<module>()
-> import time
(Pdb) quit
=================================================


The attached patch fixes all those problems. The patch applies to the
default branch.

----------
components: Library (Lib)
files: pdb_botframe_default.patch
keywords: patch
messages: 160166
nosy: xdegaye
priority: normal
severity: normal
status: open
title: on terminating, Pdb debugs itself
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25489/pdb_botframe_default.patch

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

From report at bugs.python.org  Tue May  8 00:09:21 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 May 2012 22:09:21 +0000
Subject: [New-bugs-announce] [issue14744] Use _PyUnicodeWriter API in
	str.format() internals
Message-ID: <1336428561.46.0.842580483885.issue14744@psf.upfronthosting.co.za>


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

Since 7be716a47e9d (issue #14716), str.format() uses the "unicode_writer" API. I propose to continue the work in this direction to avoid more temporary buffers.

Python 3.3:

1000000 loops, best of 3: 0.573 usec per loop
100000 loops, best of 3: 16.4 usec per loop
1000000 loops, best of 3: 0.705 usec per loop
100000 loops, best of 3: 2.61 usec per loop

Python 3.3 + patch (compared to Python 3.3):

1000000 loops, best of 3: 0.516 usec per loop (-10%)
100000 loops, best of 3: 13.2 usec per loop (-20%)
1000000 loops, best of 3: 0.574 usec per loop (-18%)
100000 loops, best of 3: 2.59 usec per loop (-1%)

--

If this patch is accepted, it's more to go even deeper: use _PyUnicodeWriter in long_to_decimal_string() for example.

--

Benchmark Python 3 / Python 2 bytes:

python -m timeit -s 'fmt="{0}.{1}.{2}"' 'fmt.format("http", "client", "HTTPConnection")'
python -m timeit -s 'fmt="{0:s}"*100' 'fmt.format("ABCDEF")'
python -m timeit -s 'fmt=" [line {0:2d}] "' 'fmt.format(5)'
python -m timeit -s 'fmt="x={} y={} z={}"' 'fmt.format(12345, 12.345, 12.345+2j)'

Benchmark Python 2 unicode:

python -m timeit -s 'fmt=u"{0}.{1}.{2}"' 'fmt.format(u"http", u"client", u"HTTPConnection")'
python -m timeit -s 'fmt=u"{0:s}"*100' 'fmt.format(u"ABCDEF")'
python -m timeit -s 'fmt=u" [line {0:2d}] "' 'fmt.format(5)'
python -m timeit -s 'fmt=u"x={} y={} z={}"' 'fmt.format(12345, 12.345, 12.345+2j)'

Python 2.7 bytes:

1000000 loops, best of 3: 0.393 usec per loop
100000 loops, best of 3: 9.72 usec per loop
1000000 loops, best of 3: 0.337 usec per loop
1000000 loops, best of 3: 1.56 usec per loop

Python 2.7 wide:

1000000 loops, best of 3: 0.443 usec per loop
100000 loops, best of 3: 10.3 usec per loop
1000000 loops, best of 3: 0.785 usec per loop
100000 loops, best of 3: 2.48 usec per loop

Python 3.2 wide:

1000000 loops, best of 3: 0.457 usec per loop
100000 loops, best of 3: 10.5 usec per loop
1000000 loops, best of 3: 0.538 usec per loop
100000 loops, best of 3: 2.36 usec per loop

----------
components: Interpreter Core
files: format_writer.patch
keywords: patch
messages: 160176
nosy: haypo, loewis, pitrou, storchaka
priority: normal
severity: normal
status: open
title: Use _PyUnicodeWriter API in str.format() internals
versions: Python 3.3
Added file: http://bugs.python.org/file25490/format_writer.patch

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

From report at bugs.python.org  Tue May  8 00:33:31 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 07 May 2012 22:33:31 +0000
Subject: [New-bugs-announce] [issue14745] Misleading exception
Message-ID: <1336430011.64.0.70812729636.issue14745@psf.upfronthosting.co.za>


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

$ python3.2 -c 'open("/dev/null", "w").read()'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
io.UnsupportedOperation: not readable
$ python3.3 -c 'open("/dev/null", "w").read()'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
_frozen_importlib.UnsupportedOperation: not readable
$ python3.3 -c 'import _frozen_importlib; _frozen_importlib.UnsupportedOperation'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'UnsupportedOperation'

----------
messages: 160178
nosy: Arfrever, brett.cannon
priority: normal
severity: normal
status: open
title: Misleading exception
versions: Python 3.3

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

From report at bugs.python.org  Tue May  8 01:24:52 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 07 May 2012 23:24:52 +0000
Subject: [New-bugs-announce] [issue14746] Remove redundant paragraphs from
	getargs.c skipitem()
Message-ID: <1336433092.13.0.553393159676.issue14746@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

There's code like this in skipitem() in Python/getargs.c:

    case 'b': /* byte -- very short int */
    /* ... a zillion more case statements here ... */
    case 'C': /* unicode char */
    case 'p': /* boolean predicate */
        {
            (void) va_arg(*p_va, void *);
            break;
        }

    case 'n': /* Py_ssize_t */
        {
            (void) va_arg(*p_va, Py_ssize_t *);
            break;
        }

    /* ... a bunch of other stuff here ... */

    case 'S': /* string object */
    case 'Y': /* string object */
    case 'U': /* unicode string object */
        {
            (void) va_arg(*p_va, PyObject **);
            break;
        }


I cannot for the life of me imagine a platform where the size of a "Py_ssize_t *" or a "PyObject **" would be different from the size of a "void *".  I've programmed on platforms where code pointers and data pointers were different sizes--but data pointers to different sizes of data?  Never heard of it.

But I've been wrong before!  So, rather than simply make the change, I'm posting this bug just as a double check.

It's safe to fold 'n', 'S', 'Y', and 'U' into the initial paragraph of case statements simply skipping a pointer... isn't it?

----------
assignee: larry
messages: 160179
nosy: larry
priority: low
severity: normal
stage: needs patch
status: open
title: Remove redundant paragraphs from getargs.c skipitem()
type: enhancement

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

From report at bugs.python.org  Tue May  8 06:55:40 2012
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Tue, 08 May 2012 04:55:40 +0000
Subject: [New-bugs-announce] [issue14747] Classifiers are missing from
	distutils2-generated	metadata
Message-ID: <1336452940.51.0.60009566738.issue14747@psf.upfronthosting.co.za>


New submission from Alex Gr?nholm <alex.gronholm+python at nextday.fi>:

Apparently they worked in 1.0a3 but not in 1.0a4 anymore.

----------
assignee: eric.araujo
components: Distutils2
messages: 160184
nosy: agronholm, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Classifiers are missing from distutils2-generated metadata
type: behavior
versions: 3rd party

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

From report at bugs.python.org  Tue May  8 10:01:56 2012
From: report at bugs.python.org (halfie)
Date: Tue, 08 May 2012 08:01:56 +0000
Subject: [New-bugs-announce] [issue14748] spwd.getspall() is returning LDAP
	(non local) users too
Message-ID: <1336464116.12.0.238019715557.issue14748@psf.upfronthosting.co.za>


New submission from halfie <assie181 at gmail.com>:

spwd.getspall() is returning LDAP (non local) users too. 

On RHEL 6.2 machine with LDAP authentication configured, spwd.getspall() 
is returning LDAP (non local) users too. On a similarly configured CentOS 6.2 machine, spwd.getspall() is returning only local users.

Is spwd.getspall() supposed to return LDAP users? (If yes, this should to documented). Why is spwd.getspall() behavior different on different Linux OSes?

----------
components: Library (Lib)
messages: 160188
nosy: halfie
priority: normal
severity: normal
status: open
title: spwd.getspall() is returning LDAP (non local) users too
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue May  8 11:56:32 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 08 May 2012 09:56:32 +0000
Subject: [New-bugs-announce] [issue14749] Add 'Z' to skipitem() in
	Python/getargs.c
Message-ID: <1336470992.95.0.551776226644.issue14749@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

skipitem() (in Python/getargs.c) has to be taught about all the "format units" understood by PyArg_Parse.  There's a note at the top of the format-unit-understanding code saying

  When you add new format codes,
  please don't forget poor skipitem() below.

Well, someone forgot poor skipitem() when they added 'Z'.

Since this is a bugfix, I assert it should go into 3.2, then get forward-ported into trunk.  So, step 1: check the attached one-line patch to 3.2.

Georg: sound good?

----------
assignee: larry
components: Interpreter Core
files: larry.skipitem.Z.1.diff
keywords: patch
messages: 160191
nosy: georg.brandl, larry
priority: low
severity: normal
stage: patch review
status: open
title: Add 'Z' to skipitem() in Python/getargs.c
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file25492/larry.skipitem.Z.1.diff

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

From report at bugs.python.org  Tue May  8 13:43:28 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 08 May 2012 11:43:28 +0000
Subject: [New-bugs-announce] [issue14750] importlib fails with tkinter
	application on Windows
Message-ID: <1336477408.86.0.0365400477373.issue14750@psf.upfronthosting.co.za>


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

I'm now getting failures to import tkinter on Windows:

C:\Users\Vinay\Projects\scratch>..\cpython\PCbuild\python tkhello.py
Traceback (most recent call last):
  File "tkhello.py", line 1, in <module>
    from tkinter import *
  File "<frozen importlib._bootstrap>", line 977, in _find_and_load
  File "<frozen importlib._bootstrap>", line 596, in load_module
  File "<frozen importlib._bootstrap>", line 262, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 484, in _load_module
  File "C:\Users\Vinay\Projects\cpython\lib\tkinter\__init__.py", line 36, in <module>
    from tkinter import _fix
ImportError: cannot import name _fix

I'm not sure if this is an importlib issue or a tkinter one, but with a recent build (30 April) this worked OK. The tkhello.py script is just

from tkinter import *
root = Tk()
w = Label(root, text="Hello, world!")
w.pack()
root.mainloop()

----------
components: Library (Lib), Windows
messages: 160198
nosy: brett.cannon, vinay.sajip
priority: normal
severity: normal
status: open
title: importlib fails with tkinter application on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue May  8 15:00:18 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 08 May 2012 13:00:18 +0000
Subject: [New-bugs-announce] [issue14751] Pdb does not stop at a breakpoint
Message-ID: <1336482018.48.0.822650830886.issue14751@psf.upfronthosting.co.za>


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

When a breakpoint is set in one of the frames of the frame stack, Pdb
may not stop at that breakpoint when the frame does not have a trace
function. This problem is closely related to issue 13183 and issue
14728. The following scenario demonstrates this problem.


====   main.py   ================================
import bar

def foo():
    bar.bar()
    x = 1

foo()
====   bar.py  ==================================
def bar():
    pass
=================================================
$ python3 -m pdb main.py 
> /path_to/main.py(1)<module>()
-> import bar
(Pdb) import sys; print(sys.version)
3.2.2 (default, Dec 27 2011, 17:35:55) 
[GCC 4.3.2]
(Pdb) break bar.bar
Breakpoint 1 at /path_to/bar.py:1
(Pdb) continue
> /path_to/bar.py(2)bar()
-> pass
(Pdb) break main.py:5
Breakpoint 2 at /path_to/main.py:5
(Pdb) continue
The program finished and will be restarted
> /path_to/main.py(1)<module>()
-> import bar
(Pdb) quit
=================================================


The attached patch fixes this problem. A test case is included in the
patch. The patch is made against the proposed fix of issue 14728 (i.e.
assumes this patch is applied), the reason being that self._curframe
must be correctly set. Actually this issue and issue 14728 should
probably be merged.

Note that the trace function does not need anymore to be set in all
the frames of the frame stack in set_trace(), so setting the trace
function has been removed from the while loop.

----------
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 160202
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Pdb does not stop at a breakpoint
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25494/pdb_default.patch

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

From report at bugs.python.org  Tue May  8 15:19:49 2012
From: report at bugs.python.org (Damien Cassou)
Date: Tue, 08 May 2012 13:19:49 +0000
Subject: [New-bugs-announce] [issue14752] Memleak in typeobject add_methods()
Message-ID: <1336483189.75.0.262092061745.issue14752@psf.upfronthosting.co.za>


New submission from Damien Cassou <damien.cassou at gmail.com>:

In add_methods() function from typeobject.c, it looks like Py_DECREF is not called where it should be. Please find attached a patch that fixes the leak. The patch is also in commit #85a01718b3e3 of my hg repository under the branch fix_add_methods_leak.

This bug has been found using Coccinelle (http://coccinelle.lip6.fr/) and a dedicated semantic patch (https://gist.github.com/2634899).

----------
components: Interpreter Core
files: fix_add_methods_leak.patch
hgrepos: 122
keywords: patch
messages: 160203
nosy: cassou, lemburg, tim_one
priority: normal
severity: normal
status: open
title: Memleak in typeobject add_methods()
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file25495/fix_add_methods_leak.patch

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

From report at bugs.python.org  Tue May  8 16:58:07 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 08 May 2012 14:58:07 +0000
Subject: [New-bugs-announce] [issue14753] multiprocessing treats negative
	timeouts differently	from before
Message-ID: <1336489087.9.0.014285533368.issue14753@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

In version 3.2 and earlier, Process.join() and Connection.poll() treat negative timeouts as zero timeouts.  (Thread.join() does the same.)

In the current 3.3 version, they treat negative timeouts as infinite timeouts.  Also multiprocessing.connection.wait() (new in 3.3) currently treats them as infinite on Unix and zero on Windows.

The attached patch fixes the regression with Process.join() and Connection.poll().  It also makes wait() treat negative timeouts as zero on both Windows and Unix.


It is worth noting that there is a fair amount of inconsistency in the handling of negative timeouts in the stdlib in 3.2:

Treat negative as infinite:
    select.select
    select.*.poll
    threading.*.acquire                   (new in 3.2)
    multiprocessing.dummy.*.acquire       (new in 3.2)

Treat negative as zero:
    threading.Thread.join
    threading.(Condition|Event).wait
    multiprocessing.Process.join
    multiprocessing.*.acquire
    multiprocessing.(Condition|Event).wait
    multiprocessing.Connection.poll
    multiprocessing.Queue.(get|put)
    concurrent.futures.Future.result
    concurrent.futures.wait

Treat negative as error:
    queue.Queue.(get|put)
    socket.socket.settimeout

----------
components: Library (Lib)
files: neg-timeout.patch
keywords: patch
messages: 160206
nosy: pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing treats negative timeouts differently from before
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25497/neg-timeout.patch

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

From report at bugs.python.org  Tue May  8 17:23:11 2012
From: report at bugs.python.org (Damien Cassou)
Date: Tue, 08 May 2012 15:23:11 +0000
Subject: [New-bugs-announce] [issue14754] Emacs configuration to enforce PEP7
Message-ID: <1336490591.2.0.870599678053.issue14754@psf.upfronthosting.co.za>


New submission from Damien Cassou <damien.cassou at gmail.com>:

Please find attached a patch that adds an emacs configuration file to enforce PEP7. The patch is also in commit #518f2af0a687 of my hg repository under the branch emacs-configuration.

----------
components: Demos and Tools
files: emacs-configuration-pep7.patch
hgrepos: 123
keywords: patch
messages: 160208
nosy: cassou
priority: normal
severity: normal
status: open
title: Emacs configuration to enforce PEP7
versions: Python 3.4
Added file: http://bugs.python.org/file25498/emacs-configuration-pep7.patch

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

From report at bugs.python.org  Tue May  8 18:06:16 2012
From: report at bugs.python.org (Nick Wilson)
Date: Tue, 08 May 2012 16:06:16 +0000
Subject: [New-bugs-announce] [issue14755] Distutils2 doesn't have a Python 3
	version on PyPI
Message-ID: <1336493176.58.0.778594682888.issue14755@psf.upfronthosting.co.za>


New submission from Nick Wilson <nick at njwilson.net>:

PyPI only has a version of distutils2 for Python 2, not for Python 3. There is an "ImportError: No module named ConfigParser" when trying to "pip install distutils2" from Python 3.

----------
assignee: eric.araujo
components: Distutils2
messages: 160211
nosy: alexis, eric.araujo, njwilson, tarek
priority: normal
severity: normal
status: open
title: Distutils2 doesn't have a Python 3 version on PyPI

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

From report at bugs.python.org  Tue May  8 18:48:01 2012
From: report at bugs.python.org (Matthew Walker)
Date: Tue, 08 May 2012 16:48:01 +0000
Subject: [New-bugs-announce] [issue14756] Empty Dict in Initializer is
	Shared Betwean Objects
Message-ID: <1336495681.08.0.928968758685.issue14756@psf.upfronthosting.co.za>


New submission from Matthew Walker <mattofak at gmail.com>:

When initializing a class with an empty dict() object as a default initializer, if it is not overridden, multiple instances of the class will share the dictionary. IE:

class test(object):
  def __init__(self, obj=dict()):
    self.obj = obj

a = test()
b = test()

Then id(a.obj) points to the same location as id(b.obj). The behaviour I would expect would be that a.obj and b.obj would be unique instances.

----------
components: Interpreter Core
messages: 160212
nosy: Matthew.Walker
priority: normal
severity: normal
status: open
title: Empty Dict in Initializer is Shared Betwean Objects
versions: Python 2.7

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

From report at bugs.python.org  Tue May  8 19:37:55 2012
From: report at bugs.python.org (stefan brunthaler)
Date: Tue, 08 May 2012 17:37:55 +0000
Subject: [New-bugs-announce] [issue14757] INCA: Inline Caching meets
	Quickening in Python 3.3
Message-ID: <1336498675.39.0.776636251166.issue14757@psf.upfronthosting.co.za>


New submission from stefan brunthaler <s.brunthaler at uci.edu>:

The attached patch adds quickening based inline caching (INCA) to the CPython 3.3 interpreter. It uses a code generator to generate instruction derivatives using the mako template engine, and a set of utility functions to enable automatic and safe quickening.

The code generator itself resides in "cgen" and the generated files reside in "Python/opt/gen". Auxiliary files resides in "Python/opt" and only minor changes are necessary in ceval.c and places where type feedback is possible (mostly in abstract.c and object.c)

Details of the technique have been published (see my home page: http://www.ics.uci.edu/~sbruntha/.) 

On my machine (i7-920 with Intel Turbo Boost disabled) this results in average arithmetic speedups of 1.47 over the vanilla interpreter without threaded code/computed gotos, and 1.13 over an interpreter with threaded code/computed gotos enabled. (Maximal speedups are 1.61 over the vanilla interpreter and 1.17 over the threaded code interpreter.) The optimized interpreter uses 206 instructions which currently only cover the standard library, i.e., there is still ample space left for optimized instruction derivatives for popular applications/libraries, such as NumPy or Django.

Furthermore, based on the purely interpretative nature of the technique, there are no compatibility implications (modulo libraries/modules relying on concrete opcode values---I would guess that such code is rather unlikely, but one never knows...) Additional memory overhead is minimal, too, since the technique only requires space for the new derivatives and is something along the lines of 80-100 KiB.

----------
components: Interpreter Core
files: 20120508-inca.patch
hgrepos: 124
keywords: patch
messages: 160216
nosy: sbrunthaler
priority: normal
severity: normal
status: open
title: INCA: Inline Caching meets Quickening in Python 3.3
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25499/20120508-inca.patch

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

From report at bugs.python.org  Tue May  8 23:15:50 2012
From: report at bugs.python.org (Ivan Sergeev)
Date: Tue, 08 May 2012 21:15:50 +0000
Subject: [New-bugs-announce] [issue14758] SMTPServer of smptd does not
	support binding to an IPv6	address
Message-ID: <1336511750.16.0.237606043889.issue14758@psf.upfronthosting.co.za>


New submission from Ivan Sergeev <vsergeev at gmail.com>:

The SMTPServer class of the smtpd module creates a server socket with the IPv4 socket.AF_INET address family hardcoded, and this prevents it from later binding to an IPv6 local address.

This occurs on line 282 of smtpd.py for the Python 2.7 branch:
http://hg.python.org/cpython/file/5319a4bf72e7/Lib/smtpd.py#l282

And on line 435 of smtpd for the Python 3.2 branch ( Lib/smtpd.py:435 ):
http://hg.python.org/cpython/file/d937b527b76e/Lib/smtpd.py#l435

One IPv4/IPv6 agnostic solution is to look up provided local address with getaddrinfo(), and use one of the result's address family, socket type and address tuple for create_socket() and bind() at those lines:

...
try:
    gai_results = socket.getaddrinfo(localaddr[0], localaddr[1])
    self.create_socket(gai_results[0][0], gai_results[0][1])
    # try to re-use a server port if possible
    self.set_reuse_addr()
    self.bind(gai_results[0][4])
    self.listen(5)
...

----------
components: Library (Lib)
messages: 160226
nosy: vsergeev
priority: normal
severity: normal
status: open
title: SMTPServer of smptd does not support binding to an IPv6 address
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May  9 03:08:20 2012
From: report at bugs.python.org (Jeff Laing)
Date: Wed, 09 May 2012 01:08:20 +0000
Subject: [New-bugs-announce] [issue14759] Berkeley DB License conditions are
	onerous (and poorly	documented)
Message-ID: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za>


New submission from Jeff Laing <jefflaing at gmail.com>:

As part of an audit of license compliance, I was looking at the terms in the LICENSE.txt that describe the Berkeley DB product.  I had thought this would be under the standard Berkeley license, but Oracle have added their own zinger.

* 3. Redistributions in any form must be accompanied by information on
*    how to obtain complete source code for the DB software and any
*    accompanying software that uses the DB software.  The source code
*    must either be included in the distribution or be available for no
*    more than the cost of distribution plus a nominal fee, and must be
*    freely redistributable under reasonable conditions.  

So, my application, which embeds Python (rather than running it as python.exe) and includes the standard runtime library, must distribute my source code.

This page:

http://mail.python.org/pipermail/python-dev/2008-September/082316.html

suggests that this is not the case for regular Python, but it makes no statement about "embedding".  Sadly the Oracle page it links to suggesting this is not an issue, does not exist.

The general "License" page on the Python websites makes no reference whatsoever to Berkeley DB license obligations.

I note that there are other modules mentioned on the Licenses webpage that are not in the LICENSES.txt file, and vice versa.  I have no idea whether this is deliberate, or an oversight.

----------
assignee: docs at python
components: Documentation
messages: 160238
nosy: Jeff.Laing, docs at python
priority: normal
severity: normal
status: open
title: Berkeley DB License conditions are onerous (and poorly documented)
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed May  9 09:15:19 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 09 May 2012 07:15:19 +0000
Subject: [New-bugs-announce] [issue14760] logging: make setLevel() return
	handler itself for	chained configuration
Message-ID: <1336547719.78.0.572014137028.issue14760@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It would be convenient if instead of:

    hdlr = logging.StreamHandler()
    hglr.setLevel(logging.DEBUG)
    root.addHandler(hdlr)

it would be possible to write:

    root.addHandler(logging.StreamHandler().setLevel(logging.DEBUG))

----------
components: Library (Lib)
messages: 160252
nosy: techtonik
priority: normal
severity: normal
status: open
title: logging: make setLevel() return handler itself for chained configuration

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

From report at bugs.python.org  Wed May  9 10:45:55 2012
From: report at bugs.python.org (Damien Cassou)
Date: Wed, 09 May 2012 08:45:55 +0000
Subject: [New-bugs-announce] [issue14761] Memleak in import.c
	load_source_module()
Message-ID: <1336553155.13.0.322701630685.issue14761@psf.upfronthosting.co.za>


New submission from Damien Cassou <damien.cassou at gmail.com>:

In load_source_module() function from import.c, it looks like Py_DECREF is not called where it should be. Please find attached a patch that fixes the leak. 

This bug has been found using Coccinelle (http://coccinelle.lip6.fr/) using a semantic patch (similar to https://gist.github.com/2634899).

----------
components: Interpreter Core
files: fix_load_source_module_leak.patch
keywords: patch
messages: 160262
nosy: benjamin.peterson, cassou, lemburg, tim_one
priority: normal
severity: normal
status: open
title: Memleak in import.c load_source_module()
versions: Python 2.7
Added file: http://bugs.python.org/file25507/fix_load_source_module_leak.patch

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

From report at bugs.python.org  Wed May  9 11:39:47 2012
From: report at bugs.python.org (Giuseppe Attardi)
Date: Wed, 09 May 2012 09:39:47 +0000
Subject: [New-bugs-announce] [issue14762] ElementTree memory leak
Message-ID: <1336556387.72.0.794459300498.issue14762@psf.upfronthosting.co.za>


New submission from Giuseppe Attardi <attardi at di.unipi.it>:

I confirm the presence of a serious memory leak in ElementTree, using the iterparse() function.
Memory grows disproportionately to dozens of GB when parsing a large XML file.

For further information, see discussion in:
  http://www.gossamer-threads.com/lists/python/bugs/912164?do=post_view_threaded#912164
but notice that the comments attributing the problem to the OS are quite off the mark.

To replicate the problem, try this on a Wikipedia dump:

    iterparse = ElementTree.iterparse(file)
    id = None
    for event, elem in iterparse:
        if elem.tag.endswith("title"):
            title = elem.text
        elif elem.tag.endswith("id") and not id:
            id = elem.text
        elif elem.tag.endswith("text"):
           print id, title, elem.text[:20]

----------
messages: 160266
nosy: Giuseppe.Attardi
priority: normal
severity: normal
status: open
title: ElementTree memory leak
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Wed May  9 13:30:37 2012
From: report at bugs.python.org (Fj)
Date: Wed, 09 May 2012 11:30:37 +0000
Subject: [New-bugs-announce] [issue14763] string.split maxsplit documented
	incorrectly
Message-ID: <1336563037.57.0.851636000616.issue14763@psf.upfronthosting.co.za>


New submission from Fj <fj.mail at gmail.com>:

string.split documentation says:

> The optional third argument maxsplit defaults to 0. If it is nonzero, at most maxsplit number of splits occur, and the remainder of the string is returned as the final element of the list (thus, the list will have at most maxsplit+1 elements).

It lies! If you give it maxsplit=0 it doesn't do any splits at all! It should say:

> The optional third argument maxsplit defaults to **-1**. If it is **nonnegative**, at most maxsplit number of splits occur, ...

Additionally, it could specify default values in the function signature explicitly, like re.split does:

    string.split(s, sep=None, maxsplit=-1)

instead of

    string.split(s, [sep, [maxsplit]])

It seems that the inconsistency stems from the time long forgotten (certainly before 2.5) when string.split used the implementation in stropmodule.c (obsolete), which does indeed uses maxsplit=0 (and on which the re.split convention was based, regrettably).

Currently string.split just calls str.split, and that uses maxsplit=-1 to mean unlimited splits.

>From searching "maxsplit" in the bug tracker I understand that split functions have had a rather difficult history and some quirks preserved for the sake of backward compatibility, and not documented for the sake of brevity. In this case, however, the documentation does try to document the particular behaviour, but is wrong, which is really confusing.

Also, maybe an even better fix would be to change the str.split documentation to use the proper signature (`str.split(sep=None, maxsplit=-1)`), and simply say that string.split(s, sep=None, maxsplit=-1) calls s.split(sep, maxsplit) here? Because that's what it does, while having _two_ different, incomplete, partially wrong explanations of the same thing is confusing!

----------
assignee: docs at python
components: Documentation
messages: 160273
nosy: Fj, docs at python
priority: normal
severity: normal
status: open
title: string.split maxsplit documented incorrectly
versions: Python 2.7

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

From report at bugs.python.org  Wed May  9 14:09:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 May 2012 12:09:53 +0000
Subject: [New-bugs-announce] [issue14764] importlib.test.benchmark broken
Message-ID: <1336565393.03.0.0926288176672.issue14764@psf.upfronthosting.co.za>


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

It seems the benchmark script didn't survive the migration:


$ ./python -m importlib.test.benchmark
Measuring imports/second over 1 second, best out of 3
Entire benchmark run should take about 33 seconds
Using <function __import__ at 0x7fdea5b3d7a0> as __import__

sys.modules [ 289195 288128 288050 ] best is 289,195
Built-in module [ 48351 48101 48432 ] best is 48,432
Source writing bytecode: small [ Traceback (most recent call last):
  File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 30, in bench
    total_time += timer.timeit(1)
  File "/home/antoine/cpython/opt/Lib/timeit.py", line 190, in timeit
    timing = self.inner(it, self.timer)
  File "<timeit-src>", line 6, in inner
  File "/home/antoine/cpython/opt/Lib/importlib/_bootstrap.py", line 1077, in __import__
    module = _gcd_import(name)
  File "/home/antoine/cpython/opt/Lib/importlib/_bootstrap.py", line 1024, in _gcd_import
    return _find_and_load(name, _gcd_import)
  File "/home/antoine/cpython/opt/Lib/importlib/_bootstrap.py", line 974, in _find_and_load
    raise ImportError(_ERR_MSG.format(name), name=name)
ImportError: No module named '__importlib_test_benchmark__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/cpython/opt/Lib/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/antoine/cpython/opt/Lib/runpy.py", line 75, in _run_code
    exec(code, run_globals)
  File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 239, in <module>
    main(import_, options)
  File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 197, in main
    for result in benchmark(seconds=seconds, repeat=repeat):
  File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 108, in source_writing_bytecode
    for result in bench(name, cleanup, repeat=repeat, seconds=seconds):
  File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 32, in bench
    cleanup()
  File "/home/antoine/cpython/opt/Lib/importlib/test/benchmark.py", line 106, in cleanup
    sys.modules.pop(name)
KeyError: '__importlib_test_benchmark__'

----------
components: Library (Lib)
messages: 160281
nosy: brett.cannon, pitrou
priority: low
severity: normal
status: open
title: importlib.test.benchmark broken
versions: Python 3.3

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

From report at bugs.python.org  Wed May  9 15:51:52 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 09 May 2012 13:51:52 +0000
Subject: [New-bugs-announce] [issue14765] the struct example should give
	consistent results across	different hardware platforms
Message-ID: <1336571512.12.0.453082723156.issue14765@psf.upfronthosting.co.za>


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

This example [1] assumes you are using a specific platform to check it out. I am using amd64, and I get different results. To fix, I prefix the format string with '>':

before:
pack('hhl', 1, 2, 3)

after:
pack('>hhl', 1, 2, 3)

1: http://hg.python.org/cpython/file/d3ddbad31b3e/Doc/library/struct.rst#l299

----------
assignee: docs at python
components: Documentation
messages: 160291
nosy: docs at python, mark.dickinson, meador.inge, tshepang
priority: normal
severity: normal
status: open
title: the struct example should give consistent results across different hardware platforms
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 10 00:11:10 2012
From: report at bugs.python.org (Chris Bergstresser)
Date: Wed, 09 May 2012 22:11:10 +0000
Subject: [New-bugs-announce] [issue14766] Non-naive time comparison throws
	naive time error
Message-ID: <1336601470.15.0.633873123281.issue14766@psf.upfronthosting.co.za>


New submission from Chris Bergstresser <chris at subtlety.com>:

The datetime module says:

An object d of type time or datetime may be naive or aware. d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None, or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns None, d is naive.

However, I can create two non-naive timezones (under this definition) which throw an exception when they're compared, because one is being considered offset-naive:

>>> import pytz, datetime
>>> UTC_TZ = pytz.utc
>>> EASTERN_TZ = pytz.timezone('America/New_York')
>>> d1 = datetime.time(10, tzinfo = UTC_TZ)
>>> d1
datetime.time(10, 0, tzinfo=<UTC>)
>>> d1.tzinfo
<UTC>
>>> d1.utcoffset(d1)
datetime.timedelta(0)
>>> d2 = datetime.time(10, tzinfo = EASTERN_TZ)
>>> d2
datetime.time(10, 0, tzinfo=<DstTzInfo 'America/New_York' EST-1 day, 19:00:00 STD>)
>>> d2.tzinfo
<DstTzInfo 'America/New_York' EST-1 day, 19:00:00 STD>
>>> d2.tzinfo.utcoffset(d2)
datetime.timedelta(-1, 68400)
>>> d1 < d2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare offset-naive and offset-aware times

----------
messages: 160314
nosy: Chris.Bergstresser
priority: normal
severity: normal
status: open
title: Non-naive time comparison throws naive time error
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu May 10 03:28:08 2012
From: report at bugs.python.org (jspenguin)
Date: Thu, 10 May 2012 01:28:08 +0000
Subject: [New-bugs-announce] [issue14767] urllib.request.HTTPRedirectHandler
	raises HTTPError when	Location header is relative
Message-ID: <1336613288.44.0.609842734336.issue14767@psf.upfronthosting.co.za>


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

If a server returns a relative URL in the 'Location:' header, HTTPRedirectHandler will fail because it checks the scheme of the URL before it calls urljoin() to convert it to an absolute URL.

----------
components: Library (Lib)
files: rel_redirect.py
messages: 160319
nosy: jspenguin
priority: normal
severity: normal
status: open
title: urllib.request.HTTPRedirectHandler raises HTTPError when Location header is relative
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file25513/rel_redirect.py

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

From report at bugs.python.org  Thu May 10 04:25:19 2012
From: report at bugs.python.org (Bradley Froehle)
Date: Thu, 10 May 2012 02:25:19 +0000
Subject: [New-bugs-announce] [issue14768] os.path.expanduser('~/a') doesn't
	works correctly when	HOME is '/'
Message-ID: <1336616719.53.0.0181039084053.issue14768@psf.upfronthosting.co.za>


New submission from Bradley Froehle <brad.froehle at gmail.com>:

When $HOME=/, os.path.expanduser('~/a') returns '//a' rather than '/a'.

This regression was created by a partially incorrect resolution to issue #5471, and affects versions 2.7 and 3.2 (at least).

$ HOME=/ python2.7 -c "import os; print os.path.expanduser('~/a')"
//a
$ HOME=/ python3.2 -c "import os; print(os.path.expanduser('~/a'))"
//a

In each case the expected result should be '/a'.

----------
components: Library (Lib)
messages: 160321
nosy: bfroehle
priority: normal
severity: normal
status: open
title: os.path.expanduser('~/a') doesn't works correctly when HOME is '/'
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu May 10 10:42:37 2012
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 10 May 2012 08:42:37 +0000
Subject: [New-bugs-announce] [issue14769] Add test to automatically detect
	missing format units in	skipitem()
Message-ID: <1336639357.09.0.810627542534.issue14769@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

I recently fixed an old bug: some time ago someone added support for a new "format unit", 'Z', to PyArg_Parse(), but neglected to add matching support for it to skipitem().  Benjamin asked for a regression test.  Initially I said, okay, how the hell do I test that?  A quick grep showed that there was already a test like that, for the format unit 'C'.  I figured adding another one-off test was dumb, and there had to be a better way.

Attached is a patch against trunk that adds a new function to _testcapimodule.c: test_skipitem_parity().  The comment at the top describes says it best:

 * This function brute-force tests all** ASCII characters (1 to 127
 * inclusive) as format units, checking to see that
 * PyArg_ParseTupleAndKeywords() return consistent errors both when
 * the unit is attempted to be used and when it is skipped.  If the
 * format unit doesn't exist, we'll get one of two specific error
 * messages (one for used, one for skipped); if it does exist we
 * *won't* get that error--we'll get either no error or some other
 * error.  If we get the "does not exist" error for one test and
 * not for the other, there's a mismatch, and the test fails.
 *
 *   ** Okay, it actually skips some ASCII characters.  Some characters
 *      have special funny semantics, and it would be difficult to
 *      accomodate them here.

I also removed the old test just for 'C', as this test subsumes that one.

Right now, the test runs to completion without complaint.  To test that it's really working, comment out an existing case statement in skipitem().  Or, add a new case statement, for a character that isn't otherwise supported (yet), to the top paragraph of case statements.  Doing either of these will cause a failure.

... you happy now, Benjamin?

----------
assignee: larry
components: Interpreter Core
files: larry.test_skipitem_parity.1.diff
keywords: patch
messages: 160329
nosy: benjamin.peterson, larry
priority: normal
severity: normal
stage: patch review
status: open
title: Add test to automatically detect missing format units in skipitem()
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25515/larry.test_skipitem_parity.1.diff

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

From report at bugs.python.org  Thu May 10 13:01:24 2012
From: report at bugs.python.org (Michael Foord)
Date: Thu, 10 May 2012 11:01:24 +0000
Subject: [New-bugs-announce] [issue14770] Minor documentation fixes
Message-ID: <1336647684.02.0.112519558227.issue14770@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

A bunch of minor fixes for the documentation suggested by Kurt Robinson to the webmaster email address:


Below, you will find 15 snippets from the Python 2.7.2 Library and Extension
FAQ (http://docs.python.org/faq/library.html), categorized by problem type,
accompanied by changes I would suggest or by questions I would have for the
author.


********** Wrong word or missing word **********

(1) CURRENT TEXT:  "Eventually you'll learn what's in the standard library
and will able to skip this step."

SUGGESTION:  Change "will able" to "will be able".


(2) CURRENT TEXT:   "The location of the sendmail program varies between
systems; sometimes it is /usr/lib/sendmail, sometime /usr/sbin/sendmail."

SUGGESTION:  Replace "sometime" with "sometimes".

(3) CURRENT TEXT:  "The Python parent can of course explicitly flush the
data it sends to the child before it reads any output, but if the child is a
naive C program it may have been written to never explicitly flush its
output, even if it is interactive, since flushing is normally automatic."

QUESTION:  Is "naive C program" the intended wording or should it be "native
C program"?


(4) CURRENT TEXT:  "[HTMLgen is] used when you are writing in Python and
wish to synthesize HTML pages for generating a web or for CGI forms, etc."

QUESTION:   I believe "web" should be "webpage". Correct?


(5) CURRENT TEXT:  "The default format used by the pickle module is a slow
one that results in readable pickles. Making it the default, but it would
break backward compatibility."

QUESTION:  It looks like some words have been left out of the second
sentence. What is the intended meaning there?


********** Punctuation issues **********

(6) CURRENT TEXT:  "The standard Python source distribution comes with a
curses module in the Modules/ subdirectory, though it's not compiled by
default (note that this is not available in the Windows distribution - there
is no curses module for Windows)." 

SUGGESTIONS: I believe the major style guides are in agreement that a
complete-sentence parenthetical note falling at the end of another sentence
should be punctuated as a separate sentence. I also think a semicolon would
be more comfortable doing what that dash is doing, but I suppose that's a
judgment call. Here's my suggested rewrite for the end of the sentence:
".though it's not compiled by default. (Note that this is not available in
the Windows distribution; there is no curses module for Windows)."


(7) CURRENT TEXT:  "Thus, to read n bytes from a pipe p created with
os.popen(), you need to use p.read(n)."

SUGGESTION:  Put commas before and after "p", or remove the "a" in front of
"pipe".


(8) CURRENT TEXT:  'For example to send name= "Guy Steele, Jr." .'

SUGGESTIONS:  Though it won't be apparent in this email, the quotation mark
before "Guy" is a close-quote symbol (&#8221;). It should be an open-quote
symbol (&#8220). I would also put a comma after "for example".


(9) CURRENT TEXT:  "For example loading a half megabyte of data may take
less than a third of a second."

SUGGESTION:  Insert a comma after "For example".


********** Ambiguity (or at least a momentary miscue) **********

(10) CURRENT TEXT:  "For testing, it helps to write the program so that it
may be easily tested by using good modular design."

SUGGESTION:  Though it will be clear for most readers that "by using good
modular design" describes the writing process and not the testing process, a
rewrite could avoid the miscue and improve the flow: "To get the most out of
testing, you should use good modular design in your program."


(11) CURRENT TEXT:  "A test suite can be associated with each module which
automates a sequence of tests."

SUGGESTION:  Though we can figure out that it's the test suite and not the
module which automates a sequence of tests, a rewrite could avoid the miscue
and improve readability: "A test suite that automates a sequence of tests
can be associated with each module."


(12) CURRENT TEXT:  "Instead of trying to guess how long a time.sleep()
delay will be enough, it's better to use some kind of semaphore mechanism."

SUGGESTION:  Insert "of" after "how long" to avoid leading to the reader
down the path of "how long a time.sleep() delay will last."


(13) CURRENT TEXT:  "The Queue class maintains a list of objects with
.put(obj) to add an item to the queue and .get() to return an item."

SUGGESTIONS:   Again, we can figure out that those are methods on the class
not methods on the objects, but rephrasing the sentence so that it says that
unambiguously makes for easier reading: "The Queue class maintains a list of
objects and has a .put(obj) method, which adds items to the queue, and
.get() method, which returns an item.

Shifting momentarily to "content perspective", I think it could be helpful
to be more specific about what .get() does. I would suggest changing
"returns an item" to something like "returns the item which has been in the
queue the longest".


********** Miscellaneous **********

(14) CURRENT TEXT:  "This can be caused because the parent expects the child
to output more text than it does, or it can be caused by data being stuck in
stdio buffers due to lack of flushing."

SUGGESTION:  "Caused because" strikes my ear as slightly redundant and
awkward, but perhaps that's just me. In any case, I think the sentence would
read better if it had a more parallel structure: "This can be caused by the
parent expecting the child to output more text than it does or by data being
stuck in stdio buffers due to lack of flushing."


(15) CURRENT TEXT:  "The atexit module provides a register function that is
similar to C's onexit."

SUGGESTION:  Change "onexit" to "onexit()".

----------
assignee: docs at python
components: Documentation
messages: 160333
nosy: docs at python, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Minor documentation fixes
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 10 20:19:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 May 2012 18:19:13 +0000
Subject: [New-bugs-announce] [issue14771] Occasional failure in test_ioctl
Message-ID: <1336673953.31.0.37144571556.issue14771@psf.upfronthosting.co.za>


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

This happens from time to time on my desktop computer:

[151/354/1] test_ioctl
test test_ioctl failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/32/Lib/test/test_ioctl.py", line 36, in test_ioctl
    self.assertIn(rpgrp, ids)
AssertionError: 25242 not found in (23865, 23615)

----------
components: Library (Lib), Tests
messages: 160357
nosy: neologix, pitrou
priority: low
severity: normal
status: open
title: Occasional failure in test_ioctl
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 10 21:26:27 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 10 May 2012 19:26:27 +0000
Subject: [New-bugs-announce] [issue14772] Return destination values in some
	shutil functions
Message-ID: <1336677987.7.0.16571427099.issue14772@psf.upfronthosting.co.za>


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

Attached is a patch to return the final destination of files or directories sent through shutil's copy, copy2, and move functions. This removes the need to construct the destination path on your own.

This is especially useful for copy/copy2 where you copy a file into a directory and need to know that resulting path. Rather than calling os.path.join(dest, os.path.basename(source)) you could get that path from copy/copy2 (which does that join internally).

Patch has docs and tests.

----------
assignee: brian.curtin
components: Library (Lib)
files: shutil_return_values.diff
keywords: needs review, patch
messages: 160363
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Return destination values in some shutil functions
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25522/shutil_return_values.diff

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

From report at bugs.python.org  Thu May 10 21:28:40 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 10 May 2012 19:28:40 +0000
Subject: [New-bugs-announce] [issue14773] fwalk breaks on dangling symlinks
Message-ID: <1336678120.54.0.411663637267.issue14773@psf.upfronthosting.co.za>


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

I'm implementing a safe rmtree using fwalk. Everything works perfectly except for one thing: if the directory contains dangling symlinks, fwalk goes belly-up:

$ ls -l test/
total 0
lrwxrwxrwx 1 vagrant vagrant 4 May 10 16:36 doesntwork -> this

$ ./python
Python 3.3.0a3+ (default:b32baa5b7626+, May 10 2012, 14:56:20) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
[71253 refs]
>>> list(os.fwalk('test'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/vagrant/p/Lib/os.py", line 342, in fwalk
    for x in _fwalk(topfd, top, topdown, onerror, followlinks):
  File "/home/vagrant/p/Lib/os.py", line 361, in _walk
    if st.S_ISDIR(fstatat(topfd, name).st_mode):
FileNotFoundError: [Errno 2] No such file or directory


Unfortunately this makes it impossible to implement rmtree. The reason is the following code:

for name in names:
    # Here, we don't use AT_SYMLINK_NOFOLLOW to be consistent with
    # walk() which reports symlinks to directories as directories. We do
    # however check for symlinks before recursing into a subdirectory.
    if st.S_ISDIR(fstatat(topfd, name).st_mode):
        dirs.append(name)
    else:
        nondirs.append(name)

The "unsafe" walk tree uses os.path.isdir() instead of os.fstatat() and handles this case gracefully.

A simple try-except protection with a symlink check fixes it and the tests pass. This is a blocker for #4489. I have expanded the test of the WalkerTests suite.

Tested on Linux (= works) and OS X (= skipped).

----------
assignee: hynek
components: Library (Lib)
files: make-fwalk-handle-dangling-symlinks.diff
keywords: patch
messages: 160364
nosy: hynek, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: fwalk breaks on dangling symlinks
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25523/make-fwalk-handle-dangling-symlinks.diff

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

From report at bugs.python.org  Thu May 10 21:47:34 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 10 May 2012 19:47:34 +0000
Subject: [New-bugs-announce] [issue14774] _sysconfigdata.py doesn't support
	multiple build	configurations
Message-ID: <1336679254.12.0.498386228703.issue14774@psf.upfronthosting.co.za>


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

When building from source, if I create multiple configuration directories and build from there e.g.:

mkdir configs
cd configs
mkdir config-A
cd config-A
../../configure
make
cd ..
mkdir config-B
cd config-B
../../configure --enable-shared
make
cd ../config-A
./python -c "import sysconfig; print(sysconfig.get_config_var('CONFIG_ARGS')

then sysconfig's settings are the same for *every* config, reflecting those of the last build (config-B above, rathern than those of config-A).

This turns out to be due to this:
   ./python -SE -m sysconfig --generate-posix-vars
This generates $(srcdir)/Lib/_sysconfigdata.py for whichever config was last

Is there a way of fixing this whilst keeping it a python file?  Or do we need to build from a C file, perhaps?

----------
components: Build
messages: 160366
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: _sysconfigdata.py doesn't support multiple build configurations
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu May 10 22:03:54 2012
From: report at bugs.python.org (stw)
Date: Thu, 10 May 2012 20:03:54 +0000
Subject: [New-bugs-announce] [issue14775] Slow unpickling of certain
	dictionaries in python 2.7 vs	python 2.6
Message-ID: <1336680234.2.0.688892312973.issue14775@psf.upfronthosting.co.za>


New submission from stw <silktw at googlemail.com>:

I've found that unpickling a certain kind of dictionary is substantially slower in python 2.7 compared to python 2.6. The dictionary has keys that are tuples of strings - a 1-tuple is enough to see the effect. The problem seems to be caused by garbage collection, as turning it off eliminates the slowdown. Both pickle and cPickle modules are affected.


I've attached two files to demonstrate this. The file 'make_file.py'
creates a dictionary of specified size, with keys containing 1-tuples of random strings. It then dumps the dictionary to a pickle file using a specified pickle module.

The file 'load_file.py' unpickles the file created by 'make_file.py', using a specified pickle module, and prints the time taken. The code can be run with garbage collection either on or off.

The results below are for a dictionary of 200000 entries. Each entry is the time taken in seconds with garbage collection on / garbage collection off. The row headings are the module used to pickle the data, the column headings the module used to unpickle it.


python 2.6, n = 200000

               size    pickle      cPickle
    pickle     4.3M    3.02/2.65   0.786/0.559 
    cPickle    3.4M    2.27/2.04   0.66/0.443 


python 2.7, n = 200000

               size    pickle      cPickle
    pickle     4.3M    10.5/2.67   6.62/0.563 
    cPickle    2.4M    1.45/1.39   0.362/0.325 


When pickle is used to pickle the data, there is a significant slowdown in python 2.7 compared to python 2.6 with garbage collection on. With garbage collection off the times in python 2.7 are essentially identical to those in python 2.6.

When cPickle is used to pickle the data, both unpicklers are faster in python 2.7 than in python 2.6. Presumably the speedup is due to the dictionary optimizations introduced from issue #5670.


Both pickle and cPickle show a slowdown when data pickled in python 2.6 is unpickled in python 2.7:


pickled in python 2.6, unpickled in python 2.7, n = 200000

                      size    pickle (2.7)    cPickle (2.7)
    pickle (2.6)      4.3M    10.4/2.66       6.64/0.56 
    cPickle (2.6)     3.4M    8.73/2.08       6.1/0.452 


I don't know enough about the internals of the pickle modules or garbage collector to offer an explanation/fix. The list of optimizations for python 2.7 indicates changes to both pickle modules (issues #5670 and #5084) and the garbage collector (issues #4074 and #4688). It seems possible that the slowdown is the result of some interaction between these changes.


Further notes:

1. System details: python 2.6.5 and python 2.7.3 on Ubuntu 10.04, 1.73GHz Pentium M processor.

2. Only pickle files created with protocols 1 and 2 are affected. Pickling with protocol 0 gives similar timings on python 2.6 and 2.7.

3. The fact that the dictionary's keys are tuples is relevant, although the length of the tuple is not. Unpickling a dictionary whose keys are strings does not show any slowdown.

----------
files: make_file.py
messages: 160368
nosy: stw
priority: normal
severity: normal
status: open
title: Slow unpickling of certain dictionaries in python 2.7 vs python 2.6
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file25524/make_file.py

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

From report at bugs.python.org  Thu May 10 23:05:16 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 10 May 2012 21:05:16 +0000
Subject: [New-bugs-announce] [issue14776] Add SystemTap static markers
Message-ID: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za>


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

I'm attaching a patch which adds static markers for SystemTap for two probeable events within CPython's bytecode interpreter, along with test cases and documentation.

I'm hoping to get this merged for 3.3; is this PEP-worthy, or can this be done through patch review?

Note: issue #4111 was originally opened on 2008-10-12 as "Add DTrace probes", and was generalized on 2009-12-08 to "Add Systemtap/DTrace probes".  That issue was closed on 2011-11-14 to be superceded by issue #13405 ("Add DTrace probes"), hence I'm opening this as a separate issue.

I believe that although DTrace and SystemTap are similar, they are sufficiently different from each other that it's going to take separate work to support one or the other (and that the maintainers of the support for each within CPython are likely to be different people).  I hope that once one of them is merged, the other will become a lot easier to merge.

Potentially other markers could be added for other events (the DTrace patch in issue #13405 has gained some), but I wanted to start small for now.

----------
components: Interpreter Core
files: cpython-systemtap-2012-05-10-001.patch
keywords: needs review, patch
messages: 160374
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: Add SystemTap static markers
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25529/cpython-systemtap-2012-05-10-001.patch

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

From report at bugs.python.org  Fri May 11 00:47:57 2012
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 10 May 2012 22:47:57 +0000
Subject: [New-bugs-announce] [issue14777] Tkinter clipboard_get() decodes
	characters incorrectly
Message-ID: <1336690077.5.0.0628232128549.issue14777@psf.upfronthosting.co.za>


New submission from Thomas Kluyver <takowl at gmail.com>:

With the text 'abc?' copied to the clipboard, on Linux, where UTF-8 is the default encoding:

Python 3.2.3 (default, Apr 12 2012, 21:55:50) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> root = tkinter.Tk()
>>> root.clipboard_get()
'abc?\x82?'
>>> 'abc?'.encode('utf-8').decode('latin-1')
'abc?\x82?'

I see the same behaviour in 2.7.3 as well (it returns a unicode string u'abc\xe2\x82\xac').

If the clipboard is only accessible at a bytes level, I think clipboard_get should return a bytes object. But I can reliably copy and paste non-ascii characters between programs, so it looks like it's possible to return unicode.

----------
components: Tkinter
messages: 160378
nosy: takluyver
priority: normal
severity: normal
status: open
title: Tkinter clipboard_get() decodes characters incorrectly
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May 11 01:14:01 2012
From: report at bugs.python.org (Nick Wilson)
Date: Thu, 10 May 2012 23:14:01 +0000
Subject: [New-bugs-announce] [issue14778] IrrationalVersionError should
	include the project name
Message-ID: <1336691641.31.0.00520688122933.issue14778@psf.upfronthosting.co.za>


New submission from Nick Wilson <nick at njwilson.net>:

IrrationalVersionError in packaging/distutils2 should include the name of the project responsible for the error. It currently only includes the version:

  >>> import packaging.pypi.xmlrpc
  >>> client = packaging.pypi.xmlrpc.Client()
  >>> client.search_projects('req')
  Irrational version error found: 0.0.0-prealpha
  Irrational version error found: 0.1dev-20110502
  ...

----------
assignee: eric.araujo
components: Distutils2
messages: 160381
nosy: alexis, eric.araujo, njwilson, tarek
priority: normal
severity: normal
status: open
title: IrrationalVersionError should include the project name
versions: 3rd party, Python 3.3

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

From report at bugs.python.org  Fri May 11 01:20:55 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 10 May 2012 23:20:55 +0000
Subject: [New-bugs-announce] [issue14779] test_buffer fails on OS X
	universal 64-/32-bit builds
Message-ID: <1336692055.13.0.571191399969.issue14779@psf.upfronthosting.co.za>


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

test_buffer can fail when run on an OS X 64-/32-bit universal build of Python is run in 32-bit mode.

$ /usr/local/bin/python3.3 -m test test_buffer
[1/1] test_buffer
1 test OK.
$ /usr/local/bin/python3.3-32 -m test -v test_buffer
== CPython 3.3.0a3 (v3.3.0a3:0b53b70a40a0, May 1 2012, 11:39:35) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
==   Darwin-11.4.0-x86_64-i386-64bit little-endian
==   /private/var/folders/fm/9wjgctqx61n796zt88qmmnxc0000gn/T/test_python_56263
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_buffer
[...]
test_memoryview_construction (test.test_buffer.TestBufferProtocol) ... FAIL
test_ndarray_format_shape (test.test_buffer.TestBufferProtocol) ... FAIL
test_ndarray_format_strides (test.test_buffer.TestBufferProtocol) ... FAIL
test_ndarray_getbuf (test.test_buffer.TestBufferProtocol) ... FAIL
test_ndarray_multidim (test.test_buffer.TestBufferProtocol) ... FAIL
test_ndarray_slice_assign_single (test.test_buffer.TestBufferProtocol) ... FAIL
[...]

The test is incorrectly testing a compile-time configuration variable which is not meaningful for universal builds since each architecture can have different values.  Further, the platform.architecture fallback test is also unreliable; as noted in the docs for the platform module, sys.maxsize should be used for run-time tests.  The attached patch fixes the test for OS X.

----------
files: issueXXXXX_test_buffer.patch
keywords: patch
messages: 160382
nosy: ned.deily, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: test_buffer fails on OS X universal 64-/32-bit builds
versions: Python 3.3
Added file: http://bugs.python.org/file25532/issueXXXXX_test_buffer.patch

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

From report at bugs.python.org  Fri May 11 02:12:13 2012
From: report at bugs.python.org (James Oakley)
Date: Fri, 11 May 2012 00:12:13 +0000
Subject: [New-bugs-announce] [issue14780] SSL should use OpenSSL-defined
	default certificate store	if ca_certs parameter is omitted
Message-ID: <1336695133.95.0.45377603567.issue14780@psf.upfronthosting.co.za>


New submission from James Oakley <jfunk at funktronics.ca>:

OpenSSL provides a method, SSL_CTX_set_default_verify_paths(), for loading a default certificate store, which is used by many distributions.

In openSUSE, the default store is not a bundle, but a directory-based store, which is not supported at all by the SSL module in Python 2.7. A bug related to this was assigned to me here:

https://bugzilla.novell.com/show_bug.cgi?id=761501

I created patches for the Python 2.7.3 and 3.2.3 SSL modules that will load the distribution-specific store if ca_certs is omitted.

----------
components: Library (Lib)
files: python-2.7.3-ssl_default_certs.patch
keywords: patch
messages: 160392
nosy: jfunk
priority: normal
severity: normal
status: open
title: SSL should use OpenSSL-defined default certificate store if ca_certs parameter is omitted
type: enhancement
Added file: http://bugs.python.org/file25533/python-2.7.3-ssl_default_certs.patch

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

From report at bugs.python.org  Fri May 11 12:54:35 2012
From: report at bugs.python.org (Matthias Meyer)
Date: Fri, 11 May 2012 10:54:35 +0000
Subject: [New-bugs-announce] [issue14781] strptime fails for year 0
Message-ID: <1336733675.67.0.302475509156.issue14781@psf.upfronthosting.co.za>


New submission from Matthias Meyer <meyer.matze at googlemail.com>:

Hi folks,

What I did:
import time
time.strptime('0000-10-03T15:35:05Z','%Y-%m-%dT%H:%M:%SZ')

What I expected:
time.struct_time(tm_year=0, tm_mon=10, tm_mday=3, tm_hour=15, tm_min=35, tm_sec=5, tm_wday=2, tm_yday=276, tm_isdst=-1)

What I got:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/_strptime.py", line 454, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/usr/lib/python2.7/_strptime.py", line 440, in _strptime
    datetime_date(year, 1, 1).toordinal() + 1
ValueError: year is out of range


Environment:
Ubuntu 12.04 x64
python --version: 2.7.3


If you need more information, please let me know...

----------
components: Library (Lib)
messages: 160404
nosy: Matthias.Meyer
priority: normal
severity: normal
status: open
title: strptime fails for year 0
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri May 11 14:16:26 2012
From: report at bugs.python.org (w.pettersson)
Date: Fri, 11 May 2012 12:16:26 +0000
Subject: [New-bugs-announce] [issue14782] Tabcompletion of classes with
	static methods and	__call__ has extra bracket
Message-ID: <1336738586.42.0.602618902889.issue14782@psf.upfronthosting.co.za>


New submission from w.pettersson <william.pettersson at gmail.com>:

With tab completion enabled via rlcompleter and readline, tab-completion will assume anything that is callable (by callable(val)) is going to be called. For example, the below code defines a class "CCC" that is callable and has a static function. However, typing 
>>> CC
and then pressing tab results in the following.
>>> CCC(
Note the extra parentheses. It would be nice if these weren't added if the object also has some other reasonable choices.

However, I don't know what would be "reasonable" here. Somehow we'd have to detect whether a callable class has static methods, possibly via dir() or directly checking class.__dict__ but at this point I am not comfortable enough with python to suggest decent solutions.


>>> class CCC:                                                                       
...   def __call__(self):
...     print "call"
...   @staticmethod
...   def f(a):
...     print "Static",a
... 
>>>CC<TAB>
>>>CCC(

----------
components: Library (Lib)
messages: 160412
nosy: wpettersson
priority: normal
severity: normal
status: open
title: Tabcompletion of classes with static methods and __call__ has extra bracket
type: behavior

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

From report at bugs.python.org  Fri May 11 17:50:13 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 May 2012 15:50:13 +0000
Subject: [New-bugs-announce] [issue14783] Update int() docstring from manual
Message-ID: <1336751413.58.0.519130225761.issue14783@psf.upfronthosting.co.za>


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

int.__doc__ starts "int(x[, base]) -> integer". That is not exactly correct as x is not required and base is only allowed if x is a string. The 3.3 manual fixes both problems with "int([number | string[, base]])"

I actually think the rest of the docstring might be replaced with the more accurate and informative manual entry. It might be condensed, but I am not sure what might be omitted.

----------
keywords: easy
messages: 160416
nosy: terry.reedy
priority: low
severity: normal
status: open
title: Update int() docstring from manual
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri May 11 21:40:16 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 May 2012 19:40:16 +0000
Subject: [New-bugs-announce] [issue14784] Re-importing _warnings changes
	warnings.filters
Message-ID: <1336765216.03.0.0611996113989.issue14784@psf.upfronthosting.co.za>


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

If you run test.test_warnings it reports that warnings.filters changed. If you comment out the import of c_warnings in that module, the warning goes away (this happens with running on tests).

It looks like _PyWarnings_Init() itself doesn't trigger a reprocessing of the sys.warnoptions as an import of warnings.py does, and thus the change in warnings.filter.

----------
components: Library (Lib)
messages: 160446
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Re-importing _warnings changes warnings.filters
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat May 12 00:40:30 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 11 May 2012 22:40:30 +0000
Subject: [New-bugs-announce] [issue14785] Add sys._debugmallocstats()
Message-ID: <1336776030.63.0.471450530302.issue14785@psf.upfronthosting.co.za>


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

I'm attaching a patch which generalizes the at-exit PYTHONMALLOCSTATS memory usage report, so that it's available in a regular build and can be triggered from Python, by calling:
   sys._debugmallocstats()

This can be useful when debugging memory usage issues: a script can call the debug hook before and after certain activities, and the before/after amounts can be compared.

The patch moves this arena-accouting code when a new arena is allocated:
     ++ntimes_arena_allocated;
     if (narenas_currently_allocated > narenas_highwater)
         narenas_highwater = narenas_currently_allocated;
from out of the #ifdef PYMALLOC_DEBUG guard and into all PYMALLOC configurations, so that this data is available within the dump.  Given how much activity happens when a new arena is allocated, I believe this doesn't impact performance.

It changes _PyObject_DebugMallocStats() to take an arbitrary FILE*, rather than assuming stderr (which was handy for my original use-case of debugging a web server).  This function is already marked with PyAPI_FUNC() but not documented (albeit only present in a debug build).

Tested with --with-pymalloc, --without-pymalloc, and --with-pydebug

FWIW, Red Hat has been using a version of this patch in RHEL 5 as of RHEL 5.6 (http://rhn.redhat.com/errata/RHSA-2011-0027.html), and also in Fedora since September 2011 with python-2.7.2-15 and python3-3.2.2-6 (for the forthcoming Fedora 17).

----------
files: add-debug-malloc-stats.patch
keywords: needs review, patch
messages: 160459
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: Add sys._debugmallocstats()
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25545/add-debug-malloc-stats.patch

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

From report at bugs.python.org  Sat May 12 10:10:08 2012
From: report at bugs.python.org (Yugang LIU)
Date: Sat, 12 May 2012 08:10:08 +0000
Subject: [New-bugs-announce] [issue14786] htmlparser with tag br
Message-ID: <1336810208.34.0.533779581931.issue14786@psf.upfronthosting.co.za>


New submission from Yugang LIU <liuyug at yahoo.cn>:

Hi,

I parse html source with htmlparser. I catch a tag, br, issue. 

my code :
<div>
aaaa<br>
</div>
parse result:
begin tag: div
begin tag: br
end tag: div

So I can't find end tag of 'br'. I know it is invalid text, '<br>', it set htmlparser parameter, strict, to 'False', it can't help me also. 

Please help fix it. Thanks.

----------
components: None
messages: 160463
nosy: liuyug
priority: normal
severity: normal
status: open
title: htmlparser with tag br
versions: Python 3.2

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

From report at bugs.python.org  Sat May 12 11:01:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 12 May 2012 09:01:11 +0000
Subject: [New-bugs-announce] [issue14787] pkgutil.walk_packages returns
	extra modules
Message-ID: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

pkgutil.walk_packages(paths) seems to return incorrect results when the name of a subpackage of a path in paths matches the name of a package in the standard library.  It both excludes modules it should include, and includes modules it should exclude.  Here is an example:

> mkdir temp
> touch temp/__init__.py
> touch temp/foo.py
> mkdir temp/logging
> touch temp/logging/__init__.py
> touch temp/logging/bar.py
> python
Python 3.2.3 (default, Apr 29 2012, 01:19:06) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

>>> from pkgutil import walk_packages
>>> for info in walk_packages(['temp']):
...   print(info[1], info[0].path)
... 
foo temp
logging temp
logging.config /opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/logging
logging.handlers /opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/logging
>>> 

Observe that logging.bar is absent from the list, and logging.config and  logging.handlers are included.

----------
components: Library (Lib)
messages: 160464
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: pkgutil.walk_packages returns extra modules
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat May 12 12:07:37 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 12 May 2012 10:07:37 +0000
Subject: [New-bugs-announce] [issue14788] Pdb debugs itself after ^C and a
	breakpoint is set	anywhere
Message-ID: <1336817257.9.0.505200749782.issue14788@psf.upfronthosting.co.za>


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

When a breakpoint is set anywhere (in which case the global system's
trace function is set), interrupting the debuggee causes Pdb to stop
into its own code. See the following pdb session run with python on
the current head of the default branch from the repo.

===   main.py   =================================
import time
def bar():
    i = 1
    while i:
        time.sleep(.100)

bar()
=================================================
$ python -m pdb main.py
> /path_to/main.py(1)<module>()
-> import time
(Pdb) import sys; print(sys.version)
3.3.0a3+ (default:4e9680570be8, May 11 2012, 12:09:15) 
[GCC 4.3.2]
(Pdb) break bar
Breakpoint 1 at /path_to/main.py:2
(Pdb) continue
> /path_to/main.py(3)bar()
-> i = 1
(Pdb) continue
^C
Program interrupted. (Use 'cont' to resume).
--Call--
> /home/xavier/src/cpython/cpython-hg-default/Lib/bdb.py(212)set_trace()
-> def set_trace(self, frame=None):
(Pdb) where
  /home/xavier/src/cpython/cpython-hg-default/Lib/bdb.py(405)run()
-> exec(cmd, globals, locals)
  <string>(1)<module>()
  /path_to/main.py(7)<module>()
-> bar()
  /path_to/main.py(5)bar()
-> time.sleep(.100)
  /home/xavier/src/cpython/cpython-hg-default/Lib/pdb.py(196)sigint_handler()
-> self.set_trace(frame)
> /home/xavier/src/cpython/cpython-hg-default/Lib/bdb.py(212)set_trace()
-> def set_trace(self, frame=None):
(Pdb) quit
=================================================


The attached patch fixes the problem and includes a test case. This
fix is the same as the one proposed at issue 14743 to fix another
problem, except that the set_step call is moved at the end of the
sigint_handler method for the sake of robustness.

----------
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 160467
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Pdb debugs itself after ^C and a breakpoint is set anywhere
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file25547/pdb_default.patch

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

From report at bugs.python.org  Sat May 12 15:54:12 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 12 May 2012 13:54:12 +0000
Subject: [New-bugs-announce] [issue14789] after continue,
	Pdb stops at a line without a breakpoint
Message-ID: <1336830852.57.0.923770658038.issue14789@psf.upfronthosting.co.za>


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

In the following test run with python on the current head of the
default branch, Pdb stops at line 3 where there is no breakpoint after
two breakpoints have been set on the same function (setting two bps on
the same location is useful, for example one bp to print a value without
stopping and the other one with an ignore count).

===   main.py   =================================
def bar():
    x = 1
    x = 2

bar()
=================================================
$ python -m pdb main.py 
> /path_to/main.py(1)<module>()
-> def bar():
(Pdb) import sys; print(sys.version)
3.3.0a3+ (default:4e9680570be8, May 11 2012, 12:09:15) 
[GCC 4.3.2]
(Pdb) break bar
Breakpoint 1 at /path_to/main.py:1
(Pdb) break bar
Breakpoint 2 at /path_to/main.py:1
(Pdb) continue
> /path_to/main.py(2)bar()
-> x = 1
(Pdb) continue
> /path_to/main.py(3)bar()
-> x = 2
(Pdb) quit
=================================================

The attached patch fixes the problem. This patch also fixes the
following problems that are caused by the same bug:

    * when more than one breakpoint is set on the same line, only the
      command of the first effective breakpoint is run, and only the
      hit count and the ignore count of the first effective breakpoint
      are updated

The patch includes a test case for all those problems.

----------
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 160470
nosy: xdegaye
priority: normal
severity: normal
status: open
title: after continue, Pdb stops at a line without a breakpoint
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25549/pdb_default.patch

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

From report at bugs.python.org  Sat May 12 18:22:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 May 2012 16:22:52 +0000
Subject: [New-bugs-announce] [issue14790] use packaging in setup.py
Message-ID: <1336839772.98.0.460402187973.issue14790@psf.upfronthosting.co.za>


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

setup.py should use packaging, not distutils.

----------
components: Build
messages: 160475
nosy: eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: use packaging in setup.py
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat May 12 18:40:43 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 May 2012 16:40:43 +0000
Subject: [New-bugs-announce] [issue14791] setup.py only adds /prefix/lib,
	not /prefix/lib64
Message-ID: <1336840843.09.0.565460268003.issue14791@psf.upfronthosting.co.za>


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

setup.py adds <prefix>/lib to the list of directories where libraries are looked for, but not <prefix>/lib64. Patch attached.

----------
components: Build
files: setup_lib64.patch
keywords: patch
messages: 160478
nosy: dmalcolm, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: setup.py only adds /prefix/lib, not /prefix/lib64
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25551/setup_lib64.patch

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

From report at bugs.python.org  Sat May 12 21:50:48 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 12 May 2012 19:50:48 +0000
Subject: [New-bugs-announce] [issue14792] setting a bp on current function,
	Pdb stops at next line although no bp
Message-ID: <1336852248.64.0.23937639047.issue14792@psf.upfronthosting.co.za>


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

Setting a breakpoint on a function from within that functions makes
pdb to stop at the following line (where no breakpoint is set) after a
continue command. In the following test pdb stops at line 3 where
there is no breakpoint.


===   main.py   =================================
def foo():
    x = 1
    x = 2

foo()
=================================================
$ python -m pdb main.py
> /path_to/main.py(1)<module>()
-> def foo():
(Pdb) import sys; print(sys.version)
3.3.0a3+ (default:4e9680570be8, May 11 2012, 12:09:15) 
[GCC 4.3.2]
(Pdb) break 2
Breakpoint 1 at /path_to/main.py:2
(Pdb) continue
> /path_to/main.py(2)foo()
-> x = 1
(Pdb) break foo
Breakpoint 2 at /path_to/main.py:1
(Pdb) continue
> /path_to/main.py(3)foo()
-> x = 2
(Pdb) where
  /home/xavier/src/cpython/cpython-hg-default/Lib/bdb.py(405)run()
-> exec(cmd, globals, locals)
  <string>(1)<module>()
  /path_to/main.py(5)<module>()
-> foo()
> /path_to/main.py(3)foo()
-> x = 2
(Pdb) quit
=================================================

The attached patch fixes the problem. The patch includes a test case.

----------
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 160489
nosy: xdegaye
priority: normal
severity: normal
status: open
title: setting a bp on current function, Pdb stops at next line although no bp
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25553/pdb_default.patch

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

From report at bugs.python.org  Sat May 12 23:53:07 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 12 May 2012 21:53:07 +0000
Subject: [New-bugs-announce] [issue14793] broken grammar in Built-in Types
	doc
Message-ID: <1336859587.23.0.399081915323.issue14793@psf.upfronthosting.co.za>


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


----------
assignee: docs at python
components: Documentation
files: grammar.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: broken grammar in Built-in Types doc
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25554/grammar.diff

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

From report at bugs.python.org  Sun May 13 00:51:38 2012
From: report at bugs.python.org (Paul Upchurch)
Date: Sat, 12 May 2012 22:51:38 +0000
Subject: [New-bugs-announce] [issue14794] slice.indices raises OverflowError
Message-ID: <1336863098.54.0.753598684211.issue14794@psf.upfronthosting.co.za>


New submission from Paul Upchurch <paulup at gmail.com>:

To reproduce the error:

Python 3.2.2 (default, Sep  5 2011, 22:09:30) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> slice(0,90000,None).indices(12600000000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: cannot fit 'int' into an index-sized integer
>>> 

The correct behaviour is to return (0, 90000, 1).

>>> slice(0,90000,None).indices(600000000)
(0, 90000, 1)

This is related to http://bugs.python.org/issue1456470.

----------
components: Interpreter Core
messages: 160500
nosy: Paul.Upchurch
priority: normal
severity: normal
status: open
title: slice.indices raises OverflowError
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun May 13 17:25:56 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 13 May 2012 15:25:56 +0000
Subject: [New-bugs-announce] [issue14795] Pdb incorrectly handles a method
	breakpoint when module	not imported
Message-ID: <1336922756.85.0.281707317817.issue14795@psf.upfronthosting.co.za>


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

In the following test, breakpoint 2 is set incorrectly at line 1 and
pdb does not know how to set a breakpoint on method C.c_foo. However
setting those two breakpoints on both methods is ok after the class
definition has been executed.


===   main.py   =================================
def foo():
    pass

class C:
    def c_foo(self):
        pass
    def foo(self):
        pass

foo()
=================================================
$ python3.1 -m pdb main.py
> /path_to/main.py(1)<module>()
-> def foo():
(Pdb) import sys; print(sys.version)
3.1.2 (r312:79147, Apr  4 2010, 17:46:48) 
[GCC 4.3.2]
(Pdb) break foo
Breakpoint 1 at /path_to/main.py:1
(Pdb) break C.foo
Breakpoint 2 at /path_to/main.py:1
(Pdb) break C.c_foo
*** The specified object 'C.c_foo' is not a function
or was not found along sys.path.
(Pdb) break 10
Breakpoint 3 at /path_to/main.py:10
(Pdb) continue
> /path_to/main.py(10)<module>()
-> foo()
(Pdb) break C.foo
Breakpoint 4 at /path_to/main.py:7
(Pdb) break C.c_foo
Breakpoint 5 at /path_to/main.py:5
(Pdb) quit
=================================================

The attached patch fixes the problem. The patch includes a test case.

----------
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 160517
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Pdb incorrectly handles a method breakpoint when module not imported
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25560/pdb_default.patch

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

From report at bugs.python.org  Sun May 13 18:06:11 2012
From: report at bugs.python.org (Oleg Plakhotnyuk)
Date: Sun, 13 May 2012 16:06:11 +0000
Subject: [New-bugs-announce] [issue14796] Calendar module test coverage
	improved
Message-ID: <1336925171.3.0.599615693844.issue14796@psf.upfronthosting.co.za>


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

I've improved calendar.py test coverage a bit.

Before:
  410    71%   calendar   (.../Lib/calendar.py)
After:
  410    77%   calendar   (.../Lib/calendar.py)

----------
components: Tests
files: test_calendar.patch
keywords: patch
messages: 160519
nosy: Oleg.Plakhotnyuk, giampaolo.rodola, ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Calendar module test coverage improved
versions: Python 3.3
Added file: http://bugs.python.org/file25562/test_calendar.patch

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

From report at bugs.python.org  Sun May 13 18:32:09 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 May 2012 16:32:09 +0000
Subject: [New-bugs-announce] [issue14797] Deprecate
	imp.find_module()/load_module()
Message-ID: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za>


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

With importlib.find_loader() now implemented, imp.find_module() (and its companion, imp.load_module()) can go away and stop inflicting their bad API upon the world.

The trick, though, is fixing code that uses the API. That means pkgutil, multiprocessing.forking, modulefinder, and idlelib.EditorWindow all need to be patched to stop using imp.find_module()/load_module().

----------
components: Library (Lib)
messages: 160522
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate imp.find_module()/load_module()
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun May 13 18:39:00 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 13 May 2012 16:39:00 +0000
Subject: [New-bugs-announce] [issue14798] pyclbr raises KeyError when the
	prefix of a dotted name	is not a package
Message-ID: <1336927140.56.0.342713229106.issue14798@psf.upfronthosting.co.za>


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

pyclbr must raise ImportError instead of KeyError.
The attached patch fixes the problem. A test case is included.

----------
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 160523
nosy: xdegaye
priority: normal
severity: normal
status: open
title: pyclbr raises KeyError when the prefix of a dotted name is not a package
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25563/pdb_default.patch

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

From report at bugs.python.org  Sun May 13 20:55:43 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 13 May 2012 18:55:43 +0000
Subject: [New-bugs-announce] [issue14799] Tkinter ttk tests hang on linux
Message-ID: <1336935343.12.0.855604727116.issue14799@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

By default python doesn't run full test suite, but regrtest accepts -u parameter. The simplest way to reproduce is:

$ ./python -m test.regrtest -u gui test_ttk_guionly

----------
components: Tkinter
messages: 160547
nosy: asvetlov
priority: critical
severity: normal
status: open
title: Tkinter ttk tests hang on linux
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon May 14 01:53:45 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 13 May 2012 23:53:45 +0000
Subject: [New-bugs-announce] [issue14800] stat.py constant comments +
	docstrings
Message-ID: <1336953225.33.0.233761576766.issue14800@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As per:
http://mail.python.org/pipermail/python-ideas/2012-May/015112.html

----------
files: stat-comments.patch
keywords: patch
messages: 160584
nosy: giampaolo.rodola, terry.reedy
priority: normal
severity: normal
status: open
title: stat.py constant comments + docstrings
Added file: http://bugs.python.org/file25569/stat-comments.patch

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

From report at bugs.python.org  Mon May 14 02:13:34 2012
From: report at bugs.python.org (Peter Marheine)
Date: Mon, 14 May 2012 00:13:34 +0000
Subject: [New-bugs-announce] [issue14801] ssize_t where size_t expected
Message-ID: <1336954414.18.0.61439717267.issue14801@psf.upfronthosting.co.za>


New submission from Peter Marheine <taricorp at gmail.com>:

Cross-compiling the interpreter for a system without a definition for ssize_t fails in PyType_FromSpec (Object/typeobject.c:2380 in the 3.2.3 release, line 2409 in hg 6b8f34a1cb22).

It appears the type of len should be corrected to size_t to match the signatures of strlen and memcpy.  This fixes the compilation error.

----------
components: Interpreter Core
messages: 160585
nosy: tari
priority: normal
severity: normal
status: open
title: ssize_t where size_t expected
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Mon May 14 05:57:25 2012
From: report at bugs.python.org (Minmin Gong)
Date: Mon, 14 May 2012 03:57:25 +0000
Subject: [New-bugs-announce] [issue14802] Python 3.2 fail to compile with
	VC11 ARM configuration
Message-ID: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za>


New submission from Minmin Gong <minmin.gong at gmail.com>:

Windows ARM doesn't support full win32 api, e.g. no registry and winsock. So the python fail to compile with VC11 beta in ARM configuration.

----------
components: Interpreter Core
messages: 160593
nosy: Minmin.Gong
priority: normal
severity: normal
status: open
title: Python 3.2 fail to compile with VC11 ARM configuration
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Mon May 14 09:43:39 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 May 2012 07:43:39 +0000
Subject: [New-bugs-announce] [issue14803] Add -C option to run code at
	Python startup
Message-ID: <1336981419.55.0.280530546632.issue14803@psf.upfronthosting.co.za>


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

Reading http://nedbatchelder.com/code/coverage/subprocess.html, it occurred to me that there are various tracing and profiling operations that could be cleanly handled with significantly less work on the part of the tracing/profiling tool authors if the interpreter supported a "-C" operation that was like the existing "-c" option, but *didn't* terminate the options list.

The interpreter would invoke such commands after the interpreter is fully initialised, but before it begins the processing to find and execute __main__.

Then, to use subprocess coverage with coverage.py as an example, you could just run a command like:

"python -C 'import coverage; coverage.process_startup()' worker.py"

Other things you could usefully do in such an invocation is reconfigure sys.std(in|out|err) to match the settings used on the invoking side (e.g. to ensure Unicode data is tunnelled correctly), configure the logging module with a custom configuration, configure the warnings module programmatically, enable a memory profiler, etc.

Providing a function that could be called from -C and then uses an atexit() handler to do any necessary post-processing may be significantly simpler than trying to use runpy.run_(path|module) to achieve a similar effect.

----------
messages: 160597
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add -C option to run code at Python startup

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

From report at bugs.python.org  Mon May 14 11:46:59 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 14 May 2012 09:46:59 +0000
Subject: [New-bugs-announce] [issue14804] Wrong defaults args notation in
	docs
Message-ID: <1336988819.38.0.761185643873.issue14804@psf.upfronthosting.co.za>


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

After having been called out on wrong default arg notation in one of my patches (eg. function:: copyfile(src, dst[, symlinks=False])), I've done a "grep -RPi "\[\w+=" Doc/library" and fixed the cases I've found ? many of them sadly from myself (all the symlinks=False ones). ;)

The patch is against tip, I'd back port it to 3.2 if the contents is okay (and do it for 2.7 too, there's a lot of this errors there, I suppose docs fixes are okay for 2.7?).

----------
assignee: docs at python
components: Documentation
files: doc-default-args.diff
keywords: patch
messages: 160599
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, hynek
priority: low
severity: normal
stage: patch review
status: open
title: Wrong defaults args notation in docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25573/doc-default-args.diff

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

From report at bugs.python.org  Mon May 14 14:00:39 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 May 2012 12:00:39 +0000
Subject: [New-bugs-announce] [issue14805] Support display of both __cause__
	and __context__
Message-ID: <1336996839.56.0.43377861765.issue14805@psf.upfronthosting.co.za>


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

With PEP 415 accepted as the implementation of the "raise exc from None" syntax, it raises the prospect of exceptions with both __cause__ and __context__ set to non-None values, and __suppress_context__ set to False.

The initial PEP 415 patch treats this case the same way PEP 409 did: it ignores __context__ if *either* __cause__ is not None *or* __suppress_context__ is True.

This issue proposes that at least the default exception display routine and the display routine in the traceback module be updated to display the __context__ any time __suppress_context__ is False, even if __cause__ is also non-None.

----------
components: Interpreter Core, Library (Lib)
messages: 160609
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Support display of both __cause__ and __context__
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon May 14 14:50:28 2012
From: report at bugs.python.org (zk)
Date: Mon, 14 May 2012 12:50:28 +0000
Subject: [New-bugs-announce] [issue14806] re.match does not match word '{'
Message-ID: <1336999828.05.0.573587450355.issue14806@psf.upfronthosting.co.za>


New submission from zk <bsnxff at gmail.com>:

>>> type(re.match('{', 'aaaa{'))
<type 'NoneType'>
>>> type(re.match('\{', 'aaaa{'))
<type 'NoneType'>
>>> type(re.search('\{', 'aaaa{'))
<type '_sre.SRE_Match'>
>>> type(re.search('{', 'aaaa{'))
<type '_sre.SRE_Match'>

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 160615
nosy: zk
priority: normal
severity: normal
status: open
title: re.match does not match word '{'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon May 14 15:04:38 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 14 May 2012 13:04:38 +0000
Subject: [New-bugs-announce] [issue14807] Move tarfile.filemode() into stat
	module
Message-ID: <1337000678.3.0.189462567372.issue14807@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As per:
http://mail.python.org/pipermail/python-ideas/2012-May/015104.html
Patch is in attachment.

----------
components: Library (Lib)
files: filemode.patch
keywords: easy, patch
messages: 160621
nosy: giampaolo.rodola, terry.reedy
priority: normal
severity: normal
status: open
title: Move tarfile.filemode() into stat module
versions: Python 3.3
Added file: http://bugs.python.org/file25577/filemode.patch

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

From report at bugs.python.org  Mon May 14 17:36:59 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 14 May 2012 15:36:59 +0000
Subject: [New-bugs-announce] [issue14808] Pdb does not stop at a breakpoint
	set on the line of a	function definition
Message-ID: <1337009819.22.0.0422011129239.issue14808@psf.upfronthosting.co.za>


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

In the following test both breakpoints are set on the line of a
function definition. However pdb does not stop when entering foo whose
breakpoint has been set with 'break 1' while pdb stops when entering
bar whose breakpoint has been set with 'break bar'. The breakpoint
table display is identical for both breakpoints. This is inconsistent
and confusing.


===   main.py  ==================================
1  def foo():
2      pass
3
4  def bar():
5      pass
6
7  def main():
8      foo()
9      bar()
10
11  import pdb; pdb.runcall(main)
=================================================
$ python main.py
> /path_to/main.py(8)main()
-> foo()
(Pdb) break 1
Breakpoint 1 at /path_to/main.py:1
(Pdb) break bar
Breakpoint 2 at /path_to/main.py:4
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /path_to/main.py:1
2   breakpoint   keep yes   at /path_to/main.py:4
(Pdb) continue
> /path_to/main.py(5)bar()
-> pass
(Pdb) continue
$
=================================================


The reverse occurs in the following test where pdb stops only at the
execution of the function definition when the breakpoint has been set
with a line number.

===   main.py  ==================================
 1  x = 1
 2
 3  def foo():
 4      pass
 5
 6  def bar():
 7      pass
 8
 9  x = 2
=================================================
$ python -m pdb main.py
> /path_to/main.py(1)<module>()
-> x = 1
(Pdb) break 3
Breakpoint 1 at /path_to/main.py:3
(Pdb) break bar
Breakpoint 2 at /path_to/main.py:6
(Pdb) break 9
Breakpoint 3 at /path_to/main.py:9
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /path_to/main.py:3
2   breakpoint   keep yes   at /path_to/main.py:6
3   breakpoint   keep yes   at /path_to/main.py:9
(Pdb) continue
> /path_to/main.py(3)<module>()
-> def foo():
(Pdb) continue
> /path_to/main.py(9)<module>()
-> x = 2
(Pdb)
=================================================


The following patch fixes both inconsistencies by having pdb stop when
entering a function and at the execution of a definition whatever the
method used to set the breakpoint (line number or function name).

Two test cases are included in the patch.

----------
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 160629
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Pdb does not stop at a breakpoint set on the line of a function definition
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25578/pdb_default.patch

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

From report at bugs.python.org  Mon May 14 20:01:12 2012
From: report at bugs.python.org (EungJun Yi)
Date: Mon, 14 May 2012 18:01:12 +0000
Subject: [New-bugs-announce] [issue14809] Add HTTP status codes introduced
	by RFC 6585
Message-ID: <1337018472.12.0.402228310257.issue14809@psf.upfronthosting.co.za>


New submission from EungJun Yi <semtlenori at gmail.com>:

This patch add HTTP status codes introduced by RFC 6585, to http.client and http.server.

428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
511 Network Authentication Required

----------
components: Library (Lib)
files: rfc6585.patch
keywords: patch
messages: 160651
nosy: EungJun.Yi
priority: normal
severity: normal
status: open
title: Add HTTP status codes introduced by RFC 6585
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25582/rfc6585.patch

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

From report at bugs.python.org  Tue May 15 01:48:28 2012
From: report at bugs.python.org (Hans Werner May)
Date: Mon, 14 May 2012 23:48:28 +0000
Subject: [New-bugs-announce] [issue14810] Bug in tarfile
Message-ID: <1337039308.77.0.231194182342.issue14810@psf.upfronthosting.co.za>


New submission from Hans Werner May <nc-mayha2 at netcologne.de>:

Bug in tarfile:

In extractall, when a file exists in tarball with changetime older than (I don't know, in my case it was year 1956) tarfile raises an Overflow exception:

  File "/usr/lib64/python2.7/tarfile.py", line 2298, in utime
    os.utime(targetpath, (tarinfo.mtime, tarinfo.mtime))
OverflowError: Python int too large to convert to C long

System: Mageia 1.0
Python version: 2.7.1

----------
messages: 160674
nosy: hwm
priority: normal
severity: normal
status: open
title: Bug in tarfile
versions: Python 2.7

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

From report at bugs.python.org  Tue May 15 06:31:40 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 15 May 2012 04:31:40 +0000
Subject: [New-bugs-announce] [issue14811] compile fails - UTF-8 character
	decoding
Message-ID: <1337056300.81.0.374626607094.issue14811@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

t33a.py demonstrates a compilation problem.  OK, it has a long line, but making it one space longer (add a space after the left parenthesis) makes it work... so it must not be line length alone.  Rather, since the error is about a bad UTF-8 character starting with \xc3, it seems that the UTF-8 decoder might play a role.  I was surprised that I could reduce the test case by removing all the lines before and after these 3: the original failure was in a much longer file to which I added this line.

Originally detected in 3.2.2, I upgraded to 3.2.3 and the problem still occurred.

----------
components: Interpreter Core
files: t33a.py
messages: 160679
nosy: v+python
priority: normal
severity: normal
status: open
title: compile fails - UTF-8 character decoding
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file25593/t33a.py

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

From report at bugs.python.org  Tue May 15 06:44:46 2012
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 15 May 2012 04:44:46 +0000
Subject: [New-bugs-announce] [issue14812] Change file associations to not be
	a default installer	feature
Message-ID: <1337057086.06.0.157566935456.issue14812@psf.upfronthosting.co.za>


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

With the addition of #3561, I think we might want to have the file association feature follow it in not being a default feature. It seems a bit off that we don't want to change the way "python" reacts on the command line by default, but we do want to change the way "script.py" reacts by default.

----------
components: Installation
messages: 160681
nosy: brian.curtin, loewis
priority: normal
severity: normal
status: open
title: Change file associations to not be a default installer feature
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue May 15 12:21:03 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 May 2012 10:21:03 +0000
Subject: [New-bugs-announce] [issue14813] Can't build under VS2008 anymore
Message-ID: <1337077263.22.0.0914534373529.issue14813@psf.upfronthosting.co.za>


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

I tried to build PC/VS9.0/pcbuild.sln using Visual Studio 2008, but it failed:

1>------ Build started: Project: make_buildinfo, Configuration: Release Win32 ------
2>------ Build started: Project: kill_python, Configuration: Debug x64 ------
2>Compiling...
1>Compiling...
2>kill_python.c
1>make_buildinfo.c
2>c1 : fatal error C1083: Cannot open source file: '.\kill_python.c': No such file or directory
1>c1 : fatal error C1083: Cannot open source file: '.\make_buildinfo.c': No such file or directory
2>Build log was saved at "file://Z:\default\PC\VS9.0\x64-temp-Debug\kill_python\BuildLog.htm"
2>kill_python - 1 error(s), 0 warning(s)
1>Build log was saved at "file://Z:\default\PC\VS9.0\Win32-temp-Release\make_buildinfo\BuildLog.htm"
1>make_buildinfo - 1 error(s), 0 warning(s)
3>------ Build started: Project: make_versioninfo, Configuration: Debug Win32 ------
4>------ Build started: Project: w9xpopen, Configuration: Debug x64 ------
3>Compiling...
4>Compiling...
3>make_versioninfo.c
4>w9xpopen.c
3>c1 : fatal error C1083: Cannot open source file: '..\PC\make_versioninfo.c': No such file or directory
4>c1 : fatal error C1083: Cannot open source file: '..\PC\w9xpopen.c': No such file or directory
3>Build log was saved at "file://Z:\default\PC\VS9.0\Win32-temp-Debug\make_versioninfo\BuildLog.htm"
3>make_versioninfo - 1 error(s), 0 warning(s)
4>Build log was saved at "file://Z:\default\PC\VS9.0\x64-temp-Debug\w9xpopen\BuildLog.htm"
4>w9xpopen - 1 error(s), 0 warning(s)
5>------ Build started: Project: pythoncore, Configuration: Debug x64 ------
5>Compiling...
5>traceback.c
5>c1 : fatal error C1083: Cannot open source file: '..\Python\traceback.c': No such file or directory
5>thread.c
5>c1 : fatal error C1083: Cannot open source file: '..\Python\thread.c': No such file or directory
5>sysmodule.c
[etc.]

----------
assignee: brian.curtin
components: Build
messages: 160704
nosy: brian.curtin, loewis, pitrou
priority: release blocker
severity: normal
status: open
title: Can't build under VS2008 anymore
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Tue May 15 14:00:08 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 May 2012 12:00:08 +0000
Subject: [New-bugs-announce] [issue14814] Implement PEP 3144 (the ipaddress
	module)
Message-ID: <1337083208.87.0.892191662466.issue14814@psf.upfronthosting.co.za>


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

This issue tracks the incorporation of the ipaddress module into Python 3.3.

Tasks to be completed:
- add Lib/ipaddress.py from [1]
- add Lib/test_ipaddress.py from [1]
- create module reference docs from docstrings in [1]
- add Doc/library/ipaddress.py and link from index
- create howto guide from wiki page [2]
- add Doc/howto/ipaddress.rst and link from index

[1] https://code.google.com/p/ipaddress-py/source/browse/

[2] https://code.google.com/p/ipaddr-py/wiki/Using3144

----------
components: Library (Lib)
messages: 160719
nosy: ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Implement PEP 3144 (the ipaddress module)
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue May 15 14:23:03 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 15 May 2012 12:23:03 +0000
Subject: [New-bugs-announce] [issue14815] random_seed uses only 32-bits of
	hash on Win64
Message-ID: <1337084583.39.0.478373351813.issue14815@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

random_seed has this code:

  long hash = PyObject_Hash(arg);

On Win64, Py_hash_t is a 64-bit type, yet long is a 32-bit type, so this truncates. I think the computation should be done in Py_ssize_t.

----------
messages: 160720
nosy: loewis
priority: normal
severity: normal
status: open
title: random_seed uses only 32-bits of hash on Win64

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

From report at bugs.python.org  Tue May 15 14:34:54 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 May 2012 12:34:54 +0000
Subject: [New-bugs-announce] [issue14816] compilation failed on Ubuntu
	shared buildbot
Message-ID: <1337085294.51.0.758788785088.issue14816@psf.upfronthosting.co.za>


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

See http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x

First failing build is http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/5955

----------
components: Build
messages: 160721
nosy: benjamin.peterson, db3l, pitrou
priority: release blocker
severity: normal
status: open
title: compilation failed on Ubuntu shared buildbot
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue May 15 21:19:00 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 15 May 2012 19:19:00 +0000
Subject: [New-bugs-announce] [issue14817] pkgutil.extend_path has no tests
Message-ID: <1337109540.72.0.0262382182113.issue14817@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

Subject says it all.

There are also no tests of .pkg files.

----------
components: Tests
keywords: easy
messages: 160751
nosy: eric.smith
priority: normal
severity: normal
status: open
title: pkgutil.extend_path has no tests

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

From report at bugs.python.org  Tue May 15 21:43:37 2012
From: report at bugs.python.org (Markus)
Date: Tue, 15 May 2012 19:43:37 +0000
Subject: [New-bugs-announce] [issue14818] C implementation of ElementTree
	causes regressions
Message-ID: <1337111017.73.0.312411341121.issue14818@psf.upfronthosting.co.za>


New submission from Markus <common at gmx.ch>:

The C implementation of ElementTree which is the default by python3.3 [1] does not accept the namespaces keyword for Element/ElementTree.find(all|iter|...) and maybe others.


[1] http://bugs.python.org/issue13988

----------
components: Library (Lib)
messages: 160753
nosy: cmn
priority: normal
severity: normal
status: open
title: C implementation of ElementTree causes regressions
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue May 15 23:13:15 2012
From: report at bugs.python.org (Patrick Smith)
Date: Tue, 15 May 2012 21:13:15 +0000
Subject: [New-bugs-announce] [issue14819] Add `assertIsSubclass` and
	`assertNotIsSubclass` to	`unittest.TestCase`
Message-ID: <1337116395.1.0.710278359687.issue14819@psf.upfronthosting.co.za>


New submission from Patrick Smith <pjs482 at gmail.com>:

The attached patch adds two helper methods to `unittest.TestCase`: `assertIsSubclass` and `assertIsNotSubclass`. These methods are similar to the `assertIsInstance` and `assertIsNotInstance` methods that are already part of `unittest.TestCase`. They allow one to test if a class is a subclass of another class using the `issubclass` builtin.

These methods can be used like:
    self.assertIsSubclass(cls, parent_cls)

These new methods provide a nicer error message and more consistent interface over the alternatives:
    self.assertTrue(issubclass(cls, parent_cls))
    assert issubclass(cls, parent_cls)

----------
components: Library (Lib)
files: assertissubclass.patch
keywords: patch
messages: 160762
nosy: patricksmith
priority: normal
severity: normal
status: open
title: Add `assertIsSubclass` and `assertNotIsSubclass` to `unittest.TestCase`
type: enhancement
Added file: http://bugs.python.org/file25600/assertissubclass.patch

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

From report at bugs.python.org  Wed May 16 01:41:37 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 15 May 2012 23:41:37 +0000
Subject: [New-bugs-announce] [issue14820] socket._decref_socketios and close
Message-ID: <1337125297.57.0.501342584096.issue14820@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Don't know the details but this condition looks wrong:
http://hg.python.org/cpython/file/cdcc816dea85/Lib/socket.py#l190

----------
messages: 160777
nosy: giampaolo.rodola, janssen
priority: normal
severity: normal
status: open
title: socket._decref_socketios and close

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

From report at bugs.python.org  Wed May 16 02:10:12 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 16 May 2012 00:10:12 +0000
Subject: [New-bugs-announce] [issue14821] Ctypes extension module builds as
	_ctypes_test.pyd
Message-ID: <1337127012.18.0.0921516678157.issue14821@psf.upfronthosting.co.za>


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

It appears with the latest changes (cdcc816dea85), ctypes builds as _ctypes_test.pyd, not _ctypes.pyd. This causes 'import ctypes' to fail with an ImportError and thus causes tests to fail that depend on test.support (which imports ctypes).

I first noticed this issue in features/pep-420, but the same behavior is present in the main repository. I cannot test it because Python fails to start altogether, but I see _ctypes_test.pyd in the pcbuild/amd64 directory.

----------
assignee: brian.curtin
components: Build
messages: 160780
nosy: brian.curtin, jason.coombs
priority: normal
severity: normal
status: open
title: Ctypes extension module builds as _ctypes_test.pyd
versions: Python 3.3

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

From report at bugs.python.org  Wed May 16 02:26:11 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 16 May 2012 00:26:11 +0000
Subject: [New-bugs-announce] [issue14822] Build unusable when compiled for
	Win 64-bit release
Message-ID: <1337127971.41.0.27312753813.issue14822@psf.upfronthosting.co.za>


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

It appears that sometime between 64b695a6cc3d and cdcc816dea85, the Windows x64 Release build is no longer viable. It crashes when invoking the importer.

----------
components: Build, Windows
messages: 160782
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: Build unusable when compiled for Win 64-bit release
versions: Python 3.3

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

From report at bugs.python.org  Wed May 16 02:49:17 2012
From: report at bugs.python.org (Q)
Date: Wed, 16 May 2012 00:49:17 +0000
Subject: [New-bugs-announce] [issue14823] Simplify threading.Lock.acquire()
	description
Message-ID: <1337129357.09.0.399271723054.issue14823@psf.upfronthosting.co.za>


New submission from Q <abonent at gmail.com>:

Hi there,

I suggest to improve the description of Lock.acquire()
[ http://docs.python.org/library/threading.html#threading.Lock.acquire ]
in the following way:

>>>>> current version >>>>>
Lock.acquire([blocking])

   Acquire a lock, blocking or non-blocking.

   When invoked without arguments, block until the lock is unlocked,
   then set it to locked, and return true.

   When invoked with the *blocking* argument set to true, do the same
   thing as when called without arguments, and return true.

   When invoked with the *blocking* argument set to false, do not
   block.  If a call without an argument would block, return false
   immediately; otherwise, do the same thing as when called without
   arguments, and return true.

<<<<< current version <<<<<


>>>>> suggested version >>>>>
Lock.acquire([blocking])

   Acquire a lock, blocking or non-blocking.

   When invoked with the *blocking* argument set to true 
   (the default), block until the lock is unlocked, 
   then set it to locked, and return true.

   When invoked with the *blocking* argument set to false, do not
   block.  If a call without an argument would block, return false
   immediately; otherwise, set the lock to locked, and return true.

<<<<< suggested version <<<<<

The idea is to simplify the structure of the explanation: get rid of an unnecessary "goto" -- "do the same thing as" as well as the extra branching ("when invoked without arguments" ... "when invoked with *blocking* argument set to true") .

The suggested patch for the text version of the documentation ( http://docs.python.org/download.html -> http://docs.python.org/archives/python-2.7.3-docs-text.tar.bz2 ) is attached. 

PS. I did not dare to capitalize the boolean variables ("true" -> "True") to adhere to the general style of the document (obviously inherited from Java). For the same reason I didn't either change the argument signature from "[blocking]" to "[blocking=True]".

----------
assignee: docs at python
components: Documentation
files: threading.txt.patch
keywords: patch
messages: 160786
nosy: docs at python, thread13
priority: normal
severity: normal
status: open
title: Simplify threading.Lock.acquire() description
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file25604/threading.txt.patch

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

From report at bugs.python.org  Wed May 16 07:52:24 2012
From: report at bugs.python.org (Jasper St. Pierre)
Date: Wed, 16 May 2012 05:52:24 +0000
Subject: [New-bugs-announce] [issue14824] reprlib documentation references
	string module
Message-ID: <1337147544.42.0.726566417701.issue14824@psf.upfronthosting.co.za>


New submission from Jasper St. Pierre <jstpierre at mecheye.net>:

http://docs.python.org/dev/library/reprlib.html

"""
Formatting methods for specific types are implemented as methods with a name based on the type name. In the method name, TYPE is replaced by string.join(string.split(type(obj).__name__, '_')). Dispatch to these methods is handled by repr1(). Type-specific methods which need to recursively format a value should call self.repr1(subobj, level - 1).
"""

Outstanding.

----------
assignee: docs at python
components: Documentation
messages: 160805
nosy: docs at python, magcius
priority: normal
severity: normal
status: open
title: reprlib documentation references string module
versions: Python 3.4

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

From report at bugs.python.org  Wed May 16 08:08:44 2012
From: report at bugs.python.org (Marcelo Delgado)
Date: Wed, 16 May 2012 06:08:44 +0000
Subject: [New-bugs-announce] [issue14825] Interactive Shell vs Executed code
Message-ID: <1337148524.71.0.147542533467.issue14825@psf.upfronthosting.co.za>


New submission from Marcelo Delgado <mardelmi at gmail.com>:

I have found inconsistency between running this code in the interactive shell and running it from a file:

Int. Shell:
n**0 ## n is a negative number
result: -1

File:
n**0 ## n is a negative number
result: 1

I am fairly new to Python, so I don't know what result should be the correct one, but if thit IS a mistake i would prefer the result of the Int. Shell :)

----------
components: Regular Expressions
messages: 160806
nosy: Marcelo.Delgado, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Interactive Shell vs Executed code
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed May 16 10:54:33 2012
From: report at bugs.python.org (Wichert Akkerman)
Date: Wed, 16 May 2012 08:54:33 +0000
Subject: [New-bugs-announce] [issue14826] urllib2.urlopen fails to load URL
Message-ID: <1337158473.64.0.398540003062.issue14826@psf.upfronthosting.co.za>


New submission from Wichert Akkerman <wichert at wiggy.net>:

There appears to be an odd networking issue with how urllib2 sends HTTP requests. Downloading an image from maw.liquifire.com gives an error:

$ python -c 'import urllib2 ; urllib2.urlopen("http://maw.liquifire.com/maw?set=image[2302.000.13314 a]&call=url[file:325x445]")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1207, in http_open
    return self.do_open(httplib.HTTPConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1180, in do_open
    r = h.getresponse(buffering=True)
  File "/usr/lib/python2.7/httplib.py", line 1030, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline()
  File "/usr/lib/python2.7/socket.py", line 447, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: [Errno 104] Connection reset by peer

Downloading the same image using wget works fine:

$ wget 'http://maw.liquifire.com/maw?set=image[2302.000.13314 a]&call=url[file:325x445]'             
--2012-05-16 10:53:27--  http://maw.liquifire.com/maw?set=image[2302.000.13314%20a]&call=url[file:325x445]
Resolving maw.liquifire.com (maw.liquifire.com)... 184.169.78.6
Connecting to maw.liquifire.com (maw.liquifire.com)|184.169.78.6|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11393 (11K) [image/jpeg]
Saving to: `maw?set=image[2302.000.13314 a]&call=url[file:325x445]'

100%[======================================>] 11,393      --.-K/s   in 0.003s  

2012-05-16 10:53:27 (3.49 MB/s) - `maw?set=image[2302.000.13314 a]&call=url[file:325x445]' saved [11393/11393]

----------
components: Library (Lib)
messages: 160811
nosy: wichert
priority: normal
severity: normal
status: open
title: urllib2.urlopen fails to load URL
versions: Python 2.7

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

From report at bugs.python.org  Wed May 16 11:51:08 2012
From: report at bugs.python.org (Julien Pecqueur)
Date: Wed, 16 May 2012 09:51:08 +0000
Subject: [New-bugs-announce] [issue14827] IDLE crash when typing ^ character
	on Mac OS X
Message-ID: <1337161868.62.0.43738376309.issue14827@psf.upfronthosting.co.za>


New submission from Julien Pecqueur <jpec80 at gmail.com>:

IDLE crash when i type the character ^ (for example writing "?" in a comment).

I have the crash only on Mac OS X (Mac OS X 64-bit/32-bit Installer (3.2.3) for Mac OS X 10.6 and 10.7).

I don't have this crash on Linux.

----------
components: IDLE
messages: 160821
nosy: JPEC
priority: normal
severity: normal
status: open
title: IDLE crash when typing ^ character on Mac OS X
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Wed May 16 11:51:34 2012
From: report at bugs.python.org (Jiba)
Date: Wed, 16 May 2012 09:51:34 +0000
Subject: [New-bugs-announce] [issue14828] itertools.groupby not working as
	expected
Message-ID: <1337161894.62.0.255300061013.issue14828@psf.upfronthosting.co.za>


New submission from Jiba <jibalamy at free.fr>:

In some situation, itertools.groupby fails to group the objects, and produces several groups with the same key. For example, the following code :


from itertools import *

class P(object):
  def __init__(self, key):
    self.key = key

p1 = P(1)
p2 = P(2)
p3 = P(1)

for key, ps in groupby([p1, p2, p3], lambda p: p.key):
  print "group", key
  for p in ps:
    print "  - object", p


Produces the following result :

group 1
  - object <__main__.P object at 0xb73d6acc>
group 2
  - object <__main__.P object at 0xb73d6aec>
group 1
  - object <__main__.P object at 0xb73d6b0c>


While I would expect to have only a single group 1, e.g. something like :

group 1
  - object <__main__.P object at 0xb73d6acc>
  - object <__main__.P object at 0xb73d6b0c>
group 2
  - object <__main__.P object at 0xb73d6aec>


It seems that this bug also affects Python 3 (tested on Python 3.1.2)

----------
components: Library (Lib)
messages: 160822
nosy: Jiba
priority: normal
severity: normal
status: open
title: itertools.groupby not working as expected
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 16 14:16:51 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 May 2012 12:16:51 +0000
Subject: [New-bugs-announce] [issue14829] test_bisect failure under 64-bit
	Windows
Message-ID: <1337170611.04.0.0622192428475.issue14829@psf.upfronthosting.co.za>


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

Shows that we lack such a buildbot...

======================================================================
FAIL: test_large_range (test.test_bisect.TestBisectC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\default\lib\test\test_bisect.py", line 129, in test_large_range
    self.assertEqual(mod.bisect_left(data, sys.maxsize-3), sys.maxsize-3)
AssertionError: 4294967294 != 9223372036854775804

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

----------
components: Library (Lib), Tests
messages: 160843
nosy: brian.curtin, mark.dickinson, pitrou
priority: high
severity: normal
status: open
title: test_bisect failure under 64-bit Windows
type: behavior

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

From report at bugs.python.org  Wed May 16 15:00:23 2012
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 16 May 2012 13:00:23 +0000
Subject: [New-bugs-announce] [issue14830] pysetup fails on non-ascii
	filenames
Message-ID: <1337173223.03.0.957024451663.issue14830@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Pyramid contains this file: pyramid/tests/fixtures/static/h\xc3\xa9h\xc3\xa9.html

and "pysetup install pyramid" chokes on it when creating the RECORD file, because the csv writer is given a wrong encoded value in util._write_record_file.

The record file orginally created by the install command seem to be in the wrong encoding

----------
assignee: eric.araujo
components: Distutils2
messages: 160856
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: pysetup fails on non-ascii filenames
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May 16 16:52:25 2012
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 16 May 2012 14:52:25 +0000
Subject: [New-bugs-announce] [issue14831] make r argument on
	itertools.combinations() optional
Message-ID: <1337179945.38.0.530735334307.issue14831@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

I'm not sure why this is allowed for permutations() but not combinations().

----------
messages: 160874
nosy: djc
priority: normal
severity: normal
status: open
title: make r argument on itertools.combinations() optional

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

From report at bugs.python.org  Wed May 16 18:47:49 2012
From: report at bugs.python.org (Kylotan)
Date: Wed, 16 May 2012 16:47:49 +0000
Subject: [New-bugs-announce] [issue14832] unittest's assertItemsEqual()
	method gives wrong order	in error output
Message-ID: <1337186869.36.0.510625348307.issue14832@psf.upfronthosting.co.za>


New submission from Kylotan <kylotan at gmail.com>:

I have the following line in a unit test in 2.7.3:

    self.assertItemsEqual(['a', 'b', 'c'], ['a', 'b', 'c', 'd'])

I expect this output:

    AssertionError: Element counts were not equal:
    First has 0, Second has 1:  'd'

Instead I get this output:

    AssertionError: Element counts were not equal:
    First has 1, Second has 0:  'd'

I would expect 'First' to refer to the first sequence I pass to assertItemsEqual, not the second, and vice versa.

(Obviously in a trivial example like this it appears unimportant, but when debugging why a test has failed, the unexpected ordering can cause problems.)

----------
messages: 160887
nosy: Kylotan
priority: normal
severity: normal
status: open
title: unittest's assertItemsEqual() method gives wrong order in error output
versions: Python 2.7

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

From report at bugs.python.org  Wed May 16 22:36:41 2012
From: report at bugs.python.org (Anthony Long)
Date: Wed, 16 May 2012 20:36:41 +0000
Subject: [New-bugs-announce] [issue14833] Copyright date in footer of /pypi
	says 2011
Message-ID: <1337200601.87.0.526059561326.issue14833@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

http://pypi.python.org/pypi

The copyright in the footer says 2011.

----------
components: None
messages: 160928
nosy: antlong
priority: normal
severity: normal
status: open
title: Copyright date in footer of /pypi says 2011

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

From report at bugs.python.org  Wed May 16 22:42:44 2012
From: report at bugs.python.org (Anthony Long)
Date: Wed, 16 May 2012 20:42:44 +0000
Subject: [New-bugs-announce] [issue14834] A list of broken links on the
	python.org website
Message-ID: <1337200964.75.0.633094398111.issue14834@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

http://python.org/community/jobs/
	http://python.org/community/jobs/www.austinfraser.com
	  \_____ error code: 404 (not found)
	http://python.org/lumino.so
	  \_____ error code: 404 (not found)
	http://python.org/community/jobs/www.osrecruit.com
	  \_____ error code: 404 (not found)
	http://python.org/community/jobs/www.tech.myemma.com
	  \_____ error code: 404 (not found)
	http://python.org/community/jobs/www.oxfordknight.co.uk
	  \_____ error code: 404 (not found)

http://python.org/download/releases/2.0.1/
	http://python.org/download/releases/2.0.1/ftp/python/2.0.1/Python-2.0.1-Debug.zip
	  \_____ error code: 404 (not found)

http://python.org/download/releases/2.5.6/
	http://python.org/download/releases/2.5.6/md5sum.py
	  \_____ error code: 404 (not found)

http://python.org/download/releases/3.1.4/
	http://python.org/download/releases/3.1.4/python-3.1.4.msi.asc
	  \_____ error code: 404 (not found)
	http://python.org/download/releases/3.1.4/python-3.1.4-pdb.zip.asc
	  \_____ error code: 404 (not found)
	http://python.org/download/releases/3.1.4/python-3.1.4.amd64.msi.asc
	  \_____ error code: 404 (not found)
	http://python.org/download/releases/3.1.4/python-3.1.4.amd64-pdb.zip.asc
	  \_____ error code: 404 (not found)

----------
messages: 160929
nosy: antlong
priority: normal
severity: normal
status: open
title: A list of broken links on the python.org website

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

From report at bugs.python.org  Thu May 17 00:17:23 2012
From: report at bugs.python.org (=?utf-8?q?Sidney_San_Mart=C3=ADn?=)
Date: Wed, 16 May 2012 22:17:23 +0000
Subject: [New-bugs-announce] [issue14835] plistlib: output empty elements
	correctly
Message-ID: <1337206643.96.0.0313352336194.issue14835@psf.upfronthosting.co.za>


New submission from Sidney San Mart?n <s at sidneysm.com>:

plistlib?s output is currently byte-for-byte identical to Apple?s, except arrays and dictionaries are stored with self-closing tags (e.g. '<array/>') and plistlib outputs empty tags with a newline (e.g. '<array>\n</array>').

This tiny patch makes its output for empty arrays and dictionaries consistent with the OS?s.

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: plistlib_empty_objects.patch
keywords: patch
messages: 160934
nosy: ronaldoussoren, ssm
priority: normal
severity: normal
status: open
title: plistlib: output empty elements correctly
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file25620/plistlib_empty_objects.patch

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

From report at bugs.python.org  Thu May 17 00:41:30 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 May 2012 22:41:30 +0000
Subject: [New-bugs-announce] [issue14836] Add next(iter(o)) to set.pop,
	dict.popitem entries.
Message-ID: <1337208090.37.0.632127020372.issue14836@psf.upfronthosting.co.za>


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

There have been several requests for a set.get() (no args) or set.pick() method to get an item without deleting it as .pop() does. Probably the best answer is to use the simple generic composition next(iter(s)). The counter response is that it is hardly obvious and needs to be documented.

Suggesion: after the current

"pop() 
Remove and return an arbitrary element from the set. Raises KeyError if the set is empty."

add "Use next(iter(s)) to return an arbitrary element without removing it."

Then change the following to match.

"popitem() 
Remove and return an arbitrary (key, value) pair from the dictionary.

popitem() is useful to destructively iterate over a dictionary, as often used in set algorithms. If the dictionary is empty, calling popitem() raises a KeyError."

to

"popitem() 
Remove and return an arbitrary (key, value) pair from the dictionary. Raises KeyError if the dict is empty. Use next(iter(d)) to return an arbitrary pair without removing it."

The old comment about destructively iterating over a dict as a set belongs more with set.pop if it is not removed.

The idiom works with all iterators, but there is no other place I can think of to put it, and it is not needed for sequences.

----------
assignee: docs at python
components: Documentation
keywords: patch
messages: 160937
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add next(iter(o)) to set.pop, dict.popitem entries.
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 17 00:45:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 May 2012 22:45:39 +0000
Subject: [New-bugs-announce] [issue14837] Better SSL errors
Message-ID: <1337208339.28.0.379758124204.issue14837@psf.upfronthosting.co.za>


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

This patch tries to provide better SSL errors by using OpenSSL's official mnemonics. The sub-library mnemonic (e.g. "SSL", "PEM"...) is provided as the "library" attribute on an exception, and the reason mnemonic (e.g. "CERTIFICATE_VERIFY_FAILED") is provided as the "reason" attribute.

I'm welcoming of any comments or suggestions.

----------
components: Extension Modules
files: ssl_errs.patch
keywords: patch
messages: 160939
nosy: exarkun, pitrou
priority: low
severity: normal
status: open
title: Better SSL errors
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25621/ssl_errs.patch

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

From report at bugs.python.org  Thu May 17 06:13:07 2012
From: report at bugs.python.org (Cain)
Date: Thu, 17 May 2012 04:13:07 +0000
Subject: [New-bugs-announce] [issue14838] IDLE Will not load on reinstall
Message-ID: <1337227987.71.0.240341715847.issue14838@psf.upfronthosting.co.za>


New submission from Cain <gaminglegend at gmail.com>:

After reinstalling Python 3.2.2, I have been unable to load IDLE - it simply refuses to respond. I have tried upgrading to 3.3 also, and still have the same problem - following multiple uninstalls, reinstalls and searching, I can't appear to find any solution to this problem which does appear to have occurred to others in the past with no solution that I can find.

Any ideas?

----------
components: IDLE
messages: 160952
nosy: BugReporter
priority: normal
severity: normal
status: open
title: IDLE Will not load on reinstall
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 17 10:42:53 2012
From: report at bugs.python.org (Robert Koziol)
Date: Thu, 17 May 2012 08:42:53 +0000
Subject: [New-bugs-announce] [issue14839] xml.sax.make_parser() returns "No
	parsers found"
Message-ID: <1337244173.26.0.384482596319.issue14839@psf.upfronthosting.co.za>


New submission from Robert Koziol <rkoziol7 at gmail.com>:

Hi all,

It seems a little weird for me but I can not find this bug created. So I create one.

Invoking xml.sax.make_parser() returns an Exception - as in the following example:

Python 2.7.3rc2 (default, Mar 21 2012, 06:59:11)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.sax
>>> xml.sax.make_parser()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/xml/sax/__init__.py", line 93, in make_parser
    raise SAXReaderNotAvailable("No parsers found", None)
xml.sax._exceptions.SAXReaderNotAvailable: No parsers found


Kind regards,
Rob

----------
components: XML
messages: 160954
nosy: rkoziol7
priority: normal
severity: normal
status: open
title: xml.sax.make_parser() returns "No parsers found"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 17 18:56:10 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 17 May 2012 16:56:10 +0000
Subject: [New-bugs-announce] [issue14840] Tutorial: Add a bit on the
	difference between tuples and	lists
Message-ID: <1337273770.17.0.397614380243.issue14840@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

I was looking through the documentation source files for things I might be able to fix, and stumbled across "XXX Add a bit on the difference between tuples and lists." in Doc\tutorial\datastructures.rst. So I took a stab at adding some prose to address that comment, reproduced here:

"""
Though tuples may seem very similar to lists, their immutability makes them
ideal for fundamentally different usage.  In typical usage, tuples are a
heterogenous structure, whereas lists are a homogenous sequence.  This tends to
mean that, in general, tuples are used as a cohesive unit while lists are used
one member at a time.
"""

Have I missed anything important (like the whole point) or is there anything I could phrase better?

Should this be applied to the tutorials of previous versions?

----------
assignee: docs at python
components: Documentation
files: tuple vs list.patch
keywords: patch
messages: 160982
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Tutorial: Add a bit on the difference between tuples and lists
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25627/tuple vs list.patch

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

From report at bugs.python.org  Thu May 17 19:21:14 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 17 May 2012 17:21:14 +0000
Subject: [New-bugs-announce] [issue14841] os.get_terminal_size() should
	check stdin as a fallback
Message-ID: <1337275274.3.0.172049776796.issue14841@psf.upfronthosting.co.za>


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

$ stty size | cat
46 157
$ python3.3 -c 'import os; print(os.get_terminal_size())' | cat
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 22] Invalid argument

Redirection to `less` are often used.

A proposed patch was attached by Victor Stinner in issue #13609.

----------
messages: 160988
nosy: Arfrever, denilsonsa, haypo, zbysz
priority: normal
severity: normal
status: open
title: os.get_terminal_size() should check stdin as a fallback
versions: Python 3.3

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

From report at bugs.python.org  Thu May 17 21:50:01 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 17 May 2012 19:50:01 +0000
Subject: [New-bugs-announce] [issue14842] Link to time.time() in the docs of
	time.localtime() is	wrong
Message-ID: <1337284201.48.0.167329102574.issue14842@psf.upfronthosting.co.za>


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

The link currently points to the time module. It should point to the time.time() function.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 161010
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
status: open
title: Link to time.time() in the docs of time.localtime() is wrong
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 17 22:48:17 2012
From: report at bugs.python.org (Daniel Holth)
Date: Thu, 17 May 2012 20:48:17 +0000
Subject: [New-bugs-announce] [issue14843] support define_macros /
	undef_macros in setup.cfg
Message-ID: <1337287697.85.0.358321566588.issue14843@psf.upfronthosting.co.za>


Changes by Daniel Holth <dholth at fastmail.fm>:


----------
assignee: eric.araujo
components: Distutils2
nosy: alexis, dholth, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: support define_macros / undef_macros in setup.cfg
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu May 17 23:23:45 2012
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Droz?=)
Date: Thu, 17 May 2012 21:23:45 +0000
Subject: [New-bugs-announce] [issue14844] netrc does not handle accentuated
	characters
Message-ID: <1337289825.27.0.400304162278.issue14844@psf.upfronthosting.co.za>


New submission from Rapha?l Droz <raphael.droz+floss at gmail.com>:

Accentuated characters are not accepted in password.
While it (unicode) was quickly talked about in issue557704 it appears that issue1170 aimed to solve this by making shlex unicode-compatible but it does not seem to be the case (at least with python 3.2 in the netrc use-case).

On a side note :
- a blank line between two comment lines
 and
- lines starting with a '#' *not* followed by a space
 fail too (shells supports both of them)

----------
components: Library (Lib)
messages: 161016
nosy: drzraf
priority: normal
severity: normal
status: open
title: netrc does not handle accentuated characters
versions: Python 3.2

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

From report at bugs.python.org  Fri May 18 00:47:37 2012
From: report at bugs.python.org (Peter Norvig)
Date: Thu, 17 May 2012 22:47:37 +0000
Subject: [New-bugs-announce] [issue14845] list(<generator expression>) !=
	[<list comprehension>]
Message-ID: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za>


New submission from Peter Norvig <pnorvig at google.com>:

PEP 289 says "the semantic definition of a list comprehension in Python 3.0 will be equivalent to list(<generator expression>).  Here is a counterexample where they differ (tested in 3.2):

def five(x):
    "Generator yields the object x five times."
    for _ in range(5):
        yield x


# If we ask five() for 10 objects in a list comprehension,
# we get an error:

>>> F = five('x')
>>> [next(F) for _ in range(10)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

# But if we ask five() for 10 objects in a list(generator expr),
# we get five objects, no  error:

>>> F = five('x')
>>> list(next(F) for _ in range(10))
['x', 'x', 'x', 'x', 'x']

----------
components: None
messages: 161023
nosy: Peter.Norvig
priority: normal
severity: normal
status: open
title: list(<generator expression>) != [<list comprehension>]
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri May 18 01:35:08 2012
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 17 May 2012 23:35:08 +0000
Subject: [New-bugs-announce] [issue14846] Change in error when sys.path
	contains a nonexistent	folder (importlib)
Message-ID: <1337297708.76.0.21488172689.issue14846@psf.upfronthosting.co.za>


New submission from Thomas Kluyver <takowl at gmail.com>:

I've come across a difference from 3.2 to 3.3 while running the IPython test suite. It occurs when a directory on sys.path has been used for an import, then deleted without being removed from sys.path. Previous versions of Python ignore the nonexistent folder, but in 3.3 a FileNotFound error appears.

This might be by design (errors should never pass silently), but I haven't found it mentioned in the What's New for 3.3.

$ cat import.py
import sys, os, shutil
os.mkdir('foo')
with open('foo/bar.py', 'w'):
    pass
sys.path.insert(0, 'foo/')
import bar   # Caches a FileFinder for foo/
shutil.rmtree('foo')
import random   # Comes later on sys.path

$ python3.2 import.py

$ python3.3 import.py
Traceback (most recent call last):
  File "import.py", line 8, in <module>
    import random
  File "<frozen importlib._bootstrap>", line 1162, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1124, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1078, in _find_module
  File "<frozen importlib._bootstrap>", line 927, in find_module
  File "<frozen importlib._bootstrap>", line 973, in find_module
  File "<frozen importlib._bootstrap>", line 1005, in _fill_cache
FileNotFoundError: [Errno 2] No such file or directory: 'foo/'

The last entry in that traceback is calling "_os.listdir(path)".

----------
components: Interpreter Core
messages: 161025
nosy: takluyver
priority: normal
severity: normal
status: open
title: Change in error when sys.path contains a nonexistent folder (importlib)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri May 18 05:22:11 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 18 May 2012 03:22:11 +0000
Subject: [New-bugs-announce] [issue14847] AttributeError: NoneType has no
	attribute 'utf_8_decode'
Message-ID: <1337311331.2.0.610588604888.issue14847@psf.upfronthosting.co.za>


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

I have run into an issue where an attempt to call .decode('utf-8') on a Python string results in the error with the following traceback:

File ...
    ''.decode('utf-8')
File "env/lib/python2.6/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
AttributeError: 'NoneType' object has no attribute 'utf_8_decode'

I've noticed this when running our applications. I've also encountered it when installing packages using distribute. With a sufficiently-complicated tree of packages to install, distribute 0.6.26 will fail with the error above at https://bitbucket.org/tarek/distribute/src/0a45ae3390cd/setuptools/command/easy_install.py#cl-745 .

Unfortunately, the only case where I've been able to reliably reproduce this behavior is with private packages in a very complex arrangement. I tried but was not able to create a small script to reproduce the issue.

I see this bug was observed in issue6551, but that only a workaround was applied to avoid the symptom, but the underlying cause was never discovered.

Furthermore, I found that I could sometimes reproduce the failure in one line of code, but not reproduce it with the same invocation one line prior, with no substantial logic in between. In other words, it's not even possible to pinpoint the cause because whatever is causing the utf_8 module to become finalize is not coincident with where the failures occur.

I'm hesitant to file a bug with Python because the core Python is not necessarily implicated, but because this problem emerged in the Python core project test suite, I'm inclined to think the issue does lie with Python itself.

Furthermore, it should be very difficult for a Python program to get into a situation where ''.decode('utf-8') fails with an AttributeError.

At this point, I could use some help. Is it possible to detect when a module (utf_8 in this case) is finalized? I'm realizing now that running python with -v might provide some insight, so I'll try that.

----------
components: Library (Lib)
messages: 161032
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: AttributeError: NoneType has no attribute 'utf_8_decode'
versions: Python 2.7

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

From report at bugs.python.org  Fri May 18 10:50:32 2012
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Fri, 18 May 2012 08:50:32 +0000
Subject: [New-bugs-announce] [issue14848] os.rename should not be used
Message-ID: <1337331032.2.0.780379839017.issue14848@psf.upfronthosting.co.za>


New submission from Vetoshkin Nikita <nikita.vetoshkin at gmail.com>:

When I attempt to remove package with pysetup remove 'package-name' on Fedora 17 - it fails with:
'my-package' cannot be removed
Error: [Errno 18] Invalid cross-device link

strace'ing showed that there was an attempt to call rename from package dir into /tmp which is tmpfs.

Proposed fix is trivial - use shutil.move instead of barebone os.rename.

----------
assignee: eric.araujo
components: Distutils2
messages: 161042
nosy: alexis, eric.araujo, nvetoshkin, tarek
priority: normal
severity: normal
status: open
title: os.rename should not be used
versions: Python 2.7

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

From report at bugs.python.org  Fri May 18 12:13:19 2012
From: report at bugs.python.org (Markus)
Date: Fri, 18 May 2012 10:13:19 +0000
Subject: [New-bugs-announce] [issue14849] C implementation of ElementTree:
	Inheriting from Element	breaks text member
Message-ID: <1337335999.38.0.656009242892.issue14849@psf.upfronthosting.co.za>


New submission from Markus <common at gmx.ch>:

Example Code to reproduce:

from xml.etree import ElementTree as etree
class xetree:
	cElement = etree.Element
	class Element(etree.Element):
		def __init__(self, tag, attrib=None):
			xetree.cElement.__init__(self, tag, attrib)

etree.Element = xetree.Element

e = etree.Element("test", {'foobar':'bar'})
e.text = "failure"
print(etree.tostring(e))
# will lack "failure"

So basic inheritance is broken.

----------
components: Library (Lib)
messages: 161043
nosy: cmn
priority: normal
severity: normal
status: open
title: C implementation of ElementTree: Inheriting from Element breaks text member
versions: Python 3.3

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

From report at bugs.python.org  Fri May 18 16:46:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 May 2012 14:46:36 +0000
Subject: [New-bugs-announce] [issue14850] The inconsistency of
	codecs.charmap_decode
Message-ID: <1337352396.54.0.468921009595.issue14850@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

codecs.charmap_decode behaves differently with native and user string as decode table.

>>> import codecs
>>> print(ascii(codecs.charmap_decode(b'\x00', 'replace', '\uFFFE')))
('\ufffd', 1)
>>> class S(str): pass
... 
>>> print(ascii(codecs.charmap_decode(b'\x00', 'replace', S('\uFFFE'))))
('\ufffe', 1)

It's because charmap decoder (function PyUnicode_DecodeCharmap in Objects/unicodeobject.c) uses different algorithms for exact strings and for other.

We need to fix it? If yes, what should return `codecs.charmap_decode(b'\x00', 'replace', {0:'\uFFFE'})`? What should return `codecs.charmap_decode(b'\x00', 'replace', {0:0xFFFE})`?

----------
components: Interpreter Core
messages: 161054
nosy: storchaka
priority: normal
severity: normal
status: open
title: The inconsistency of codecs.charmap_decode
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri May 18 18:18:08 2012
From: report at bugs.python.org (gene)
Date: Fri, 18 May 2012 16:18:08 +0000
Subject: [New-bugs-announce] [issue14851] Python-2.6.8 install fails due to
	missing files
Message-ID: <1337357888.33.0.194512138439.issue14851@psf.upfronthosting.co.za>


New submission from gene <eduvall at nrao.edu>:

Hi,
I've downloaded both source versions of Python for Mac 2.6.8 and have unziped them with Mac GUI or gunzip but all attempts fail due to build not finding files. First missing file is pyconfig.h which appears to be named pyconfig.h.in. When I remove the .in then next missing object is Modules/Setup. I don't see a fix for this. I'm installing this in Mac OS X 10.6.8. Any ideas?
Gene
Sources: http://www.python.org/download/releases/2.6.8/

----------
components: Installation
messages: 161060
nosy: spacebuoy
priority: normal
severity: normal
status: open
title: Python-2.6.8 install fails due to missing files
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri May 18 19:29:22 2012
From: report at bugs.python.org (Frederick Ross)
Date: Fri, 18 May 2012 17:29:22 +0000
Subject: [New-bugs-announce] [issue14852] json and ElementTree parsers
	misbehave on streams	containing more than a single object
Message-ID: <1337362162.37.0.214988903095.issue14852@psf.upfronthosting.co.za>


New submission from Frederick Ross <madhadron at gmail.com>:

When parsing something like '<a>x</a><a>y</a>' with xml.etree.ElementTree, or '{}{}' with json, these parser throw exceptions instead of reading a single element of the kind they understand off the stream (or throwing an exception if there is no element they understand) and leaving the stream in a sane state.

So I should be able to write

import xml.etree.ElementTree as et
import StringIO
s = StringIO.StringIO("<a>x</a><a>y</a>")
elem1 = et.parse(s)
elem2 = et.parse(s)

and have elem1 correspond to "<a>x</a>" and elem2 correspond to "<a>y</a>".

At the very least, if the parsers refuse to parse partial streams, they should at least not destroy the streams.

----------
components: Library (Lib)
messages: 161068
nosy: Frederick.Ross
priority: normal
severity: normal
status: open
title: json and ElementTree parsers misbehave on streams containing more than a single object
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri May 18 20:50:06 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 18 May 2012 18:50:06 +0000
Subject: [New-bugs-announce] [issue14853] test_file.py depends on sys.stdin
	being unseekable
Message-ID: <1337367006.89.0.99847274779.issue14853@psf.upfronthosting.co.za>


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

./python Lib/test/test_file.py    # passes
./python Lib/test/test_file.py </dev/null   # fails
nohup ./python Lib/test/test_file.py   # fails


======================================================================
FAIL: testStdin (__main__.COtherFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_file.py", line 160, in testStdin
    self.assertRaises((IOError, ValueError), sys.stdin.seek, -1)
AssertionError: (<type 'exceptions.IOError'>, <type 'exceptions.ValueError'>) not raised

======================================================================
FAIL: testStdin (__main__.PyOtherFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_file.py", line 160, in testStdin
    self.assertRaises((IOError, ValueError), sys.stdin.seek, -1)
AssertionError: (<type 'exceptions.IOError'>, <type 'exceptions.ValueError'>) not raised


2.7 only; works fine in 3.2.

----------
keywords: easy
messages: 161073
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: test_file.py depends on sys.stdin being unseekable
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat May 19 10:53:12 2012
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Sat, 19 May 2012 08:53:12 +0000
Subject: [New-bugs-announce] [issue14854] faulthandler: segfault with
	"SystemError: null argument	to internal routine"
Message-ID: <1337417592.83.0.722972299314.issue14854@psf.upfronthosting.co.za>


New submission from Zbyszek J?drzejewski-Szmek <zbyszek at in.waw.pl>:

Simply running './python -X faulthandler' in the source directory gives me this:

% ./python -X faulthandler
Fatal Python error: Py_Initialize: can't initialize faulthandler
SystemError: null argument to internal routine
[1]    25118 abort (core dumped)  ./python -X faulthandler

% gdb ./python core
Core was generated by `./python -X faulthandler'.
Program terminated with signal 6, Aborted.
#0  0x00007f52d7ff9475 in *__GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f52d7ff9475 in *__GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f52d7ffc6f0 in *__GI_abort () at abort.c:92
#2  0x00000000004bc984 in Py_FatalError (msg=0x5b3750 "Py_Initialize: can't initialize faulthandler")
    at Python/pythonrun.c:2283
#3  0x00000000004b85ed in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:361
#4  0x00000000004b86ea in Py_Initialize () at Python/pythonrun.c:398
#5  0x00000000004d55a6 in Py_Main (argc=3, argv=0x1b8f010) at Modules/main.c:624
#6  0x000000000041b120 in main (argc=3, argv=0x7fffc1ebb558) at ./Modules/python.c:65
(gdb) 
#0  0x00007f52d7ff9475 in *__GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f52d7ffc6f0 in *__GI_abort () at abort.c:92
#2  0x00000000004bc984 in Py_FatalError (msg=0x5b3750 "Py_Initialize: can't initialize faulthandler")
    at Python/pythonrun.c:2283
#3  0x00000000004b85ed in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:361
#4  0x00000000004b86ea in Py_Initialize () at Python/pythonrun.c:398
#5  0x00000000004d55a6 in Py_Main (argc=3, argv=0x1b8f010) at Modules/main.c:624
#6  0x000000000041b120 in main (argc=3, argv=0x7fffc1ebb558) at ./Modules/python.c:65

----------
messages: 161097
nosy: haypo, zbysz
priority: normal
severity: normal
status: open
title: faulthandler: segfault with "SystemError: null argument to internal routine"

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

From report at bugs.python.org  Sat May 19 11:49:33 2012
From: report at bugs.python.org (Yuriy Syrovetskiy)
Date: Sat, 19 May 2012 09:49:33 +0000
Subject: [New-bugs-announce] [issue14855] IPv6 support for logging.handlers
Message-ID: <1337420973.71.0.891474201343.issue14855@psf.upfronthosting.co.za>


New submission from Yuriy Syrovetskiy <cblp at cblp.su>:

IPv4 operations may fail on IPv6 systems, and vice versa. So we have to create sockets with the proper address family.

Maybe this behaviour could be incapsulated in socket object, but didn't find a good way to do it.

No documentation changed, because I just eliminate lack of implementation of already documented feature.

Please help to write tests.

I worked on the 3.2 branch, because the default branch has broken test_logging.

----------
components: Library (Lib)
files: mywork.patch
keywords: patch
messages: 161101
nosy: cblp, vinay.sajip
priority: normal
severity: normal
status: open
title: IPv6 support for logging.handlers
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file25635/mywork.patch

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

From report at bugs.python.org  Sat May 19 14:27:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_Buira?=)
Date: Sat, 19 May 2012 12:27:51 +0000
Subject: [New-bugs-announce] [issue14856] argparse: creating an already
	defined subparsers does	not raises an exception
Message-ID: <1337430471.4.0.633032333136.issue14856@psf.upfronthosting.co.za>


New submission from ?tienne Buira <etienne.buira at free.fr>:

With this patch, it raises an ArgumentException, instead of overwriting previous subparser without notice.

Regards.

----------
components: Library (Lib)
files: argparse_no_dup_subparsers.diff
keywords: patch
messages: 161112
nosy: eacb
priority: normal
severity: normal
status: open
title: argparse: creating an already defined subparsers does not raises an exception
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file25637/argparse_no_dup_subparsers.diff

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

From report at bugs.python.org  Sat May 19 16:52:10 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 19 May 2012 14:52:10 +0000
Subject: [New-bugs-announce] [issue14857] Direct access to lexically scoped
	__class__ is broken in	3.3
Message-ID: <1337439130.16.0.122225885221.issue14857@psf.upfronthosting.co.za>


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

Currently, __class__ references from methods in 3.3 aren't being mapped correctly to the class currently being defined.

This goes against the documented behaviour of PEP 3135, which states explicitly that the new zero-argument form is equivalent to super(__class__, <firstarg>), where __class__ is the closure reference.

This breakage is almost certainly due to the fix for #12370

The fact the test suite didn't break is a sign we also have a gap in our test coverage.

Given that a workaround is documented in #12370, but there's no workaround for this breakage, reverting the fix for that issue may prove necessary (unlike that current breakage, at least that wouldn't be a regression from 3.2).

----------
keywords: 3.2regression
messages: 161126
nosy: ncoghlan
priority: release blocker
severity: normal
stage: test needed
status: open
title: Direct access to lexically scoped __class__ is broken in 3.3
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat May 19 17:17:24 2012
From: report at bugs.python.org (Todd DeLuca)
Date: Sat, 19 May 2012 15:17:24 +0000
Subject: [New-bugs-announce] [issue14858] 'pysetup create' off-by-one when
	choosing classification	maturity status interactively.
Message-ID: <1337440644.55.0.0135974430118.issue14858@psf.upfronthosting.co.za>


New submission from Todd DeLuca <todddeluca at gmail.com>:

Today I installed distutils2 via pip and ran 'pysetup create'.  During the selection of Trove classifiers for Development status I chose '2 - Alpha' but setup.cfg ended up incorrectly indicating that my project is Pre-Alpha.

Here is a "screenshot" of the interactive setup with me choosing '2 - Alpha':

```
Do you want to set Trove classifiers? (y/n): y
            Please select the project status:

            0 - Planning
1 - Pre-Alpha
2 - Alpha
3 - Beta
4 - Production/Stable
5 - Mature
6 - Inactive

            Status: 2
```

Here is the relevant line in setup.cfg:

    classifier = Development Status :: 2 - Pre-Alpha

Here are the relevant Trove classifications from http://pypi.python.org/pypi?%3Aaction=list_classifiers:

``` 
Development Status :: 1 - Planning
Development Status :: 2 - Pre-Alpha
Development Status :: 3 - Alpha
Development Status :: 4 - Beta
Development Status :: 5 - Production/Stable
Development Status :: 6 - Mature
Development Status :: 7 - Inactive
```

Notice above that the numbers assigned to the Trove classifiers are greater (by one) than the numbers displayed in the pysetup script.

The problem is in file distutil2/create.py (http://hg.python.org/distutils2/file/d015f9edccb8/distutils2/create.py) in class MainProgram, method set_maturity_status().  

Changing the following line:


   676             Status''' % '\n'.join('%s - %s' % (i, maturity_name(n))

To the following:


   676             Status''' % '\n'.join('%s - %s' % (i + 1, maturity_name(n))

Should display the numbers correctly and fix the problem.  I tested this fix on my system (using python2.7.3) and it works correctly.

Regards,
Todd

P.S. Apologies for not submitting a "Pull request".

----------
assignee: eric.araujo
components: Distutils2
messages: 161129
nosy: alexis, eric.araujo, tarek, todddeluca
priority: normal
severity: normal
status: open
title: 'pysetup create' off-by-one when choosing classification maturity status interactively.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat May 19 18:45:09 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Sat, 19 May 2012 16:45:09 +0000
Subject: [New-bugs-announce] [issue14859] Patch to make IDLE window rise to
	top in OS X on launch
Message-ID: <1337445909.62.0.684123352682.issue14859@psf.upfronthosting.co.za>


New submission from Marc Abramowitz <msabramo at gmail.com>:

On OS X 10.6.8, when I execute "idle", I see nothing in the Terminal and the IDLE GUI launches but is not visible until I Command-Tab to the "Python" application. I stumbled upon a solution to this problem using OS X's built-in /usr/bin/osascript utility. Attaching a patch...

----------
components: IDLE
files: osx_raise_idle.patch
keywords: patch
messages: 161137
nosy: Marc.Abramowitz
priority: normal
severity: normal
status: open
title: Patch to make IDLE window rise to top in OS X on launch
type: enhancement
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file25639/osx_raise_idle.patch

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

From report at bugs.python.org  Sat May 19 22:18:37 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Sat, 19 May 2012 20:18:37 +0000
Subject: [New-bugs-announce] [issue14860] devguide: Clarify how to run
	cpython test suite - esp.	on 2.7
Message-ID: <1337458717.87.0.813620785863.issue14860@psf.upfronthosting.co.za>


New submission from Marc Abramowitz <msabramo at gmail.com>:

The way to test on Python 2.7 (discovered on IRC) is:

~/dev/hg-repos/cpython$ ./python.exe -m test.regrtest -j3

This is not documented. I will submit a patch...

----------
components: Devguide
files: devguide.patch
keywords: patch
messages: 161155
nosy: Marc.Abramowitz, ezio.melotti
priority: normal
severity: normal
status: open
title: devguide: Clarify how to run cpython test suite - esp. on 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file25641/devguide.patch

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

From report at bugs.python.org  Sun May 20 05:56:52 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Sun, 20 May 2012 03:56:52 +0000
Subject: [New-bugs-announce] [issue14861] (Patch included) Make ./python -m
	test work to run test	suite in Python 2.7
Message-ID: <1337486212.38.0.32150232851.issue14861@psf.upfronthosting.co.za>


New submission from Marc Abramowitz <msabramo at gmail.com>:

Currently, the devguide (http://docs.python.org/devguide/) mentions two sets of commands for running the CPython test suite:

* For Python 3, one uses: ./python -m test

* For Python 2.7, one must use: ./python -m test.regrtest because ./python -m test fails with an error:No module named test.__main__; 'test' is a package and cannot be directly executed

If you take these two variations and multiply by the 3 variations of "python" command required depending on the OS (Windows, OS X, or other), then there are 6 permutations. I would say that this doesn't exactly encourage newcomers to CPython to contribute.

To take away a bit of the complexity, I have an extremely simple patch that adds one two line file to make ./python -m test work on 2.7.

----------
components: Tests
files: python2.7_test.patch
keywords: patch
messages: 161180
nosy: Marc.Abramowitz
priority: normal
severity: normal
status: open
title: (Patch included) Make ./python -m test work to run test suite in Python 2.7
versions: Python 2.7
Added file: http://bugs.python.org/file25648/python2.7_test.patch

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

From report at bugs.python.org  Sun May 20 12:20:32 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 20 May 2012 10:20:32 +0000
Subject: [New-bugs-announce] [issue14862] fdopen not listed in__all__ of
	os.py
Message-ID: <1337509232.46.0.169160883451.issue14862@psf.upfronthosting.co.za>


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

>>> from os import *
>>> fdopen
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'fdopen' is not defined

----------
components: Library (Lib)
keywords: easy
messages: 161196
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: fdopen not listed in__all__ of os.py
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun May 20 12:59:37 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 20 May 2012 10:59:37 +0000
Subject: [New-bugs-announce] [issue14863] Update docs of os.fdopen()
Message-ID: <1337511577.61.0.183128218571.issue14863@psf.upfronthosting.co.za>


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

os.fdopen() is merely a very thin wrapper around the builtin open(). It should have a very minimal documentation of its own to minimize maintenance burden.

----------
messages: 161198
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: Update docs of os.fdopen()
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun May 20 15:39:38 2012
From: report at bugs.python.org (Guillaume)
Date: Sun, 20 May 2012 13:39:38 +0000
Subject: [New-bugs-announce] [issue14864] Mention
	logging.disable(logging.NOTSET) to reset the	command in
	logging module documentation
Message-ID: <1337521178.31.0.00920557235265.issue14864@psf.upfronthosting.co.za>


New submission from Guillaume <guibog at gmail.com>:

In the logging module documentation, nothing tells the user how to undo or reset a call to logging.disable(lvl). From reading the code (python 2.6 version) it seem the correct way to undo disable(lvl) is to call disable(0), but I think calling disable(NOTSET) would make more sense. The sentence I propose to add at the end of the paragraph about the disable() function is:

To undo the effect of a call to logging.disable(lvl), call logging.disable(logging.NOTSET).

(This is my first doc bug report, please feel free to tell me how to improve.)

----------
assignee: docs at python
components: Documentation
messages: 161206
nosy: docs at python, guibog
priority: normal
severity: normal
status: open
title: Mention logging.disable(logging.NOTSET) to reset the command in logging module documentation
type: enhancement

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

From report at bugs.python.org  Sun May 20 19:58:14 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 20 May 2012 17:58:14 +0000
Subject: [New-bugs-announce] [issue14865] #doctest: directives removed from
	doctest chapter	examples
Message-ID: <1337536694.63.0.542931738001.issue14865@psf.upfronthosting.co.za>


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

In the doctest section, 25.2.3.5. Option Flags and Directives has examples of using #doctest: directives in the .rst source
'''
An example's doctest directives modify doctest's behavior for that single example.  Use ``+`` to enable the named behavior, or ``-`` to disable it.

For example, this test passes::

   >>> print(list(range(20))) #doctest: +NORMALIZE_WHITESPACE
   [0,   1,  2,  3,  4,  5,  6,  7,  8,  9,
   10,  11, 12, 13, 14, 15, 16, 17, 18, 19]
'''
However, when converted to html or Window's help, the directive is removed. See for example

http://docs.python.org/py3k/library/doctest.html#option-flags-and-directives

This was reported on python-list for 2.7 and 3.? (.2 probably) by Steven D'Aprano and verified by me for 3.3.0 Win help. Vincent Vande Vyvre provided quote from 3.? .rst source and I verified it and several more following in 3.3.0.

I presume the problem is that we now use the same directives to help doctest source examples for other modules and sphinx with our customizations does not know to leave these particular directives in the text after using them.

I searched issues for '#doctest' and did not see anything about removal.

----------
assignee: docs at python
components: Documentation
messages: 161220
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: #doctest: directives removed from doctest chapter examples
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May 21 07:20:30 2012
From: report at bugs.python.org (=?utf-8?b?44OJ44Of44OI44OqIOOCueODhuODkeODjOOCt+OCreODsw==?=)
Date: Mon, 21 May 2012 05:20:30 +0000
Subject: [New-bugs-announce] [issue14866] 2.x,
	3.x iOS static build: Fatal Python error: exceptions
	bootstrapping	error.
Message-ID: <1337577630.57.0.506475645157.issue14866@psf.upfronthosting.co.za>


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

I trying to make minimal part of Python to work as part (static library) of my iOS application for internal scripting. I used configure under Mac OS X(10.7) and it was successful. Then I got compilable and linkable XCode project very fast.
The problem is, when I trying to use Python by 
Py_NoSiteFlag=1;
Py_Initialize();
it fails with error "Fatal Python error: exceptions bootstrapping error." inside _PyExc_Init().
I tried to debug it, but unfortunately I cant understand why it fails. May be bacause I noob in Python source, but anyway, I need to port it. Tried 2.7.3, or latest 3.x, it was the same result as above. Any solution or hint will be very helpful.

Best Regards

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
messages: 161244
nosy: ronaldoussoren, ????.???????
priority: normal
severity: normal
status: open
title: 2.x,3.x iOS static build: Fatal Python error: exceptions bootstrapping error.
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon May 21 08:22:07 2012
From: report at bugs.python.org (=?utf-8?q?Nacsa_Krist=C3=B3f?=)
Date: Mon, 21 May 2012 06:22:07 +0000
Subject: [New-bugs-announce] [issue14867] chm link missing from 2.7 download
	page
Message-ID: <1337581327.16.0.0447696908146.issue14867@psf.upfronthosting.co.za>


New submission from Nacsa Krist?f <anaxagramma at gmail.com>:

The link `http://python.org/ftp/python/2.7.3/python273.chm` is missing from `http://python.org/download/releases/2.7.3/` although the checksum is listed and the file exists.

----------
assignee: docs at python
components: Documentation, Installation, Windows
messages: 161248
nosy: Nacsa.Krist?f, docs at python
priority: normal
severity: normal
status: open
title: chm link missing from 2.7 download page
versions: Python 2.7

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

From report at bugs.python.org  Mon May 21 09:56:09 2012
From: report at bugs.python.org (=?utf-8?b?TGx1w61z?=)
Date: Mon, 21 May 2012 07:56:09 +0000
Subject: [New-bugs-announce] [issue14868] Allow log calls to return True for
	code optimization.
Message-ID: <1337586969.05.0.311712609253.issue14868@psf.upfronthosting.co.za>


New submission from Llu?s <llpamies at pamies.cat>:

One of the problems with the logging library is that it can affect code performance when logging calls are over-utilized.

One possible solution would be to allow the compiler to remove logging calls when code is optimized with "python -O" by wrapping log calls with an assert:

   assert logging.debug("This is a test.")

Note that now debug(), info(), etc in the logging module always return "None" and this is not possible. An enhancement would be to make all logging calls to return True. In normal conditions messages would be logged without raising any error, but in optimized code they would never be called.

It is really easy to implement and I would be pleased to provide a patch for this, but I want to receive feedback from python core developers.

Thanks?

----------
components: Library (Lib)
messages: 161251
nosy: Llu?s
priority: normal
severity: normal
status: open
title: Allow log calls to return True for code optimization.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May 21 11:56:51 2012
From: report at bugs.python.org (Daniel Kinzler)
Date: Mon, 21 May 2012 09:56:51 +0000
Subject: [New-bugs-announce] [issue14869] imaplib erronously quotes atoms
	such as flags
Message-ID: <1337594211.69.0.0102835741934.issue14869@psf.upfronthosting.co.za>


New submission from Daniel Kinzler <daniel at brightbyte.de>:

imap consideres flags to be atoms, and atoms should not be quoted. Attempting to use a quoted flag with e.g. STORE +FLAGS will cause some servers, like dovecot, to return an error.

However, imaplib apparently auto-quotes all parameters that contain a backslash. This applies to default flags such as \Deleted or \Seen. This results in an error from some IMAP servers.

The reason seems to be that _checkquote method wants to quote anything that matches the _mustquote pattern, and that pattern matches strings containing backslashes.

----------
components: Extension Modules
messages: 161257
nosy: brightbyte
priority: normal
severity: normal
status: open
title: imaplib erronously quotes atoms such as flags
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon May 21 13:50:06 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 21 May 2012 11:50:06 +0000
Subject: [New-bugs-announce] [issue14870] os.utimensat's method description
	uses wrong notation
Message-ID: <1337601006.45.0.685713178373.issue14870@psf.upfronthosting.co.za>


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

It says:

> os.utimensat(dirfd, path[, atime=(atime_sec, atime_nsec), mtime=(mtime_sec, mtime_nsec), flags=0])
> Updates the timestamps of a file with nanosecond precision. The atime and mtime tuples default to None, which sets those values to the current time.

It should be the other way around: atime=None, mtime=None in the signature and explain in the body how they look like. It looks like atime_sec and atime_nsec are some magic constants this way.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 161264
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, hynek
priority: low
severity: normal
status: open
title: os.utimensat's method description uses wrong notation
versions: Python 3.3

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

From report at bugs.python.org  Mon May 21 21:21:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 May 2012 19:21:34 +0000
Subject: [New-bugs-announce] [issue14871] Rewrite the command line parsers
	and actions system used	in distutils2
Message-ID: <1337628094.39.0.351535654763.issue14871@psf.upfronthosting.co.za>


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

At present distutils2/packaging uses many command line parsers:

- one parser for commands and their options implemented in the dist.Distribution class, inherited from distutils and based on fanncy_getopt;

- another parser for pysetup actions and options implemented in run.Dispatcher, also using fancy_getopt;

- a _parse_args function based on getopt (le gasp!) and used by the functions implementing pysetup actions.

This causes no end of bugs and maintenance issues.  The actions system could also be much improved; one issue is that the option parsing is not automated (unlike for commands) and the loading of actions is not lazy.  See https://groups.google.com/forum/#!topic/the-fellowship-of-the-packaging/pxOZ_j4_4yg for details.

My current inclination is to just use argparse everywhere, with a thin wrapper to preserve the current way to declare commands options, and something similar for actions.  Backporting argparse for 2.5, 2.6 and 3.1 won?t be hard and using it should buy us much.  The key thing is that the various subparsers (e.g. for pysetup, for the run action, for one command) should work together lazily: the pysetup parser should parse its options and stop at the 'run' segment, then pass on to the run action parser, etc.  The goal is to avoid creating all the parsers for actions and commands.

----------
assignee: eric.araujo
components: Distutils2
messages: 161289
nosy: alexis, eric.araujo, jkloth, michael.mulich, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Rewrite the command line parsers and actions system used in distutils2
type: enhancement
versions: 3rd party, Python 3.3

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

From report at bugs.python.org  Mon May 21 22:33:13 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 21 May 2012 20:33:13 +0000
Subject: [New-bugs-announce] [issue14872] subprocess is not safe from
	deadlocks
Message-ID: <1337632393.15.0.575365490644.issue14872@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

There is no way to write a program in Python capable to process large/unlimited output coming from a subprocess stream without deadlocks.

http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
    "Note The data read is buffered in memory, so do not use this method if the data size is large or unlimited."

http://docs.python.org/library/subprocess.html#subprocess.Popen.stdin
http://docs.python.org/library/subprocess.html#subprocess.Popen.stdout
http://docs.python.org/library/subprocess.html#subprocess.Popen.stderr
    "Warning Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process."


So, what should I use?

----------
components: Library (Lib)
messages: 161294
nosy: techtonik
priority: normal
severity: normal
status: open
title: subprocess is not safe from deadlocks
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon May 21 23:32:14 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Mon, 21 May 2012 21:32:14 +0000
Subject: [New-bugs-announce] [issue14873] Windows devguide: clarification
	for build errors due to	missing optional dependencies
Message-ID: <1337635934.97.0.00774228484409.issue14873@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

The amount of errors in the solution during the windows build was surprising to me - I interpreted it as if python was not built correctly. Upon further inspection, just some extension modules were not built due to missing dependencies, and the interpreter runs without problems.

To clarify this in the devguide, I suggest the attached changes.

----------
components: Devguide
files: devguide_windows_build_errors_notes.patch
keywords: patch
messages: 161299
nosy: ezio.melotti, valhallasw
priority: normal
severity: normal
status: open
title: Windows devguide: clarification for build errors due to missing optional dependencies
Added file: http://bugs.python.org/file25663/devguide_windows_build_errors_notes.patch

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

From report at bugs.python.org  Tue May 22 00:19:30 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 May 2012 22:19:30 +0000
Subject: [New-bugs-announce] [issue14874] Faster charmap decoding
Message-ID: <1337638770.26.0.783937266614.issue14874@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Charmap decoders are not as important as UTF decoders, but are still widely used. In Python 3.3 with PEP 393 they slowed down 4x. The proposed patch restores the performance.

Optimized only the most common case, when the decoder is specified by the UCS2 table with length >= 256. Map-based decoders translated to table-based. UCS1 tables widened to UCS2 by adding 257th fake characters.

Benchmark results:

                             3.2           3.3(vanilla)  3.3(patched)

cp1251    'A'*10000          111 (+10%)    31 (+294%)    122
cp1251    '\xa0'*10000       111 (+8%)     29 (+314%)    120
cp1251    '\u0402'*10000     111 (+6%)     25 (+372%)    118

----------
components: Interpreter Core, Unicode
files: decode_charmap.patch
keywords: patch
messages: 161301
nosy: ezio.melotti, haypo, lemburg, pitrou, storchaka
priority: normal
severity: normal
status: open
title: Faster charmap decoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25664/decode_charmap.patch

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

From report at bugs.python.org  Tue May 22 00:39:01 2012
From: report at bugs.python.org (Sasha B)
Date: Mon, 21 May 2012 22:39:01 +0000
Subject: [New-bugs-announce] [issue14875] Unusual way of doing 'Inf' in json
	library
Message-ID: <1337639941.66.0.830399497264.issue14875@psf.upfronthosting.co.za>


New submission from Sasha B <sbermeister at gmail.com>:

If you have a look at the file 'python/Lib/json/encode.py', on line 30 it says:

    # Assume this produces an infinity on all machines (probably not guaranteed)
    INFINITY = float('1e66666')
    FLOAT_REPR = repr

Isn't float('Inf') an accepted way of doing this? Should line 31 be INFINITY = float('Inf')?

Sasha

----------
components: Library (Lib)
messages: 161304
nosy: sbermeister
priority: normal
severity: normal
status: open
title: Unusual way of doing 'Inf' in json library
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue May 22 02:19:45 2012
From: report at bugs.python.org (Andrew McChildren)
Date: Tue, 22 May 2012 00:19:45 +0000
Subject: [New-bugs-announce] [issue14876] IDLE highlighting theme does not
	preview with	user-selected fonts
Message-ID: <1337645985.47.0.17303528345.issue14876@psf.upfronthosting.co.za>


New submission from Andrew McChildren <greenen72 at gmail.com>:

When changing theme colors, preview window uses only default font

----------
components: IDLE
messages: 161309
nosy: Andrew.McChildren
priority: normal
severity: normal
status: open
title: IDLE highlighting theme does not preview with user-selected fonts
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue May 22 03:36:23 2012
From: report at bugs.python.org (Aaron Staley)
Date: Tue, 22 May 2012 01:36:23 +0000
Subject: [New-bugs-announce] [issue14877] No option to run bdist_wininst
	against newer msvc	versions on non-windows systems
Message-ID: <1337650583.73.0.740719723595.issue14877@psf.upfronthosting.co.za>


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

On a *nix system, bdist_wininst.get_exe_bytes will always return an open  wininst-6.0.exe.

However, Windows python2.7 is compiled against msvc 9.0 and ideally would take an installer based on wininst-9.0.exe.  Windows-64bit needs an installer based on wininst-9.0-amd64.exe.

The ideal solution would be for bdist_wininst to take an option what "template exe" to be used. While I've monkey-patched things on my own, I'm not providing a patch as I'm not sure how the community wants to handle this (it could be anywhere from the exe name to tables being driven by target_version and some some 64bit option)

----------
assignee: eric.araujo
components: Distutils
messages: 161313
nosy: Aaron.Staley, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: No option to run bdist_wininst against newer msvc versions on non-windows systems
versions: Python 2.7

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

From report at bugs.python.org  Tue May 22 06:54:53 2012
From: report at bugs.python.org (Stephen Lacy)
Date: Tue, 22 May 2012 04:54:53 +0000
Subject: [New-bugs-announce] [issue14878] send statement from PEP342 is
	poorly documented.
Message-ID: <1337662493.01.0.380911981252.issue14878@psf.upfronthosting.co.za>


New submission from Stephen Lacy <slacy at slacy.com>:

There's reasonable documentation of the yield statement for most python versions under Section 6: Simple Statements, particularly 6.8 "The Yield Statement" (http://docs.python.org/release/2.7/reference/simple_stmts.html#the-yield-statement)

But, there's no mention of the return value of the yield statement, or that the send statement even exists.  It's mentioned in passing here under "PEP342 New Generator Features" (http://docs.python.org/whatsnew/2.5.html#pep-342-new-generator-features) but should be given fuller explanation and cross-linking from the yield statement documentation. 

It's also mentioned a bit here: http://docs.python.org/howto/functional.html#passing-values-into-a-generator but again, not under the language documentation itself.

----------
assignee: docs at python
components: Documentation
messages: 161320
nosy: Stephen.Lacy, docs at python
priority: normal
severity: normal
status: open
title: send statement from PEP342 is poorly documented.
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/issue14878>
_______________________________________

From report at bugs.python.org  Tue May 22 08:09:54 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 22 May 2012 06:09:54 +0000
Subject: [New-bugs-announce] [issue14879] invalid docs for subprocess
	exceptions with shell=True
Message-ID: <1337666994.08.0.287605633225.issue14879@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/subprocess.html#exceptions documentation is wrong at least for the case when shell=True on Linux. An attempt to execute a non-existent file with:

  process = subprocess.Popen("sdfsdf", shell=True, stdout=subprocess.PIPE, stderr=errpipe)
  out, err = process.communicate()
  print out

Results in a message "/bin/sh: sfs: command not found" with no exceptions. Other statements may be invalid too.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 161329
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: invalid docs for subprocess exceptions with shell=True
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/issue14879>
_______________________________________

From report at bugs.python.org  Tue May 22 09:07:36 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 22 May 2012 07:07:36 +0000
Subject: [New-bugs-announce] [issue14880] csv.reader and .writer use wrong
	kwargs notation in 2.7	docs
Message-ID: <1337670456.12.0.0273828432105.issue14880@psf.upfronthosting.co.za>


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

It says

> csv.reader(csvfile[, dialect='excel'][, fmtparam])
> csv.writer(csvfile[, dialect='excel'][, fmtparam])

in 2.7. I presume it should be like in 3.x:

> csv.reader(csvfile, dialect='excel', **fmtparams)
> csv.writer(csvfile, dialect='excel', **fmtparams)

Or am I missing something?

(I found argument renaming to be too invasive for my default-args-notation ticket #14804)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 161332
nosy: docs at python, hynek
priority: normal
severity: normal
status: open
title: csv.reader and .writer use wrong kwargs notation in 2.7 docs
versions: Python 2.7

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

From report at bugs.python.org  Tue May 22 10:51:10 2012
From: report at bugs.python.org (Itay Brandes)
Date: Tue, 22 May 2012 08:51:10 +0000
Subject: [New-bugs-announce] [issue14881] multiprocessing.dummy craches
	when	self._parent._children does not exist
Message-ID: <1337676670.99.0.0296506896441.issue14881@psf.upfronthosting.co.za>


New submission from Itay Brandes <akari.il at gmail.com>:

multiprocessing.dummy crashes when attempting to create a ThreadPool from a Thread.

The following code will crush on 2.7.3:

    import multiprocessing.dummy
    import threading
     
    class Worker(threading.Thread):
        def __init__(self):
            threading.Thread.__init__(self)
     
        def run(self):
            poll = multiprocessing.dummy.Pool(5)
            print str(poll)
     
    w = Worker()
    w.start()

will crush with the following traceback:

    poll = multiprocessing.dummy.Pool(5)
  File "C:\Python27\lib\multiprocessing\dummy\__init__.py", line 150, in Pool
    return ThreadPool(processes, initializer, initargs)
  File "C:\Python27\lib\multiprocessing\pool.py", line 685, in __init__
    Pool.__init__(self, processes, initializer, initargs)
  File "C:\Python27\lib\multiprocessing\pool.py", line 136, in __init__
    self._repopulate_pool()
  File "C:\Python27\lib\multiprocessing\pool.py", line 199, in _repopulate_pool
    w.start()
  File "C:\Python27\lib\multiprocessing\dummy\__init__.py", line 73, in start
    self._parent._children[self] = None
AttributeError: 'Worker' object has no attribute '_children'

If you have access to the thread itself, you can set the _children attribute youself (w._children = weakref.WeakKeyDictionary()), but it is not possible with threads different from threading.thread (Such as PyQt4's QThread thread, which is essential for GUI programming).

The fix that I found is to edit the Python27\Lib\multiprocessing\dummy\__init__.py file. The crashing code is line number 73.
This line should be nested in an if block:

        if hasattr(self._parent, '_children'):
            self._parent._children[self] = None

That way the code is fixed.
Thanks!

----------
components: None
messages: 161339
nosy: Itay.Brandes
priority: normal
severity: normal
status: open
title: multiprocessing.dummy craches when self._parent._children does not exist
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue May 22 11:31:45 2012
From: report at bugs.python.org (Chang Xiaojiang)
Date: Tue, 22 May 2012 09:31:45 +0000
Subject: [New-bugs-announce] [issue14882] Link/Compile Error on Sun Sparc
	Solaris10 with	gcc3.4.3----python2.6.8
Message-ID: <1337679105.42.0.19403489432.issue14882@psf.upfronthosting.co.za>


New submission from Chang Xiaojiang <chang847 at oki.com>:

I download the source package of python2.6.8from http://www.python.org/getit/releases/2.6.8/, and start a build on my Sun Sparc Solaris10 with gcc3.4.3 which is preinstalled.But the following error logs are reported.
gcc -shared build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/callproc.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/cfield.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/ffi.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/v8.o build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/v9.o -L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.6/_ctypes.so -mimpure-text
ld: ??????: ??????: R_SPARC_32: ???? build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/v8.o: ???? <??>: ????? 0xfed638e7 ??????????
ld: ??????: ??????: R_SPARC_32: ???? build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/v8.o: ???? <??>: ????? 0xfed638ed ??????????
ld: ??????: ??????: R_SPARC_32: ???? build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/v8.o: ???? <??>: ????? 0xfed638f1 ??????????
ld: ??????: ??????: R_SPARC_32: ???? build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/v8.o: ???? <??>: ????? 0xfed638f5 ??????????
ld: ??????: ??????: R_SPARC_32: ???? build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/v8.o: ???? <??>: ????? 0xfed73d5a ??????????
ld: ??????: ??????: R_SPARC_32: ???? build/temp.solaris-2.10-sun4u-2.6/export/diskArray/changxiaojiang/Mercurial/python-src/Python-2.6.8/Modules/_ctypes/libffi/src/sparc/v8.o: ???? <??>: ????? 0xfed75dfe ??????????
collect2: ld returned 1 exit status

Failed to find the necessary bits to build these modules:
_bsddb             _sqlite3           _tkinter
bsddb185           gdbm               linuxaudiodev
ossaudiodev        readline
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_ctypes            _curses            _curses_panel
_hashlib           _ssl

running build_scripts

Anyone can tell me what's wrong?
>From some website, I was told that this is caused by a fault of Solaris's gcc.To fix it, I need to recompile the gcc and reinstall it.But I donnot want to do so.Because it is a public server.

----------
components: None
messages: 161344
nosy: seeker77
priority: normal
severity: normal
status: open
title: Link/Compile Error on Sun Sparc Solaris10 with gcc3.4.3----python2.6.8
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue May 22 16:15:31 2012
From: report at bugs.python.org (Alex Garel)
Date: Tue, 22 May 2012 14:15:31 +0000
Subject: [New-bugs-announce] [issue14883] html documentation does not show
	comments in code blocks
Message-ID: <1337696131.0.0.436301420344.issue14883@psf.upfronthosting.co.za>


New submission from Alex Garel <alex.garel at gmail.com>:

Just under http://docs.python.org/library/doctest.html#doctest.REPORTING_FLAGS documentation speaks about how Doctest directives maybe expressed as special Python comments.

There are some example along with the narrative story, however comments which here are the important part, are not displayed in code snippet.

Looking at the sphinx source for this page : http://docs.python.org/_sources/library/doctest.txt the comments are present. Eg.

   >>> print range(20) #doctest: +NORMALIZE_WHITESPACE
   [0,   1,  2,  3,  4,  5,  6,  7,  8,  9,
   10,  11, 12, 13, 14, 15, 16, 17, 18, 19]

However in the generated html, they are not:

  <span class="k">print</span> <span class="nb">range</span>
  <span class="p">(</span><span class="mi">20</span><span class="p">)</span> 
  <span class="go">[0,   1,  2,  3,  4,  5,  6,  7,  8,  9,</span>


Note that this issue is not present in python 2.6.8?documentation http://docs.python.org/release/2.6.8/library/doctest.html#doctest.REPORTING_FLAGS and also 3.1.5 is ok.

It appears versions at 3.2.1?and 2.7.3

----------
assignee: docs at python
components: Documentation
messages: 161351
nosy: alexgarel, docs at python
priority: normal
severity: normal
status: open
title: html documentation does not show comments in code blocks
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May 22 21:12:27 2012
From: report at bugs.python.org (Michael Driscoll)
Date: Tue, 22 May 2012 19:12:27 +0000
Subject: [New-bugs-announce] [issue14884] Windows Build instruction typo
Message-ID: <1337713947.27.0.552062347283.issue14884@psf.upfronthosting.co.za>


New submission from Michael Driscoll <mike at pythonlibrary.org>:

In http://docs.python.org/devguide/setup.html#windows the devguide mentions that the user must go to the "Build" menu to run "Build Solution". When I tried doing that with Visual C++ 2010 per the instructions, I discovered that there is no "Build" menu and the menu item is actually under the "Debug" menu. I have attached my first attempt at a patch in the hopes that this might be fixed.

----------
components: Devguide
files: setup.patch
keywords: patch
messages: 161373
nosy: ezio.melotti, michael.driscoll
priority: normal
severity: normal
status: open
title: Windows Build instruction typo
versions: Python 3.4
Added file: http://bugs.python.org/file25674/setup.patch

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

From report at bugs.python.org  Tue May 22 22:01:45 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 22 May 2012 20:01:45 +0000
Subject: [New-bugs-announce] [issue14885] shutil tests,
	test_copy2_xattr and test_copyxattr, fail
Message-ID: <1337716905.24.0.187943814331.issue14885@psf.upfronthosting.co.za>


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

$ ./python -m test -v test_shutil
...[snip]...
======================================================================
ERROR: test_copy2_xattr (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wena/src/python/cpython/Lib/test/test_shutil.py", line 439, in test_copy2_xattr
    os.setxattr(src, 'user.foo', b'42')
OSError: [Errno 95] Operation not supported

======================================================================
ERROR: test_copyxattr (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wena/src/python/cpython/Lib/test/test_shutil.py", line 325, in test_copyxattr
    os.setxattr(src, 'user.foo', b'42')
OSError: [Errno 95] Operation not supported

...[snip]...

----------
components: Library (Lib)
messages: 161376
nosy: hynek, tarek, tshepang
priority: normal
severity: normal
status: open
title: shutil tests, test_copy2_xattr and test_copyxattr, fail
versions: Python 3.3

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

From report at bugs.python.org  Wed May 23 11:25:29 2012
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 23 May 2012 09:25:29 +0000
Subject: [New-bugs-announce] [issue14886] json C vs pure-python
	implementation difference
Message-ID: <1337765129.86.0.0917200779683.issue14886@psf.upfronthosting.co.za>


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

Pure-python implementation:
    if isinstance(o, (list, tuple)):

C implementation:
    if (PyList_Check(obj) || PyTuple_Check(obj))

This make real difference (!) in my code.

So, please change pure-python implementation to:
    if type(o) in (list, tuple):
Or, fix C implementation to: /* intentionally forgot (only for this example) to check if return value is -1 */
    if (PyObject_IsInstance(obj, PyList_Type) || PyObject_IsInstance(obj, PyTuple_Type)

----------
components: Library (Lib)
messages: 161395
nosy: mmarkk
priority: normal
severity: normal
status: open
title: json C vs pure-python implementation difference
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May 23 11:38:50 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 23 May 2012 09:38:50 +0000
Subject: [New-bugs-announce] [issue14887] pysetup: unfriendly error message
	for unknown commands
Message-ID: <1337765930.75.0.694558770649.issue14887@psf.upfronthosting.co.za>


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

The pysetup3 command gives a fairly unfriendly error message with python traceback when you specify an unknown command:


pysetup3 instal
Unrecognized action "instal"
Traceback (most recent call last):
  File "/Library/Frameworks/PythonDev.framework/Versions/3.3/lib/python3.3/packaging/run.py", line 647, in main
    dispatcher = Dispatcher(args)
  File "/Library/Frameworks/PythonDev.framework/Versions/3.3/lib/python3.3/packaging/run.py", line 401, in __init__
    raise PackagingArgError(msg)
packaging.errors.PackagingArgError: Unrecognized action "instal"


The traceback is not useful for the user of the script and should therefore not be shown.


BTW. It would also be nice if 'pysetup3 help' would give the same output as 'pysetup3 --help', similar to how 'hg help' behaves.

----------
assignee: eric.araujo
components: Distutils2
messages: 161396
nosy: alexis, eric.araujo, ronaldoussoren, tarek
priority: low
severity: normal
stage: needs patch
status: open
title: pysetup: unfriendly error message for unknown commands
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed May 23 15:20:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 May 2012 13:20:14 +0000
Subject: [New-bugs-announce] [issue14888] _md5 module crashes on large data
Message-ID: <1337779214.24.0.36753428268.issue14888@psf.upfronthosting.co.za>


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

This appears to be 2.7-only:

$ ./python -m test.regrtest -M5G -v test_hashlib
== CPython 2.7.3+ (2.7:086afe7b61f5, May 23 2012, 15:15:34) [GCC 4.5.2]
==   Linux-2.6.38.8-desktop-10.mga-x86_64-with-mandrake-1-Official little-endian
==   /home/antoine/cpython/27/build/test_python_6042
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_hashlib
test_algorithms_attribute (test.test_hashlib.HashLibTestCase) ... ok
test_case_md5_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_md5_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_md5_2 (test.test_hashlib.HashLibTestCase) ... ok
test_case_md5_huge (test.test_hashlib.HashLibTestCase) ... python: /home/antoine/cpython/27/Modules/md5module.c:276: MD5_new: Assertion `(Py_ssize_t)(unsigned int)(view.len) == (view.len)' failed.
Abandon

----------
components: Extension Modules
messages: 161406
nosy: gregory.p.smith, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: _md5 module crashes on large data
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed May 23 16:39:51 2012
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 23 May 2012 14:39:51 +0000
Subject: [New-bugs-announce] [issue14889] PyBytes_FromObject(bytes_object)
	fails
Message-ID: <1337783991.34.0.187633914161.issue14889@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

If you pass a valid PyUnicodeObject into PyUnicode_AsObject(), it incref's the original object and returns it.

If you pass a valid PyBytesObject into PyBytes_AsObject()... it fails.

I assert that in the PyBytes_AsObject() should behave like PyUnicode_AsObject() when faced with an identity transformation.

(Brett: I tagged you because I saw your name in the comments, so I figured you were a good candidate.)

----------
assignee: larry
messages: 161414
nosy: brett.cannon, larry
priority: normal
severity: normal
stage: needs patch
status: open
title: PyBytes_FromObject(bytes_object) fails
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed May 23 18:06:05 2012
From: report at bugs.python.org (ninsen)
Date: Wed, 23 May 2012 16:06:05 +0000
Subject: [New-bugs-announce] [issue14890] typo in difflib
Message-ID: <1337789165.67.0.646119826221.issue14890@psf.upfronthosting.co.za>


Changes by ninsen <jcslassi at gmail.com>:


----------
components: Library (Lib)
files: mywork.patch
keywords: patch
nosy: ninsen
priority: normal
severity: normal
status: open
title: typo in difflib
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25683/mywork.patch

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

From report at bugs.python.org  Wed May 23 18:19:36 2012
From: report at bugs.python.org (Frederick Ross)
Date: Wed, 23 May 2012 16:19:36 +0000
Subject: [New-bugs-announce] [issue14891] An error in bindings of closures
Message-ID: <1337789976.83.0.562394292273.issue14891@psf.upfronthosting.co.za>


New submission from Frederick Ross <madhadron at gmail.com>:

The following code throws an UnboundLocal error:

def f(x):
    def g():
        x = x + "a"
        return x
    return g()
f("b")

----------
components: None
messages: 161432
nosy: Frederick.Ross
priority: normal
severity: normal
status: open
title: An error in bindings of closures
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 23 20:55:19 2012
From: report at bugs.python.org (olivier-mattelaer)
Date: Wed, 23 May 2012 18:55:19 +0000
Subject: [New-bugs-announce] [issue14892] 'import readline' fails when
	launching with '&'
Message-ID: <1337799319.38.0.727886103909.issue14892@psf.upfronthosting.co.za>


New submission from olivier-mattelaer <olivier.mattelaer at uclouvain.be>:

Hi Everyone, 

I have found a strange behavior of the import command for the routine readline:

The commands (put in the file test.py) is simply:
import readline
print readline.__doc__

If I run this programs "normally" (i.e. python2.x test.py) everything runs normally:
[tmp]$ python2.7 tmp.py 
Importing this module enables command line editing using GNU readline.

But if I launched it in the following way:
python2.X test.py &
It's stops before finishing the import command (so no output even if I print the output into a file). 
This doesn't raise any error just stop the program.

I tried to add a try...except...finally... but even the finally statement is not executed.

Of course, I realize that readline is not that interesting to load with that options. So I would be more than happy if you could indicate me a way to either detect that the user launch the program with '&' or a way to avoid readline to stop the program in this situations.

Thanks a lot,

Olivier

----------
assignee: ronaldoussoren
components: Macintosh
messages: 161450
nosy: olivier-mattelaer, ronaldoussoren
priority: normal
severity: normal
status: open
title: 'import readline' fails when launching with '&'
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed May 23 21:42:35 2012
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 23 May 2012 19:42:35 +0000
Subject: [New-bugs-announce] [issue14893] Tutorial: Add function annotation
	example to function	tutorial
Message-ID: <1337802155.15.0.316800230533.issue14893@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

A couple months ago, I had never before heard of function annotations and came across a function that had them (I don't remember where or what it was).  I spent a fair bit of time searching fruitlessly to figure out what the heck that "->" in the function definition meant.  Then finally, a week or two ago, I came across a mention of pep 3107 and function annotations, and figured out what it was that confused me so thoroughly.

In an effort to save others from the same confusion, I've put together a small subsection to add to the tutorial about function definition.  The text I'm proposing to add is as follows:

"""
:ref:`Function annotations <function>` are completely optional,
arbitrary metadata information about user-defined functions.  Python itself
currently does not use annotations for anything, so this section is just for
familiarity with the syntax.

Annotations are stored in the :attr:`__annotations__` attribute of the function
as a dictionary and have no effect on any other part of the function.  Parameter
annotations are defined by a colon after the parameter name, followed by an
expression evaluating to the value of the annotation.  Return annotations are
defined by a literal ``->``, followed by an expression, between the parameter
list and the colon denoting the end of the :keyword:`def` statement.  The
following example has a positional argument, a keyword argument, and the return
value annotated with nonsense::

   >>> def f(ham: 42, eggs: int = 'spam') -> "Nothing to see here":
   ...     print("Annotations:", f.__annotations__) # print the function's own annotations
   ...     print("Arguments:", ham, eggs)
   ...
   >>> f('wonderful')
   Annotations: {'eggs': <class 'int'>, 'return': 'Nothing to see here', 'ham': 42}
   Arguments: wonderful spam
"""

I'd also like to see a link for "->" in the index, either to this note or to the relevant paragraph of compound_stmts.rst or both.  The attached patch attempts to add such a link to this section, but I'm not certain that it's done properly.

Thanks :)

----------
assignee: docs at python
components: Documentation
files: annotations_tutorial.patch
keywords: patch
messages: 161451
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Tutorial: Add function annotation example to function tutorial
type: enhancement
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25684/annotations_tutorial.patch

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

From report at bugs.python.org  Wed May 23 22:42:29 2012
From: report at bugs.python.org (Natalia)
Date: Wed, 23 May 2012 20:42:29 +0000
Subject: [New-bugs-announce] [issue14894] distutils.LooseVersion fails to
	compare number and a word
Message-ID: <1337805749.61.0.661955519892.issue14894@psf.upfronthosting.co.za>


New submission from Natalia <natalia.frydrych at gmail.com>:

$ python2.7 -c 'from distutils.version import LooseVersion as V; print V("a") > V("1")'
True
$ python3.2 -c 'from distutils.version import LooseVersion as V; print(V("a") > V("b"))'
False
$ python3.2 -c 'from distutils.version import LooseVersion as V; print(V("a") > V("1"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.2/distutils/version.py", line 70, in __gt__
    c = self._cmp(other)
  File "/usr/lib/python3.2/distutils/version.py", line 343, in _cmp
    if self.version < other.version:
TypeError: unorderable types: str() < int()

----------
assignee: eric.araujo
components: Distutils
messages: 161453
nosy: Natalia, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils.LooseVersion fails to compare number and a word
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May 23 23:50:47 2012
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 23 May 2012 21:50:47 +0000
Subject: [New-bugs-announce] [issue14895] test_warnings.py
	EnvironmentVariableTests is a bad test
Message-ID: <1337809847.78.0.457285588571.issue14895@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

EnvironmentVariableTests depends on format of string representation of objects.

While working on Jython 2.7 the test failed due to:
    AssertionError: "[u'ignore::DeprecationWarning']" != "['ignore::DeprecationWarning']"

Attached is a patch to get the output of child process via marshal and also use set so order is not important.

----------
components: Tests
files: tw.diff
keywords: patch
messages: 161463
nosy: tebeka
priority: normal
severity: normal
status: open
title: test_warnings.py EnvironmentVariableTests is a bad test
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file25692/tw.diff

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

From report at bugs.python.org  Thu May 24 03:16:54 2012
From: report at bugs.python.org (Peter VG)
Date: Thu, 24 May 2012 01:16:54 +0000
Subject: [New-bugs-announce] [issue14896] plistlib handling of real datatype
Message-ID: <1337822214.65.0.825826573046.issue14896@psf.upfronthosting.co.za>


New submission from Peter VG <petervg at gmail.com>:

Since strings cannot reliably be converted to floats and back, plistlib should provide an option to treat the real datatype as strings/data or to use the Decimal library class. Currently, reading and then writing a real value can change its representation in the plist even if it has not been modified. For instance:

Read:
<real>0.015</real>
Written:
<real>0.014999999999999999</real>

or 

Read:
<real>0.4</real>
Written:
<real>0.40000000000000002</real>

----------
messages: 161471
nosy: pvg
priority: normal
severity: normal
status: open
title: plistlib handling of real datatype
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/issue14896>
_______________________________________

From report at bugs.python.org  Thu May 24 08:21:59 2012
From: report at bugs.python.org (mesheb82)
Date: Thu, 24 May 2012 06:21:59 +0000
Subject: [New-bugs-announce] [issue14897] struct.pack raises unexpected
	error message
Message-ID: <1337840519.45.0.558860957014.issue14897@psf.upfronthosting.co.za>


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

I found some unexpected behavior while working with the struct module.
>>> import struct

This works as expected:
>>> struct.pack('1s1s','3','4')
'34'

In this case, with bad input, the error message says I need 2 arguments, when I provide 2 arguments.
>>> struct.pack('1s1s','33')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: pack requires exactly 2 arguments

----------
components: IO
messages: 161481
nosy: mesheb82
priority: normal
severity: normal
status: open
title: struct.pack raises unexpected error message
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu May 24 12:38:30 2012
From: report at bugs.python.org (Sasha B)
Date: Thu, 24 May 2012 10:38:30 +0000
Subject: [New-bugs-announce] [issue14898] Dict collision on boolean and
	integer values
Message-ID: <1337855910.73.0.357745750737.issue14898@psf.upfronthosting.co.za>


New submission from Sasha B <sbermeister at gmail.com>:

Not sure if this is predicted behaviour, but if I make a dict like:

>>> x = {0: 'bar', True: 'foo'}

and modify True with 1, or 0 with False:
>>> x[False] = 'boo'
>>> x[1] = 'far'

the modifications happen:
>>> x
{0: 'boo', True: 'far'}

Is this expected behaviour? It seems that the hashes for 'False' and 0 are confused, as are the hashes for 'True' and 1.

----------
messages: 161497
nosy: sbermeister
priority: normal
severity: normal
status: open
title: Dict collision on boolean and integer values

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

From report at bugs.python.org  Thu May 24 14:42:06 2012
From: report at bugs.python.org (=?utf-8?q?Beno=C3=AEt_Bryon?=)
Date: Thu, 24 May 2012 12:42:06 +0000
Subject: [New-bugs-announce] [issue14899] Naming conventions and guidelines
	for packages and	namespace packages
Message-ID: <1337863326.85.0.0790625001968.issue14899@psf.upfronthosting.co.za>


New submission from Beno?t Bryon <benoit at marmelune.net>:

Scope:

* Python documentation lacks conventions, or at least guidelines,
  to choose a name for a package.

* Python has tools to create and distribute packages.
  Not covered by this issue.

* Python has tools to create namespace packages.
  Not covered by this issue.

* Python has conventions about "syntax" of module names in PEP 8.
  Not covered by this issue.

Goal: add guidelines+conventions about package names in Doc/packaging/

Discussion started at http://mail.python.org/pipermail/distutils-sig/2012-May/018551.html

Jim Fulton said in http://mail.python.org/pipermail/distutils-sig/2012-May/018553.html:

> +1 for an official document (or addition to an existinhg document)
     providing a rational for namespace packages and their naming

Here is a ticket where proposals can be referenced.

Contributions can be pushed on the "doc-package-naming-conventions" branch of https://bitbucket.org/benoitbryon/cpython

----------
assignee: docs at python
components: Documentation
hgrepos: 128
messages: 161502
nosy: benoitbryon, docs at python
priority: normal
severity: normal
status: open
title: Naming conventions and guidelines for packages and namespace packages
type: enhancement

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

From report at bugs.python.org  Thu May 24 16:19:23 2012
From: report at bugs.python.org (Arne Babenhauserheide)
Date: Thu, 24 May 2012 14:19:23 +0000
Subject: [New-bugs-announce] [issue14900] cProfile does not take its result
	headers as sort	arguments
Message-ID: <1337869163.57.0.920578910684.issue14900@psf.upfronthosting.co.za>


New submission from Arne Babenhauserheide <arne_bab at web.de>:

cProfile reports the profiling result in a table with the headers

  ncalls  tottime  percall  cumtime  percall filename:lineno(function)

The respective arguments are 

  calls   time     -        cumulative -     nfl

Since I had to lookup these different names everytime I used cProfile, I think that it should take the table headings as argument aliases.

Also there is inconsistent naming of pcalls between docs and code.

In the docs of Stats.sort_stats pcalls is named primitive call count.
In the code at Stats.sort_arg_dict_default it was just named call count.

I created 4 patches to fix that in Python 2.7 and Python 3.2. The first is attached here, the later will be attached to comments. 

They apply to 822d7a1f8885 for 2.7 and 89b699e68fa2 for 3.2.

I also created a patch for adding percall sorting, but that requires more invasive changes and I did not see a simple name to distinguish between the two bycall headings.

----------
components: Library (Lib)
files: 2.7-0-pcalls.diff
keywords: patch
messages: 161508
nosy: ArneBab
priority: normal
severity: normal
status: open
title: cProfile does not take its result headers as sort arguments
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file25695/2.7-0-pcalls.diff

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

From report at bugs.python.org  Thu May 24 17:26:07 2012
From: report at bugs.python.org (Michael Driscoll)
Date: Thu, 24 May 2012 15:26:07 +0000
Subject: [New-bugs-announce] [issue14901] Python Windows FAQ is Very Outdated
Message-ID: <1337873167.77.0.855144378298.issue14901@psf.upfronthosting.co.za>


New submission from Michael Driscoll <mike at pythonlibrary.org>:

I was reading through http://docs.python.org/faq/windows.html and noticed that its examples are based on Python 2.2-2.3 and it only really covers up to Windows 2000 with just a couple mentions of XP. 

There are also sections in there that I'm not even sure are still issues, such as the "Why does Python sometimes take so long to start?" and "Where is Freeze for Windows?". The latter should probably be a different question like "How do I make my program into an EXE?" or similar and then list some of the binary building scripts, like cx_freeze, py2exe, bbfreeze, etc, especially since the "freeze" script isn't included in the newer distros as far as I can tell. At least, it's not in the location that the FAQ says it is.

Do we even want the questions about NT and Windows 98? I would be happy to try to update the FAQ if my fellow developers can give me some direction on what we need to cut, keep and/or add.

----------
messages: 161519
nosy: michael.driscoll
priority: normal
severity: normal
status: open
title: Python Windows FAQ is Very Outdated

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

From report at bugs.python.org  Thu May 24 20:42:40 2012
From: report at bugs.python.org (Yuriy Syrovetskiy)
Date: Thu, 24 May 2012 18:42:40 +0000
Subject: [New-bugs-announce] [issue14902] test_logging failed
Message-ID: <1337884960.13.0.189536942826.issue14902@psf.upfronthosting.co.za>


New submission from Yuriy Syrovetskiy <cblp at cblp.su>:

rev 152c78b94e41

test test_logging failed -- Traceback (most recent call last):
  File "/home/cblp/my/cpython_default/Lib/test/test_logging.py", line 2903, in test_time
    self.assertEqual(f.formatTime(r), '1993-04-21 08:03:00,123')
AssertionError: '1993-04-21 09:03:00,123' != '1993-04-21 08:03:00,123'
- 1993-04-21 09:03:00,123
?             ^
+ 1993-04-21 08:03:00,123
?             ^

----------
components: Tests
messages: 161523
nosy: cblp
priority: normal
severity: normal
status: open
title: test_logging failed
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Thu May 24 22:19:44 2012
From: report at bugs.python.org (Daniel Farina)
Date: Thu, 24 May 2012 20:19:44 +0000
Subject: [New-bugs-announce] [issue14903] dictobject infinite loop on 2.6.5
	on 32-bit x86
Message-ID: <1337890784.99.0.00556765207687.issue14903@psf.upfronthosting.co.za>


New submission from Daniel Farina <daniel at heroku.com>:

I seem to be encountering somewhat rare an infinite loop
in hash table probing while importing _socket, as triggered by
init_socket.c in Python 2.6, as seen/patched shipped with Ubuntu 10.04
LTS.  The problem only reproduces on 32 bit machines, on both -O2 and
-O0 builds (which is how I have managed to retrieve the detailed stack
traces below).  To cut to the chase, the bottom of the stack trace
invariably looks like this, in particular the "key" (and therefore
"hash") value is always the same:

#0  0x08088637 in lookdict_string (mp=0xa042714, key='SO_RCVTIMEO',
   hash=612808203) at ../Objects/dictobject.c:421
#1  0x080886cd in insertdict (mp=0xa042714, key='SO_RCVTIMEO', hash=612808203,
   value=20) at ../Objects/dictobject.c:450
#2  0x08088cac in PyDict_SetItem (op=<unknown at remote 0x37>, key=
   'SO_RCVTIMEO', value=20) at ../Objects/dictobject.c:701
#3  0x0808b8d4 in PyDict_SetItemString (v=
   {'AF_INET6': 10, 'SocketType': <type at remote 0x8275e00>,
'getaddrinfo': <built-in function getaddrinfo>,
'TIPC_MEDIUM_IMPORTANCE': 1, 'htonl': <built-in function htonl>,
'AF_UNSPEC': 0, 'TIPC_DEST_DROPPABLE': 129, 'TIPC_ADDR_ID': 3,
'PF_PACKET': 17, 'AF_WANPIPE': 25, 'PACKET_OTHERHOST': 3, 'AF_AX25':
3, 'PACKET_BROADCAST': 1, 'PACKET_FASTROUTE': 6, 'TIPC_NODE_SCOPE': 3,
'inet_pton': <built-in function inet_pton>, 'AF_ATMPVC': 8,
'NETLINK_IP6_FW': 13, 'NETLINK_ROUTE': 0, 'TIPC_PUBLISHED': 1,
'TIPC_WITHDRAWN': 2, 'AF_ECONET': 19, 'AF_LLC': 26, '__name__':
'_socket', 'AF_NETROM': 6, 'SOCK_RDM': 4, 'AF_IRDA': 23, 'htons':
<built-in function htons>, 'SOCK_RAW': 3, 'inet_ntoa': <built-in
function inet_ntoa>, 'AF_NETBEUI': 13, 'AF_NETLINK': 16,
'TIPC_WAIT_FOREVER': -1, 'AF_UNIX': 1, 'TIPC_SUB_PORTS': 1,
'HCI_TIME_STAMP': 3, 'gethostbyname_ex': <built-in function
gethostbyname_ex>, 'SO_RCVBUF': 8, 'AF_APPLETALK': 5,
'SOCK_SEQPACKET': 5, 'AF_DECnet': 12, 'PACKET_OUTGOING': 4,
'SO_SNDLOWAT': 19, 'TIPC_SRC_DROPPABLE':...(truncated), key=0x81ac5fb
"SO_RCVTIMEO", item=20) at ../Objects/dictobject.c:2301
#4  0x080f6c98 in PyModule_AddObject (m=<module at remote 0xb73cac8c>, name=
   0x81ac5fb "SO_RCVTIMEO", o=20) at ../Python/modsupport.c:615
#5  0x080f6d0b in PyModule_AddIntConstant (m=<module at remote 0xb73cac8c>,
   name=0x81ac5fb "SO_RCVTIMEO", value=20) at ../Python/modsupport.c:627
#6  0x081321fd in init_socket () at ../Modules/socketmodule.c:4708

Here, we never escape from lookdict_string.  The key is not in the
dictionary, but at this stage Python is trying to figure out that is
the case, and cannot seem to exit because of the lack of a dummy
entry.  Furthermore, every single reproduced case has a dictionary
with a suspicious looking violation of an invariant that I believe is
communicated by the source of dictobject.c, with emphasis on the
values of ma_fill, ma_used, and ma_mask, which never deviate in any
reproduced case.  It seems like no hash table should ever get this
full, per the comments in the source:

$3 = {ob_refcnt = 1, ob_type = 0x81c3aa0, ma_fill = 128, ma_used = 128,
 ma_mask = 127, ma_table = 0xa06b4a8, ma_lookup =
   0x8088564 <lookdict_string>, ma_smalltable = {{me_hash = 0, me_key = 0x0,
     me_value = 0x0}, {me_hash = 1023053529, me_key = '__name__', me_value =
   '_socket'}, {me_hash = 1679430097, me_key = 'gethostbyname', me_value =
   <built-in function gethostbyname>}, {me_hash = 0, me_key = 0x0, me_value =
   0x0}, {me_hash = 779452068, me_key = 'gethostbyname_ex', me_value =
   <built-in function gethostbyname_ex>}, {me_hash = -322108099, me_key =
   '__doc__', me_value = None}, {me_hash = -1649837379, me_key =
   'gethostbyaddr', me_value = <built-in function gethostbyaddr>}, {
     me_hash = 1811348911, me_key = '__package__', me_value = None}}}

The Python program that is running afoul this bug is using gevent, but
the stack traces suggest that all gevent is doing at the time this
crashes is importing "socket", and this is done at the very, very
beginning of program execution.

Finally, what's especially strange is that I had gone a very long time
running this exact version of Python, libraries, and application quite
frequently: it suddenly started cropping up a little while ago (maybe
a few weeks).  It could have been just coincidence, but if there are
code paths in init_socket.c that may somehow be sensitive to the
network somehow, this could have been related.  I also have a limited
suspicion that particularly unlucky OOM (these systems are configured
in a way where malloc and friends will return NULL, i.e. no overcommit
on Linux) could be related.

----------
components: Interpreter Core
messages: 161527
nosy: Daniel.Farina
priority: normal
severity: normal
status: open
title: dictobject infinite loop on 2.6.5 on 32-bit x86
type: behavior
versions: 3rd party, Python 2.6

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

From report at bugs.python.org  Fri May 25 01:46:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 May 2012 23:46:52 +0000
Subject: [New-bugs-announce] [issue14904] test_unicode_repr_oflw (in
	test_bigmem) crashes
Message-ID: <1337903212.58.0.439916347295.issue14904@psf.upfronthosting.co.za>


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

Someone needs to debug this (someone with enough RAM).

http://www.python.org/dev/buildbot/all/builders/AMD64%20Ubuntu%20LTS%20bigmem%202.7/builds/6/steps/test/logs/stdio

My intuition is that the crash is on the eval(), since test_unicode_repr above passes.

----------
components: Interpreter Core, Tests
messages: 161535
nosy: benjamin.peterson, lukasz.langa, pitrou, twouters
priority: normal
severity: normal
status: open
title: test_unicode_repr_oflw (in test_bigmem) crashes
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri May 25 02:27:07 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 25 May 2012 00:27:07 +0000
Subject: [New-bugs-announce] [issue14905] zipimport.c needs to support
	namespace packages when no	'directory' entry exists
Message-ID: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

If a zip file contains "pkg/foo.py" but no "pkg/" entry, it will not be possible for "pkg" to be a namespace package portion.

----------
components: Extension Modules
messages: 161543
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: zipimport.c needs to support namespace packages when no 'directory' entry exists
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri May 25 04:19:39 2012
From: report at bugs.python.org (Curu Wong)
Date: Fri, 25 May 2012 02:19:39 +0000
Subject: [New-bugs-announce] [issue14906] rotatingHandler WindowsError
Message-ID: <1337912379.85.0.584273983424.issue14906@psf.upfronthosting.co.za>


New submission from Curu Wong <prinbra at gmail.com>:

I setup and use rotatingHandler this way:
=========================================================
#create logger
logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)
#create rotate handler
rotatefh = logging.handlers.RotatingFileHandler(filename=logfile, maxBytes=20000000, backupCount=100)
rotatefh.setLevel(logging.INFO)
#create formatter
formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s')
rotatefh.setFormatter(formatter)
logger.addHandler(rotatefh)
...
	logger.info("%s, create time: %s" % (pdb, time.strftime("%Y-%m-%d %H:%M:%S", time.localtime(create_time))))
	logger.info("copying '%s' to '%s' ..." % (src, dst))
	copy_cmd = 'xcopy /I /E /Y "%s" "%s"' % (src, dst)
	process = subprocess.Popen(copy_cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
	for msg in process.stdout:
		logger.info(msg.strip())
	process.wait()
	error_msg = process.stderr.read()
	if error_msg:
		logger.error(error_msg.strip())
	else:
		if build_num in release_version:
			logger.info("leave release version '%s' un touched" % pdb)
			continue
		else:
			logger.info("deleting '%s'" % src)
			subprocess.call('rd /s /q "%s"' % src, shell=True)
	logger.info("=" * 80)
==========================================================
All other part has nothing to do with log file.
when it comes to rotate, I always get this error:


============================================================
Traceback (most recent call last):
  File "C:\Python27\lib\logging\handlers.py", line 78, in emit
    self.doRollover()
  File "C:\Python27\lib\logging\handlers.py", line 141, in doRollover
    os.rename(self.baseFilename, dfn)
WindowsError: [Error 32]
Logged from file backup_pdb.py, line 76
Traceback (most recent call last):
  File "C:\Python27\lib\logging\handlers.py", line 78, in emit
    self.doRollover()
  File "C:\Python27\lib\logging\handlers.py", line 141, in doRollover
    os.rename(self.baseFilename, dfn)
WindowsError: [Error 32]
Logged from file backup_pdb.py, line 76
Traceback (most recent call last):
  File "C:\Python27\lib\logging\handlers.py", line 78, in emit
    self.doRollover()
  File "C:\Python27\lib\logging\handlers.py", line 141, in doRollover
    os.rename(self.baseFilename, dfn)
WindowsError: [Error 32]
Logged from file backup_pdb.py, line 76
============================================================
I don't have any anti-virus software on this machine,  the error is somewhat like http://bugs.python.org/issue14450 . However, I have only one handler referring to the log file, but still get the error.

----------
components: Library (Lib), Windows
messages: 161546
nosy: jacuro
priority: normal
severity: normal
status: open
title: rotatingHandler WindowsError
versions: Python 2.7

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

From report at bugs.python.org  Fri May 25 08:49:10 2012
From: report at bugs.python.org (Marc Schlaich)
Date: Fri, 25 May 2012 06:49:10 +0000
Subject: [New-bugs-announce] [issue14907] SSL module cannot handle unicode
	filenames
Message-ID: <1337928550.27.0.394572153469.issue14907@psf.upfronthosting.co.za>


New submission from Marc Schlaich <marc.schlaich at googlemail.com>:

Here is a short example to reproduce the error:

>>> import socket, ssl
>>> sock = socket.socket()
>>> sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_REQUIRED, ca_certs=u'?.crt')
>>> sock.connect((None, None))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\ssl.py", line 322, in connect
    self._real_connect(addr, False)
  File "C:\Python27\lib\ssl.py", line 305, in _real_connect
    self.ca_certs, self.ciphers)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0:
ordinal not in range(128)

----------
components: Library (Lib), Unicode
messages: 161554
nosy: ezio.melotti, ms4py
priority: normal
severity: normal
status: open
title: SSL module cannot handle unicode filenames
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri May 25 10:53:20 2012
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 25 May 2012 08:53:20 +0000
Subject: [New-bugs-announce] [issue14908] datetime.datetime should have a
	timestamp() method
Message-ID: <1337936000.24.0.545813704843.issue14908@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

There's datetime.fromtimestamp() and datetime.timetuple(), but no datetime.timestamp(). It should be possible to round-trip a UNIX timestamp through a datetime.datetime.

----------
messages: 161558
nosy: djc
priority: normal
severity: normal
status: open
title: datetime.datetime should have a timestamp() method
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May 25 11:58:18 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 25 May 2012 09:58:18 +0000
Subject: [New-bugs-announce] [issue14909] Fix incorrect use of *Realloc()
	and *Resize()
Message-ID: <1337939898.7.0.470133921814.issue14909@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

A number of places were using PyMem_Realloc() apis and PyObject_GC_Resize() with incorrect error handling.  In case of errors, they would leak the original object.  This patch fixes those cases.

----------
files: realloc.diff
keywords: patch
messages: 161561
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Fix incorrect use of *Realloc() and *Resize()
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file25703/realloc.diff

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

From report at bugs.python.org  Fri May 25 12:59:55 2012
From: report at bugs.python.org (=?utf-8?q?Jens_J=C3=A4hrig?=)
Date: Fri, 25 May 2012 10:59:55 +0000
Subject: [New-bugs-announce] [issue14910] argparse disable abbreviation
Message-ID: <1337943595.94.0.585154488375.issue14910@psf.upfronthosting.co.za>


Changes by Jens J?hrig <jaehrig.jens at googlemail.com>:


----------
components: None
nosy: jens.jaehrig
priority: normal
severity: normal
status: open
title: argparse disable abbreviation
type: enhancement
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri May 25 13:02:16 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 25 May 2012 11:02:16 +0000
Subject: [New-bugs-announce] [issue14911] generator.throw() documentation
	inaccurate
Message-ID: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

the documentation for generator.throw() does not mention the fact that it has the same semantics for the three arguments as a "raise" expression has.
The first two arguments can be:
throw(exc_type, None)
throw(exc_type, value)
throw(exc_type, exc_instance)
throw(exc_instance, None)

----------
assignee: docs at python
components: Documentation
messages: 161565
nosy: docs at python, kristjan.jonsson
priority: normal
severity: normal
status: open
title: generator.throw() documentation inaccurate
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri May 25 13:35:57 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 25 May 2012 11:35:57 +0000
Subject: [New-bugs-announce] [issue14912] Pdb does not stop at a breakpoint
	after a restart	command and source changes
Message-ID: <1337945757.27.0.114974346451.issue14912@psf.upfronthosting.co.za>


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

In the following session, main.py is changed just before the restart
command. Pdb does not stop at Breakpoint 1 after the last continue.

$ python -m pdb main.py
> /path_to/main.py(1)<module>()
-> def foo():
(Pdb) import sys; print(sys.version)
3.2.2 (default, Dec 27 2011, 17:35:55) 
[GCC 4.3.2]
(Pdb) break foo
Breakpoint 1 at /path_to/main.py:1
(Pdb) list
  1 B-> def foo():
  2         x = 1
  3         x = 2
  4
  5     foo()
[EOF]
(Pdb) continue
> /path_to/main.py(2)foo()
-> x = 1
(Pdb) restart
Restarting main.py with arguments:
        main.py
> /path_to/main.py(1)<module>()
-> def bar():
(Pdb) list
  1 B-> def bar():
  2         x = 1
  3         x = 2
  4
  5     def foo():
  6         bar()
  7
  8     foo()
[EOF]
(Pdb) continue
The program finished and will be restarted
> /path_to/main.py(1)<module>()
-> def bar():
(Pdb)

----------
components: Library (Lib)
messages: 161567
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Pdb does not stop at a breakpoint after a restart command and source changes
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri May 25 13:49:13 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 25 May 2012 11:49:13 +0000
Subject: [New-bugs-announce] [issue14913] tokenize the source to manage Pdb
	breakpoints
Message-ID: <1337946553.88.0.954704249232.issue14913@psf.upfronthosting.co.za>


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

Pdb behavior is not consistent with GNU gdb behavior when setting a
breakpoint on an empty line, a comment or a multi-line statement (the
breakpoint is ignored by pdb on a non-first line of a multi-line
statement and rejected on empty lines or comment lines).  It is also
confusing that, when a breakpoint is set on a function definition, pdb
also stops at the function definition execution when the module is
being loaded.

Pdb performance:
----------------
When a breakpoint is set in a module, pdb sets the trace function on
all the frames whose function is defined in this module (and the trace
function is run for each line in the function), regardless of the fact
that the function may not have any breakpoint.

Pdb breakpoint management problems:
-----------------------------------
See issue 14789, issue 14792, issue 14795, issue 14808 and issue 14912.

Pdb rejects setting a breakpoint in a function or method defined in a
non imported submodule of a package, but accepts to set it when the
non imported module is not in a package.  For example with
'asyncore.close_all' and 'logging.info':

    $ python
    Python 3.2.2 (default, Dec 27 2011, 17:35:55) 
    [GCC 4.3.2] on linux2
    Type "help", "copyright", "credits" or "license" for more
    information.
    >>> import pdb; pdb.run('def foo(): pass')
    > <string>(1)<module>()
    (Pdb) break asyncore.close_all
    Breakpoint 1 at /usr/local/lib/python3.2/asyncore.py:580
    (Pdb) break logging.info
    *** The specified object 'logging.info' is not a function or was
    not found along sys.path.

When a breakpoint is set at the line number of a function definition,
the algorithm used to find the first statement of the function (the
actual breakpoint) is not robust, so that when another breakpoint is
also set at this fuction using the function name instead of the line
number, then this last breakpoint hides the first one.


Use tokenize:
-------------
One solution is to parse the module source to build a description of
each function and method defined in the source:
    The description is the set of line_set of a function.  A line_set
    is either the line(s) of a function definition statement, or a
    group of consecutive statement lines, or a group of the physical
    lines of a logical line.

The attached patch implements this solution with std lib tokenize:

    When a breakpoint is set at an empty line or a comment in a
    function, pdb stops at the next statement. When a breakpoint is
    set at a multi-line statement (but not a function definition
    statement), pdb stops at the first line of the multi-line
    statement.  When a breakpoint is set at a line in a function
    definition or at a function name, pdb stops at the first statement
    in this function.  Attempting to set a breakpoint on a line
    outside a function definition is rejected with an error message.
    Pdb does not stop anymore at the function definition execution
    when the module is loaded.

    The trace function is only set on frames whose function has one
    breakpoint or more.

    The patch fixes issue 14789, issue 14792, issue 14795, issue 14808
    and issue 14912.  The patch fixes the problem of setting a
    breakpoint in a function or method defined in package submodule
    when the submodule is not imported.  The patch fixes the problem
    described above of having a breakpoint set by function name hide a
    breakpoint set by line number.  The patch includes test cases for
    all those issues.

    Parser performance: a file is only parsed when a breakpoint is set
    in this file (and parsed only once of course).  Some performance
    results of the parser on a laptop:

        * rpdb2.py from the rpdb2 project: 14500 lines parsed in 2.0
          seconds
        * a more reasonable (but still large) file size with
          turtle.py from the std library: 4100 lines parsed in 0.6
          second

----------
components: Library (Lib)
files: pdb_default.patch
keywords: patch
messages: 161570
nosy: xdegaye
priority: normal
severity: normal
status: open
title: tokenize the source to manage Pdb breakpoints
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25704/pdb_default.patch

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

From report at bugs.python.org  Fri May 25 16:52:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 May 2012 14:52:25 +0000
Subject: [New-bugs-announce] [issue14914] pysetup installed distribute
	despite dry run option	being specified
Message-ID: <1337957545.29.0.422035789743.issue14914@psf.upfronthosting.co.za>


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

After approving the pyvenv PEP, I decided to play around with the other big packaging enhancement in 3.3: pysetup.

The following command installed distribute:

    pysetup3.3 -n install distribute

The "-n" *should* have caused that to be a dry run, but it actually installed the module.

----------
assignee: eric.araujo
components: Distutils2
messages: 161582
nosy: alexis, eric.araujo, ncoghlan, tarek
priority: critical
severity: normal
stage: test needed
status: open
title: pysetup installed distribute despite dry run option being specified
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri May 25 17:03:49 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 May 2012 15:03:49 +0000
Subject: [New-bugs-announce] [issue14915] pysetup may leave a package in a
	half-installed state
Message-ID: <1337958229.94.0.76647930894.issue14915@psf.upfronthosting.co.za>


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

Do "make altinstall" from trunk.

Try running "pysetup3.3 install distutils2"

This won't work properly, because distutils2 uses Python 2 syntax.

However, after running that command:

"pysetup3.3 remove distutils2" complains that distutils2 is not installed, but "import distutils2" works at the 3.3. command prompt

----------
assignee: eric.araujo
components: Distutils2
messages: 161583
nosy: alexis, eric.araujo, ncoghlan, tarek
priority: high
severity: normal
status: open
title: pysetup may leave a package in a half-installed state
versions: Python 3.3

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

From report at bugs.python.org  Fri May 25 17:42:38 2012
From: report at bugs.python.org (Kevin Barry)
Date: Fri, 25 May 2012 15:42:38 +0000
Subject: [New-bugs-announce] [issue14916] PyRun_InteractiveLoop fails to run
	interactively when	using a Linux pty that's not tied to stdin/stdout
Message-ID: <1337960558.56.0.442179213708.issue14916@psf.upfronthosting.co.za>


New submission from Kevin Barry <ta0kira at gmail.com>:

I have been trying to get PyRun_InteractiveLoop to run on a pty (Linux) without replacing stdin and stdout with that pty; however, it seems like Python (2.6.6) is hard-coded to only run interactively on stdin and stdout.


Compile the attached program with:

> gcc `python-config --cflags` working.c -o working `python-config --ldflags`

and run it with:

> ./working xterm -S/0

and you should see that there is no interactivity in the xterm that's opened.


Compile the attached file with:

> gcc -DREADLINE_HACK `python-config --cflags` working.c -o working `python-config --ldflags` -lreadline -lcurses

and run it with:

> ./working xterm -S/0

to see how it runs with my best attempt to get it to function properly with a readline hack. Additionally, try running:

> ./working xterm -S/0 > /dev/null
> ./working xterm -S/0 < /dev/null

both of which should cause interactivity in the xterm to fail, indicating that Python is checking stdin/stdout for tty status when determining if it should run interactively (i.e. it's not checking the tty status of the file passed to PyRun_InteractiveLoop.)


Am I somehow using this function wrong? I've been trying to work around this problem for a while, and I don't think I should be using readline hacks (especially since they don't port to other OSes with ptys, e.g. OS X.) I even tried to patch the call to PyOS_Readline in tok_nextc (Parser/tokenizer.c) to use tok->fp instead of stdin/stdout, which caused I/O to use the pty but it still failed to make interactivity work.


Thanks!

Kevin Barry

----------
components: Interpreter Core, Library (Lib)
files: working.c
messages: 161586
nosy: Kevin.Barry
priority: normal
severity: normal
status: open
title: PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file25706/working.c

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

From report at bugs.python.org  Fri May 25 18:16:01 2012
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 25 May 2012 16:16:01 +0000
Subject: [New-bugs-announce] [issue14917] Make os.symlink on Win32 detect if
	target is directory
Message-ID: <1337962561.24.0.688592071719.issue14917@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

The prototype for os.symlink on Windows adds a "target_is_directory" flag, which indicates whether or not the destination is a directory.

Surely we could detect that and pass in the correct value ourselves?  A quick GetFileAttributes() call would do.  I doubt this would make the function much slower, as it's about to write to that area of the disk anyway.  And if os.symlink is a performance-critical function on Windows I'll eat my hat.

Since os.symlink support for Windows shipped in 3.2, we can't get rid of the argument at the same time.  But we could just ignore it, and since it's marked as optional people could start removing it, and maybe we could deprecate it.

----------
components: Windows
messages: 161587
nosy: larry
priority: low
severity: normal
stage: needs patch
status: open
title: Make os.symlink on Win32 detect if target is directory
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri May 25 18:21:04 2012
From: report at bugs.python.org (Thanos Tsouanas)
Date: Fri, 25 May 2012 16:21:04 +0000
Subject: [New-bugs-announce] [issue14918] Incorrect explanation of TypeError
	exception
Message-ID: <1337962864.62.0.211953440829.issue14918@psf.upfronthosting.co.za>


New submission from Thanos Tsouanas <thanos at sians.org>:

# This correctly raises a type error, but the explanation
# that comes with it is bad:

def foo(x, y, z=28):
    return

foo(x, z=8)

# TypeError: foo() takes at least 2 arguments (2 given)

----------
messages: 161588
nosy: Thanos.Tsouanas
priority: normal
severity: normal
status: open
title: Incorrect explanation of TypeError exception
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May 25 18:44:36 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 25 May 2012 16:44:36 +0000
Subject: [New-bugs-announce] [issue14919] what disables one from adding self
	to the "nosy" list
Message-ID: <1337964276.05.0.327308817778.issue14919@psf.upfronthosting.co.za>


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

It's implied in the devguide[1] that there are cases where one won't have permission to edit the nosy list. Can someone mention on that text what cases are those. I thought everybody who is logged in had such permissions.

1: http://docs.python.org/devguide/triaging.html#nosy-list

----------
components: Devguide
messages: 161590
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: what disables one from adding self to the "nosy" list

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

From report at bugs.python.org  Fri May 25 22:14:23 2012
From: report at bugs.python.org (Tuukka Tolvanen)
Date: Fri, 25 May 2012 20:14:23 +0000
Subject: [New-bugs-announce] [issue14920] help(urllib.parse) fails when
	LANG=C
Message-ID: <1337976863.52.0.802945658166.issue14920@psf.upfronthosting.co.za>


New submission from Tuukka Tolvanen <tuukka.tolvanen at gmail.com>:

LANG=C python3.2 -c 'import urllib.parse; help(urllib.parse)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.2/site.py", line 477, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python3.2/pydoc.py", line 1778, in __call__
    self.help(request)
  File "/usr/lib/python3.2/pydoc.py", line 1828, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/usr/lib/python3.2/pydoc.py", line 1564, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/lib/python3.2/pydoc.py", line 1372, in pager
    pager(text)
  File "/usr/lib/python3.2/pydoc.py", line 1392, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/usr/lib/python3.2/pydoc.py", line 1413, in pipepager
    pipe.write(text)
UnicodeEncodeError: 'ascii' codec can't encode character '\xab' in position 5495: ordinal not in range(128)

presumably the offending part is 
 quote_from_bytes(b'abc def?') -> 'abc%20def%AB'

debian python3.2 3.2.3~rc2-1
macports python32 @3.2.3_0

----------
components: None
messages: 161618
nosy: timeless, tt
priority: normal
severity: normal
status: open
title: help(urllib.parse) fails when LANG=C
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri May 25 22:34:09 2012
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 25 May 2012 20:34:09 +0000
Subject: [New-bugs-announce] [issue14921] New trove classifier for simple
	printers of nested lists
Message-ID: <1337978049.53.0.267517027605.issue14921@psf.upfronthosting.co.za>


New submission from Daniel Holth <dholth at fastmail.fm>:

Based on the supply, there is a tremendous demand for printers of nested lists (as long as they are not too complicated). But how will I find and compare the available options? Add a trove classifier

Topic :: Nested Lists

to ease the search burden.

----------
messages: 161624
nosy: dholth
priority: normal
severity: normal
status: open
title: New trove classifier for simple printers of nested lists
type: enhancement

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

From report at bugs.python.org  Sat May 26 00:55:21 2012
From: report at bugs.python.org (Pablo Oliveira)
Date: Fri, 25 May 2012 22:55:21 +0000
Subject: [New-bugs-announce] [issue14922] mailbox.Maildir.get_message() may
	fail when Maildir	dirname is a unicode string
Message-ID: <1337986521.77.0.280125876775.issue14922@psf.upfronthosting.co.za>


New submission from Pablo Oliveira <pablo at sifflez.org>:

I'm using Python 2.7.3rc2 from debian sid packages.

If a mailbox.Maildir object is created with a unicode dirname,
retrieving a message tagged with maildir flags with get() or get_message() fails with the following exception:

Traceback (most recent call last):
  File "reproduce.py", line 21, in <module>
    mb.get_message(key)
  File "/usr/lib/python2.7/mailbox.py", line 343, in get_message
    msg.set_info(name.split(self.colon)[-1])
  File "/usr/lib/python2.7/mailbox.py", line 1480, in set_info
    raise TypeError('info must be a string: %s' % type(info))
TypeError: info must be a string: <type 'unicode'>


Since python os.path module seems to cope with unicode paths http://docs.python.org/howto/unicode.html, it would be nice to fix this issue.

Attached is a simple script reproducing the bug.

The following patch seems to solve the issue for me:
--- /usr/lib/python2.7/mailbox.py	2012-04-23 01:25:48.000000000 +0200
+++ mailbox.py	2012-05-26 00:34:03.585347627 +0200
@@ -1474,7 +1474,7 @@
 
     def set_info(self, info):
         """Set the message's "info" string."""
-        if isinstance(info, str):
+        if isinstance(info, basestring):
             self._info = info
         else:
             raise TypeError('info must be a string: %s' % type(info))


Regards,

Pablo Oliveira.

----------
components: Library (Lib)
files: reproduce.py
messages: 161629
nosy: poliveira
priority: normal
severity: normal
status: open
title: mailbox.Maildir.get_message() may fail when Maildir dirname is a unicode string
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25710/reproduce.py

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

From report at bugs.python.org  Sat May 26 11:11:07 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 May 2012 09:11:07 +0000
Subject: [New-bugs-announce] [issue14923] Even faster UTF-8 decoding
Message-ID: <1338023467.99.0.0909826635798.issue14923@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

As strange as it may seem, but using a simple trick was made UTF-8 decoding even more speed up.

Here are the benchmark results.

On 32-bit Linux, AMD Athlon 64 X2:

                                          vanilla      patched

utf-8     'A'*10000                       2061 (+3%)   2115
utf-8     '\x80'*10000                    383 (-7%)    355
utf-8       '\x80'+'A'*9999               1273 (+1%)   1290
utf-8     '\u0100'*10000                  382 (+47%)   562
utf-8       '\u0100'+'A'*9999             1239 (+1%)   1253
utf-8       '\u0100'+'\x80'*9999          383 (+47%)   562
utf-8     '\u8000'*10000                  434 (-6%)    409
utf-8       '\u8000'+'A'*9999             1245 (+1%)   1256
utf-8       '\u8000'+'\x80'*9999          382 (+47%)   560
utf-8       '\u8000'+'\u0100'*9999        383 (+44%)   553
utf-8     '\U00010000'*10000              358 (+4%)    373
utf-8       '\U00010000'+'A'*9999         1171 (+0%)   1176
utf-8       '\U00010000'+'\x80'*9999      381 (+44%)   548
utf-8       '\U00010000'+'\u0100'*9999    381 (+44%)   548
utf-8       '\U00010000'+'\u8000'*9999    404 (+0%)    406

On 32-bit Linux, Intel Atom N570:

                                          vanilla      patched

utf-8     'A'*10000                       623 (+0%)    626
utf-8     '\x80'*10000                    145 (+15%)   167
utf-8       '\x80'+'A'*9999               354 (+2%)    362
utf-8     '\u0100'*10000                  164 (+10%)   181
utf-8       '\u0100'+'A'*9999             343 (-0%)    342
utf-8       '\u0100'+'\x80'*9999          164 (+11%)   182
utf-8     '\u8000'*10000                  175 (+5%)    183
utf-8       '\u8000'+'A'*9999             349 (+0%)    349
utf-8       '\u8000'+'\x80'*9999          164 (+11%)   182
utf-8       '\u8000'+'\u0100'*9999        164 (+10%)   181
utf-8     '\U00010000'*10000              152 (+11%)   168
utf-8       '\U00010000'+'A'*9999         313 (+0%)    313
utf-8       '\U00010000'+'\x80'*9999      161 (+11%)   179
utf-8       '\U00010000'+'\u0100'*9999    161 (+11%)   179
utf-8       '\U00010000'+'\u8000'*9999    160 (+11%)   177

----------
components: Interpreter Core, Unicode
files: decode_utf8_signed_byte.patch
keywords: patch
messages: 161652
nosy: Arfrever, ezio.melotti, haypo, janssen, jcea, loewis, mark.dickinson, ned.deily, pitrou, python-dev, ronaldoussoren, storchaka
priority: normal
severity: normal
status: open
title: Even faster UTF-8 decoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25717/decode_utf8_signed_byte.patch

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

From report at bugs.python.org  Sun May 27 11:13:17 2012
From: report at bugs.python.org (Francisco Gracia)
Date: Sun, 27 May 2012 09:13:17 +0000
Subject: [New-bugs-announce] [issue14924] re.finditer() oddity
Message-ID: <1338109997.99.0.370113417988.issue14924@psf.upfronthosting.co.za>


New submission from Francisco Gracia <fgragu023 at gmail.com>:

I find baffling the following behaviour of *re.finditer()*:

    Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
    Type "copyright", "credits" or "license()" for more information.
    >>> import re
    >>> m = re.finditer( '123', 'abc' )
    >>> m
    <callable_iterator object at 0x00BF09B0>
    >>> if m : 'I am Napoleon'
    
    'I am Napoleon'

No other way of formulating the condition that I have tried has worked either. Apparently *m* is always true, although all efforts to test its value indicate the contrary:

    >>> m == True
    False
    >>>

This does not happen with any other of the related methods (*findall*, *match*, *search*), which no doubt is the correct and logical behaviour:

    >>> n = re.findall( '123', 'abc' )
    >>> n
    []
    >>> if n : 'I am Napoleon'
    
    >>> 

I have not seen any warning or explanation for this fact in the official or third party documentation that I have consulted. Perhaps it is not a bug, but, as the preceding lines show, it makes impossible to test the result of the operation and direct the subsequent program flow.

If this were an unavoidable feature of *re.finditer*, it should be at least clearly exposed and, if possible, with indications of how to circumvent its undesirable consequences.

Thanks for your attention and efforts.

----------
components: Regular Expressions
messages: 161705
nosy: ezio.melotti, fgracia, mrabarnett
priority: normal
severity: normal
status: open
title: re.finditer() oddity
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun May 27 17:25:30 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 27 May 2012 15:25:30 +0000
Subject: [New-bugs-announce] [issue14925] email package does not register
	defect when blank line	between header and body is missing
Message-ID: <1338132330.03.0.317391299675.issue14925@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The error recovery heuristic the parser uses is that if it sees a line with no leading whitespace and no ':' in it, it assumes that the blank line between the headers and the body was missing.  It does not, however, register defect for this case.

Attached is a patch.  It introduces a new Defect and deprecates an old one that could never have been issued, so I'm not going to back port it.  (Especially seeing as no one has ever complained about it...I found the bug through code inspection.)

----------
assignee: r.david.murray
components: email
files: bodyseparator.patch
keywords: patch
messages: 161708
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: email package does not register defect when blank line between header and body is missing
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25732/bodyseparator.patch

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

From report at bugs.python.org  Sun May 27 17:41:31 2012
From: report at bugs.python.org (Christopher Smith)
Date: Sun, 27 May 2012 15:41:31 +0000
Subject: [New-bugs-announce] [issue14926] random.seed docstring needs edit
	of "*a *is"
Message-ID: <1338133291.27.0.1725405252.issue14926@psf.upfronthosting.co.za>


New submission from Christopher Smith <smichr at users.sourceforge.net>:

In the following, the asterisk and space should change places so

  bits are used if *a *is a str,

would appear as 

  bits are used if *a* is a str,

----------
components: Library (Lib)
messages: 161709
nosy: smichr
priority: normal
severity: normal
status: open
title: random.seed docstring needs edit of "*a *is"
versions: Python 3.2

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

From report at bugs.python.org  Sun May 27 17:44:08 2012
From: report at bugs.python.org (Christopher Smith)
Date: Sun, 27 May 2012 15:44:08 +0000
Subject: [New-bugs-announce] [issue14927] add not about int to shuffle
Message-ID: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za>


New submission from Christopher Smith <smichr at users.sourceforge.net>:

In randrange there is the note, "Do not supply the 'int' argument." That could probably be added to shuffle, too.

----------
components: Library (Lib)
messages: 161710
nosy: smichr
priority: normal
severity: normal
status: open
title: add not about int to shuffle
versions: Python 3.2

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

From report at bugs.python.org  Sun May 27 19:54:00 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 May 2012 17:54:00 +0000
Subject: [New-bugs-announce] [issue14928] Fix importlib bootstrapping issues
Message-ID: <1338141240.88.0.988941435062.issue14928@psf.upfronthosting.co.za>


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

See http://mail.python.org/pipermail/python-dev/2012-May/119703.html

Two competing proposals:

- Benjamin: "Perhaps freeze_importlib.py could be rewritten in C, so
importlib could be recompiled when the compiler changes?"

- Martin: "Or we support bootstrapping from the source file, e.g. with an
environment variable BOOTSTRAP_PY which points to the _bootstrap.py
source"

----------
components: Build, Interpreter Core
messages: 161714
nosy: benjamin.peterson, brett.cannon, eric.snow, loewis, pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Fix importlib bootstrapping issues
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun May 27 22:47:21 2012
From: report at bugs.python.org (Francisco Gracia)
Date: Sun, 27 May 2012 20:47:21 +0000
Subject: [New-bugs-announce] [issue14929] IDLE crashes on *Edit / Find in
	files ...* command	(Python 3.2, Windows XP)
Message-ID: <1338151641.58.0.68836434552.issue14929@psf.upfronthosting.co.za>


New submission from Francisco Gracia <fgragu023 at gmail.com>:

There is little more that I can add to the title statement.

   1. Start IDLE
   2. Go to *Edit* menu option
   3. Select *Find in files...* option
   4. Put some word in the *Find* input box
   5. Press *Search files* button

When the command is issued the disappearance of IDLE's window is so quick that almost nothing can be seen. There is however a hint that a new window pops up with some message, that I have been unable to read. With some input strings or if the search is happening in a directory with many *.py files a quickly moving list of messages shows in this window, but the final result is the same: IDLE disappears immediately.

----------
components: IDLE
messages: 161727
nosy: fgracia
priority: normal
severity: normal
status: open
title: IDLE crashes on *Edit / Find in files ...* command (Python 3.2, Windows XP)
versions: Python 3.2

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

From report at bugs.python.org  Sun May 27 23:06:00 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 27 May 2012 21:06:00 +0000
Subject: [New-bugs-announce] [issue14930] Make memoryview weakrefable
Message-ID: <1338152760.41.0.3704127468.issue14930@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

The attached patch makes memoryview objects weakrefable.

The reason I would like them to be weakrefable is so that I can manage the finalization and pickling of memoryview objects which wrap shared mmap segments.

(It would be even better if memoryview were subclassable, but I don't know if naively changing tp_flags would be enough.)

----------
components: Interpreter Core
files: memoryview-weakref.patch
keywords: patch
messages: 161729
nosy: sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Make memoryview weakrefable
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25739/memoryview-weakref.patch

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

From report at bugs.python.org  Sun May 27 23:12:55 2012
From: report at bugs.python.org (austin McCalley)
Date: Sun, 27 May 2012 21:12:55 +0000
Subject: [New-bugs-announce] [issue14931] Compattible
Message-ID: <1338153175.64.0.332562338858.issue14931@psf.upfronthosting.co.za>


New submission from austin McCalley <mcaustin1 at gmail.com>:

When I try to run python 2.5 scripts on 2.7 it keeps saying error that there is no module named so and so

----------
components: None
messages: 161733
nosy: austin.McCalley
priority: normal
severity: normal
status: open
title: Compattible
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon May 28 12:57:52 2012
From: report at bugs.python.org (Thomas Robitaille)
Date: Mon, 28 May 2012 10:57:52 +0000
Subject: [New-bugs-announce] [issue14932] Python 3.3.0a3 build fails on
	MacOS 10.7 with XCode 4.3.2
Message-ID: <1338202672.71.0.602323430498.issue14932@psf.upfronthosting.co.za>


New submission from Thomas Robitaille <thomas.robitaille at gmail.com>:

I can build Python 2.6 to 3.2 on MacOS 10.7 with XCode 4.3.2 using solely:

    ./configure
    make

But if I do this with Python 3.3 alpha 3 I get the following error:

    gcc   -framework CoreFoundation -o python.exe Modules/python.o libpython3.3m.a -ldl  -framework CoreFoundation     
    ./python.exe -SE -m sysconfig --generate-posix-vars
    Could not find platform dependent libraries <exec_prefix>
    Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
    python.exe(92825) malloc: *** mmap(size=7310873954244194304) failed (error code=12)
    *** error: can't allocate region
    *** set a breakpoint in malloc_error_break to debug
    Could not import runpy module
    make: *** [Lib/_sysconfigdata.py] Segmentation fault: 11

The full log is attached.

----------
components: Installation
files: python3.3_log
messages: 161765
nosy: Thomas.Robitaille
priority: normal
severity: normal
status: open
title: Python 3.3.0a3 build fails on MacOS 10.7 with XCode 4.3.2
versions: Python 3.3
Added file: http://bugs.python.org/file25743/python3.3_log

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

From report at bugs.python.org  Mon May 28 15:17:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 May 2012 13:17:39 +0000
Subject: [New-bugs-announce] [issue14933] Misleading documentation about
	weakrefs
Message-ID: <1338211059.84.0.366871304361.issue14933@psf.upfronthosting.co.za>


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

In http://docs.python.org/dev/extending/newtypes.html?highlight=pyobject_clearweakrefs#weak-reference-support, you can read:

?The only further addition is that the destructor needs to call the weak reference manager to clear any weak references. This should be done before any other parts of the destruction have occurred?

I don't believe there is any need to clear weakrefs before starting with other parts of the destruction. Weakref callbacks cannot access the original object, by construction (else they never get called).

Actually, if a weakref callback can rely on some resources having been released (say, a file descriptor), it is better to clear the weakrefs *after* other parts of the destruction.

This seems to be a by-product of the erroneous doc committed in SVN r16381, part of which was removed in r18223.

----------
assignee: docs at python
components: Documentation
messages: 161780
nosy: docs at python, fdrake, ncoghlan, pitrou, sbt, tim_one
priority: normal
severity: normal
status: open
title: Misleading documentation about weakrefs
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May 28 15:20:08 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 May 2012 13:20:08 +0000
Subject: [New-bugs-announce] [issue14934] generator objects can clear their
	weakrefs before being	resurrected
Message-ID: <1338211208.4.0.755454859587.issue14934@psf.upfronthosting.co.za>


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

In Objects/genobject.c, gen_dealloc() calls PyObject_ClearWeakRefs() before trying to finalize the generator, during which the generator object can be resurrected. This is probably a bug, since weakrefs are supposed to be cleared (and their callbacks called) only when the object is really being destroyed.

(see also issue14933)

----------
components: Interpreter Core
messages: 161781
nosy: ncoghlan, pitrou
priority: low
severity: normal
status: open
title: generator objects can clear their weakrefs before being resurrected
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May 28 18:22:51 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Mon, 28 May 2012 16:22:51 +0000
Subject: [New-bugs-announce] [issue14935] PEP 341 Refactoring applied to
	_csv module
Message-ID: <1338222171.68.0.797250497291.issue14935@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

Corresponding to my previous Issue #14732 I have now applied the Heap-Type Refactoring from PEP 341 to the _csv module. As I will apply this refactoring for almost every Standard Module, I will bundle my PEP3121 and PEP341 refactorings into a single patch for future releases. (In case there are no objections)

----------
components: Extension Modules
files: csv_pep341.patch
keywords: patch
messages: 161791
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 341 Refactoring applied to _csv module
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25745/csv_pep341.patch

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

From report at bugs.python.org  Mon May 28 18:44:30 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Mon, 28 May 2012 16:44:30 +0000
Subject: [New-bugs-announce] [issue14936] PEP 3121,
	384 refactoring applied to curses_panel module
Message-ID: <1338223470.25.0.655210931272.issue14936@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

I have now applied the Heap-Type Refactoring from PEP 384 to the curses_panel module. Currently I still provide seperate patches for the PEP 3121 and PEP 384 refactoring. As mentioned in Issue #14935 I am planning to release single patches in the future for each module I refactor.

----------
components: Extension Modules
files: curses_panel_pep384.patch
keywords: patch
messages: 161793
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to curses_panel module
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25746/curses_panel_pep384.patch

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

From report at bugs.python.org  Mon May 28 19:17:25 2012
From: report at bugs.python.org (Francisco Gracia)
Date: Mon, 28 May 2012 17:17:25 +0000
Subject: [New-bugs-announce] [issue14937] IDLE's deficiency in the
	completion of file names	(Python 32, Windows XP)
Message-ID: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za>


New submission from Francisco Gracia <fgragu023 at gmail.com>:

I find specially nice the completion feature for filenames of IDLE when they include long paths, something that is more mand more frequent with big disks and infinite amounts of files.

But there is a small problem with it. If the name of any of the directories that intervene in the path to the file has any special character in it (meaning by that I suppose any non ASCII character), the completion mechanism ceases to work.

For instance, if the path were:

    d:/Biblioteca/T?cnica/inform?tica/Python ...

the cesation of the help would occur after the incorporation of *T?cnica*, because its *e* is accented.

There is plenty of cheap software which shows this minor deficiency, but I consider that IDLE for Python 3 should not be in that group.

----------
components: IDLE
messages: 161795
nosy: fgracia
priority: normal
severity: normal
status: open
title: IDLE's deficiency in the completion of file names (Python 32, Windows XP)
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon May 28 20:52:20 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Mon, 28 May 2012 18:52:20 +0000
Subject: [New-bugs-announce] [issue14938] 'import my_pkg.__init__' creates
	duplicate modules
Message-ID: <1338231140.08.0.643684499153.issue14938@psf.upfronthosting.co.za>


New submission from Ronan Lamy <ronan.lamy at gmail.com>:

If an __init__.py file contains relative imports, doing 'import my_pkg.__init__' or calling __import__('my_pkg.__init__') creates duplicate versions of the relatively imported modules, which (I believe) causes cryptic errors in some cases (cf. the metaclass issue in http://code.google.com/p/sympy/issues/detail?id=3272 ).

More precisely, with my_pkg/__init__.py containing (see attachment for the full setup):

from .module1 import a
from my_pkg.module2 import b

I get:

Python 3.3.0a3+ (default:0685f51e9891, May 27 2012, 02:22:12) 
[GCC 4.6.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import my_pkg.__init__
>>> import sys
>>> sorted(name for name in sys.modules if name.startswith('my_'))
['my_pkg', 'my_pkg.__init__', 'my_pkg.__init__.module1', 'my_pkg.module1', 'my_pkg.module2']
>>> 

Note the bogus 'my_pkg.__init__.module1' entry. For reference, in Python 3.2, the last line is:

['my_pkg', 'my_pkg.__init__', 'my_pkg.module1', 'my_pkg.module2']


NB: calling __import__('my_pkg.__init__') might seem odd (I didn't actually expect it to work on any Python version), but doctest apparently relies on it to test __init__.py files.

----------
components: Interpreter Core
files: my_pkg.tar.bz2
messages: 161799
nosy: Ronan.Lamy
priority: normal
severity: normal
status: open
title: 'import my_pkg.__init__' creates duplicate modules
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25749/my_pkg.tar.bz2

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

From report at bugs.python.org  Tue May 29 01:10:04 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 May 2012 23:10:04 +0000
Subject: [New-bugs-announce] [issue14939] Usage documentation for pyvenv
Message-ID: <1338246604.46.0.951372284166.issue14939@psf.upfronthosting.co.za>


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

Command line documentation for pyvenv must be provided under http://docs.python.org/dev/using/index.html before 3.3 is released.

----------
assignee: docs at python
components: Documentation
messages: 161815
nosy: docs at python, ncoghlan, vinay.sajip
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Usage documentation for pyvenv
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue May 29 01:11:17 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 May 2012 23:11:17 +0000
Subject: [New-bugs-announce] [issue14940] Usage documentation for pysetup
Message-ID: <1338246677.91.0.429583785939.issue14940@psf.upfronthosting.co.za>


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

Command line documentation for pysetup must be provided under http://docs.python.org/dev/using/index.html before 3.3 is released.

----------
messages: 161816
nosy: eric.araujo, ncoghlan, tarek
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Usage documentation for pysetup
type: enhancement

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

From report at bugs.python.org  Tue May 29 01:18:39 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 May 2012 23:18:39 +0000
Subject: [New-bugs-announce] [issue14941] "Using Python on Windows" end user
	docs are out of date
Message-ID: <1338247119.84.0.812166179273.issue14941@psf.upfronthosting.co.za>


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

The following docs should be updated based on the automatic PATH manipulation in the updated installer:
http://docs.python.org/dev/using/windows.html#using-python-on-windows

The section on script execution should also mention the -m switch and the section on compiling Python on Windows should be replaced with a reference to the devguide (if there is information here which is both still current and not in the devguide, then it should be added there).

----------
messages: 161817
nosy: brian.curtin, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: "Using Python on Windows" end user docs are out of date
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue May 29 01:56:24 2012
From: report at bugs.python.org (Eric Snow)
Date: Mon, 28 May 2012 23:56:24 +0000
Subject: [New-bugs-announce] [issue14942] add PyType_New()
Message-ID: <1338249384.08.0.153670588779.issue14942@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Nick Coghlan suggested[1] exploring an easier spelling for "type(name, (), {})" in the C API.  I've attached a patch that adds a function that does so: _PyType_New().  It's "private" in the patch, but only because I am reticent to expand the API without solid feedback from the more experienced devs.

Even if I didn't get the implementation quite right (I'm relatively new to the C API), the patch at least demonstrates the concept.  :)


[1] http://mail.python.org/pipermail/python-ideas/2012-May/015281.html

----------
files: PyType_New.diff
keywords: patch
messages: 161820
nosy: eric.snow
priority: normal
severity: normal
status: open
title: add PyType_New()
versions: Python 3.3
Added file: http://bugs.python.org/file25752/PyType_New.diff

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

From report at bugs.python.org  Tue May 29 02:14:41 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 29 May 2012 00:14:41 +0000
Subject: [New-bugs-announce] [issue14943] winreg OpenKey doesn't work as
	documented
Message-ID: <1338250481.35.0.334465326284.issue14943@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

My first time to use winreg and I am sure that some of this report is documentation, but depending on behavior in other versions, maybe it is a regression in code as well, but I doubt it.

I'm reading the 3.3 documentation, but using 3.2.3 for testing.  The documentation doesn't indicate any change execpt the exception thrown, between 3.2 and 3.3.

The documentation for OpenKey indicates it has 4 parameters, calling the 3rd "reserverd" and the 4th "access".  These are given default values of 0 and KEY_ALL_ACCESS, respectively, according to the function definition.

The text of the documentation does not further explain these parameters, rather it explains "res" and "sam" which may appear to correspond... (that is problem #1)

Assuming a correspondence, and a name change for those parameters somewhere along the line (perhaps between 3.1 and 3.2 when named parameters became supported, per the doc. note), then "sam" is defined to have a default value of "KEY_READ".  That conflicts with the default value shown in the function definition (this is problem #2).

The behavior of OpenKey in 3.2.2 seems to be that the access parameter actually defaults to "KEY_READ", rather than "KEY_ALL_ACCESS".  Since the documentation is inconsistent in this area, I'm not sure if there was intended to be a code change, nor what the prior behavior might have been, nor what the future behavior is intended to be.  If a change in default was intended, either it was implemented wrong, or documented wrong, and there is no indication in the documentation that a change was made, or should have been made (this is problem #3).

I suspect the changes should all be to the documentation, changing the function definition to read "KEY_READ" instead of "KEY_ALL_ACCESS", and changing the parameters in the text to be called "reserved" and "access" instead of "res" and "sam", and if so, then problem #3 is fictitious, just a result of the other inconsistencies, and speculation.

----------
assignee: docs at python
components: Documentation
messages: 161822
nosy: docs at python, v+python
priority: normal
severity: normal
status: open
title: winreg OpenKey doesn't work as documented
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May 29 03:47:38 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 May 2012 01:47:38 +0000
Subject: [New-bugs-announce] [issue14944] Setup & Usage documentation for
	pydoc
Message-ID: <1338256058.02.0.10025521772.issue14944@psf.upfronthosting.co.za>


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

pydoc is installed as a script by Python. It should be documented under http://docs.python.org/dev/using/index.html.

----------
assignee: docs at python
components: Documentation
messages: 161831
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Setup & Usage documentation for pydoc
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May 29 03:50:59 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 May 2012 01:50:59 +0000
Subject: [New-bugs-announce] [issue14945] Setup & Usage documentation for
	selected stdlib modules
Message-ID: <1338256259.22.0.129056676976.issue14945@psf.upfronthosting.co.za>


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

Some stdlib modules have officially documented and supported behaviour when executed via -m. These should be referenced from the Setup & Usage documentation at http://docs.python.org/dev/using/index.html

Current candidates:
python -m unittest
python -m timeit

----------
assignee: docs at python
components: Documentation
messages: 161832
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Setup & Usage documentation for selected stdlib modules
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May 29 05:40:37 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 May 2012 03:40:37 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue14946=5D_packaging=E2=80=99?=
 =?utf-8?q?spysetup_script_should_be_named_differently_than_distutils2?=
 =?utf-8?b?4oCZcyBweXNldHVw?=
Message-ID: <1338262837.82.0.276782764765.issue14946@psf.upfronthosting.co.za>


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

The whole point of naming distutils2 ?packaging? in the standard library is to avoid name conflicts in case someone wants to import a distutils2 version from site-packages that?s newer than the packaging version in the standard library.  However the main command-line entry point, the pysetup script, has a conflicting name: both packaging and distutils2 use it.

I don?t have an elegant solution to that; suggestions welcome.

----------
assignee: eric.araujo
components: Distutils2
messages: 161848
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: packaging?spysetup script should be named differently than distutils2?s pysetup
versions: Python 3.3

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

From report at bugs.python.org  Tue May 29 07:47:31 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 May 2012 05:47:31 +0000
Subject: [New-bugs-announce] [issue14947] Missing cross reference in
	types.new_class documentation
Message-ID: <1338270451.09.0.735247268366.issue14947@psf.upfronthosting.co.za>


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

The http://docs.python.org/dev/library/types#dynamic-type-creation docs should have a see also ref to the main class creation docs in the language reference.

Just a reminder to myself so I don't forget to fix it.

----------
assignee: ncoghlan
components: Documentation
messages: 161856
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Missing cross reference in types.new_class documentation
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue May 29 07:51:13 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 May 2012 05:51:13 +0000
Subject: [New-bugs-announce] [issue14948] setup.cfg - rename home_page to
	homepage
Message-ID: <1338270673.24.0.647423801852.issue14948@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

home_page is too conservative, ugly and requires more time typing. "home page" is also 2.15 times less popular that "homepage" spelling http://www.google.com/trends/?q=%22home+page%22,+%22homepage%22

Writing setup.cfg files for humans should be simple and intuitive without too much referencing to official docs. Perhaps it is possible to support both home_page and homepage with the latter being the preferred syntax.

----------
assignee: eric.araujo
components: Distutils2
messages: 161857
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: setup.cfg - rename home_page to homepage

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

From report at bugs.python.org  Tue May 29 12:22:39 2012
From: report at bugs.python.org (Alexis Metaireau)
Date: Tue, 29 May 2012 10:22:39 +0000
Subject: [New-bugs-announce] [issue14949] Documentation should state clearly
	the differences	between "pysetup run install_dist" and
	"pysetup install"
Message-ID: <1338286959.61.0.121303328814.issue14949@psf.upfronthosting.co.za>


New submission from Alexis Metaireau <alexis at notmyidea.org>:

The packaging tutorial currently talks about "pysetup run install_dist" and "pysetup install" which aren't doing the same thing: one fetches the dependencies while the other doesn't.

This should be stated clearly.

----------
assignee: eric.araujo
components: Distutils2
keywords: easy
messages: 161867
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Documentation should state clearly the differences between "pysetup run install_dist" and "pysetup install"
versions: Python 3.3

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

From report at bugs.python.org  Tue May 29 12:47:26 2012
From: report at bugs.python.org (Alexis Metaireau)
Date: Tue, 29 May 2012 10:47:26 +0000
Subject: [New-bugs-announce] [issue14950] packaging.install does not have a
	clear API.
Message-ID: <1338288446.67.0.0715913421745.issue14950@psf.upfronthosting.co.za>


New submission from Alexis Metaireau <alexis at notmyidea.org>:

The "packaging.install" module doesn't have a clear API defined and it's doing a lot of indirections between all the functions to get metadata, fetch the dependencies and install what's need to be installed.

We might be able to come with a better solution for the API we expose there, and to allow easier maintenance. I'll go ahead this week and propose a change to this module which hopefully will make things clearer.

----------
assignee: alexis
components: Distutils2
messages: 161868
nosy: alexis, tarek
priority: normal
severity: normal
status: open
title: packaging.install does not have a clear API.
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue May 29 14:29:23 2012
From: report at bugs.python.org (Damien Cassou)
Date: Tue, 29 May 2012 12:29:23 +0000
Subject: [New-bugs-announce] [issue14951] Daikon/KVasir report: Invalid read
	of size 4
Message-ID: <1338294563.1.0.472607755254.issue14951@psf.upfronthosting.co.za>


New submission from Damien Cassou <damien.cassou at gmail.com>:

Hi,

I've just executed a dynamic program analyzer (kvasir frontend for daikon) on the python runtime with an hello world python input. I got a lot of errors (796 errors from 61 contexts), potentially showing bugs in cpython. The following presents one such errors. I can report more if the following is useful to anyone. 

    Invalid read of size 4
       at 0x459897: PyObject_Free (obmalloc.c:969)
       by 0x5133E5: PyGrammar_RemoveAccelerators (acceler.c:47)
       by 0x4DCD92: Py_Finalize (pythonrun.c:539)
       by 0x417946: Py_Main (main.c:664)
       by 0x416703: main (python.c:23)
     Address 0x6108020 is 256 bytes inside a block of size 676 free'd
       at 0x4C24242: free (vg_replace_malloc.c:366)
       by 0x459F3F: PyObject_Free (obmalloc.c:1166)
       by 0x51379F: fixstate (acceler.c:124)
       by 0x51344F: fixdfa (acceler.c:60)
       by 0x513369: PyGrammar_AddAccelerators (acceler.c:30)
       by 0x513C84: PyParser_New (parser.c:77)
       by 0x417D73: parsetok (parsetok.c:136)
       by 0x417D1B: PyParser_ParseFileFlagsEx (parsetok.c:106)
       by 0x4DF284: PyParser_ASTFromFile (pythonrun.c:1476)
       by 0x4CD570: parse_source_module (import.c:829)
       by 0x4CDB2A: load_source_module (import.c:1006)
       by 0x4CF05B: load_module (import.c:1822)

----------
components: Interpreter Core
messages: 161872
nosy: cassou, haypo, lemburg, tim_one
priority: normal
severity: normal
status: open
title: Daikon/KVasir report: Invalid read of size 4
versions: Python 2.7

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

From report at bugs.python.org  Tue May 29 16:56:36 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 29 May 2012 14:56:36 +0000
Subject: [New-bugs-announce] [issue14952] Cannot run regrtest with
	amd64/debug on windows
Message-ID: <1338303396.99.0.893670978528.issue14952@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Running the regression tests from the build directory no longer works for Amd64/debug, windows build.

D:\pydev\hg\cpython2>PCbuild\amd64\python_d.exe -m test.regrtest
Traceback (most recent call last):
  File "D:\pydev\hg\cpython2\lib\runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "D:\pydev\hg\cpython2\lib\runpy.py", line 75, in _run_code
    exec(code, run_globals)
  File "D:\pydev\hg\cpython2\lib\test\regrtest.py", line 243, in <module>
    from test import support
ImportError: cannot import name support
[96946 refs]

D:\pydev\hg\cpython2>PCbuild\amd64\python_d.exe lib\test\regrtest.py
Traceback (most recent call last):
  File "lib\test\regrtest.py", line 243, in <module>
    from test import support
ImportError: cannot import name support
[95993 refs]

This works for release.

----------
messages: 161891
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Cannot run regrtest with amd64/debug on windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue May 29 16:59:43 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 29 May 2012 14:59:43 +0000
Subject: [New-bugs-announce] [issue14953] Reimplement subset of
	multiprocessing.sharedctypes using	memoryview
Message-ID: <1338303583.56.0.322806581737.issue14953@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

The attached patch enables creation of shared objects allocated from shared memory using memoryview objects instead of ctypes.

This enables the use of shared memory on systems where ctypes is unavailable.

The new functions/classes RawArray, RawValue, Array and Array have been added to multiprocessing.heap.  They are almost equivalent to the functions/classes of the same name in multiprocessing and multiprocessing.sharedctypes when a letter typecode is used (rather than a ctypes type).

The differences in behaviour are due to the differences between memoryview objects and ctypes arrays.  The most noticeable is the fact that you can't set a slice using an arbitrary sequence, so

    arr = multiprocessing.RawArray('i', [0]*10)
    arr[:3] = [1,2,3]

has to be rewritten to something like

    arr = multiprocessing.heap.RawArray('i', [0]*10)
    arr[:3] = array.array('i', [1,2,3])

(No documetation yet.)

----------
files: memoryview-array-value.patch
keywords: patch
messages: 161892
nosy: sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Reimplement subset of multiprocessing.sharedctypes using memoryview
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25754/memoryview-array-value.patch

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

From report at bugs.python.org  Tue May 29 18:04:42 2012
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 May 2012 16:04:42 +0000
Subject: [New-bugs-announce] [issue14954] weakref doc clarification
Message-ID: <1338307482.44.0.878689614277.issue14954@psf.upfronthosting.co.za>


New submission from Ethan Furman <ethan at stoneleaf.us>:

The weak reference docs could be clearer about when weak ref'ed objects are no longer available.  Attached doc patch attempts to do so.

----------
files: weakref_doc_updates.diff
keywords: patch
messages: 161895
nosy: stoneleaf
priority: normal
severity: normal
status: open
title: weakref doc clarification
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25755/weakref_doc_updates.diff

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

From report at bugs.python.org  Tue May 29 18:36:51 2012
From: report at bugs.python.org (Jon Oberheide)
Date: Tue, 29 May 2012 16:36:51 +0000
Subject: [New-bugs-announce] [issue14955] hmac.secure_compare() is not
	time-independent for	unicode strings
Message-ID: <1338309411.99.0.502749568919.issue14955@psf.upfronthosting.co.za>


New submission from Jon Oberheide <jon at oberheide.org>:

Hi all,

I was informed that the hmac.secure_compare() function added in 14532 is not time-independent when processing unicode values:

"The function as given is probably not timing independent if the attacker can provide unicode values. This is because (in CPython at least) all integer values in the range [-5, 256] inclusive are made singletons to avoid the performance hit of integer object creation, meaning that as long as (x ^ y) < 257, no integer object is created and the function appears constant time. When that assumption is violated, you get a timing delta that is actually fairly large compared to the delta for a single character compare."

One way to work around this issue is to perform strict 8-bit byte comparisons by converting any string type parameters to bytes via a utf-8 encode. The attached patch does this.

Regards,
Jon Oberheide

----------
components: Library (Lib)
files: secure-compare-fix-v1.patch
keywords: patch
messages: 161898
nosy: Jon.Oberheide
priority: normal
severity: normal
status: open
title: hmac.secure_compare() is not time-independent for unicode strings
type: security
versions: Python 3.3
Added file: http://bugs.python.org/file25756/secure-compare-fix-v1.patch

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

From report at bugs.python.org  Tue May 29 21:56:52 2012
From: report at bugs.python.org (Jan Kratochvil)
Date: Tue, 29 May 2012 19:56:52 +0000
Subject: [New-bugs-announce] [issue14956] custom PYTHONPATH breaks
	Python-embedded apps
Message-ID: <1338321412.45.0.331737203349.issue14956@psf.upfronthosting.co.za>


New submission from Jan Kratochvil <jan.kratochvil at redhat.com>:

People use custom Python builds setting PYTHONHOME and PYTHONPATH to these custom builds. This may be expected to break running system Python binary but it also unexpectedly breaks various applications which also embed Python:

$ echo foo >site.py; export PYTHONPATH=.
$ gdb
Traceback (most recent call last):
  File "./site.py", line 1, in <module>
    foo
NameError: name 'foo' is not defined
$ _

It is not obvious to the user who even already forgot about custom PYTHONPATH why GDB breaks.

Standard Fedora applications may link with system libpython incompatible with the PYTHONHOME/PYTHONPATH files for the other Python version. Python does not keep the scripts too compatible across Python versions.

This issues was discussed first for GDB upstream:
[RFA] ignore PYTHONHOME environment variable.
http://sourceware.org/ml/gdb-patches/2010-11/msg00328.html
http://sourceware.org/ml/gdb-patches/2010-12/msg00214.html
http://sourceware.org/ml/gdb-patches/2011-01/msg00307.html
http://sourceware.org/ml/gdb-patches/2012-05/msg00710.html
(first mail of the thread in each month)
Then also in Fedora:
https://fedorahosted.org/fesco/ticket/858
This Python issue would not be filed by the user if it gets resolved:
Issue12140

Exactly the same problem exists for many other apps, yum for all

$ echo foo >site.py; PYTHONPATH=. yum list bash
Traceback (most recent call last):
  File "./site.py", line 1, in <module>
    foo
NameError: name 'foo' is not defined
$ _

Various proposal have been, applicable possibly in some combination together:

 * Ignore PYTHONHOME/PYTHONPATH for embedded applications. (dot)
 * Ignore PYTHONHOME, use only GDB_PYTHONHOME (if set). This proposal is not applicable for all applications in general.
 * Print warning if PYTHONHOME/PYTHONPATH is set.
 * Recover from Python startup failure and suppress the environment vars.
   or Recover from Python startup failure and disable the Python support, if possible.
 * Should the special care affect PYTHONHOME? Differently for PYTHONPATH? What about PYTHONVERBOSE and other PYTHON* settings? 

How should get PYTHONHOME/PYTHONPATH inherited into child processes, if any (debuggees in the GDB case).

Another question is whether the behavior should be the same if upstream application has been linked with non-system libpython location.

----------
components: Interpreter Core
messages: 161906
nosy: dmalcolm, jankratochvil
priority: normal
severity: normal
status: open
title: custom PYTHONPATH breaks Python-embedded apps
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 30 00:34:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 May 2012 22:34:50 +0000
Subject: [New-bugs-announce] [issue14957] Improve docs for str.splitlines
Message-ID: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za>


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

The docs for str.splitlines() should explain:

1. That it uses the universal newlines approach to splitting lines
2. That unlike str.split() a trailing empty line is *not* included in the resulting list

----------
assignee: docs at python
components: Documentation
messages: 161915
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Improve docs for str.splitlines
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed May 30 02:37:48 2012
From: report at bugs.python.org (Roger Serwy)
Date: Wed, 30 May 2012 00:37:48 +0000
Subject: [New-bugs-announce] [issue14958] IDLE 3 and PEP414 - highlighting
	unicode literals
Message-ID: <1338338268.62.0.441053102014.issue14958@psf.upfronthosting.co.za>


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

Issue8641 addressed the problem of not highlighting byte literals, but dropped Unicode literals, as it should have. This happened months before the acceptance of PEP414.

IDLE 3 should now highlight u"" as well as b"", as well as valid combinations with r"".

----------
components: IDLE
keywords: easy
messages: 161921
nosy: serwy
priority: low
severity: normal
stage: needs patch
status: open
title: IDLE 3 and PEP414 - highlighting unicode literals
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed May 30 03:23:12 2012
From: report at bugs.python.org (David Beck)
Date: Wed, 30 May 2012 01:23:12 +0000
Subject: [New-bugs-announce] [issue14959] ttk.Scrollbar in Notebook widget
	freezes
Message-ID: <1338340992.23.0.15573788402.issue14959@psf.upfronthosting.co.za>


New submission from David Beck <dbeck at ualberta.ca>:

I am working on an iMac running OS 10.7, TK 8.5.11. I built a simple app containing a Notebook widget, and with Listboxes and linked tkk.Scrollbars on each of three tabs. All of the Scrollbars work the first time I manipulate them, but once the Scrollbar on third tab (the last one created by the script) is manipulated, the others become unresponsive to mouse clicks (though the Scrollbars continue to move when the Listboxes are scrolled using the mouse/trackpad. I first found this issue working with Python 3.2.3 (using IDLE), but the same thing happens with Python 3.3. I asked someone to try this on a PC (Windows 7, Python 3.2.3, Tkinter 8.5), but the problem wasn't recreated.

----------
assignee: ronaldoussoren
components: Macintosh, Tkinter
files: Notebook.py
messages: 161923
nosy: davidjamesbeck, ronaldoussoren
priority: normal
severity: normal
status: open
title: ttk.Scrollbar in Notebook widget freezes
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25758/Notebook.py

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

From report at bugs.python.org  Wed May 30 08:43:22 2012
From: report at bugs.python.org (Fan Li)
Date: Wed, 30 May 2012 06:43:22 +0000
Subject: [New-bugs-announce] [issue14960] about the slowly HTTPServer
Message-ID: <1338360202.75.0.403756763766.issue14960@psf.upfronthosting.co.za>


New submission from Fan Li <m4.lifan at gmail.com>:

first, i'm sorry about my english.

when i test the HTTPServer lib local, it's fast. but when i run the test script on another PC, i found it very slow, response for a request cost about 4s.

then, i walk into the source about HTTPServer and found an function which just print some infomation about the request like this: 
xxx.xxx.xxx.xxx - 'GET /path/xxx.xxx' 200

i cost 4s long!! just because it call a function name getfqdn(), it's very slow to do this.

then i overwrite the BaseHttpRequest.log_message, problem solved.

may be you can remove the function getfqdn() ?

----------
components: Library (Lib)
messages: 161931
nosy: Fan.Li
priority: normal
severity: normal
status: open
title: about the slowly HTTPServer
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed May 30 10:59:54 2012
From: report at bugs.python.org (Vladimir Berkutov)
Date: Wed, 30 May 2012 08:59:54 +0000
Subject: [New-bugs-announce] [issue14961] map() and filter() methods for
	iterators
Message-ID: <1338368394.87.0.444048276529.issue14961@psf.upfronthosting.co.za>


New submission from Vladimir Berkutov <dair.targ at gmail.com>:

It might be useful to introduce a new map() and filter() methods to iterators and iterables. Both methods should accept lambda/function which transforms a single argument into value. Both methods should return another iterator.

# proposed methods usage:
range(10).map(abs).filter(lambda x: x % 5 == 0)
# existing equivalent:
filter(lambda x: x % 5 == 0, map(abs, range(-10, 10)))
# result:
[10, 5, 0, 5]

Rough equivalent of implementation:
class iterator:
    def map(self, fn):
        for v in self:
            yield fn(v)
    
    def filter(self, fn):
        for v in self:
            if fn(v):
                yield v
            else:
                continue

Introduction of such methods will allow to transform collections lazy without significant memory consumption (as was mentioned in http://bugs.python.org/issue912738).

----------
components: Interpreter Core, Library (Lib)
messages: 161935
nosy: dair-targ
priority: normal
severity: normal
status: open
title: map() and filter() methods for iterators
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed May 30 11:00:59 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 30 May 2012 09:00:59 +0000
Subject: [New-bugs-announce] [issue14962] When changing IDLE configuration
	all text in editor	window loses highlighting
Message-ID: <1338368459.11.0.63783286393.issue14962@psf.upfronthosting.co.za>


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

When applying or okaying IDLE configuration (Options-> Configure IDLE) all text in the shell window loses highlighting.
Text in the shell window created after the configuration is applied is highlighted though.

----------
components: IDLE
messages: 161936
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: When changing IDLE configuration all text in editor window loses highlighting
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed May 30 13:07:47 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 May 2012 11:07:47 +0000
Subject: [New-bugs-announce] [issue14963] Use an iterative implementation
	for	contextlib.ExitStack.__exit__
Message-ID: <1338376067.22.0.0825835075506.issue14963@psf.upfronthosting.co.za>


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

The current implementation of contextlib.ExitStack [1] actually creates a nested series of frames when unwinding the callback stack in an effort to ensure exceptions are chained correctly, just as they would be if using nested with statements.

It would be nice to avoid this overhead by just using the one frame to iterate over the callbacks and handling correct exception chaining directly. This is likely to be a little tricky to get right, though, so the first step would be to set up a test that throws and suppresses a few exceptions and ensures the chaining when using ExitStack matches that when using nested with statements.

[1] http://hg.python.org/cpython/file/94a5bf416e50/Lib/contextlib.py#l227

----------
components: Library (Lib)
messages: 161944
nosy: ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Use an iterative implementation for contextlib.ExitStack.__exit__
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu May 31 01:08:33 2012
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 30 May 2012 23:08:33 +0000
Subject: [New-bugs-announce] [issue14964] distutils2.utils.resolve_name
	cleanup
Message-ID: <1338419313.79.0.682817999286.issue14964@psf.upfronthosting.co.za>


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

this patch simplifies and cleans up the resolve_name function

----------
assignee: eric.araujo
components: Distutils2
files: resolve_name.patch
keywords: patch
messages: 161974
nosy: Ronny.Pfannschmidt, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2.utils.resolve_name cleanup
type: enhancement
Added file: http://bugs.python.org/file25766/resolve_name.patch

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

From report at bugs.python.org  Thu May 31 05:04:01 2012
From: report at bugs.python.org (=?utf-8?b?54yrIOm7kg==?=)
Date: Thu, 31 May 2012 03:04:01 +0000
Subject: [New-bugs-announce] [issue14965] super() and property inheritance
	behavior
Message-ID: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za>


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

super() objects allow access to inherited properties fget() but not fset() or fdel(), resulting in unexpected behavior.

Today on pydev thread 'Property inheritance in Python' GvR said "I
don't see the need for a Python-Ideas detour. It seems worth fixing"

>>> class BaseProp(object):
...     @property
...     def p(self):
...         return self._p
...     @p.setter
...     def p(self, value):
...         self._p = value
>>> class DerivedProp(BaseProp):
...     @property
...     def p(self):
...         return super(DerivedProp, self).p * 2
...     @p.setter
...     def p(self, value):
...         super(DerivedProp, self).p = value / 2
>>> d = DerivedProp()
>>> d._p = 21
>>> d.p
42
>>> d.p = 50
Traceback (most recent call last):
   ...
AttributeError: 'super' object has no attribute 'p'

----------
components: Library (Lib)
messages: 161980
nosy: ?.?
priority: normal
severity: normal
status: open
title: super() and property inheritance behavior
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu May 31 08:46:02 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 31 May 2012 06:46:02 +0000
Subject: [New-bugs-announce] [issue14966] Fully document
	subprocess.CalledProcessError
Message-ID: <1338446762.96.0.360332771622.issue14966@psf.upfronthosting.co.za>


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

CalledProcessError provides a nice encapsulation for a returncode, the original command and any partial output. The API should be officially documented so that third party subprocess.Popen convenience wrappers can use it easily.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 161984
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Fully document subprocess.CalledProcessError
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 31 13:34:37 2012
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Thu, 31 May 2012 11:34:37 +0000
Subject: [New-bugs-announce] [issue14967] distutils2.utils.resolve_name
	cannot be implemented to	give correct errors in all situations
Message-ID: <1338464077.51.0.267710921151.issue14967@psf.upfronthosting.co.za>


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

due to the lack of a marker that denotes where the module ends and the attribute starts, unrelated import errors can break the try&error chain at unexpected places and the code can pass on to the recursive getattr chain, giving a completely different error instead of the real error

this is not solvable without a marker or really nasty hacks o track subsequent imports

----------
assignee: eric.araujo
components: Distutils2
messages: 161990
nosy: Ronny.Pfannschmidt, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2.utils.resolve_name cannot be implemented to give correct errors in all situations

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

From report at bugs.python.org  Thu May 31 14:32:46 2012
From: report at bugs.python.org (Lars Buitinck)
Date: Thu, 31 May 2012 12:32:46 +0000
Subject: [New-bugs-announce] [issue14968] Section "Inplace Operators" of
	:mod:`operator` should be	a subsection
Message-ID: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za>


New submission from Lars Buitinck <L.J.Buitinck at uva.nl>:

The section "Inplace Operators" of the module docs for operator now show up in TOC at http://docs.python.org/dev/library/. I don't think that's intended as it does not describe a separate module.

----------
assignee: docs at python
components: Documentation
files: operator-module-docs.patch
keywords: patch
messages: 161996
nosy: docs at python, larsmans
priority: normal
severity: normal
status: open
title: Section "Inplace Operators" of :mod:`operator` should be a subsection
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25772/operator-module-docs.patch

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

From report at bugs.python.org  Thu May 31 15:41:44 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 31 May 2012 13:41:44 +0000
Subject: [New-bugs-announce] [issue14969] Restore sys.exc_clear()?
Message-ID: <1338471704.64.0.423710323237.issue14969@psf.upfronthosting.co.za>


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

When adding the test case for #14963, I discovered that contextlib.ExitStack can't *quite* reproduce the exception handling of nested with statements.

The problem arises when the original exception gets suppressed by one of the handlers, but an outer handler raises a *new* exception, then nested with statements will correctly indicate that there was no exception context active when the new exception was raised (since the inner with statement will fully clear the exception state).

By contrast, when using ExitStack, the interpreter will add the original exception from inside the body of the with statement as the context for the *new* exception, even though the inner exception had been suppressed before the outer one was encountered.

Restoring sys.exc_clear() *might* allow this discrepancy to be resolved by explicitly clearing the exception state when one of the callbacks indicates that the current exception has been handled (although it might be trickier than that, if the problem is actually due to caching the exception state inside the with cleanup code in the eval loop)

----------
components: Interpreter Core, Library (Lib)
messages: 161998
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Restore sys.exc_clear()?
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu May 31 16:40:42 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 31 May 2012 14:40:42 +0000
Subject: [New-bugs-announce] [issue14970] -v command line option is broken
Message-ID: <1338475242.98.0.095498277626.issue14970@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Using the -v command line option to diagnose import problem is no longer useful.  In stead of lines like this in version 2.7:

import UserDict # from D:\p4\games\branches\development\MAIN\eve\dust\tool\bin/../../../../carbon/src/stackless/Lib/UserDict.py

we now get:
import 'textwrap' # <_frozen_importlib.SourceFileLoader object at 0x0000000002E14438>

I don't even know what a _frozen_importlib.SourceFileLoader is.

----------
components: Interpreter Core
messages: 162002
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: -v command line option is broken
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu May 31 21:02:19 2012
From: report at bugs.python.org (Alessandro Piccione)
Date: Thu, 31 May 2012 19:02:19 +0000
Subject: [New-bugs-announce] [issue14971] (unittest) loadTestsFromName does
	not work on method	with a decorator
Message-ID: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>


New submission from Alessandro Piccione <alessandro.piccione.75 at gmail.com>:

Steps to reproduce the problem.
1. Create a module (ex. name it "test") 
2. Create a file in it (ex. mainTest.py) with a class (ex. MainTest) derived from TestCase.
3. Create a test method in that class, (ex. test_base), prefix it with "test".
4. Create a decorator (ex. clear_args) and use it on the test method 
5. Create a test suite with the function "loadTestsFromName" of TestLoader class and make a TestRunner run it (I use a TextTestRunner). 
suite = unittest.TestLoader().loadTestsFromName('test.mainTest.MainTest.test_base')
unittest.TextTestRunner(verbosity=2).run(suite)


It is expected that the test is run (it runs without decorator).
It gives an error: no such test method in <class 'test.mainTest.MainTest'>: wrapper.
"wrapper" is the name of the returned function in the decorator.


I'm using Python 2.7.3 on Windows 7 64bit.
I search "loadTestsFromName decorator" without results, so I decided to report as new issue. This is my first report, I admit I've not read any guide/instructions.

----------
components: None
messages: 162015
nosy: alex.75
priority: normal
severity: normal
status: open
title: (unittest) loadTestsFromName does not work on method with a decorator
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 31 23:40:54 2012
From: report at bugs.python.org (josmiley)
Date: Thu, 31 May 2012 21:40:54 +0000
Subject: [New-bugs-announce] [issue14972] listcomp with nested classes
Message-ID: <1338500454.97.0.157911114425.issue14972@psf.upfronthosting.co.za>


New submission from josmiley <joel-murielle at sfr.fr>:

# this runs with python2.7, not with python3.2
class Foo(object):

    class Bar(object):
        pass

    Attr = [Bar()for n in range(10)]

# solved in this way ...
class Foo(object):

    class Bar(object):
        pass

    Attr = []
    for n in range(10): Attr.append(Bar())

----------
messages: 162022
nosy: josmiley
priority: normal
severity: normal
status: open
title: listcomp with nested classes
type: behavior
versions: Python 3.2

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