From report at bugs.python.org  Sun Sep  1 00:26:14 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sat, 31 Aug 2013 22:26:14 +0000
Subject: [New-bugs-announce] [issue18897] Illegal instruction at
	Python-2.7.5/Modules/_sre.c:1173
Message-ID: <1377987974.98.0.815254157912.issue18897@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

I was trying to use DUMA to find errors in python runtime and it indeed killed python-based utility called emerge. Let's see what you say now:

# export LD_PRELOAD=/usr/lib64/libduma.so.0.0.0
# sysctl -w vm.max_map_count=1000000

# emerge dev-lang/python:2.7 
DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington <meddington at gmail.com>
Copyright (C) 2002-2008 Hayati Ayguen <h_ayguen at web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce at perens.com>

DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington <meddington at gmail.com>
Copyright (C) 2002-2008 Hayati Ayguen <h_ayguen at web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce at perens.com>

DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington <meddington at gmail.com>
Copyright (C) 2002-2008 Hayati Ayguen <h_ayguen at web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce at perens.com>


DUMA Aborting: mprotect() failed: Cannot allocate memory.
Check README section 'MEMORY USAGE AND EXECUTION SPEED'
  if your (Linux) system may limit the number of different page mappings per process
Illegal instruction (core dumped)
# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 127104
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 127104
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
#

(gdb) where
#0  0x00007febd6ed84d7 in kill () from /lib64/libc.so.6
#1  0x00007febd78e2f9c in DUMA_Abort () from /usr/lib64/libduma.so.0.0.0
#2  0x00007febd78e1b77 in _duma_allocate () from /usr/lib64/libduma.so.0.0.0
#3  0x00007febd78e1fef in _duma_malloc () from /usr/lib64/libduma.so.0.0.0
#4  0x00007febd7626c60 in sre_umatch (state=0x7fff96f0de10, pattern=0x7feb2804ecb8) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1173
#5  0x00007febd762932f in pattern_match (self=0x7feb2804ec58, args=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1896
#6  0x00007febd751ffcc in PyCFunction_Call (func=<built-in method match of _sre.SRE_Pattern object at remote 0x7feb2804ec58>, arg=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/methodobject.c:85
#7  0x00007febd75c4b81 in call_function (pp_stack=0x7fff96f0e6d0, oparg=1) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:4021
#8  0x00007febd75bf6c6 in PyEval_EvalFrameEx (f=Frame 0x7feb374ebce8, for file /usr/lib64/portage/pym/portage/dep/__init__.py, line 1227, in __init__ (self=<Atom(blocker=False, eapi=None) at remote 0x7fea931d5fb0>, s=u'>=gnome-base/libbonobo-2.32::gentoo-haskell', unevaluated_atom=None, allow_wildcard=True, allow_repo=True, _use=None, eapi=None, is_valid_flag=None, eapi_attrs=<_eapi_attrs at remote 0x7feb31931f48>, atom_re=<_sre.SRE_Pattern at remote 0x7feb2804ec58>, blocker_prefix=u'', blocker=False), throwflag=0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:2666

[cut]

(gdb) bt full
#0  0x00007febd6ed84d7 in kill () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007febd78e2f9c in DUMA_Abort () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#2  0x00007febd78e1b77 in _duma_allocate () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#3  0x00007febd78e1fef in _duma_malloc () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#4  0x00007febd7626c60 in sre_umatch (state=0x7fff96f0de10, pattern=0x7feb2804ecb8) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1173
        end = 0x7fea931cfffc
        alloc_pos = 1648
        ctx_pos = 1648
        i = 128
        ret = 0
        jump = 2
        sigcount = 187
        ctx = 0x7fea931fbcf8
        nextctx = 0x7fea931fbcf8
        __PRETTY_FUNCTION__ = "sre_umatch"
#5  0x00007febd762932f in pattern_match (self=0x7feb2804ec58, args=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1896
        state = {ptr = 0x7fea931cffbc, beginning = 0x7fea931cff50, start = 0x7fea931cff50, end = 0x7fea931cfffc, string = u'>=gnome-base/libbonobo-2.32::gentoo-haskell', pos = 0, endpos = 43, charsize = 4, lastindex = 2, lastmark = 43, mark = {0x7fea931cff50, 0x0, 0x7fea931cff50, 0x7fea931cffbc, 0x7fea931cff50, 0x7fea931cff58, 0x7fea931cff58, 0x7fea931cffbc, 0x7fea931cff58, 0x7fea931cffa8, 0x0 <repeats 24 times>, 0x7fea931cffac, 0x7fea931cffb0, 0x7fea931cffb0, 0x7fea931cffbc, 0x7fea931cffb0, 0x7fea931cffbc, 0x7fea931cffbc, 0x7fea931cffbc, 0x7fea931cffbc, 0x7fea931cffbc, 0x0 <repeats 82 times>, 0x7fea931cffbc, 0x0, 0x7fea931cffc0, 0x0 <repeats 71 times>}, data_stack = 0x7fea931fb688 "\377\377\377\377\377\377\377\377", data_stack_size = 2424, data_stack_base = 1712, repeat = 0x0, lower = 0x7febd7620852 <sre_lower_unicode>}
        status = 32746
        string = u'>=gnome-base/libbonobo-2.32::gentoo-haskell'
        start = 0
        end = 9223372036854775807
        kwlist = {0x7febd7660ad8 "pattern", 0x7febd7660cd9 "pos", 0x7febd7660cdd "endpos", 0x0}
#6  0x00007febd751ffcc in PyCFunction_Call (func=<built-in method match of _sre.SRE_Pattern object at remote 0x7feb2804ec58>, arg=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/methodobject.c:85
        f = 0x7feb37087fc8
        meth = 0x7febd76291f7 <pattern_match>
        self = <_sre.SRE_Pattern at remote 0x7feb2804ec58>
        size = -1282872823
#7  0x00007febd75c4b81 in call_function (pp_stack=0x7fff96f0e6d0, oparg=1) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:4021
        callargs = (u'>=gnome-base/libbonobo-2.32::gentoo-haskell',)
        flags = 3
        tstate = 0x7febd7bd1f58
        na = 1
        nk = 0
        n = 1
        pfunc = 0x7feb374ebf88
        func = <built-in method match of _sre.SRE_Pattern object at remote 0x7feb2804ec58>
        x = <_sre.SRE_Pattern at remote 0x7feb2804ec58>
        w = 0x0
#8  0x00007febd75bf6c6 in PyEval_EvalFrameEx (f=Frame 0x7feb374ebce8, for file /usr/lib64/portage/pym/portage/dep/__init__.py, line 1227, in __init__ (self=<Atom(blocker=False, eapi=None) at remote 0x7fea931d5fb0>, s=u'>=gnome-base/libbonobo-2.32::gentoo-haskell', unevaluated_atom=None, allow_wildcard=True, allow_repo=True, _use=None, eapi=None, is_valid_flag=None, eapi_attrs=<_eapi_attrs at remote 0x7feb31931f48>, atom_re=<_sre.SRE_Pattern at remote 0x7feb2804ec58>, blocker_prefix=u'', blocker=False), throwflag=0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:2666
        sp = 0x7feb374ebf90
        stack_pointer = 0x7feb374ebf98
        next_instr = 0x7feb930726fd "}\f"
        opcode = 131
        oparg = 1
        why = WHY_NOT
        err = 0
        x = u'>=gnome-base/libbonobo-2.32::gentoo-haskell'
        v = <unknown at remote 0x83>
        w = 'match'
        u = False
        t = <unknown at remote 0x1>
        stream = 0x0
        fastlocals = 0x7feb374ebe70
        freevars = 0x7feb374ebf88
        retval = 0x0
        tstate = 0x7febd7bd1f58
        co = 0x7feb92e96f70
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1

[cut]

----------
components: Interpreter Core
files: core.emerge.4097.gdb.txt
messages: 196684
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file31540/core.emerge.4097.gdb.txt

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

From report at bugs.python.org  Sun Sep  1 07:14:53 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 05:14:53 +0000
Subject: [New-bugs-announce] [issue18898] Apply the setobject optimizations
	to dictionaries
Message-ID: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Once http://bugs.python.org/issue18835 is resolved, I would like to see the various set optimizations applied to dictionaries as well:

* Move the key before the hash in the dict struct (the key is accessed more frequently in the code and being in the first struct position allows it to be looked-up without a struct offset).

* Don't INCREF and DECREF dummy objects.  Only one reference needs to be held.  See http://bugs.python.org/issue18797

* Reduce the cost of hash collisions by inspecting nearby dict entries for matches prior to moving on to other probes elsewhere in memory.  See http://bugs.python.org/issue18771

* Make the previous improvement more effective by using aligned memory allocations for the dict tables.  See http://bugs.python.org/issue18835

Collectively, these optimizations can substantially improve dictionary performance.

----------
components: Interpreter Core
messages: 196706
nosy: haypo, pitrou, rhettinger, tim.peters
priority: low
severity: normal
status: open
title: Apply the setobject optimizations to dictionaries
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep  1 19:34:51 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 01 Sep 2013 17:34:51 +0000
Subject: [New-bugs-announce] [issue18899] make pystone.py Py3 compatible in
	benchmark suite
Message-ID: <1378056891.98.0.165106942337.issue18899@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

diff --git a/performance/pystone.py b/performance/pystone.py
--- a/performance/pystone.py
+++ b/performance/pystone.py
@@ -59,9 +59,9 @@
 
 def main(loops=LOOPS):
     benchtime, stones = pystones(loops)
-    print "Pystone(%s) time for %d passes = %g" % \
-          (__version__, loops, benchtime)
-    print "This machine benchmarks at %g pystones/second" % stones
+    print("Pystone(%s) time for %d passes = %g" %
+          (__version__, loops, benchtime))
+    print("This machine benchmarks at %g pystones/second" % stones)
 
 
 def pystones(loops=LOOPS):
@@ -72,7 +72,7 @@
 Char1Glob = '\0'
 Char2Glob = '\0'
 Array1Glob = [0]*51
-Array2Glob = map(lambda x: x[:], [Array1Glob]*51)
+Array2Glob = list(map(lambda x: x[:], [Array1Glob]*51))
 PtrGlb = None
 PtrGlbNext = None

----------
components: Benchmarks
messages: 196723
nosy: scoder
priority: normal
severity: normal
status: open
title: make pystone.py Py3 compatible in benchmark suite
type: behavior

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

From report at bugs.python.org  Sun Sep  1 20:49:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 18:49:28 +0000
Subject: [New-bugs-announce] [issue18900] Add the random.distrib module
Message-ID: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In some functions in the random module checking input arguments and precomputation takes a considerable portion of time. Here is a sample implementation of new random.distrib module which provides alternative faster interface to generating of random distributed values. It contains generators which generates values with same distributions as functions with same name in the random module.

Benchmark results:

                                random distrib
random()                         0.061   0.055  1.12
randrange(0, 100, 5)             1.494   0.620  2.41
randint(1, 100)                  1.283   0.551  2.33
uniform(-10.0, 10.0)             0.332   0.121  2.73
triangular(0.0, 10.0, 6.0)       0.661   0.317  2.09
gauss(5.0, 2.0)                  0.707   0.280  2.53
normalvariate(5.0, 2.0)          0.867   0.553  1.57
lognormvariate(5.0, 2.0)         1.078   0.640  1.68
expovariate(0.1,)                0.508   0.293  1.73
vonmisesvariate(1.0, 1.0)        1.201   0.671  1.79
gammavariate(0.35, 1.45)         1.117   0.508  2.20
betavariate(2.71828, 3.14159)    2.868   1.776  1.61
paretovariate(5.0,)              0.493   0.238  2.07
weibullvariate(1.0, 3.0)         0.670   0.402  1.67
choice([0, 1, 2, 3, 4, 5, 6...   0.887   0.594  1.49

Distrib functions are 1.5-2.8 times faster than random functions. Weighted choice() function (see issue18844) can be even dozens times faster (depends on size of the input).

In additional some random generators (i.e. gauss()) looks simpler when implemented as generators. distrib.gauss() is twice faster than distrib.normalvariate() (both generates numbers with same distribution) and I think some other generators can be implemented more efficient in generator style.

----------
components: Library (Lib)
files: distrib.py
messages: 196727
nosy: mark.dickinson, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add the random.distrib module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31549/distrib.py

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

From report at bugs.python.org  Sun Sep  1 21:20:23 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 01 Sep 2013 19:20:23 +0000
Subject: [New-bugs-announce] [issue18901] sunau.getparams should return a
	namedtuple
Message-ID: <1378063223.81.0.0712073256156.issue18901@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

This is similar to what was done for issue17818 and issue17487 and will gain for all the three audio libraries, aifc, wave and sunau a similar API. Patch and tests attached.

----------
components: Library (Lib)
files: sunau.patch
keywords: patch
messages: 196729
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: sunau.getparams should return a namedtuple
versions: Python 3.4
Added file: http://bugs.python.org/file31551/sunau.patch

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

From report at bugs.python.org  Mon Sep  2 02:03:41 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 00:03:41 +0000
Subject: [New-bugs-announce] [issue18902] Make ET event handling more
	modular to allow custom	targets for the non-blocking parser
Message-ID: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

As issue #17741 shows in detail, there's a number of implementation problems in the current ET that make a fully non-blocking parser more difficult to implement than it should be.

The main problem is that XMLParser._setevents relies on internal implementation details of the default TreeBuilder to do some of its tasks.

This has to be decoupled from implementation details completely. An XMLParser already has a non-blocking input side (feed/close) and a callback "push" API to the target. The API has to be fully expanded to include start-ns/end-ns and any other events that are required to allow custom tree builders as targets. This would make it possible to layer XMLPullParser on top of the stock XMLParser coupled with a special target that collects "events" from the callback calls.

----------
components: Library (Lib)
messages: 196758
nosy: eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: Make ET event handling more modular to allow custom targets for the non-blocking parser
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Sep  2 03:33:35 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 02 Sep 2013 01:33:35 +0000
Subject: [New-bugs-announce] [issue18903] IDLE file-completion is
	case-sensitive in Windows
Message-ID: <1378085615.28.0.091077723559.issue18903@psf.upfronthosting.co.za>


New submission from Westley Mart?nez:

Hi, I'm not sure if this would be considered a bug or a feature request, but IDLE's file-completion is case-sensitive in Windows (e.g. if I have a file named ABBA and I type in 'abb' + tab, ABBA won't pop up.  Since Windows files systems are not case-sensitive, it might make sense for the file-completion to disregard case as well.  I'm not sure if this behaviour is preferred, however, so I'll leave that up for discussion.

I tested the behaviour on 3.3 and 3.4; I assume it's the same for other versions as well.

----------
components: IDLE, Windows
messages: 196765
nosy: anikom15
priority: normal
severity: normal
status: open
title: IDLE file-completion is case-sensitive in Windows
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep  2 05:39:34 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 02 Sep 2013 03:39:34 +0000
Subject: [New-bugs-announce] [issue18904] Unnecessary test in file
	descriptor inheritance test
Message-ID: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/test/test_os.py in class FDInheritanceTests, we have an unnecessary test, which is test_set_inheritable. What test_set_inheritable tests is already being covered by test_get_inheritable.

Also, I think test_get_inheritable should be renamed to test_set_inheritable.

Please, see the patch to see what I mean.

----------
components: Tests
files: remove_unnecessary_test_fd_inheritable.patch
keywords: patch
messages: 196768
nosy: haypo, vajrasky
priority: normal
severity: normal
status: open
title: Unnecessary test in file descriptor inheritance test
versions: Python 3.4
Added file: http://bugs.python.org/file31553/remove_unnecessary_test_fd_inheritable.patch

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

From report at bugs.python.org  Mon Sep  2 18:49:20 2013
From: report at bugs.python.org (Wieland Hoffmann)
Date: Mon, 02 Sep 2013 16:49:20 +0000
Subject: [New-bugs-announce] [issue18905] pydoc -p 0 says the server is
	available at localhost:0
Message-ID: <1378140560.28.0.729434187467.issue18905@psf.upfronthosting.co.za>


New submission from Wieland Hoffmann:

In Python 3 one can use `pydoc -p 0` to start a pydoc HTTP server on an arbitrary unused port. This works (somewhat) in Python 2 as well, except that pydoc doesn't tell you which port it's listening on. Applying the attached patch makes pydoc print the correct port.

----------
components: Library (Lib)
files: pydoc-port.patch
keywords: patch
messages: 196789
nosy: Wieland.Hoffmann
priority: normal
severity: normal
status: open
title: pydoc -p 0 says the server is available at localhost:0
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31556/pydoc-port.patch

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

From report at bugs.python.org  Mon Sep  2 19:17:17 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 17:17:17 +0000
Subject: [New-bugs-announce] [issue18906] Create a way to always run tests
	in subprocesses within	regrtest
Message-ID: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

There were numerous discussions and issues in the past about the cross-test dependencies that sometimes exist because some tests need to muck with import caches (both on the Python and C level). Some examples:

http://mail.python.org/pipermail/python-dev/2013-January/123409.html
http://mail.python.org/pipermail/python-dev/2013-August/127766.html

Issue #15651 is an example of a hack that has to stay in the code to allow tests to pass. Other things are also difficult - such as simulating situations where some optional modules don't exist (like pyexpat).

----

I suggest to add a capability to regrtest that will allow certain tests to request always being run inside a subprocess. Most of the infrastructure is already in place, since this is what regrtest uses to run with -jN today.

An alternative would be to add some test.support utility to help with this, but then test execution would not be uniform between -j1 and -jN and also some things would be difficult to track, such as -R executions (currently all -R runs of a single test have to be within a single process for the refcount tracking to work).

----------
assignee: eli.bendersky
components: Tests
messages: 196793
nosy: eli.bendersky, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Create a way to always run tests in subprocesses within regrtest
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep  2 20:18:51 2013
From: report at bugs.python.org (John Nagle)
Date: Mon, 02 Sep 2013 18:18:51 +0000
Subject: [New-bugs-announce] [issue18907] urllib2.open FTP open times out at
	20 secs despite	timeout parameter
Message-ID: <1378145931.18.0.826598432393.issue18907@psf.upfronthosting.co.za>


New submission from John Nagle:

urllib2.open for an FTP url does not obey the timeout parameter.

Attached test program times out on FTP open after 21 seconds, even though the specified timeout is 60 seconds.  Timing is consistent; times have ranged from 21.03 to 21.05 seconds. Python documentation (http://docs.python.org/2/library/urllib2.html) says "The optional timeout parameter specifies a timeout in seconds for blocking operations like the connection attempt (if not specified, the global default timeout setting will be used). This actually only works for HTTP, HTTPS and FTP connections."  The documentation for Python 3 reads the same.

Open of ftp://ftp.sec.gov/edgar/daily-index failed after 21.05 seconds: <urlopen error ftp error: [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond>

This was on Windows 7, but the same result is observed on Linux.  

(The FTP server at the U.S. Securities and Exchange Commission is now imposing a 20-second connection delay during busy periods.  This is causing our Python code that retrieves new SEC filings to fail.  It may be necessary to run the program at different times of the day to reproduce the problem.)

----------
components: Library (Lib)
files: edgartimeouttest.py
messages: 196800
nosy: nagle
priority: normal
severity: normal
status: open
title: urllib2.open FTP open times out at 20 secs despite timeout parameter
versions: Python 2.7
Added file: http://bugs.python.org/file31558/edgartimeouttest.py

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

From report at bugs.python.org  Tue Sep  3 00:40:00 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Mon, 02 Sep 2013 22:40:00 +0000
Subject: [New-bugs-announce] [issue18908] Enum docs: sections leak out
Message-ID: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

Inner sections "leak" out from enum to the general datatypes index:
http://docs.python.org/3.4/library/datatypes.html

(sections 8.14 - 8.17)

----------
assignee: docs at python
components: Documentation
messages: 196816
nosy: docs at python, elazar
priority: normal
severity: normal
status: open
title: Enum docs: sections leak out

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

From report at bugs.python.org  Tue Sep  3 03:25:03 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 03 Sep 2013 01:25:03 +0000
Subject: [New-bugs-announce] [issue18909] Segfaults on win-amd64 due to
	corrupt pointer to	Tkapp_Interp
Message-ID: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>


New submission from Christoph Gohlke:

Using 64 bit CPython 2.6.6, 2.7.5, 3.2.5 or 3.3.2, numpy 1.7.1 and matplotlib 1.3.0 on Windows 8 64 bit, the following script segfaults most of the times: 

```
# allocate ~4GB fragmented data
import numpy
a = [numpy.zeros(2**i, 'uint8') for i in range(1, 31)]
b = [numpy.zeros(131072, 'float64') for i in range(2048)]

# plot using TkAgg
import matplotlib
matplotlib.use('TkAgg')
from matplotlib import pyplot
pyplot.plot()
pyplot.show()
```

```
Fatal Python error: Segmentation fault

Current thread 0x00036c5c:
  File "X:\Python33\lib\site-packages\matplotlib\backends\tkagg.py", line 17 in blit
  File "X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 349 in draw
  File "X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 276 in resize
  File "X:\Python33\lib\tkinter\__init__.py", line 1475 in __call__
  File "X:\Python33\lib\tkinter\__init__.py", line 965 in update
  File "X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 574 in show
  File "X:\Python33\lib\site-packages\matplotlib\backend_bases.py", line 87 in __call__
  File "X:\Python33\lib\site-packages\matplotlib\pyplot.py", line 145 in show
  File "tk_crash_win-amd64.py", line 14 in <module>
```

The pointer returned by Python's _tkinter.tkapp.interpaddr() is often wrong because the 64 bit pointer is cast to 32 bit long and returned as PyInt. Instead, the pointer should be cast to Py_ssize_t and returned as PyLong on win-amd64.

The following patches for win-amd64-py2.7.5 and win-amd64-py3.3.2 fix the issue:

```
--- a/Modules/_tkinter.c        Sun Sep 01 19:06:35 2013 -0400
+++ b/Modules/_tkinter.c        Mon Sep 02 17:44:53 2013 -0700
@@ -2814,7 +2814,7 @@
     if (!PyArg_ParseTuple(args, ":interpaddr"))
         return NULL;

-    return PyInt_FromLong((long)Tkapp_Interp(self));
+    return PyInt_FromSsize_t((Py_ssize_t)Tkapp_Interp(self));
 }
```

```
--- a/Modules/_tkinter.c        Sun Sep 01 19:03:41 2013 -0400
+++ b/Modules/_tkinter.c        Mon Sep 02 17:44:02 2013 -0700
@@ -2688,7 +2688,7 @@
     if (!PyArg_ParseTuple(args, ":interpaddr"))
         return NULL;

-    return PyLong_FromLong((long)Tkapp_Interp(self));
+    return PyLong_FromSsize_t((Py_ssize_t)Tkapp_Interp(self));
 }
```

Updated _tkinter.pyd files are available at <http://www.lfd.uci.edu/~cgohlke/pythonlibs/#_tkinter>.

----------
messages: 196819
nosy: cgohlke
priority: normal
severity: normal
status: open
title: Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
type: crash
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep  3 03:56:46 2013
From: report at bugs.python.org (Phil Webster)
Date: Tue, 03 Sep 2013 01:56:46 +0000
Subject: [New-bugs-announce] [issue18910] IDLE: Unit test for textView.py
Message-ID: <1378173406.38.0.908315708817.issue18910@psf.upfronthosting.co.za>


New submission from Phil Webster:

Started writing the tests for textView.py.

----------
components: IDLE
files: test_textview.patch
keywords: patch
messages: 196820
nosy: JayKrish, Todd.Rovito, philwebster, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Unit test for textView.py
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31569/test_textview.patch

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

From report at bugs.python.org  Tue Sep  3 07:36:59 2013
From: report at bugs.python.org (Brian Vanderburg)
Date: Tue, 03 Sep 2013 05:36:59 +0000
Subject: [New-bugs-announce] [issue18911] minidom does not encode correctly
	when calling	Document.writexml
Message-ID: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>


New submission from Brian Vanderburg:

When I have unicode data to save, it seems that it does not save correctly, giving an encode error. I know this exists on 2.7 and from checking the code in xml/dom/minidom.py it looks like it does in 3.2 as well.

The method call that seem to be problematic is doc.writexml(open(filename, "wb"), "", "  ", "utf-8")

Currently I found this to work: doc.writexml(codecs.open(filename, "w", "utf-8"), "", "  ", "utf-8")

It seems like this should be handled by the writexml method since it already has the specified encoding.

----------
components: XML
messages: 196824
nosy: brianvanderburg2
priority: normal
severity: normal
status: open
title: minidom does not encode correctly when calling Document.writexml
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep  3 10:08:26 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Tue, 03 Sep 2013 08:08:26 +0000
Subject: [New-bugs-announce] [issue18912] Intendation issue in example code
	in itertools.count	documentation
Message-ID: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>


New submission from Jeroen Van Goey:

The sample code in the itertools.count documentation should be indented by 4 spaces.

For 2.7.4: lines 3429 till 3432 in http://hg.python.org/releasing/2.7.4/file/026ee0057e2d/Modules/itertoolsmodule.c#l3429

For 3.4.0a1: lines 3981 till 3984 in http://hg.python.org/releasing/py3.4.0a1/file/edc668a667ad/Modules/itertoolsmodule.c#l3981

Also, the example code uses the arguments 'firstval' and 'step' whereas the documentation of the function itself uses the arguments 'start' and 'step'. Maybe better be consistent and use as first argument 'start' in both cases?

----------
assignee: docs at python
components: Documentation
hgrepos: 207
messages: 196826
nosy: docs at python, jeroen-vangoey
priority: normal
severity: normal
status: open
title: Intendation issue in example code in itertools.count documentation
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Sep  3 13:46:41 2013
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Tue, 03 Sep 2013 11:46:41 +0000
Subject: [New-bugs-announce] [issue18913] ssl._ssl._test_decode_cert seems
	to leak memory with	certain certificates in Python 2.6
Message-ID: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>


New submission from Mat?j Stuchl?k:

Doing 'valgrind --suppressions=Misc/valgrind-python.supp ./python Lib/tests/test_ssl.py' I'm getting:

==322== LEAK SUMMARY:
==322==    definitely lost: 32 bytes in 1 blocks
==322==    indirectly lost: 392 bytes in 16 blocks
==322==      possibly lost: 1,617,191 bytes in 1,052 blocks
==322==    still reachable: 4,068,239 bytes in 3,201 blocks
==322==         suppressed: 0 bytes in 0 blocks


I managed to reduce that to a shorter reproducer:

"""
import os
import ssl

NULLBYTECERT = os.path.join(os.path.dirname(__file__) or os.curdir, "nullbytecert.pem")
p = ssl._ssl._test_decode_cert(NULLBYTECERT)
"""

where NULLBYTECERT is the cert introduced in issue18709.

Python 2.7 does not leak like this, and the PySSL_test_decode_certificate function looks the same there as in Python 2.6, so I assume it's something else that does the actual leaking.

----------
components: Extension Modules
messages: 196837
nosy: sYnfo
priority: normal
severity: normal
status: open
title: ssl._ssl._test_decode_cert seems to leak memory with certain certificates in Python 2.6
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Tue Sep  3 19:30:20 2013
From: report at bugs.python.org (Brian Mingus)
Date: Tue, 03 Sep 2013 17:30:20 +0000
Subject: [New-bugs-announce] [issue18914] Python docs link to terrible outsi
Message-ID: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>


New submission from Brian Mingus:

The python documentation links to an outside website for info and examples on http basic auth. This documentation is terrible and confusing. The link should be removed, and user's should be advised to use the Requests library.


# this example is from http://www.voidspace.org.uk/python/articles/authentication.shtml
# which is linked to by the official python docs http://docs.python.org/2/howto/urllib2.html

import urllib2
 
theurl = 'http://www.someserver.com/toplevelurl/somepage.htm'
username = 'johnny'
password = 'XXXXXX'
# a great password
 
passman = urllib2.HTTPPasswordMgrWithDefaultRealm()
# this creates a password manager
passman.add_password(None, theurl, username, password)
# because we have put None at the start it will always
# use this username/password combination for  urls
# for which `theurl` is a super-url
 
authhandler = urllib2.HTTPBasicAuthHandler(passman)
# create the AuthHandler
 
opener = urllib2.build_opener(authhandler)
 
urllib2.install_opener(opener)
# All calls to urllib2.urlopen will now use our handler
# Make sure not to include the protocol in with the URL, or
# HTTPPasswordMgrWithDefaultRealm will be very confused.
# You must (of course) use it when fetching the page though.
 
pagehandle = urllib2.urlopen(theurl)
# authentication is now handled automatically for us

----------
assignee: docs at python
components: Documentation
messages: 196854
nosy: docs at python, mingus
priority: normal
severity: normal
status: open
title: Python docs link to terrible outsi
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  4 01:15:19 2013
From: report at bugs.python.org (mpb)
Date: Tue, 03 Sep 2013 23:15:19 +0000
Subject: [New-bugs-announce] [issue18915] ssl.wrap_socket,
	pass in certfile and keyfile as PEM strings
Message-ID: <1378250119.17.0.25988823326.issue18915@psf.upfronthosting.co.za>


New submission from mpb:

It would be nice to be able to pass ssl.wrap_socket the key and certificate as PEM encoded strings, rather than as paths to files.

Similarly for SSLContext.load_cert_chain.

----------
components: Library (Lib)
messages: 196878
nosy: mpb
priority: normal
severity: normal
status: open
title: ssl.wrap_socket, pass in certfile and keyfile as PEM strings
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 02:39:05 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Sep 2013 00:39:05 +0000
Subject: [New-bugs-announce] [issue18916] Various out-of-date Lock text in
	3.2+
Message-ID: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za>


New submission from Tim Peters:

Here under 3.3.2:

"""
>>> from threading import Lock
>>> help(Lock)
Help on built-in function allocate_lock in module _thread:

allocate_lock(...)
    allocate_lock() -> lock object
    (allocate() is an obsolete synonym)
    
    Create a new lock object.  See help(LockType) for information about locks.
"""

But there is no relevant LockType anymore.  The type is now:

"""
>>> type(Lock())
<class '_thread.lock'>
"""

The docs should probably say "help(type(Lock())" instead of "help(LockType)" now.  So let's try that:

"""
>>> help(type(Lock()))
Help on class lock in module _thread:

class lock(builtins.object)
 |  A lock object is a synchronization primitive.  To create a lock,
 |  call the PyThread_allocate_lock() function.
"""

That's a problem:  PyThread_allocate_lock() is a C function, not available (under that name) to Python code.  A Python user should probably stick to threading.Lock().

Skipping most other output:

"""
...
 |  acquire(...)
 |      acquire([wait]) -> bool
 |      (acquire_lock() is an obsolete synonym)
 |      
 |      Lock the lock.  Without argument, this blocks if the lock is already
 |      locked (even by the same thread), waiting for another thread to release
 |      the lock, and return True once the lock is acquired.
 |      With an argument, this will only block if the argument is true,
 |      and the return value reflects whether the lock is acquired.
 |      The blocking operation is interruptible.
...
"""

That's not the right signature for acquire anymore.  Should be

acquire(blocking=True, timeout=-1) 

which is what the threading module docs say.  That is, the docs are up-to-date, but the help strings in the code aren't.  Since 3.2 is the first version introducing the timeout option, that's the earliest version I selected on this report.

I'm going to leave this for someone who wants an easy patch exercise - you're welcome ;-)

----------
components: Interpreter Core
keywords: easy
messages: 196881
nosy: tim.peters
priority: low
severity: normal
stage: needs patch
status: open
title: Various out-of-date Lock text in 3.2+
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep  4 05:59:43 2013
From: report at bugs.python.org (Nick)
Date: Wed, 04 Sep 2013 03:59:43 +0000
Subject: [New-bugs-announce] [issue18917] python won't display greek
	characters in apache under	windows
Message-ID: <1378267183.66.0.904044097978.issue18917@psf.upfronthosting.co.za>


New submission from Nick:

I've set up apache on Windows 7 and I'm running python with cgi.

I have a script that contains this:
#!C:\Python34\python.exe
print ("Content-Type: text/html; charset=utf-8\n")
print ("??????")

Pretty simple, right? When I'm opening the page to my browser in stead of "??????" I get weird ??? symbols (when the browser is set on UTF-8) If I set my browser to ISO-8859-7 I will get the normal greek letters.

"sys.stdout.encoding" will display "cp1253" instead of "utf-8" as it probably should.

scripts with only english characters will work totally fine. the problems seems to be on non-english characters. it displays them as ISO-8859-7.

this doesn't seem to be an apache or windows issue as PHP and Lua will run just fine and all the scripts will display greek characters in my browser. the problem occurs only with python.

----------
messages: 196886
nosy: nickl1
priority: normal
severity: normal
status: open
title: python won't display greek characters in apache under windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 06:40:20 2013
From: report at bugs.python.org (bussau)
Date: Wed, 04 Sep 2013 04:40:20 +0000
Subject: [New-bugs-announce] [issue18918] help('FILES') finds no
	documentation
Message-ID: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za>


New submission from bussau:

Calling for help() about the topic 'FILES' returns 

no documentation found for 'FILES'
------------------------------

Python 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help('topics')

Here is a list of available topics.  Enter any topic name to get more help.

ASSERTION           DEBUGGING           LITERALS            SEQUENCEMETHODS2
ASSIGNMENT          DELETION            LOOPING             SEQUENCES
ATTRIBUTEMETHODS    DICTIONARIES        MAPPINGMETHODS      SHIFTING
ATTRIBUTES          DICTIONARYLITERALS  MAPPINGS            SLICINGS
AUGMENTEDASSIGNMENT DYNAMICFEATURES     METHODS             SPECIALATTRIBUTES
BACKQUOTES          ELLIPSIS            MODULES             SPECIALIDENTIFIERS
BASICMETHODS        EXCEPTIONS          NAMESPACES          SPECIALMETHODS
BINARY              EXECUTION           NONE                STRINGMETHODS
BITWISE             EXPRESSIONS         NUMBERMETHODS       STRINGS
BOOLEAN             FILES               NUMBERS             SUBSCRIPTS
CALLABLEMETHODS     FLOAT               OBJECTS             TRACEBACKS
CALLS               FORMATTING          OPERATORS           TRUTHVALUE
CLASSES             FRAMEOBJECTS        PACKAGES            TUPLELITERALS
CODEOBJECTS         FRAMES              POWER               TUPLES
COERCIONS           FUNCTIONS           PRECEDENCE          TYPEOBJECTS
COMPARISON          IDENTIFIERS         PRINTING            TYPES
COMPLEX             IMPORTING           PRIVATENAMES        UNARY
CONDITIONAL         INTEGER             RETURNING           UNICODE
CONTEXTMANAGERS     LISTLITERALS        SCOPING             
CONVERSIONS         LISTS               SEQUENCEMETHODS1    

>>> help('FILES')
no documentation found for 'FILES'

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

best regards
stephan

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 196888
nosy: docs at python, st.sempert at gmail.com
priority: normal
severity: normal
status: open
title: help('FILES') finds no documentation
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  4 13:11:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 11:11:50 +0000
Subject: [New-bugs-announce] [issue18919] Unify audio modules tests
Message-ID: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Three audio modules, aifc, sunau and wave, have similar interfaces and poor tests. The proposed patch introduces new file Lib/test/audiotests.py with common audio tests.

New testing exposes some bugs and discrepancy between different audio modules. For example aifc uses bytes for compression type and name, while sunau and wave use strings (issue8934). aifc closes underlied file object on close(), while sunau and wave don't. wave rounds a framerate, while aifc and sunau truncate it. Different modules have different behaviors when process framedata with length which is not divisible by frame size.

----------
assignee: serhiy.storchaka
components: Tests
files: audiotests.patch
keywords: patch
messages: 196900
nosy: Claudiu.Popa, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Unify audio modules tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31584/audiotests.patch

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

From report at bugs.python.org  Wed Sep  4 14:30:47 2013
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 04 Sep 2013 12:30:47 +0000
Subject: [New-bugs-announce] [issue18920] argparse module version action
Message-ID: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

Hi,
I just noticed that version output generated via the
**'version' action** of the **argparse** module
is routed to stderr. I'd expect regular output to go to stdout instead.
The current behavior also seems inconsistent to me because --help
prints to stdout.
Best,
Wolfgang

----------
messages: 196905
nosy: wolma
priority: normal
severity: normal
status: open
title: argparse module version action
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep  4 16:27:30 2013
From: report at bugs.python.org (Steven Murdoch)
Date: Wed, 04 Sep 2013 14:27:30 +0000
Subject: [New-bugs-announce] [issue18921] In imaplib,
	cached capabilities may be out of date after login
Message-ID: <1378304850.85.0.68028293284.issue18921@psf.upfronthosting.co.za>


New submission from Steven Murdoch:

When an IMAP server is behind a proxy, the proxy's capabilities may differ from that of the actual IMAP server. However, in Python imaplib, the client will ignore any updates to available capabilities in the response to the LOGIN command (see rfc3501, section 6.2.3). As a result, imaplib will incorrectly assume that certain features are not available (including the IDLE patch in issue 11245, and as implemented in getmail 4.43.0). imaplib should refresh its capability list either based on the result of the login command or by explicitly sending a CAPABILITY command following login.

----------
components: Library (Lib)
messages: 196920
nosy: sjmurdoch
priority: normal
severity: normal
status: open
title: In imaplib, cached capabilities may be out of date after login
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep  4 16:49:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 14:49:28 +0000
Subject: [New-bugs-announce] [issue18922] Output versions of scripts to
	stdout
Message-ID: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The Lib/smtpd.py and Tools/i18n/msgfmt.py scripts write their version strings to stderr. It should be changed to stdout for consistency with most common practice. See also issue18338 and issue18920.

----------
components: Demos and Tools, Library (Lib)
keywords: easy
messages: 196922
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Output versions of scripts to stdout
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 20:41:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Sep 2013 18:41:35 +0000
Subject: [New-bugs-announce] [issue18923] Use the new selectors module in
	the subprocess module
Message-ID: <1378320095.08.0.301150241372.issue18923@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python 3.4 has a new selectors module (issue #16853). It would be nice to use it instead of select.poll or select.select in the subprocess module.

----------
messages: 196936
nosy: haypo
priority: normal
severity: normal
status: open
title: Use the new selectors module in the subprocess module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 21:47:27 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Sep 2013 19:47:27 +0000
Subject: [New-bugs-announce] [issue18924] Enum members are easily replaced
Message-ID: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Python 3.4.0a1+ (default:33727fbb4668+, Aug 31 2013, 12:34:55) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
--> import enum
--> class Test(enum.Enum):
...   this = 'that'
... 
--> Test.this
<Test.this: 'that'>
--> Test.this = 9
--> Test.this
9

I'm pretty sure we don't want that.

----------
assignee: ethan.furman
messages: 196945
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: Enum members are easily replaced
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 22:53:57 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 04 Sep 2013 20:53:57 +0000
Subject: [New-bugs-announce] [issue18925] select.poll.modify is not
	documented
Message-ID: <1378328037.99.0.424927131422.issue18925@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

It was introduced in Python 2.6:
http://bugs.python.org/issue1657
Will commit a patch soon.

----------
assignee: docs at python
components: Documentation
messages: 196953
nosy: docs at python, giampaolo.rodola
priority: normal
severity: normal
status: open
title: select.poll.modify is not 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/issue18925>
_______________________________________

From report at bugs.python.org  Wed Sep  4 23:51:08 2013
From: report at bugs.python.org (Raymond Piller)
Date: Wed, 04 Sep 2013 21:51:08 +0000
Subject: [New-bugs-announce] [issue18926] plistlib - str converted to bool
Message-ID: <1378331468.16.0.119656145942.issue18926@psf.upfronthosting.co.za>


New submission from Raymond Piller:

A plist with:
<key>My key</key>
<string>False</string>

will parse to a dict as:
{'My key': False}

Expected:
{'My key': 'False'}

If bool(False) is needed, the plist should say:
<key>My key</key>
<false/>

----------
messages: 196959
nosy: VertigoRay
priority: normal
severity: normal
status: open
title: plistlib - str converted to bool
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  4 23:54:08 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Sep 2013 21:54:08 +0000
Subject: [New-bugs-announce] [issue18927] Lock.acquire() docs incorrect
	about negative timeout
Message-ID: <1378331648.69.0.879815072803.issue18927@psf.upfronthosting.co.za>


New submission from Tim Peters:

Here from the 3.3.2 docs for threading.Lock:

"""
acquire(blocking=True, timeout=-1) 
Acquire a lock, blocking or non-blocking.

...

When invoked with the floating-point timeout argument set to a positive value, block for at most the number of seconds specified by timeout and as long as the lock cannot be acquired. A negative timeout argument specifies an unbounded wait. 

...

"""

However, that's not what the code does for a negative timeout:

>>> from threading import Lock
>>> x = Lock()
>>> x.acquire(1, -0.2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: timeout value must be strictly positive

The only negative value the code allows is -1, in lock_PyThread_acquire_lock():

    if (timeout < 0 && timeout != -1) {
        PyErr_SetString(PyExc_ValueError, "timeout value must be "
                        "strictly positive");
        return NULL;
    }

The docs should change to say that -1 is special ;-)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 196960
nosy: docs at python, tim.peters
priority: normal
severity: normal
status: open
title: Lock.acquire() docs incorrect about negative timeout
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep  5 02:18:34 2013
From: report at bugs.python.org (David Benbennick)
Date: Thu, 05 Sep 2013 00:18:34 +0000
Subject: [New-bugs-announce] [issue18928] Remove misleading documentation
	for random.shuffle
Message-ID: <1378340314.25.0.0317280223826.issue18928@psf.upfronthosting.co.za>


New submission from David Benbennick:

Since Python 2.1 [1], when random.shuffle was added, the documentation has said:

"""Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated."""

This comment is incorrect and misleading.  In fact, I claim that shuffle can produce "all" permutations for any representable sequence.

To shuffle a sequence of length N requires log(N!) ~ N * log(N/e) bits of randomness [2].  The random module provides a generator with "a period of 2**19937-1", meaning you can get 2**19937 bits of randomness out of it before it starts repeating.

All of which is to say that any representable sequence, say N < 2**50, will need no more than 2**60 bits of randomness to shuffle.  That is well within the period of the random number generator.

Attached is a patch that deletes the comment.

An illustration of this misconception is at [3].


1: http://docs.python.org/release/2.1/lib/module-random.html
2: https://en.wikipedia.org/wiki/Factorial#Rate_of_growth_and_approximations_for_large_n
3: http://stackoverflow.com/questions/3062741/maximal-length-of-list-to-shuffle-with-python-random-shuffle

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 196971
nosy: dbenbenn, docs at python
priority: normal
severity: normal
status: open
title: Remove misleading documentation for random.shuffle
Added file: http://bugs.python.org/file31593/mywork.patch

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

From report at bugs.python.org  Thu Sep  5 04:51:02 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Sep 2013 02:51:02 +0000
Subject: [New-bugs-announce] [issue18929] inspect.classify_class_attrs
	ignores metaclass
Message-ID: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Part of the solution for Issue18693 is to have `inspect.classify_class_attrs()` properly consider the metaclass (or type) of the class when searching for the origination point of class attributes.

The fix is changing line 325:

-        for base in (cls,) + mro:
+        for base in (cls,) + mro + (type(cls),):

or line 361:

-    return cls.__mro__
+    return cls.__mro__ + (type(cls), )

Should we target previous Pythons with this fix?

----------
messages: 196973
nosy: eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: inspect.classify_class_attrs ignores metaclass
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  5 12:52:34 2013
From: report at bugs.python.org (Stefan Schukat)
Date: Thu, 05 Sep 2013 10:52:34 +0000
Subject: [New-bugs-announce] [issue18930] os.spawnXX functions terminates
	process if second	argument is empty list
Message-ID: <1378378354.78.0.544374922966.issue18930@psf.upfronthosting.co.za>


New submission from Stefan Schukat:

If os.spawnv or os.spawnve  is called with an empty second argument the process terminates in release builds under Windows. This is simple to reproduce:

>>> import os
>>> nPath = os.path.join(os.environ["windir"], "notepad.exe")
>>> os.spawnv(os.P_NOWAIT, nPath, []) # or os.spawnv(os.P_NOWAIT, nPath, [], {})

This has the same cause as the bug reported for execv http://bugs.python.org/issue1039 and could be fixed in the same way.

----------
components: Interpreter Core
messages: 196988
nosy: SSchukat
priority: normal
severity: normal
status: open
title: os.spawnXX functions terminates process if second argument is empty list
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  5 12:58:35 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 Sep 2013 10:58:35 +0000
Subject: [New-bugs-announce] [issue18931] new selectors module should
	support devpoll on Solaris
Message-ID: <1378378715.64.0.328227872693.issue18931@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

This is a follow up of issue 16853.
I will try to see whether I can come up with a patch later today.

----------
messages: 196989
nosy: christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, haypo, meador.inge, neologix, pitrou, python-dev, rosslagerwall, sbt
priority: normal
severity: normal
status: open
title: new selectors module should support devpoll on Solaris
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  5 13:01:54 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 Sep 2013 11:01:54 +0000
Subject: [New-bugs-announce] [issue18932] selectors and modify()
Message-ID: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

This is a follow up of issue 16853 (see comment http://bugs.python.org/issue16853#msg196984).

----------
messages: 196990
nosy: christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, haypo, meador.inge, neologix, pitrou, python-dev, rosslagerwall, sbt
priority: normal
severity: normal
status: open
title: selectors and modify()
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  5 16:10:06 2013
From: report at bugs.python.org (Jonathan Frere)
Date: Thu, 05 Sep 2013 14:10:06 +0000
Subject: [New-bugs-announce] [issue18933] Add link to source code in logging
	documentation
Message-ID: <1378390206.88.0.825858805448.issue18933@psf.upfronthosting.co.za>


New submission from Jonathan Frere:

The logging module documentation is probably best accompanied by the source that it is meant to be documenting.  Could a link to either the package directory (http://hg.python.org/cpython/file/2.7/Lib/logging/) or the __init__.py file in that directory (http://hg.python.org/cpython/file/2.7/Lib/logging/__init__.py), I'd argue the __init__.py file.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 197000
nosy: Johz, docs at python, vinay.sajip
priority: normal
severity: normal
status: open
title: Add link to source code in logging documentation
type: enhancement

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

From report at bugs.python.org  Thu Sep  5 18:46:25 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 Sep 2013 16:46:25 +0000
Subject: [New-bugs-announce] [issue18934] multiprocessing: use selectors
	module
Message-ID: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Here's a patch.

----------
components: Library (Lib)
files: selectors_multiprocessing.diff
keywords: needs review, patch
messages: 197012
nosy: neologix, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing: use selectors module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31616/selectors_multiprocessing.diff

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

From report at bugs.python.org  Thu Sep  5 18:59:58 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 Sep 2013 16:59:58 +0000
Subject: [New-bugs-announce] [issue18935] test_regrtest.test_timeout failure
Message-ID: <1378400398.96.0.0580722992203.issue18935@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

http://buildbot.python.org/all/builders/AMD64 Fedora without threads 3.x/builds/5074/steps/test/logs/stdio
"""
======================================================================
FAIL: test_timeout (test.test_regrtest.ParseArgsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_regrtest.py", line 30, in test_timeout
    self.assertEqual(ns.timeout, 4.2)
AssertionError: None != 4.2
"""

That's because the "--timeout" isn't supported if Python is built --without-threads.

Possible patch attached.

----------
components: Tests
files: test_timeout.diff
keywords: needs review, patch
messages: 197013
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: test_regrtest.test_timeout failure
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31617/test_timeout.diff

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

From report at bugs.python.org  Thu Sep  5 22:03:08 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 05 Sep 2013 20:03:08 +0000
Subject: [New-bugs-announce] [issue18936] getopt chokes on unicode option
	names
Message-ID: <1378411388.86.0.748005801735.issue18936@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Today I encountered a bug where I was using a Distutils.Command subclass, which uses getopt for option parsing. The implementation is here: https://bitbucket.org/jaraco/jaraco.packaging/src/2.2/jaraco/packaging/depends.py?at=default

Around line 59, the options are defined, but because the syntax is Python 3 style with unicode literals, under Python 2.7, those get created as unicode objects.

When I invoke that Command under Python 2.7, I get this error:

Traceback (most recent call last):
  File "setup.py", line 160, in <module>
    setup(**setup_params)
  File "/usr/lib/python2.7/distutils/core.py", line 138, in setup
    ok = dist.parse_command_line()
  File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 250, in parse_command_line
  File "/usr/lib/python2.7/distutils/dist.py", line 467, in parse_command_line
    args = self._parse_command_opts(parser, args)
  File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 533, in _parse_command_opts
  File "/usr/lib/python2.7/distutils/dist.py", line 564, in _parse_command_opts
    (args, opts) = parser.getopt(args[1:])
  File "/usr/lib/python2.7/distutils/fancy_getopt.py", line 253, in getopt
    self._grok_option_table()
  File "/usr/lib/python2.7/distutils/fancy_getopt.py", line 171, in _grok_option_table
    "must be a string of length >= 2") % long
distutils.errors.DistutilsGetoptError: invalid long option 'requirement=': must be a string of length >= 2

That error is raised because 'requirement=' is a Unicode, but the test in fancy_getopt is isinstance(opt, str).

I can work around the issue by wrapping all of the options in str() calls, which leaves them unchanged on Python 3 and downcasts them to strings on Python 2, but that's not pretty.

I suggest that fancy_getopt should either include 'unicode' in the isinstance test or (if unicode values really aren't supported), encode unicode values first.

----------
components: Library (Lib)
messages: 197020
nosy: jason.coombs
priority: low
severity: normal
status: open
title: getopt chokes on unicode option names
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  5 22:26:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Sep 2013 20:26:01 +0000
Subject: [New-bugs-announce] [issue18937] add unittest assertion for logging
Message-ID: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It is sometimes useful to check for the log messages emitted by some piece of code (especially a library). Would it be a good idea to add a dedicated assertion method for that? I would propose the following API:


with self.assertLogging("logger.name", level="WARN") as cm:
    ...

The `cm` context manager could give access to all the log records and formatted output lines for the given logger name (and children) and at least the given logging level. I have something like that here, except not with a dedicated assertion method:
https://bitbucket.org/optiflowsrd/obelus/src/c2a2f78068123264adde8cc3ece4889c61773f00/obelus/test/__init__.py?at=default#cl-20

----------
components: Library (Lib)
messages: 197022
nosy: ezio.melotti, michael.foord, pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: add unittest assertion for logging
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  5 23:11:25 2013
From: report at bugs.python.org (Johnny Boy)
Date: Thu, 05 Sep 2013 21:11:25 +0000
Subject: [New-bugs-announce] [issue18938] Prepend Is Not A Word
Message-ID: <1378415485.5.0.896501812591.issue18938@psf.upfronthosting.co.za>


New submission from Johnny Boy:

If you do a custom install on Windows and click "Add python.exe to Path" the text below says "Prepend c:\Python33\ to the system Path variable"

Prepend is not a word!
The word you are looking for is Prefix.
http://encyclopedia2.thefreedictionary.com/prepend
"
Although it sounds correct, prepend is not an English word. It was created to sound like the opposite of "append," which means to add to the end. The correct English word is "prefix;"
"

----------
components: Installation
messages: 197025
nosy: opticyclic
priority: normal
severity: normal
status: open
title: Prepend Is Not A Word
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep  6 00:02:40 2013
From: report at bugs.python.org (Graham Wideman)
Date: Thu, 05 Sep 2013 22:02:40 +0000
Subject: [New-bugs-announce] [issue18939] Venv docs regarding original
	python install
Message-ID: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>


New submission from Graham Wideman:

http://docs.python.org/dev/library/venv.html

More detail needed regarding the original python environment

The article explains how to use venv to create a new python installation with independent libraries etc, and a means to activate one or another virtual python environment. However, there are some points regarding the original python environment which are cloudy.

(1) After pyvenv, what status does the original python installation have? Does pyvenv turn it into just one of now two or more virtual environments? Or is the original one special? Must it be specifically deactivated in order to activate a (different) virtual environment?

(2) The motivation behind venv seems to be to create virtual enviroments that can be substantially or completely separate from the system site directories or from the original python that pyvenv was run from.  Yet elsewhere the doc discusses how  pyvenv creates a pyvenv.cfg file with a home key pointing back to the originating Python installation, and "sys.base_prefix and sys.base_exec_prefix point to the non-venv Python installation which was used to create the venv."... which suggest that a venv is _not_ independent of its creating Python installation.

It would be helpful to provide some context for this seemingly contradictory information.  Perhaps there are scenarios with differing degrees of independence, in which these pointers back to the originating Python installation may or may not be relevant?

(3) How do you proceed to create virtual environments from scratch when you have no initial python installation, or no python installation of that python version?

-- Hope these suggestions help.

----------
assignee: docs at python
components: Documentation
messages: 197030
nosy: docs at python, gwideman
priority: normal
severity: normal
status: open
title: Venv docs regarding original python install
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep  6 01:49:27 2013
From: report at bugs.python.org (Joshua Olson)
Date: Thu, 05 Sep 2013 23:49:27 +0000
Subject: [New-bugs-announce] [issue18940] TimedRotatingFileHandler fails to
	doRollover if a logger	has delay=True and no logs in that time.
Message-ID: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>


New submission from Joshua Olson:

In TimedRotatingFileHandler if you have a low volume logger than hasn't written to the log within the interval time doRollover will fail because there is no file to rotate.

os.rename(self.baseFilename, dfn) 

should be something like

if os.path.exists(self.base_fileName):
    os.rename(self.baseFilename, dfn

I have included a unit test file.  This test fails on 2.7.1 and 2.7.3. I have not tried 2.7.5.

----------
components: Library (Lib)
files: logging_test.py
messages: 197035
nosy: solarmist
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler fails to doRollover if a logger has delay=True and no logs in that time.
versions: Python 2.7
Added file: http://bugs.python.org/file31620/logging_test.py

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

From report at bugs.python.org  Fri Sep  6 01:56:08 2013
From: report at bugs.python.org (Joshua Olson)
Date: Thu, 05 Sep 2013 23:56:08 +0000
Subject: [New-bugs-announce] [issue18941] RotatingFileHandler and
	TimedRotatingFileHandler do not	respect delay on rollover
Message-ID: <1378425368.84.0.428778978895.issue18941@psf.upfronthosting.co.za>


New submission from Joshua Olson:

For low volume loggers RotatingFileHandler and TimedRotatingFileHandler will create possibly unnecessary files on doRollover, since they don't check the value of delay when opening the new self.stream.

self.stream = self._open()

should be something like

if not self.delay:
    self.stream = self._open()

----------
messages: 197036
nosy: solarmist
priority: normal
severity: normal
status: open
title: RotatingFileHandler and TimedRotatingFileHandler do not respect delay on rollover

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

From report at bugs.python.org  Fri Sep  6 05:46:24 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Sep 2013 03:46:24 +0000
Subject: [New-bugs-announce] [issue18942] _debugmallocstats() gibberish
	output on Windows
Message-ID: <1378439184.72.0.614374936253.issue18942@psf.upfronthosting.co.za>


New submission from Tim Peters:

On Windows, _debugmallocstats() output ends with lines like this:

  0 free 12-sized PyTupleObjects * zd bytes each =                    0
  0 free 13-sized PyTupleObjects * zd bytes each =                    0

"zd" is senseless.  Betting it's due to using a %zd format code, which MS doesn't support (but Python itself supports in other printf-like functions, like PyErr_Format()).  I'll track it down and fix it :-)

----------
assignee: tim.peters
messages: 197048
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: _debugmallocstats() gibberish output on Windows
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Sep  6 11:00:02 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 09:00:02 +0000
Subject: [New-bugs-announce] [issue18943] argparse: default args in mutually
	exclusive groups
Message-ID: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>


New submission from Armin Rigo:

In argparse, default arguments have a strange behavior that shows up in mutually exclusive groups: specifying explicitly on the command-line an argument, but giving it its default value, is sometimes equivalent to not specifying the argument at all, and sometimes not.

See the attached test diff: it contains two apparently equivalent pieces of code, but one passes and one fails.  The difference is that, in CPython, int("42") is 42 but int("4200") is not 4200 (in the sense of the operator "is").

The line that uses "is" in this way is this line in argparse.py (line 1783 in 2.7 head):

            if argument_values is not action.default:

----------
files: test_argparse.diff
keywords: patch
messages: 197058
nosy: arigo
priority: normal
severity: normal
status: open
title: argparse: default args in mutually exclusive groups
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file31626/test_argparse.diff

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

From report at bugs.python.org  Fri Sep  6 11:12:51 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 09:12:51 +0000
Subject: [New-bugs-announce] [issue18944] Minor mistake in test_set.py
Message-ID: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>


New submission from Armin Rigo:

Found a minor mistake in test_set.py.  Patch attached.

----------
components: Interpreter Core
files: test_set.diff
keywords: patch
messages: 197060
nosy: arigo
priority: normal
severity: normal
status: open
title: Minor mistake in test_set.py
versions: Python 3.5
Added file: http://bugs.python.org/file31627/test_set.diff

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

From report at bugs.python.org  Fri Sep  6 11:34:12 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Fri, 06 Sep 2013 09:34:12 +0000
Subject: [New-bugs-announce] [issue18945] Name collision handling in
	tempfile is not covered by	tests
Message-ID: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>


New submission from Vlad Shcherbina:

I intend to add test for (existing dir)-(new file) collision in http://bugs.python.org/issue18849, but file-file, file-dir and dir-dir collisions are yet to be covered.

----------
components: Tests
messages: 197062
nosy: vlad
priority: normal
severity: normal
status: open
title: Name collision handling in tempfile is not covered by tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Sep  6 18:10:43 2013
From: report at bugs.python.org (James Lu)
Date: Fri, 06 Sep 2013 16:10:43 +0000
Subject: [New-bugs-announce] [issue18946] HTMLParser should ignore errors
	when parsing text in	<script> tags
Message-ID: <1378483843.82.0.705841583098.issue18946@psf.upfronthosting.co.za>


New submission from James Lu:

It will show invalid html inside of script tags, for example, at the learners dictionary:
	function output_creative (id)
		{	document.write
				("<div id='" + id + "'>" + 
					"<scr" + "ipt type='text/javascript'>\r\n" + 
					"googletag.cmd.push(function() { googletag.display('" + id + "'); });\r\n" +
					"</sc" + "ript>" + invalid end tag
					"</div>");
		};
it thinks </sc" + "ript"> is an actual end tag.

----------
messages: 197077
nosy: James.Lu
priority: normal
severity: normal
status: open
title: HTMLParser should ignore errors when parsing text in <script> tags

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

From report at bugs.python.org  Fri Sep  6 20:14:05 2013
From: report at bugs.python.org (Mikael Ryding)
Date: Fri, 06 Sep 2013 18:14:05 +0000
Subject: [New-bugs-announce] [issue18947] Bug in module netaddr
Message-ID: <1378491245.37.0.748278475446.issue18947@psf.upfronthosting.co.za>


New submission from Mikael Ryding:

I found this in the netaddr module when I was trying to get the CIDR from a number of ip/netmask combinations. The expected cidr in the example below should be: 192.1.0.0/23.

>>> ip = netaddr.IPNetwork("192.1.1.128", "255.255.254.0")
>>> ip.netmask
IPAddress('255.255.255.0')
>>> ip.cidr
IPNetwork('192.1.1.0/24')

----------
messages: 197085
nosy: mryding
priority: normal
severity: normal
status: open
title: Bug in module netaddr
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  6 20:56:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 18:56:05 +0000
Subject: [New-bugs-announce] [issue18948] deliberately crashing tests should
	prevent core dumps
Message-ID: <1378493765.27.0.466855736327.issue18948@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Here is a (exhaustive?) list of tests which deliberately crash the interpreter:
- test_daemon_threads_fatal_error() in test_threading
- several fatal error tests in test_faulthandler
- test_recursionlimit_fatalerror() in test_sys
- test_no_FatalError_infinite_loop() in test_capi

They should reuse the new SuppressCoreFiles facility from test.support.

----------
components: Tests
keywords: easy
messages: 197090
nosy: lambertv, neologix, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: deliberately crashing tests should prevent core dumps
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep  6 20:59:45 2013
From: report at bugs.python.org (Wilberto Morales)
Date: Fri, 06 Sep 2013 18:59:45 +0000
Subject: [New-bugs-announce] [issue18949] codeop possible flow erro
Message-ID: <1378493985.89.0.543332382387.issue18949@psf.upfronthosting.co.za>


New submission from Wilberto Morales:

I think the way this loop in /Lib/codeop.py is wrong

def _maybe_compile(compiler, source, filename, symbol):
    # Check for source consisting of only blank lines and comments
    for line in source.split("\n"):
        line = line.strip()
        if line and line[0] != '#':
            break               # Leave it alone
    else:
        if symbol != "eval":
            source = "pass"     # Replace it with a 'pass' statement

I think the else statement shouldn't be there.

----------
messages: 197091
nosy: Wilberto
priority: normal
severity: normal
status: open
title: codeop possible flow erro
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep  6 23:24:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 21:24:54 +0000
Subject: [New-bugs-announce] [issue18950] Miscellaneous fixes for the sunau
	module
Message-ID: <1378502694.18.0.563332968903.issue18950@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch fixes followed bugs in the sunau module:

1. Au_read.readframes() reads wrong number of frames from multichannel stream.

2. Au_read.readframes() doesn't change current file position.

3. Au_write.writeframesraw() incorrectly updates current file position in a stream with u-Law compression.

4. Au_read.getnframes() returns a float (underporting from Python 2).

5. Au_write incorrectly updates header when it was opened with existing non-empty file object.

New tests proposed in issue18919 expose all these bugs.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: sunau.patch
keywords: patch
messages: 197109
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Miscellaneous fixes for the sunau module
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31631/sunau.patch

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

From report at bugs.python.org  Sat Sep  7 04:46:26 2013
From: report at bugs.python.org (py.user)
Date: Sat, 07 Sep 2013 02:46:26 +0000
Subject: [New-bugs-announce] [issue18951] In unittest.TestCase.assertRegex
	change "re" and "regex"	to "r"
Message-ID: <1378521986.13.0.796704852763.issue18951@psf.upfronthosting.co.za>


New submission from py.user:

there is no direct link to table

look under link
http://docs.python.org/3/library/unittest.html#unittest.TestCase.assertWarnsRegex

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 197130
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestCase.assertRegex change "re" and "regex" to "r"
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31636/issue.diff

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

From report at bugs.python.org  Sat Sep  7 06:22:13 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 07 Sep 2013 04:22:13 +0000
Subject: [New-bugs-announce] [issue18952] Fix test.support.open_urlresource
	(support package	regression)
Message-ID: <1378527733.08.0.636104620502.issue18952@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Since test.support was moved into its own package, support.open_urlresource has been unable to work.  It expects <__file__ dir>/data to exist, but since <__file__ dir> is now Lib/test/support instead of Lib/test, it doesn't unless someone creates it manually.  Since open_urlresource turns all exceptions into SkipTest, this means that all test runs have been silently skipping test_codecmaps_* and a couple others since support became a package.

Here's a patch with my preferred fix, which is to move Lib/test/data to Lib/test/support/data.  This dir is only used by support.open_urlresource, and moving it does just a tiny bit to de-clutter Lib/test.

----------
components: Tests
files: move_test_data.diff
keywords: patch
messages: 197132
nosy: ezio.melotti, ncoghlan, zach.ware
priority: normal
severity: normal
status: open
title: Fix test.support.open_urlresource (support package regression)
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31637/move_test_data.diff

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

From report at bugs.python.org  Sat Sep  7 06:40:22 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 04:40:22 +0000
Subject: [New-bugs-announce] [issue18953] Typo in NEWS about fixed format
	specifiers for	Py_ssize_t in debugging output in the _sre module
Message-ID: <1378528822.12.0.535842380939.issue18953@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

File Misc/NEWS, line 65 & 66:

- Issue #18672: Fixed format specifiers for Py_ssize_t in debugging output in
  the _sre moduel.

"moduel" => "module"

Related commit:
http://hg.python.org/cpython/rev/c41c68a18bb6

----------
assignee: docs at python
components: Documentation
messages: 197134
nosy: docs at python, serhiy.storchaka, vajrasky
priority: normal
severity: normal
status: open
title: Typo in NEWS about fixed format specifiers for Py_ssize_t in debugging output in the _sre module
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  7 06:48:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 04:48:08 +0000
Subject: [New-bugs-announce] [issue18954] Grammatically incorrect sentences
	in Python/fileutils.c
Message-ID: <1378529288.44.0.552917798936.issue18954@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In commit about "implementation of the PEP 446: file descriptors and file handles are now created non-inheritable", there are some grammatically incorrect sentences in Python/fileutils.c.

Please see the patch for details.

Related commit:
http://hg.python.org/cpython/rev/ef889c3d5dc6?revcount=240

----------
assignee: docs at python
components: Documentation
files: fix_typo_in_fileutils.patch
keywords: patch
messages: 197135
nosy: docs at python, haypo, vajrasky
priority: normal
severity: normal
status: open
title: Grammatically incorrect sentences in Python/fileutils.c
versions: Python 3.4
Added file: http://bugs.python.org/file31639/fix_typo_in_fileutils.patch

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

From report at bugs.python.org  Sat Sep  7 06:56:33 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 04:56:33 +0000
Subject: [New-bugs-announce] [issue18955] Confusing documentation in
	Lib/importlib/util.py
Message-ID: <1378529793.43.0.614039652943.issue18955@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/importlib/util.py, the documentation is confusing me.

Line 42 & 43:

    If an exception is raised and the decorator created the module it is
    subsequently removed from sys.modules.

Is it supposed to be:

    "If an exception is raised and the decorator which created the module is
    subsequently removed from sys.modules." ?

----------
assignee: docs at python
components: Documentation
messages: 197136
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Confusing documentation in Lib/importlib/util.py
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  7 07:38:56 2013
From: report at bugs.python.org (Ben Finney)
Date: Sat, 07 Sep 2013 05:38:56 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue18956=5D_Document_useful_fu?=
 =?utf-8?b?bmN0aW9ucyBpbiDigJhweWRvY+KAmSBtb2R1bGU=?=
Message-ID: <1378532336.08.0.216765249116.issue18956@psf.upfronthosting.co.za>


New submission from Ben Finney:

The library documentation for ?pydoc? expects that the ?pydoc? module will only ever be run as a command-line program. This ignores the general usefulness of several of the functions in that module when imported from the library.

The documentation should describe at least the following functions:

* pydoc.getdoc

* pydoc.synopsis

* pydoc.splitdoc

The following would be useful also:

* pydoc.classname

* pydoc.cram

* pydoc.allmethods

----------
assignee: docs at python
components: Documentation
messages: 197138
nosy: bignose, docs at python
priority: normal
severity: normal
status: open
title: Document useful functions in ?pydoc? module
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Sep  7 10:34:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Sep 2013 08:34:01 +0000
Subject: [New-bugs-announce] [issue18957] PYTHONFAULTHANDLER enables
	faulthandler when the	variable is empty
Message-ID: <1378542841.95.0.330646753662.issue18957@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Most Python environment variables (PYTHON*) only enable something when their value is non-empty. The PYTHONFAULTHANDLER enables the faulthandler even if the value is empty. As the author of the module, I think that it is a bug and should be fixed (even in Python 3.3).

----------
messages: 197142
nosy: haypo
priority: normal
severity: normal
status: open
title: PYTHONFAULTHANDLER enables faulthandler when the variable is empty
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Sep  7 14:33:15 2013
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Chaves_Fern=C3=A1ndez?=)
Date: Sat, 07 Sep 2013 12:33:15 +0000
Subject: [New-bugs-announce] [issue18958] Exception('No JSON object could be
	decoded') when	parsing a valid JSON
Message-ID: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>


New submission from Adri?n Chaves Fern?ndez:

Calling json.load() with a file object or json.loads() with a string containing the attached JSON code raises an exception with the message 'No JSON object could be decoded'.

I?ve pasted the JSON code into http://jsonlint.com/ and it reports it as valid JSON.

This JSON code comes from the 0 A.D. game (https://github.com/0ad/0ad/blob/master/binaries/data/mods/public/civs/maur.json), and the game successfully parses it as well (with whatever they use for that). Yet it fails with json.load() and json.loads().

Note also that the rest of the JSON files of the same game folder (https://github.com/0ad/0ad/tree/master/binaries/data/mods/public/civs) do work with json.load() and json.loads().

----------
components: Extension Modules
files: input.json
messages: 197152
nosy: Gallaecio
priority: normal
severity: normal
status: open
title: Exception('No JSON object could be decoded') when parsing a valid JSON
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31643/input.json

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

From report at bugs.python.org  Sat Sep  7 15:09:22 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Sep 2013 13:09:22 +0000
Subject: [New-bugs-announce] [issue18959] Create a "Superseded modules"
	section in standard	library ToC
Message-ID: <1378559362.61.0.726437189184.issue18959@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As discussed at the language summit earlier this year [1], it isn't alway easy to tell when glancing through the standard library docs which modules are merely hanging around because removing them would break backwards compatibility.

However, after reviewing the current ToC, we currently appear to only have two genuinely superseded modules: optparse (superseded by argparse) and imp (superseded by importlib).

Other cases where different modules touch on the same area are high level/low level splits (e.g. select vs selectors), or ones where the alternate modules are offering compatibility with different styles of API (e.g. etree vs DOM for XML, getopt vs argparse).

In future, asyncore/asynchat will hopefully be superseded by the PEP 3156 code (as "concurrent.events" or similar) and would also be moved under the new heading.

Marking as "easy" since the mechanics of the patch should be pretty simple: create a new heading and move the references to optparse and imp from their current locations.

[1] http://python-notes.boredomandlaziness.org/en/latest/conferences/pyconus2013/20130313-language-summit.html#legacy-modules

(I thought I had already created a bug for this, but can't find it, so I've created this new one. If I did already create an issue, we can close it as a duplicate and keep this one.)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 197154
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Create a "Superseded modules" section in standard library ToC
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  7 15:11:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 13:11:33 +0000
Subject: [New-bugs-announce] [issue18960] First line can be executed twice
Message-ID: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When run in Python 3 followed script:

print('first')
#coding=iso8859-1
print('second')

it prints the 'first' string twice.

Besides this weird behavior I think PEP-0263 should specify that if a magic comment is second line in the file then first line should be a comment too.

----------
components: Interpreter Core
files: double_first_line.py
messages: 197156
nosy: loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: First line can be executed twice
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31644/double_first_line.py

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

From report at bugs.python.org  Sat Sep  7 17:35:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 15:35:49 +0000
Subject: [New-bugs-announce] [issue18961] Non-UTF8 encoding line
Message-ID: <1378568149.13.0.824239204214.issue18961@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a file which is accepted by Python interpreter but is rejected by the tokenize module.

$ ./python nonutf8_coding_line.py 
$ ./python -m tokenize nonutf8_coding_line.py 
nonutf8_coding_line.py: error: invalid or missing encoding declaration for 'nonutf8_coding_line.py'

Python itself checks that a line is UTF-8 encoded only if not found a magic comment. The tokenize module checks it before searching (issue14629).

----------
components: Interpreter Core, Library (Lib)
files: nonutf8_coding_line.py
messages: 197169
nosy: Arfrever, benjamin.peterson, brett.cannon, eric.snow, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Non-UTF8 encoding line
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31648/nonutf8_coding_line.py

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

From report at bugs.python.org  Sat Sep  7 20:26:28 2013
From: report at bugs.python.org (Wouter Bolsterlee)
Date: Sat, 07 Sep 2013 18:26:28 +0000
Subject: [New-bugs-announce] [issue18962] Add special case for single
	iterator in heapq.merge	function
Message-ID: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>


New submission from Wouter Bolsterlee:

The heapq.merge() function merges multiple sorted iterables into a single sorted output.  The function uses a heap queue that is repeatedly looped over until it has generated all output.

If only a single iterable is passed to heapq.merge(), the heap will have len(h) == 1, which means the looping and heap manipulation just degrades to a convoluted "yield from iterables[0]". This negatively impacts performance. The attached patch adds a short-circuit for this single input case.

The behaviour of the function remains unchanged:

>>> list(merge_before([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
[0, 1, 2, 3, 4, 5, 5, 7, 8, 10, 15, 20, 25]
>>> list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
[0, 1, 2, 3, 4, 5, 5, 7, 8, 10, 15, 20, 25]

For multiple inputs, there is no measurable performance difference (measured
using IPython's %timeit). Without patch:

>>> %timeit list(merge_before([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.7 ?s per loop
>>> %timeit list(merge_before([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.4 ?s per loop
>>> %timeit list(merge_before([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.5 ?s per loop

With patch:

>>> %timeit list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.7 ?s per loop
>>> %timeit list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.6 ?s per loop
>>> %timeit list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.6 ?s per loop
>>> %timeit list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.8 ?s per loop

The real performance gain is of course when only a single iterable is passed. Without patch:

>>> %timeit for x in merge_before(range(10000)): pass
100 loops, best of 3: 2.65 ms per loop
>>> %timeit for x in merge_before(range(10000)): pass
100 loops, best of 3: 2.52 ms per loop
>>> %timeit for x in merge_before(range(10000)): pass
100 loops, best of 3: 2.51 ms per loop

With patch:

>>> %timeit for x in merge_after(range(10000)): pass
1000 loops, best of 3: 604 ?s per loop
>>> %timeit for x in merge_after(range(10000)): pass
1000 loops, best of 3: 609 ?s per loop
>>> %timeit for x in merge_after(range(10000)): pass
1000 loops, best of 3: 603 ?s per loop

This is a ~4x speedup for an input consisting of 10000 items. Compared to plain iteration:

>>> %timeit for x in range(10000): pass
1000 loops, best of 3: 263 ?s per loop
>>> %timeit for x in range(10000): pass
1000 loops, best of 3: 268 ?s per loop
>>> %timeit for x in range(10000): pass
1000 loops, best of 3: 273 ?s per loop

Without the patch, heapq.merge() is ~10x as slow as plain iteration. With the patch, this is reduced to ~2.5x.

(Note: all testing done using Python 3.3.2 on a 64bit Linux machine.)

----------
components: Library (Lib)
files: heapq-merge-single-input-optimization.patch
keywords: patch
messages: 197174
nosy: wbolster
priority: normal
severity: normal
status: open
title: Add special case for single iterator in heapq.merge function
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file31649/heapq-merge-single-input-optimization.patch

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

From report at bugs.python.org  Sat Sep  7 23:32:00 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Sep 2013 21:32:00 +0000
Subject: [New-bugs-announce] [issue18963] test_selectors
	test_above_fd_setsize cases fail on OS X	due to infinite hard limit
Message-ID: <1378589520.51.0.514840120494.issue18963@psf.upfronthosting.co.za>


New submission from Ned Deily:

======================================================================
ERROR: test_above_fd_setsize (test.test_selectors.PollSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/support/__init__.py", line 485, in wrapper
    return func(*args, **kw)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_selectors.py", line 312, in test_above_fd_setsize
    resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard))
ValueError: current limit exceeds maximum limit

======================================================================
ERROR: test_above_fd_setsize (test.test_selectors.KqueueSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/support/__init__.py", line 485, in wrapper
    return func(*args, **kw)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_selectors.py", line 312, in test_above_fd_setsize
    resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard))
ValueError: current limit exceeds maximum limit

----------------------------------------------------------------------
Ran 58 tests in 8.080s

FAILED (errors=2, skipped=12)

Looking at the OS X man page for setrlimit(2), it appears the test's strategy of trying to set the soft RLIMIT_NOFILE to the hard RLIMIT_NOFILE ceiling will fail on OS X (at least) if the hard limit is infinite:

>>> import resource
>>> resource.getrlimit(resource.RLIMIT_NOFILE)
(2560, 9223372036854775807)

>From the man page:
COMPATIBILITY
     setrlimit() now returns with errno set to EINVAL in places that historically
     succeeded.  It no longer accepts "rlim_cur = RLIM_INFINITY" for RLIM_NOFILE.
     Use "rlim_cur = min(OPEN_MAX, rlim_max)".

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/setrlimit.2.html

----------
components: Tests
messages: 197189
nosy: ned.deily, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: test_selectors test_above_fd_setsize cases fail on OS X due to infinite hard limit
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  7 23:45:31 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Sep 2013 21:45:31 +0000
Subject: [New-bugs-announce] [issue18964] test_tcl fails when _tkinter
	linked with Tcl 8.4
Message-ID: <1378590331.21.0.150230107781.issue18964@psf.upfronthosting.co.za>


New submission from Ned Deily:

The 32bit-only OS X installer links with Tcl/Tk 8.4 as these are the only supported native (Aqua) versions on older supported systems (OS X 10.5 Leopard and earlier).  These failures are also appearing on the Tiger (10.4) buildbots.

$ /usr/local/bin/python3.4 -c 'import tkinter;print(tkinter.TclVersion)'
8.4
$ /usr/local/bin/python3.4 -m test -w -uall test_tcl
[1/1] test_tcl
test test_tcl failed -- multiple errors occurred; run in verbose mode for details
1 test failed:
    test_tcl
Re-running failed tests in verbose mode
Re-running test 'test_tcl' in verbose mode
testCall (test.test_tcl.TclTest) ... ok
testCallException (test.test_tcl.TclTest) ... ok
testCallException2 (test.test_tcl.TclTest) ... ok
testEval (test.test_tcl.TclTest) ... ok
testEvalException (test.test_tcl.TclTest) ... ok
testEvalException2 (test.test_tcl.TclTest) ... ok
testEvalFile (test.test_tcl.TclTest) ... ok
testEvalFileException (test.test_tcl.TclTest) ... ok
testGetVar (test.test_tcl.TclTest) ... ok
testGetVarArray (test.test_tcl.TclTest) ... ok
testGetVarArrayException (test.test_tcl.TclTest) ... ok
testGetVarException (test.test_tcl.TclTest) ... ok
testLoadWithUNC (test.test_tcl.TclTest) ... skipped 'Requires Windows'
testPackageRequireException (test.test_tcl.TclTest) ... ok
testSetVar (test.test_tcl.TclTest) ... ok
testSetVarArray (test.test_tcl.TclTest) ... ok
testUnsetVar (test.test_tcl.TclTest) ... ok
testUnsetVarArray (test.test_tcl.TclTest) ... ok
testUnsetVarException (test.test_tcl.TclTest) ... ok
test_passing_values (test.test_tcl.TclTest) ... ok
test_split (test.test_tcl.TclTest) ... ERROR
test_splitlist (test.test_tcl.TclTest) ... ERROR
testFlattenLen (test.test_tcl.TkinterTest) ... ok
test_huge_string (test.test_tcl.BigmemTclTest) ... skipped 'needs UINT_MAX < SIZE_MAX'

======================================================================
ERROR: test_split (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_tcl.py", line 237, in test_split
    (call('dict', 'create', 12, '\u20ac', b'\xe2\x82\xac', (3.4,)),
_tkinter.TclError: invalid command name "dict"

======================================================================
ERROR: test_splitlist (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_tcl.py", line 203, in test_splitlist
    (call('dict', 'create', 1, '\u20ac', b'\xe2\x82\xac', (3.4,)),
_tkinter.TclError: invalid command name "dict"

----------------------------------------------------------------------
Ran 24 tests in 7.573s

FAILED (errors=2, skipped=2)
test test_tcl failed

----------
components: Tests, Tkinter
keywords: buildbot
messages: 197192
nosy: ned.deily, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tcl fails when _tkinter linked with Tcl 8.4
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Sep  8 02:06:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 00:06:39 +0000
Subject: [New-bugs-announce] [issue18965] 2to3 can produce illegal bytes
	literals
Message-ID: <1378598799.8.0.0499553446902.issue18965@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In Python 2 string literals are allowed to contain non-ascii characters. In Python 3 bytes literals can contains only ascii characters, non-ascii characters should be escaped with \xXX. However 2to3 doesn't change b'...' literals and produces illegal code.

I propose new fixer which escapes non-ascii bytes in bytes literals. Here is a patch (without tests yet).

----------
components: 2to3 (2.x to 3.x conversion tool)
files: 2to3_nonascii_bytes.patch
keywords: patch
messages: 197205
nosy: serhiy.storchaka, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 can produce illegal bytes literals
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31657/2to3_nonascii_bytes.patch

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

From report at bugs.python.org  Sun Sep  8 03:20:27 2013
From: report at bugs.python.org (Piet van Oostrum)
Date: Sun, 08 Sep 2013 01:20:27 +0000
Subject: [New-bugs-announce] [issue18966] Threads within multiprocessing
	Process terminate early
Message-ID: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za>


New submission from Piet van Oostrum:

When a process started as a multiprocessing Process spawns a thread, it doesn't wait until the thread terminates. It terminates the thread early when the main thread of the process terminates, as if the thread would be daemonic (it isn't).

It may sound a bit weird to start a Thread within multiprocessing, but it isn't prohibited. Neither is this behavior documented.

In the attached program the thread doesn't complete. However when the mythread.join() statement is uncommented it does run to completion.

----------
components: Library (Lib)
files: processthread.py
messages: 197210
nosy: pietvo
priority: normal
severity: normal
status: open
title: Threads within multiprocessing Process terminate early
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file31658/processthread.py

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

From report at bugs.python.org  Sun Sep  8 04:04:41 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Sep 2013 02:04:41 +0000
Subject: [New-bugs-announce] [issue18967] Find a less conflict prone
	approach to Misc/NEWS
Message-ID: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

We keep muttering about coming up with a less conflict-prone approach to Misc/NEWS updates, without ever settling on a concrete solution.

For the last big discussion on this, see the subthread starting at https://mail.python.org/pipermail/python-committers/2013-May/002554.html

----------
messages: 197211
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Find a less conflict prone approach to Misc/NEWS
type: enhancement

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

From report at bugs.python.org  Sun Sep  8 05:05:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Sep 2013 03:05:34 +0000
Subject: [New-bugs-announce] [issue18968] Find a way to detect regressions
	in test execution
Message-ID: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 18952 (fixed in http://hg.python.org/cpython/rev/23770d446c73) was another case where a test suite change resulted in tests not be executed as expected, but this wasn't initially noticed since it didn't *fail* the tests, it just silently skipped them.

We've had similar issues in the past, due to test name conflicts (so the second test shadowed the first), to old regrtest style test discovery missing a class name from the test list, and to incorrect skip conditions on platform specific tests.

Converting "unexpected skips" to a failure isn't enough, since these errors occur at a narrower scope than entire test modules.

I'm not sure on what *would* work, though. Perhaps collecting platform specific coverage stats for the test suite itself and looking for regressions?

----------
messages: 197218
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Find a way to detect regressions in test execution
type: enhancement

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

From report at bugs.python.org  Sun Sep  8 11:52:48 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Sep 2013 09:52:48 +0000
Subject: [New-bugs-announce] [issue18969] test suite: enable faulthandler
	timeout in assert_python
Message-ID: <1378633968.54.0.772886567193.issue18969@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, the test suite, as well as processes spawned by the script_helper.assert_python family, are run with faulthandler enabled.
That's great to debug crashes, but it would be even better if those processes were started with faulthandler's timeout:

1) Most deadlock-prone tests are run in child processes, so in case of deadlock, you don't get any trace:

http://buildbot.python.org/all/builders/AMD64 FreeBSD 10.0 3.x/builds/353/steps/test/logs/stdio
"""
[269/380] test_threading
Timeout (1:00:00)!
Thread 0x0000000801c06400:
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/subprocess.py", line 1615 in _communicate_with_poll
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/subprocess.py", line 1535 in _communicate
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/subprocess.py", line 945 in communicate
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/script_helper.py", line 36 in _assert_python
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/script_helper.py", line 55 in assert_python_ok
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 617 in assertScriptHasOutput
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 692 in test_4_joining_across_fork_in_worker_thread
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 496 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 535 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1649 in _run_suite
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1683 in run_unittest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1275 in <lambda>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1276 in runtest_inner
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 965 in runtest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 761 in main
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1560 in main_in_temp_cwd
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 3 in <module>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 73 in _run_code
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 1
"""

Here, we just see that the main process is waiting for its child to complete, but we don't know anything about the child process stack.

2) As an added benefit, this would prevent dangling child processes: when the parent is killed, they're reparented to init, and can keep running arbitrarily long, consuming memory/CPU/process table entry (well, maybe the buildbot scripts kill the whole process group, I don't know).

----------
components: Tests
messages: 197239
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: test suite: enable faulthandler timeout in assert_python
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep  8 15:36:31 2013
From: report at bugs.python.org (Lukas Wunner)
Date: Sun, 08 Sep 2013 13:36:31 +0000
Subject: [New-bugs-announce] [issue18970] run_setup() behavior differs from
	cli invocation of	setup.py
Message-ID: <1378647391.64.0.940770484425.issue18970@psf.upfronthosting.co.za>


New submission from Lukas Wunner:

The principle of least surprise suggests that run_setup() should behave equivalently to a command line invocation of setup.py. However there are currently (at least) two issues preventing this:


(a) When calling exec(), both a globals and a locals dict is passed.

According to the documentation: "If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition." [1] Consequence: "The scope of names defined in a class block is limited to the class block; it does not extend to the code blocks of methods". [2]

One example where this is relevant is the "MarkupSafe" PyPI package [3]: Its setup.py defines a class BuildFailed which is used in other methods defined in setup.py. Calling run_setup() with this setup.py will therefore fail. Calling setup.py from the command line works.

Solution: Only pass a globals dict to exec().


(b) The globals dict does not contain '__name__':'__main__'.

Many setup.py scripts use the idiomatic 'conditional script' stanza "if __name__ == '__main__'". An example is the "PyYAML" PyPI package. [4] In these cases, run_setup() will raise a RuntimeError exception ("'distutils.core.setup()' was never called").

Solution: Add '__name__':'__main__' to the globals dict.


Attached are patches to fix these issues in Python 2.6 to 3.4.


[1] http://docs.python.org/3/library/functions.html#exec
[2] http://docs.python.org/reference/executionmodel.html#naming-and-binding
[3] https://pypi.python.org/pypi/MarkupSafe
[4] https://pypi.python.org/pypi/PyYAML

----------
assignee: eric.araujo
components: Distutils
files: run_setup-py32-py33-py34.diff
keywords: patch
messages: 197259
nosy: eric.araujo, l, tarek
priority: normal
severity: normal
status: open
title: run_setup() behavior differs from cli invocation of setup.py
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31661/run_setup-py32-py33-py34.diff

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

From report at bugs.python.org  Sun Sep  8 16:48:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 14:48:55 +0000
Subject: [New-bugs-announce] [issue18971] Use argparse in the
	profile/cProfile modules
Message-ID: <1378651735.34.0.106872134579.issue18971@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the profile and cProfile modules.

----------
components: Library (Lib)
files: profile_argparse.patch
keywords: patch
messages: 197262
nosy: bethard, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in the profile/cProfile modules
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31665/profile_argparse.patch

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

From report at bugs.python.org  Sun Sep  8 16:53:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 14:53:48 +0000
Subject: [New-bugs-announce] [issue18972] Use argparse in email example
	scripts
Message-ID: <1378652028.96.0.621116344908.issue18972@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the Doc/includes/email-dir.py and Doc/includes/email-unpack.py scripts.

----------
assignee: docs at python
components: Documentation, email
files: email_examples_argparse.patch
keywords: patch
messages: 197263
nosy: barry, docs at python, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in email example scripts
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31666/email_examples_argparse.patch

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

From report at bugs.python.org  Sun Sep  8 17:06:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 15:06:16 +0000
Subject: [New-bugs-announce] [issue18973] Use argparse in the calendar module
Message-ID: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the calendar modules.

----------
components: Library (Lib)
messages: 197264
nosy: bethard, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in the calendar module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep  8 17:28:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 15:28:01 +0000
Subject: [New-bugs-announce] [issue18974] Use argparse in the diff script
Message-ID: <1378654081.42.0.0708536053784.issue18974@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the Tools/scripts/diff.py script.

----------
components: Demos and Tools
files: diff_argparse.patch
keywords: patch
messages: 197269
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in the diff script
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31669/diff_argparse.patch

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

From report at bugs.python.org  Sun Sep  8 18:00:31 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 08 Sep 2013 16:00:31 +0000
Subject: [New-bugs-announce] [issue18975] timeit: Use thousands separators
	and print number of	loops per second
Message-ID: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>


New submission from Jakub Stasiak:

This patch includes:
* making code more PEP8-compatible and refactoring it a bit
* printing number of loops per second when using command line interface
* using thousands separators when printing numbers of loops (also in command line interface)
* changing examples in the module documentation

The output is changed from this:

    10000 loops, best of 3: 40.3 usec per loop

to that:

    10,000 loops, best of 3: 34.6 usec per loop, 28,870.783/s

I'm still not sure about details of "28,870.783/s" part:
* whether it should always include the fractional part (in this example it doesn't make any sense)
* maybe it should say "loops/s" rather than just "/s"

----------
components: Library (Lib)
files: timeit.patch
keywords: patch
messages: 197274
nosy: jstasiak
priority: normal
severity: normal
status: open
title: timeit: Use thousands separators and print number of loops per second
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31672/timeit.patch

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

From report at bugs.python.org  Sun Sep  8 18:20:20 2013
From: report at bugs.python.org (Benedikt Morbach)
Date: Sun, 08 Sep 2013 16:20:20 +0000
Subject: [New-bugs-announce] [issue18976] distutils/command/build_ext passes
	wrong linker flags
Message-ID: <1378657220.2.0.111053625387.issue18976@psf.upfronthosting.co.za>


New submission from Benedikt Morbach:

At http://hg.python.org/cpython/file/1043cc2cb0ff/Lib/distutils/command/build_ext.py#l247
build_ext.py compares sys.executable against sys.exec_prefix.

When cross compiling cpython, it notices that the interpreter running the build is located at exec_prefix and concludes that it is building a third-party module.
Thus, it passes '-L{HOST_LIBDIR}', instead of '-L.', which breaks the build.

The attached patch reverses the logic, checking if sys.executable resides in ${PWD} and assuming a third-party module otherwise.

This should also fix http://bugs.python.org/issue16326

----------
assignee: eric.araujo
components: Cross-Build, Distutils, Extension Modules, Library (Lib)
files: 0001-make-sure-to-pass-L.-when-building-standard-extensio.patch
keywords: patch
messages: 197277
nosy: Benedikt.Morbach, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils/command/build_ext passes wrong linker flags
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31674/0001-make-sure-to-pass-L.-when-building-standard-extensio.patch

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

From report at bugs.python.org  Sun Sep  8 18:28:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 16:28:44 +0000
Subject: [New-bugs-announce] [issue18977] The -t option has no effect in for
	uu command-line
Message-ID: <1378657724.77.0.882529649295.issue18977@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The uu module can be run as command-line tool. In Python 2, "uu -t infile outfile" opens input file in text mode, i.e. convert '\r\n' to '\n' on Windows and '\r' to '\n' on Mac Classic, and "uu -d -t infile outfile" opens output file in text mode, i.e. convert '\n' to '\r\n' on Windows and '\n' to '\r' on Mac Classic. In Python 3 this option has no effect.

The proposed patch restores former behavior and extends it. Encoding with -t option now uses universal newlines for reading, and decoding with -t option now converts '\n' to os.linesep for writing. In additional text mode now works with standard input/output.

This change perhaps is too large for the fix of such  insignificant bug and that is why I propose it as a new feature.

----------
assignee: serhiy.storchaka
components: Demos and Tools, Library (Lib)
files: uu_text_mode.patch
keywords: patch
messages: 197279
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: The -t option has no effect in for uu command-line
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31675/uu_text_mode.patch

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

From report at bugs.python.org  Sun Sep  8 18:41:28 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Sep 2013 16:41:28 +0000
Subject: [New-bugs-announce] [issue18978] Allow urllib.request.Request
	subclasses to override	method
Message-ID: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

In Python 2.x and 3.2, I used to use a Request subclass I created for overriding the method used:

class MethodRequest(request.Request):
	def __init__(self, *args, **kwargs):
		"""
		Construct a MethodRequest. Usage is the same as for
		`urllib.request.Request` except it also takes an optional `method`
		keyword argument. If supplied, `method` will be used instead of
		the default.
		"""
		if 'method' in kwargs:
			self.method = kwargs.pop('method')
		return request.Request.__init__(self, *args, **kwargs)

	def get_method(self):
		return getattr(self, 'method', request.Request.get_method(self))

In Python 3.3, which now supports a method parameter, it broke this paradigm (because the method is stored in the instance and is always set to None in __init__ if not specified).

I believe a paradigm where the method is stored as a class attribute and possibly overridden in an instance would be much better, allowing for subclasses to simply and directly override the method. For example:

class HeadRequest(MethodRequest):
	method = 'HEAD'

That straightforward example works very well if method is allowed to be a class attribute, but won't work at all if 'method' is always set as an instance attribute in __init__.

And while it's possible for HeadRequest to override __init__, that requires HeadRequest to override that entire signature, which is less elegant than simply setting a class attribute.

For Python 3.4, I'd like to adapt the Request class to allow the Method to be defined at the class level (while still honoring customization at the instance level).

----------
components: Library (Lib)
messages: 197281
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: Allow urllib.request.Request subclasses to override method
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep  8 19:23:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 17:23:44 +0000
Subject: [New-bugs-announce] [issue18979] Use argparse in the uu module
Message-ID: <1378661024.73.0.529726485343.issue18979@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the uu module.

----------
components: Demos and Tools, Library (Lib)
files: uu_argparse.patch
keywords: patch
messages: 197289
nosy: bethard, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in the uu module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31679/uu_argparse.patch

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

From report at bugs.python.org  Sun Sep  8 21:16:26 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Sun, 08 Sep 2013 19:16:26 +0000
Subject: [New-bugs-announce] [issue18980] Docs: enum - ReST format
Message-ID: <1378667786.26.0.0622956462221.issue18980@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

in http://docs.python.org/3.4/library/enum.html :
"..note: Nomenclature"
and 
".:meth:__format__"

visible in the html.

----------
assignee: docs at python
components: Documentation
files: enum_minor.patch
keywords: patch
messages: 197312
nosy: docs at python, elazar
priority: normal
severity: normal
status: open
title: Docs: enum - ReST format
versions: Python 3.4
Added file: http://bugs.python.org/file31682/enum_minor.patch

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

From report at bugs.python.org  Sun Sep  8 22:55:41 2013
From: report at bugs.python.org (Anoop Thomas Mathew)
Date: Sun, 08 Sep 2013 20:55:41 +0000
Subject: [New-bugs-announce] [issue18981] Typo in the ctypes tests
Message-ID: <1378673741.26.0.448771285371.issue18981@psf.upfronthosting.co.za>


New submission from Anoop Thomas Mathew:

Comment in the test_number.py in ctypes test hold a typo bug. Instead of superseeded, it should be superseded. Patch attached.

----------
assignee: docs at python
components: Documentation, Tests
files: ctypes_test_typo.patch
keywords: patch
messages: 197318
nosy: Anoop.Thomas.Mathew, docs at python
priority: normal
severity: normal
status: open
title: Typo in the ctypes tests
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31685/ctypes_test_typo.patch

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

From report at bugs.python.org  Sun Sep  8 23:08:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 21:08:40 +0000
Subject: [New-bugs-announce] [issue18982] Add tests for CLI of the calendar
	module
Message-ID: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds tests for command-line interface of the calendar module. It also makes calendar tests discoverable and makes some existing tests more strong.

----------
components: Tests
files: test_calendar_cli.patch
keywords: patch
messages: 197320
nosy: r.david.murray, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add tests for CLI of the calendar module
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31687/test_calendar_cli.patch

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

From report at bugs.python.org  Sun Sep  8 23:15:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 21:15:56 +0000
Subject: [New-bugs-announce] [issue18983] Specify time unit for timeit CLI
Message-ID: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Just an idea. Currently the timeit module in command line automatically choice most appropriate time unit for human readable output. But this makes the output less machine readable. I propose to add new option which specifies fixed time unit (usec, msec, sec).

----------
components: Library (Lib)
keywords: easy
messages: 197322
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Specify time unit for timeit CLI
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep  8 23:46:26 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 21:46:26 +0000
Subject: [New-bugs-announce] [issue18984] Remove .stopped Event from Thread
	internals
Message-ID: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>


New submission from Tim Peters:

As discussed in issue 18808, now that we're checking for a tstate lock, the Thread._stopped Event has become an "attractive nuisance".  The attached patch removes it.

This simplifies .join() and .is_alive(), and restores pre-18808 .join(timeout) endcase behavior (i.e., if join returns before the timeout expires, .is_alive() will always be False).

Since this doesn't add any new locks, I hope it won't create more problems with fork tests - but running on Windows I wouldn't know ;-)

----------
assignee: tim.peters
components: Library (Lib)
files: remove_stopped
keywords: needs review, patch
messages: 197325
nosy: pitrou, tim.peters
priority: normal
severity: normal
stage: patch review
status: open
title: Remove .stopped Event from Thread internals
versions: Python 3.4
Added file: http://bugs.python.org/file31690/remove_stopped

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

From report at bugs.python.org  Mon Sep  9 12:35:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Sep 2013 10:35:19 +0000
Subject: [New-bugs-announce] [issue18985] Improve the documentation in fcntl
	module
Message-ID: <1378722919.93.0.901392318122.issue18985@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

The attached patch fixed typos and improved the documentation to improve the clarity in Modules/fcntlmodule.c.

Please see the attached patch and feel free to disagree with the improvement.

----------
assignee: docs at python
components: Documentation
files: fix_documentation_on_fcntl_module.patch
keywords: patch
messages: 197358
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Improve the documentation in fcntl module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31695/fix_documentation_on_fcntl_module.patch

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

From report at bugs.python.org  Mon Sep  9 13:22:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 11:22:01 +0000
Subject: [New-bugs-announce] [issue18986] Add a case-insensitive
	case-preserving dict
Message-ID: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is a very common need when implementing network protocols. You want to match keys case-insensitively but also preserve the original casing (e.g. for presentation).

When searching on the Web, you see many people reimplementing their own variant (often incomplete, or buggy). For example, Twisted has its own, the email package has something resembling it, WebOb also.

Having an implementation in the stdlib would spare many people the effort, ensure the implementation is complete and well-tested, and perhaps also add some optimizations to mitigate the overhead compared to a plain dict.

Note this is an instance of a more general pattern, where they key used for matching is derived from the lookup key using a constant derivation function. So maybe we want to implement the more general pattern and let users specify str.lower as the key derivation function.

----------
components: Library (Lib)
messages: 197359
nosy: barry, pitrou, r.david.murray, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Add a case-insensitive case-preserving dict
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep  9 15:03:01 2013
From: report at bugs.python.org (Sam Ferencik)
Date: Mon, 09 Sep 2013 13:03:01 +0000
Subject: [New-bugs-announce] [issue18987] distutils.utils.get_platform() for
	32-bit Python on a	64-bit machine
Message-ID: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>


New submission from Sam Ferencik:

distutils.util.get_platform() semantically differs on (a) Windows and OS X, and on (b) Linux.

Windows/OS X: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on a 64-bit system, get_platform() = 'win32'/'macosx-10.6-i386' (32-bit).

Linux: the return value is derived from the architecture of the *OS*, hence for 32-bit Python running on 64-bit Linux get_platform() = 'linux-x86_64' (64-bit).

Based on a discussion on distutils-sig, the Linux behaviour is probably wrong and should be changed. https://mail.python.org/pipermail/distutils-sig/2013-August/subject.html

My context (where this hit me): I was installing the 32-bit version of the Perforce API (compiled module) on 64-bit Windows and on 64-bit Linux. My command-line was

  python3.3-32 setup.py install --root FOO --install-platlib=lib.$PLAT

(note the '-32' and the '$PLAT')

On Windows, this installed the 32-bit version of the API into "FOO\lib.win32". On Linux, this installed the 64-bit version of the API into "FOO/lib.linux-x86_64".

----------
assignee: eric.araujo
components: Distutils
messages: 197363
nosy: eric.araujo, sferencik, tarek
priority: normal
severity: normal
status: open
title: distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep  9 15:14:36 2013
From: report at bugs.python.org (Howitzer21)
Date: Mon, 09 Sep 2013 13:14:36 +0000
Subject: [New-bugs-announce] [issue18988] Tab key doesn't work sometimes.
Message-ID: <1378732476.83.0.954740499881.issue18988@psf.upfronthosting.co.za>


New submission from Howitzer21:

In the IDLE program for Python 3.3.2, I've run across a situation where the tab key is not working.  I have attached a file that shows everything in IDLE's console.  At the very end of the file, you can see where I have typed in the word "queue" in IDLE without pressing enter.  At this point, if I press tab, nothing happens.  If I press space and then tab, suddenly it'll work just fine.  But then if I delete all the spaces and tabs and just go back to having nothing more than "queue" on the line, with no trailing whitespace, suddenly tab will go back to not working.

----------
components: IDLE
files: console.txt
messages: 197364
nosy: Howitzer21
priority: normal
severity: normal
status: open
title: Tab key doesn't work sometimes.
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31696/console.txt

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

From report at bugs.python.org  Mon Sep  9 20:58:50 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Sep 2013 18:58:50 +0000
Subject: [New-bugs-announce] [issue18989] reuse of enum names in class
	creation inconsistent
Message-ID: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Consider:

==================================================================================
-->from enum import Enum

-->class Color(Enum):
...   red = 1
...   green = 2
...   blue = 3
...   red = 4
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in Color
  File "/home/ethan/source/python/issue18924/Lib/enum.py", line 87, in __setitem__
    raise TypeError('Attempted to reuse key: %r' % key)
TypeError: Attempted to reuse key: 'red'
==================================================================================

versus

==================================================================================
-->class Color(Enum):
...   red = 1
...   green = 2
...   blue = 3
...   def red(self):
...     return 'fooled ya!'
... 

# no error
==================================================================================

or

==================================================================================
-->class Color(Enum):
...   red = 1
...   green = 2
...   blue = 3
...   @property
...   def red(self):
...     return 'fooled ya!'
... 

# no error
==================================================================================

In both of the latter two cases the redefinition of 'red' is allowed because the new definition is not an enum member.

This is inconsistent as well as confusing.

I know normal class creation semantics don't place any such limitations on names and allow redefining at will, but Enum is not a regular class.

----------
assignee: ethan.furman
files: no_reuse_of_enum_names.stoneleaf.01.patch
keywords: patch
messages: 197375
nosy: barry, eli.bendersky, eric.snow, ethan.furman, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: reuse of enum names in class creation inconsistent
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31699/no_reuse_of_enum_names.stoneleaf.01.patch

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

From report at bugs.python.org  Mon Sep  9 21:32:33 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 09 Sep 2013 19:32:33 +0000
Subject: [New-bugs-announce] [issue18990] Remove unnecessary API
	inconsistency from	ElementTree.XMLPullParser.close()
Message-ID: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The .close() method of the new XMLPullParser (see issue17741) in Py3.4 shows an unnecessarily complicated behaviour that is inconsistent with the .close() method of the existing XMLParser.

The attached patch removes some code to fix this.

----------
components: Library (Lib), XML
files: xmlpullparser_close.patch
keywords: patch
messages: 197383
nosy: scoder
priority: normal
severity: normal
status: open
title: Remove unnecessary API inconsistency from ElementTree.XMLPullParser.close()
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31702/xmlpullparser_close.patch

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

From report at bugs.python.org  Mon Sep  9 23:50:06 2013
From: report at bugs.python.org (Davi Post)
Date: Mon, 09 Sep 2013 21:50:06 +0000
Subject: [New-bugs-announce] [issue18991] Overriding
	OrderedDict.__getitem__() doesn't work
Message-ID: <1378763406.5.0.0321724375688.issue18991@psf.upfronthosting.co.za>


New submission from Davi Post:

class MyOrderedDict(OrderedDict):
   
    def __getitem__(self, key):
        OrderedDict.__getitem__(self, key)

After setting a key, getting it returns None. See attached.

Am I missing something?

Discovered this when trying to use the dict_type parameter of ConfigParser.RawConfigParser -- caused an AttributeError.

Possibly relevant to http://bugs.python.org/issue9534

----------
components: Library (Lib)
files: OrderedDictTest.py
messages: 197404
nosy: davipo
priority: normal
severity: normal
status: open
title: Overriding OrderedDict.__getitem__() doesn't work
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31703/OrderedDictTest.py

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

From report at bugs.python.org  Tue Sep 10 03:02:26 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 10 Sep 2013 01:02:26 +0000
Subject: [New-bugs-announce] [issue18992] test_sax fails on Windows under
	3.4.0a2
Message-ID: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>


New submission from Tim Peters:

Don't know whether this is new.  Found it running the test suite under a 3.4.0a2 freshly installed from the python.org .msi installer:

== CPython 3.4.0a2 (v3.4.0a2:9265a2168e2c+, Sep 8 2013, 19:41:05) [MSC v.1600 32 bit (Intel)]
==   Windows-Vista-6.0.6002-SP2 little-endian

`regrtest -v test_sax` output attached.  Interestingly, test_sax passes under the tip HG Pythons I build myself.

Didn't we recently fix something like this???  Appears to be a line-end problem.  Ya!  Whoever builds the Windows installer needs to delete directory Lib\test\xmltestdata on their box, and then do "hg revert" on that directory to get fresh copies of the test data.  .hgeol was changed to treat those files as binary, but Mercurial doesn't replace the files automatically just because .hgeol changed.

----------
components: Tests
files: test_sax.out
messages: 197415
nosy: tim.peters
priority: normal
severity: normal
status: open
title: test_sax fails on Windows under 3.4.0a2
versions: Python 3.4
Added file: http://bugs.python.org/file31705/test_sax.out

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

From report at bugs.python.org  Tue Sep 10 08:55:03 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Sep 2013 06:55:03 +0000
Subject: [New-bugs-announce] [issue18993] There is an overshadowed and
	invalid test in testmock.py
Message-ID: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/unittest/test/testmock/testmock.py, there are two test_attribute_deletion. One of them is overshadowed (not executed) by the other.

    def test_attribute_deletion(self):
        # this behaviour isn't *useful*, but at least it's now tested...
        for Klass in Mock, MagicMock, NonCallableMagicMock, NonCallableMock:
            m = Klass()
            original = m.foo
            m.foo = 3
            del m.foo
            self.assertEqual(m.foo, original)

            new = m.foo = Mock()
            del m.foo
            self.assertEqual(m.foo, new)

    def test_attribute_deletion(self):
        for mock in Mock(), MagicMock():
            self.assertTrue(hasattr(mock, 'm'))

            del mock.m
            self.assertFalse(hasattr(mock, 'm'))

            del mock.f
            self.assertFalse(hasattr(mock, 'f'))
            self.assertRaises(AttributeError, getattr, mock, 'f')

They are testing the same thing but with different expectations. The first one is invalid and should be removed. The patch altered a bit of the second test to incorporate more mock classes.

----------
components: Tests
files: remove_wrongly_test_in_testmock.patch
keywords: patch
messages: 197424
nosy: vajrasky
priority: normal
severity: normal
status: open
title: There is an overshadowed and invalid test in testmock.py
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31708/remove_wrongly_test_in_testmock.patch

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

From report at bugs.python.org  Tue Sep 10 09:08:30 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Sep 2013 07:08:30 +0000
Subject: [New-bugs-announce] [issue18994] Inside fcntl module,
	we does not check the return code of all_ins function
Message-ID: <1378796910.87.0.444759444485.issue18994@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Modules/fcntlmodule.c, there is a code to insert symbolic constants to the module.

    all_ins(m);

But we don't check the return code of the function whether it is successful or not, unlike in posix module in which we check it.

    if (all_ins(m))
        return NULL;

Attached the patch to add checking of the return code of all_ins function in fcntl module file.

----------
components: Extension Modules
files: check_return_code_all_ins_in_fcntl.patch
keywords: patch
messages: 197425
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Inside fcntl module, we does not check the return code of all_ins function
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31709/check_return_code_all_ins_in_fcntl.patch

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

From report at bugs.python.org  Tue Sep 10 11:14:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Sep 2013 09:14:23 +0000
Subject: [New-bugs-announce] [issue18995] Enum does not work with reversed
Message-ID: <1378804463.14.0.741296151335.issue18995@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

cutecat at amiau:~/cpython$ cat /tmp/innerplanets.py 
from enum import Enum

class innerplanets(Enum):
    mercury = 1
    venus = 2
    earth = 3
    mars = 4

for planet in innerplanets:
    print(planet)
for planet in reversed(innerplanets):
    print(planet)
cutecat at amiau:~/cpython$ ./python /tmp/innerplanets.py 
innerplanets.mercury
innerplanets.venus
innerplanets.earth
innerplanets.mars
Traceback (most recent call last):
  File "/tmp/innerplanets.py", line 11, in <module>
    for planet in reversed(innerplanets):
  File "/home/cutecat/cpython/Lib/enum.py", line 255, in __getitem__
    return cls._member_map_[name]
KeyError: 3

Attached the patch to add support for reversed in enum.

----------
components: Library (Lib)
files: add_reversed_support_for_enum.patch
keywords: patch
messages: 197428
nosy: ethan.furman, vajrasky
priority: normal
severity: normal
status: open
title: Enum does not work with reversed
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31711/add_reversed_support_for_enum.patch

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

From report at bugs.python.org  Tue Sep 10 13:51:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Sep 2013 11:51:47 +0000
Subject: [New-bugs-announce] [issue18996] unittest: more helpful truncating
	long strings
Message-ID: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Error message in assertEqual() is not vary useful when compared long strings with long common prefix. It looks as:

'For the first time in his life h [truncated]...' != 'For the first time in his life h [truncated]...'

With the proposed patch it will look as:

'For [25 chars]e he seemed to be vividly aware of his own existence.' != 'For [25 chars]e he felt humble. He perceived how misgui[105 chars]ers.'

New algorithm splits strings on common prefix and differing suffixes, shortens every part if it is too long, and concatenates them back. So user always see the start and the end of string, and the place of first difference with some characters before and after.

----------
components: Tests
files: assertEqual_shorten.patch
keywords: patch
messages: 197433
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: unittest: more helpful truncating long strings
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31712/assertEqual_shorten.patch

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

From report at bugs.python.org  Tue Sep 10 15:49:20 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Tue, 10 Sep 2013 13:49:20 +0000
Subject: [New-bugs-announce] [issue18997] Crash when using pickle and
	ElementTree
Message-ID: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>


New submission from Germ?n M. Bravo:

On the tip of 3.3, I've found `Element.__getstate__` doesn't work and neither as `pickle.dumps(Element)` under certain circumstances.

This crashes:
  e1 = ElementTree().parse('houses.xml')
  e1.__getstate__()

This doesn't crash:
  e2 = ElementTree().parse('houses.xml')
  e2.text = 'some'
  e2.__getstate__()

But still, both of these crash:
  pickle.dumps(e1)
  pickle.dumps(e2)

----------
components: Extension Modules
files: houses.xml
messages: 197440
nosy: Kronuz, eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: Crash when using pickle and ElementTree
versions: Python 3.3
Added file: http://bugs.python.org/file31719/houses.xml

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

From report at bugs.python.org  Tue Sep 10 16:37:01 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Tue, 10 Sep 2013 14:37:01 +0000
Subject: [New-bugs-announce] [issue18998] iter() not working in ElementTree
Message-ID: <1378823821.86.0.0607841458966.issue18998@psf.upfronthosting.co.za>


New submission from Germ?n M. Bravo:

The added iter/itertext methods in Element are not working under certain circumstances (crashes):

This crashes:
  e = ElementTree().parse('/Users/kronuz/Desktop/tests/houses.xml')
  e.iter()

But the problem is not there if I use bootstrapped iterators instead (from the previous commit to the one introducing Element iterator)

----------
components: Extension Modules
files: houses.xml
messages: 197441
nosy: Kronuz, eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: iter() not working in ElementTree
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file31720/houses.xml

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

From report at bugs.python.org  Tue Sep 10 16:53:41 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Tue, 10 Sep 2013 14:53:41 +0000
Subject: [New-bugs-announce] [issue18999] Allow multiple calls to
	multiprocessing.set_start_method
Message-ID: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>


New submission from Lars Buitinck:

The new multiprocessing based on forkserver (issue8713) looks great, but it has two problems. The first:

"set_start_method() should not be used more than once in the program."

The documentation does not explain what the effect of calling it twice would be. Judging from the documentation, it should be possible to do

start_method = get_start_method()
if start_method is None:
    set_start_method('forkserver')

but this code shows the second problem: it always succeeds with the (undocumented!) side-effect of setting the start method in get_start_method, to the system default, if it hasn't been set already.

I was just going to forge a patch for joblib (http://pythonhosted.org/joblib/) to set the start method to forkserver at import time. But in the current state of affairs, it would be impossible for the user to safely override the start method before importing joblib, because joblib can't figure out if it's been set already without setting it.

The enclosed patch solves the problem by making the new functions more robust:

* get_start_method no longer sets anything, but returns None if the start method has not been set already;
* set_start_method raises a RuntimeError (for want of a better exception type) when resetting the start method is attempted.

Unfortunately, I had to hack up the tests a bit, because they were violating the set_start_method contract. There is a test for the new set_start_method behavior, though, and all {fork,forkserver,spawn} tests pass on Linux.

----------
components: Library (Lib)
files: mp_getset_start_method.patch
keywords: patch
messages: 197444
nosy: larsmans
priority: normal
severity: normal
status: open
title: Allow multiple calls to multiprocessing.set_start_method
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31721/mp_getset_start_method.patch

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

From report at bugs.python.org  Tue Sep 10 17:29:40 2013
From: report at bugs.python.org (Howitzer21)
Date: Tue, 10 Sep 2013 15:29:40 +0000
Subject: [New-bugs-announce] [issue19000] Alt + <Num> Does Not Work in IDLE.
Message-ID: <1378826980.96.0.574950615331.issue19000@psf.upfronthosting.co.za>


New submission from Howitzer21:

While Num Lock is in use, if I hold Alt, type 234, then release Alt, ? is supposed to be printed (and it is printed in most other programs).  If I try to do this in IDLE, however, IDLE will toggle its maximization along the y-axis and move the cursor to the beginning of the line, without printing anything.

----------
components: IDLE
messages: 197448
nosy: Howitzer21
priority: normal
severity: normal
status: open
title: Alt + <Num> Does Not Work in IDLE.
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Sep 10 21:36:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Sep 2013 19:36:13 +0000
Subject: [New-bugs-announce] [issue19001] test_gdb fails on Fedora buildbot
Message-ID: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is on Stefan's "Fedora without threads" buildbot, and it's the sets pretty-printing tests which fail:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5119

----------
components: Demos and Tools, Interpreter Core
messages: 197463
nosy: ncoghlan, pitrou, rhettinger, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb fails on Fedora buildbot
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep 11 08:20:51 2013
From: report at bugs.python.org (David Halter)
Date: Wed, 11 Sep 2013 06:20:51 +0000
Subject: [New-bugs-announce] [issue19002] ``dir`` function does not work
	correctly with classes.
Message-ID: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>


New submission from David Halter:

I recently stumbled over the ``dir`` function not working correctly with classes. This means that ``dir(object)`` won't list ``object.__bases__`` or ``object.__subclasses`` (and many other useful methods).

I think that we should change that. The C function ``type_dir`` (in ``Objects/typeobject.c``) has a documentation entry which states:

"We deliberately don't suck up its __class__, as methods belonging to the metaclass would probably be more confusing than helpful."

I think that that's not true. The current behaviour of ``dir`` is way more confusing, since ``dir`` is typically the tool how we find out about magic methods.

I wrote about it in more details here: http://jedidjah.ch/code/2013/9/8/wrong_dir_function/

----------
components: Interpreter Core
messages: 197471
nosy: davidhalter
priority: normal
severity: normal
status: open
title: ``dir`` function does not work correctly with classes.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 11 09:47:20 2013
From: report at bugs.python.org (Alexander Kruppa)
Date: Wed, 11 Sep 2013 07:47:20 +0000
Subject: [New-bugs-announce] [issue19003] email.generator.BytesGenerator
	corrupts data by changing	line endings
Message-ID: <1378885640.45.0.020973506597.issue19003@psf.upfronthosting.co.za>


New submission from Alexander Kruppa:

This is a follow-up to #16564. In that issue, BytesGenerator was changed to accept a bytes payload, however processing binary data that way leads to data corruption.

Repost of the update I posted in #16564:

***********************************************************
~/build/Python-3.3.2$ ./python --version
Python 3.3.2

When modifying the test case in Lib/test/test_email/test_email.py like this:

--- Lib/test/test_email/test_email.py	2013-05-15 18:32:55.000000000 +0200
+++ Lib/test/test_email/test_email_mine.py	2013-09-10 14:22:08.160089440 +0200
@@ -1461,17 +1461,17 @@
         # Issue 16564: This does not produce an RFC valid message, since to be
         # valid it should have a CTE of binary.  But the below works in
         # Python2, and is documented as working this way.
-        bytesdata = b'\xfa\xfb\xfc\xfd\xfe\xff'
+        bytesdata = b'\x0b\xfa\xfb\xfc\xfd\xfe\xff'
         msg = MIMEApplication(bytesdata, _encoder=encoders.encode_noop)
         # Treated as a string, this will be invalid code points.
-        self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
+        # self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
         self.assertEqual(msg.get_payload(decode=True), bytesdata)
         s = BytesIO()
         g = BytesGenerator(s)
         g.flatten(msg)
         wireform = s.getvalue()
         msg2 = email.message_from_bytes(wireform)
-        self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
+        # self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
         self.assertEqual(msg2.get_payload(decode=True), bytesdata)

then running:

./python ./Tools/scripts/run_tests.py test_email

results in:

======================================================================
FAIL: test_binary_body_with_encode_noop (test_email_mine.TestMIMEApplication)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/localdisk/kruppaal/build/Python-3.3.2/Lib/test/test_email/test_email_mine.py", line 1475, in test_binary_body_with_encode_noop
    self.assertEqual(msg2.get_payload(decode=True), bytesdata)
AssertionError: b'\x0b\n\xfa\xfb\xfc\xfd\xfe\xff' != b'\x0b\xfa\xfb\xfc\xfd\xfe\xff'

The '\x0b' byte is incorrectly translated to '\x0b\n', i.e., a New Line character is inserted.

Encoding the bytes array:
bytes(range(256))

results output data (MIME Header stripped):

0000000: 0001 0203 0405 0607 0809 0a0b 0a0c 0a0a  ................
0000010: 0e0f 1011 1213 1415 1617 1819 1a1b 1c0a  ................
0000020: 1d0a 1e0a 1f20 2122 2324 2526 2728 292a  ..... !"#$%&'()*
0000030: 2b2c 2d2e 2f30 3132 3334 3536 3738 393a  +,-./0123456789:
0000040: 3b3c 3d3e 3f40 4142 4344 4546 4748 494a  ;<=>?@ABCDEFGHIJ
0000050: 4b4c 4d4e 4f50 5152 5354 5556 5758 595a  KLMNOPQRSTUVWXYZ
0000060: 5b5c 5d5e 5f60 6162 6364 6566 6768 696a  [\]^_`abcdefghij
0000070: 6b6c 6d6e 6f70 7172 7374 7576 7778 797a  klmnopqrstuvwxyz
0000080: 7b7c 7d7e 7f80 8182 8384 8586 8788 898a  {|}~............
0000090: 8b8c 8d8e 8f90 9192 9394 9596 9798 999a  ................
00000a0: 9b9c 9d9e 9fa0 a1a2 a3a4 a5a6 a7a8 a9aa  ................
00000b0: abac adae afb0 b1b2 b3b4 b5b6 b7b8 b9ba  ................
00000c0: bbbc bdbe bfc0 c1c2 c3c4 c5c6 c7c8 c9ca  ................
00000d0: cbcc cdce cfd0 d1d2 d3d4 d5d6 d7d8 d9da  ................
00000e0: dbdc ddde dfe0 e1e2 e3e4 e5e6 e7e8 e9ea  ................
00000f0: ebec edee eff0 f1f2 f3f4 f5f6 f7f8 f9fa  ................
0000100: fbfc fdfe ff                             .....

That is, a '\n' is inserted after '\x0b', '\x1c', '\x1d', and '\x1e', 
and '\x0d' is replaced by '\n\n'.

***********************************************************

I suspect this is due to the use of self._write_lines(msg._payload) in BytesGenerator._handle_text(); since _write_lines() mangles line endings.

----------
components: email
messages: 197476
nosy: Alexander.Kruppa, barry, r.david.murray
priority: normal
severity: normal
status: open
title: email.generator.BytesGenerator corrupts data by changing line endings
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep 11 12:20:13 2013
From: report at bugs.python.org (Timothy Pederick)
Date: Wed, 11 Sep 2013 10:20:13 +0000
Subject: [New-bugs-announce] [issue19004] datetime: Read in isoformat()
	output
Message-ID: <1378894813.85.0.443530732743.issue19004@psf.upfronthosting.co.za>


New submission from Timothy Pederick:

At present, the datetime module does not provide the capability to parse its own output from the isoformat() methods.

strptime() can't handle timezones with colons in them (and anyway it seems to me you'd need to try several possible format strings depending on ' ' vs 'T' separators, presence/absence of microseconds, pres/abs timezone...). Adding this capability would be one option (%f already establishes a precedent for adding codes outside of what C supports).

Another, perhaps superior option would be a specific method for parsing the output of isoformat().

----------
components: Library (Lib)
messages: 197482
nosy: perey
priority: normal
severity: normal
status: open
title: datetime: Read in isoformat() output
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep 11 12:22:22 2013
From: report at bugs.python.org (Evgeny Kapun)
Date: Wed, 11 Sep 2013 10:22:22 +0000
Subject: [New-bugs-announce] [issue19005] PyIter_Next crashes if passed a
	non-iterator
Message-ID: <1378894942.16.0.763585748614.issue19005@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

According to the documentation, PyIter_Next should raise TypeError if passed an object which is not an iterator as an argument. Instead, it calls a function through a null pointer, which leads to a crash.

----------
components: Interpreter Core
messages: 197483
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: PyIter_Next crashes if passed a non-iterator
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep 11 17:45:35 2013
From: report at bugs.python.org (Roy Smith)
Date: Wed, 11 Sep 2013 15:45:35 +0000
Subject: [New-bugs-announce] [issue19006] UnitTest docs should have a single
	list of assertions
Message-ID: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>


New submission from Roy Smith:

http://docs.python.org/2/library/unittest.html#assert-methods

The docs say, "The TestCase class provides a number of methods to check for and report failures, such as", and then when you scroll a couple of screens down, there's another list, "There are also other methods used to perform more specific checks, such as".  These should be merged into a single list.  There's nothing fundamentally different about the two lists and breaking them into two parts just makes it harder to find what you want.

----------
assignee: docs at python
components: Documentation
messages: 197492
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: UnitTest docs should have a single list of assertions
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 12 21:44:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Sep 2013 19:44:34 +0000
Subject: [New-bugs-announce] [issue19007] precise time.time() under Windows 8
Message-ID: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

For whoever is interested: Windows 8 apparently has a new API named GetSystemTimePreciseAsFileTime which returns the system API with a much better resolution than GetSystemTimeAsFileTime does ("The GetSystemTimePreciseAsFileTime function retrieves the current system date and time with the highest possible level of precision (<1us)").
http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895%28v=vs.85%29.aspx

(spawned from this topic on the tulip mailing-list: https://groups.google.com/forum/#!topic/python-tulip/vX9vOZB1FOI )

----------
components: Library (Lib), Windows
messages: 197538
nosy: belopolsky, haypo, lemburg, pitrou, tim.peters
priority: low
severity: normal
status: open
title: precise time.time() under Windows 8
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 13 14:04:45 2013
From: report at bugs.python.org (Laurence McGlashan)
Date: Fri, 13 Sep 2013 12:04:45 +0000
Subject: [New-bugs-announce] [issue19008] tkinter: UnboundLocalError: local
	variable 'sys'	referenced before assignment
Message-ID: <1379073885.83.0.804640187446.issue19008@psf.upfronthosting.co.za>


New submission from Laurence McGlashan:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/sk1/__init__.py", line 21, in <module>
    app.main.main()
  File "/usr/lib64/python2.7/site-packages/sk1/app/main.py", line 150, in main
    application = SketchApplication(filename, options.display, options.geometry, run_script = options.run_script)
  File "/usr/lib64/python2.7/site-packages/sk1/app/skapp.py", line 155, in __init__
    TkApplication.__init__(self, screen_name = screen_name, geometry = geometry)
  File "/usr/lib64/python2.7/site-packages/sk1/app/skapp.py", line 60, in __init__
    self.init_tk(screen_name, geometry)
  File "/usr/lib64/python2.7/site-packages/sk1/app/skapp.py", line 185, in init_tk
    TkApplication.init_tk(self, screen_name = screen_name, geometry = geometry)
  File "/usr/lib64/python2.7/site-packages/sk1/app/skapp.py", line 63, in init_tk
    self.root = Tk(screenName = screen_name, baseName = self.tk_basename, className = self.tk_class_name)
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1748, in __init__
    if not sys.flags.ignore_environment:
UnboundLocalError: local variable 'sys' referenced before assignment


Patch attached.

----------
components: Tkinter
files: Tkinter.patch
keywords: patch
messages: 197563
nosy: Laurence.McGlashan
priority: normal
severity: normal
status: open
title: tkinter: UnboundLocalError: local variable 'sys' referenced before assignment
versions: Python 2.7
Added file: http://bugs.python.org/file31738/Tkinter.patch

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

From report at bugs.python.org  Fri Sep 13 15:39:30 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Sep 2013 13:39:30 +0000
Subject: [New-bugs-announce] [issue19009] Enhance HTTPResponse.readline()
	performance
Message-ID: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

Some applications require reading http response data in "long" polls as it becomes available.  This is used, e.g. to receive "notifications" over a HTTP stream.
Using response.read(large_buffer) is not possible because this will attempt to fullfill the entire request (using multiple underlying recv() calls), negating the attempt to get data as it becomes available.
Using "readline", and using \n boundaries in the data, this problem can be overcome.
Currently, readline is slow because it will attempt to read one byte at a time.  Even if it is doing so from a buffered stream, it is still doing it one character at a time.
This patch adds a "peek" method to HttpResponse, which works both for chunked and non-chunked transfer encoding, thus improving the performance of readline.  IOBase.readline will use peek() to determine the readahead it can use, instead of one byte which it must use by default.

----------
components: Library (Lib)
files: peek.patch
keywords: patch
messages: 197574
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Enhance HTTPResponse.readline() performance
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file31741/peek.patch

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

From report at bugs.python.org  Fri Sep 13 18:03:32 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Sep 2013 16:03:32 +0000
Subject: [New-bugs-announce] [issue19010] Make XMLPullParser in ElementTree
	inherit from XMLParser
Message-ID: <1379088212.34.0.0740514839917.issue19010@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

As mentioned in tickets #18902 and #17741, the XMLPullParser in the external lxml.etree package inherits from the existing XMLParser class. This makes the interface simpler, both simpler to explain and to implement.

The implementation in ElementTree should do the same.

----------
components: Library (Lib), XML
messages: 197605
nosy: eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: Make XMLPullParser in ElementTree inherit from XMLParser
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 13 18:55:43 2013
From: report at bugs.python.org (Chris Lambacher)
Date: Fri, 13 Sep 2013 16:55:43 +0000
Subject: [New-bugs-announce] [issue19011] Enum should have a __getattr__
	that makes all the	instances available from an instance
Message-ID: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>


New submission from Chris Lambacher:

The use case for this is that when you are in a template and you want to use the Enum instances in a conditional, then you need to pass the Enum class to the template or start using someenumvariable.__class__.someenumvalue. Instead it would be useful to be able to do someenumvariable.someenumvalue. Implimenting as __getattr__ on enum class allows real attributes to take precedence and also allows for overriding of behaviour in child classes.

----------
components: Library (Lib)
files: getattr_for_enum_class.patch
keywords: patch
messages: 197611
nosy: lambacck
priority: normal
severity: normal
status: open
title: Enum should have a __getattr__ that makes all the instances available from an instance
versions: Python 3.4
Added file: http://bugs.python.org/file31745/getattr_for_enum_class.patch

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

From report at bugs.python.org  Fri Sep 13 20:57:22 2013
From: report at bugs.python.org (Sjoerd)
Date: Fri, 13 Sep 2013 18:57:22 +0000
Subject: [New-bugs-announce] [issue19012] liburl2: bad proxy configuration
	throws "getaddrinfo"	error
Message-ID: <1379098642.08.0.213959473701.issue19012@psf.upfronthosting.co.za>


New submission from Sjoerd:

I'm sorry for providing very little information, but I don't have the system at hand anymore. Therefore I will try to reproduce what I know, hoping that you recognise the problem. If not, I will get back to the system and try to obtain the necessary information.

Calling liburl2.openurl('http://www.google.com') gave me an getaddrinfo error. Therefore, I checked my DNS configuration, which seemed okay and I issued a socket.getaddrinfo('www.google.com'), which correctly returned an IP address. Finally, I found out that I had an old, non-existing (?) proxy configuration in the Windows registry (that indeed turned up when calling liburl2.getproxies()). Removing the proxy configuration from my Windows registry solved the problem.

Is it preliminary to conclude that the getaddrinfo error may actually mean several things (not only a simple getaddrinfo problem)? If so, I suggest that the error message be broadened ("DNS lookup or proxy problem"), because it took me several hours to find the proxy problem.

----------
components: Library (Lib)
messages: 197629
nosy: SjoerdOptLand
priority: normal
severity: normal
status: open
title: liburl2: bad proxy configuration throws "getaddrinfo" error
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 13 21:49:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 19:49:11 +0000
Subject: [New-bugs-announce] [issue19013] unittest's own test suite is not
	CLI-friendly
Message-ID: <1379101751.33.0.506221476811.issue19013@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Nothing happens when you try to execute it on the command line:

$ ./python -m unittest.test
/home/antoine/cpython/default/python: No module named unittest.test.__main__; 'unittest.test' is a package and cannot be directly executed
$ ./python -m unittest.test.test_case
$

----------
components: Library (Lib), Tests
messages: 197634
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest's own test suite is not CLI-friendly
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 13 22:52:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 20:52:29 +0000
Subject: [New-bugs-announce] [issue19014] Allow memoryview.cast() for empty
	views
Message-ID: <1379105549.83.0.888503022363.issue19014@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This is one of most annoying things in Python to me. When you want accept any bytes-like object in you bytes-processing function you need special case empty input.

def foo(data):
    data = memoryview(data)
    if data:
        data = data.cast('B')
    else:
        data = b''

You can't use just memoryview(data).cast('B') because it doesn't work for empty data.

>>> memoryview(b'').cast('b')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: memoryview: cannot cast view with zeros in shape or strides

It would be very nice to allow cast() for empty views.

----------
components: Interpreter Core
messages: 197655
nosy: pitrou, serhiy.storchaka, skrah, teoliphant
priority: normal
severity: normal
status: open
title: Allow memoryview.cast() for empty views
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 14 04:01:11 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 14 Sep 2013 02:01:11 +0000
Subject: [New-bugs-announce] [issue19015] Too long command returns 32512
Message-ID: <1379124071.08.0.89239994658.issue19015@psf.upfronthosting.co.za>


New submission from Sworddragon:

If a command gets too long os.system() will return 32512. As I have figured out from Google this normally happens if the command can't be found. In the attachments is an example command which will fail on os.system() (it was generated as test during development - it is nearly 600.000 characters long). Executing the file with bash works fine but using os.system() makes troubles.

----------
components: Library (Lib)
files: test.sh
messages: 197680
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Too long command returns 32512
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31753/test.sh

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

From report at bugs.python.org  Sat Sep 14 11:36:45 2013
From: report at bugs.python.org (Shawn Krisman)
Date: Sat, 14 Sep 2013 09:36:45 +0000
Subject: [New-bugs-announce] [issue19016] autospecced namedtuples should be
	truthy by default
Message-ID: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>


New submission from Shawn Krisman:

import mock
from collections import namedtuple

Foo = namedtuple('Foo', bar)
mock_foo = mock.create_autospec(Foo)

if mock_foo:
    print('the namedtuple is truthy')
else:
    print('the namedtuple is not truthy')


The expected behavior is that it should print "the namedtuple is truthy." Instead it prints "the namedtuple is not truthy." Almost all namedtuples are truthy, the exception being the nearly useless namedtuple with 0 fields. The problem stems from the fact that tuples have a __len__ defined which is what is used derive truthiness. MagicMocks define __len__ to be zero by default. Workarounds to the problem are very difficult because you cannot simply define __len__ to be a nonzero number and have the mock work correctly. 


In general MagicMock has defaults that encourage the mocks to be very truthy all around:

__bool__ -- True
__int__ -- 1
__complex__ -- 1j
__float__ -- 1.0
__index__ -- 1

So it was interesting to me to find out that __len__ was defined to be 0. The fix that I am proposing is to make 1 the new default for __len__. I believe this is a more useful default in general because an instance of a class with a __len__ attribute will likely be truthy far more often then not.


There are of course backwards compatibility issues to consider here, however I don't think many people are assuming this behavior. Certainly nobody in the python code base.

----------
components: Library (Lib)
files: namedtuple_truthiness.patch
keywords: patch
messages: 197698
nosy: michael.foord, skrisman
priority: normal
severity: normal
status: open
title: autospecced namedtuples should be truthy by default
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file31755/namedtuple_truthiness.patch

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

From report at bugs.python.org  Sat Sep 14 13:01:58 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 Sep 2013 11:01:58 +0000
Subject: [New-bugs-announce] [issue19017] selectors: towards uniform EBADF
	handling
Message-ID: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, in case of invalid file descriptor (which can happen easily e.g. if the user closes the FD before unregistering it), selector.select() will react differently depending on the backend:

SelectSelector fails with EBADF
PollSelector returns EVENT_READ/EVENT_WRITE for the FD (translated from poll()'s POLLNVAL)
EpollSelector returns nothing (epoll silently removes the FD from the set of monitored FD, there's no EPOLLNVAL)
KqueueSelector behaves like EpollSelector

One possibility would be for PollSelector.select() to raise EBADF in case of POLLNVAL. That would be consistent with select, but not with epoll and kqueue.

Another possibility would be to silently fix those, i.e. in case of EBADF/POLLNVAL in select/poll, remove the offending FD from the list of monitored FDs. That's what libev does (see e.g. http://cvs.schmorp.de/libev/ev_poll.c?revision=1.39&view=markup and http://cvs.schmorp.de/libev/ev.c?revision=1.457&view=markup), and that's also what twisted does, at least for select (see http://twistedmatrix.com/trac/browser/trunk/twisted/internet/selectreactor.py#L77).

One advantage is that once we've detected a bad FD, we remove it so we're sure we won't loop endlessly: e.g. for poll, if the user doesn't try to use the FD no exception will be raised and selector.select() keep reporting the FD ready.

(Note that performing this cleanup is easy for poll since it's flagged with POLLNVAL, but for select this requires looping over the registered FDs, but since that's only called in case of error, it's not performance critical, see Twisted's code)

I personally favor the later solution.

Second point: if we opt for the later solution, we should probably update {EpollSelector,KqueueSelector}.unregister() to silently catch an error if the FD wasn't registered in the underlying epoll/kqueue.
That's what libev does, and amusingly that's what the select module already does:
http://hg.python.org/cpython/file/c9644c1f9c94/Modules/selectmodule.c#l1329

Third point: should the current select behavior (ignoring epoll.unregister() error) be kept?

Thoughts?

----------
messages: 197701
nosy: giampaolo.rodola, gvanrossum, haypo, neologix, pitrou, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: selectors: towards uniform EBADF handling
type: enhancement

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

From report at bugs.python.org  Sat Sep 14 21:16:38 2013
From: report at bugs.python.org (Artem Fokin)
Date: Sat, 14 Sep 2013 19:16:38 +0000
Subject: [New-bugs-announce] [issue19018] Heapq.merge suppreses IndexError
	from user generator
Message-ID: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>


New submission from Artem Fokin:

Suppose we have the following code:

    from heapq import merge

    def iterable():
        lst = range(10)
        for i in xrange(20):
            yield lst[i]
        
    it1, it2= iterable(), iterable()

    print list(merge(it1, it2)) # no IndexError
    #output is: [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8, 9]


The reason is that in heapq.merge http://hg.python.org/cpython/file/7c18b799841e/Lib/heapq.py#l372 try-catch clause for IndexError is too broad

    while 1:
        try:
            while 1:
                v, itnum, next = s = h[0]   # raises IndexError when h is empty
                yield v
                s[0] = next()               # raises StopIteration when exhausted, 
                _heapreplace(h, s)          # restore heap condition
        except _StopIteration:
            _heappop(h)                     # remove empty iterator
        except IndexError:
            return

s[0] = next() also may raise different kinds of exceptions including IndexError which will be silently suppressed. 
For example, this loop can be rewritten as

    while 1:
        try:
            while 1:
                try:
                    v, itnum, next = s = h[0]   # raises IndexError when h is empty
                except IndexError:
                    return
                yield v
                s[0] = next()               # raises StopIteration when exhausted, 
                _heapreplace(h, s)          # restore heap condition
        except _StopIteration:
            _heappop(h)                     # remove empty iterator

----------
components: Library (Lib)
messages: 197726
nosy: afn
priority: normal
severity: normal
status: open
title: Heapq.merge suppreses IndexError from user generator
type: behavior
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Sep 14 22:31:13 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 Sep 2013 20:31:13 +0000
Subject: [New-bugs-announce] [issue19019] Investigate using Apple clang for
	building OS X	installers
Message-ID: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>


New submission from Ned Deily:

On the python-dev mailing list, Raymond Hettinger asks:
> I was exercising the alpha two release of 3.4 and noticed that
> it is still being built under GCC 4.2.1.  
> 
> Is there any reason we have to use an old compiler?

Yes, kinda.  It's because the 64-bit/32-bit installer we supply is designed to run on multiple versions of OS X: 10.6 (Snow Leopard), 10.7, 10.8, and the upcoming 10.9.  The safest way to ensure that the bits produced (executables, shared libs, and .so bundles) are linked with compatible versions of system shared libraries and frameworks is to build on the lowest supported system, 10.6, or - carefully - with a 10.6 SDK on a newer system.  The standard compiler in the Apple Developer Tools for 10.6 is gcc 4.2.  The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK.  Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries.  We have been burned by that in the past.

> I would like to see it built under the latest version of Clang
> (like the other tools on the Mac) or under GCC 4.8.1.
> I've better using the latter for many months.  It works great
> and produces *much* better code (in terms of readability
> for those of us who look at assembly output and in terms
> of speed (approx 20-25% better for cpu bound code)).
> 
> I'm wondering whether is some issue that forces us to use
> GCC 4.2.1 or whether that is just an artifact of continuing
> to do what we've always been doing.

I'd like to move to Apple's latest clang, as well.  (Apple is dropping gcc totally from the next release of Xcode.)  There are a couple of approaches that may work and still reliably support multiple versions of OS X.  Investigating this is on my list of things to do prior to the next alpha.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 197729
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: Investigate using Apple clang for building OS X installers
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 15 00:11:22 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Sep 2013 22:11:22 +0000
Subject: [New-bugs-announce] [issue19020] Regression: Windows-tkinter-idle,
	unicode, and 0xxx filename
Message-ID: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Current 3.3.2+ repository build (32 bit) and 3.4.0a2 repository build (32 bit) and installation (64 bit) have a problem that did not exist in my Win6 3.3.2 installation (64 bit). (Bruce Sherwood discovered the symption with some installed version of 3.4.0a?) Adding to recent files a path with a directory or file whose name begins with '0' causes Idle to stop with a traceback such as given below. Currently, opening *any* file causes the recent files list to be rebuilt (seen in traceback). So the problem happens whether one opens a new file with a leading 0 somewhere or if there merely is one such already on the list.

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python34\lib\tkinter\__init__.py", line 1475, in __call__
    return self.func(*args)
  File "C:\Python34\lib\idlelib\IOBinding.py", line 179, in open
    flist.open(filename, self.loadfile)
  File "C:\Python34\lib\idlelib\FileList.py", line 34, in open
    return action(filename)
  File "C:\Python34\lib\idlelib\IOBinding.py", line 240, in loadfile
    self.updaterecentfileslist(filename)
  File "C:\Python34\lib\idlelib\IOBinding.py", line 521, in updaterecentfileslist
    self.editwin.update_recent_files_list(filename)
  File "C:\Python34\lib\idlelib\EditorWindow.py", line 915, in update_recent_files_list
    menu.delete(0, END)  # clear, and rebuild:
  File "C:\Python34\lib\tkinter\__init__.py", line 2739, in delete
    if 'command' in self.entryconfig(i):
  File "C:\Python34\lib\tkinter\__init__.py", line 2749, in entryconfigure
    return self._configure(('entryconfigure', index), cnf, kw)
  File "C:\Python34\lib\tkinter\__init__.py", line 1247, in _configure
    self.tk.call(_flatten((self._w, cmd)))):
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 14: invalid start byte

'invalid start byte' 0xc0 has appeared before in other issues.

Bruce got this with
  H:\HP_Documents\0PythonWork\AirplaneKinematics\accel2.py
I get 12' instead of '14' with
  F:\Python\mypy\0...' (file or directory, must be 0, not 1)
It appears that the string is being improperly 're-cooked' at some point, so that '\x' sequences are 1 position rather than 2.

At the point of failure, I believe tk is checking whether a particular menuitem has an associated callback that should be deleted before the menuitem itself is deleted (before later being rebuilt). (It is a separate issue of whether we could just adjust the recent file list (sub sub menu) rather than deleting and rebuilding it, possibly the same as it was. Even if we did, the issue would still arise when opening a new '0' file, or when closing Idle.)

----------
messages: 197736
nosy: bsherwood, ezio.melotti, haypo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Regression: Windows-tkinter-idle, unicode, and 0xxx filename
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Sep 15 01:46:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Sep 2013 23:46:46 +0000
Subject: [New-bugs-announce] [issue19021] AttributeError in Popen.__del__
Message-ID: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Sometimes closing IDLE I got such exception:

Exception ignored in: <bound method Popen.__del__ of <subprocess.Popen object at 0xb5b8618c>>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/subprocess.py", line 890, in __del__
TypeError: 'NoneType' object is not callable

It is happened because the builtins module was destroyed before running __del__ in process of garbage collecting.

Here is a patch which should fix the bug. Anothe possible solution is get rid from getattr and catch AttributeError instead.

See also issue16650.

----------
components: Library (Lib)
files: subprocess_del_getattr.patch
keywords: patch
messages: 197737
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: AttributeError in Popen.__del__
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31762/subprocess_del_getattr.patch

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

From report at bugs.python.org  Sun Sep 15 09:33:28 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Sep 2013 07:33:28 +0000
Subject: [New-bugs-announce] [issue19022] Improve handling of
	type.__abstractmethods__ descriptor
Message-ID: <1379230408.43.0.525404043988.issue19022@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 10006 pointed out that attempting to access object.__abstractmethods__ raises AttributeError. The solution was to ensure type.__abstractmethods__ *also* raises AttributeError.

This is thoroughly confusing, since the name is clearly visible in the output of dir(type). While it's technically legal for a descriptor to always raise AttributeError, breaking the following typical assumed invariant is *highly* dubious:

    all(hasattr(obj, x) for x in dir(obj))

I see three main alternatives for improving the situation:

1. Make __abstractmethods__ a read-only descriptor that returns something meaningful (like a frozenset(), the same as you get if you inherit from abc.ABCMeta without defining any abstract methods)

2. Throw a better exception message that explains the broken invariant rather than the generic "AttributeError with attribute name" that is currently thrown.

3. Implement type.__dir__ to filter out the uncooperative descriptor

----------
messages: 197755
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve handling of type.__abstractmethods__ descriptor
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 15 13:57:50 2013
From: report at bugs.python.org (Sye van der Veen)
Date: Sun, 15 Sep 2013 11:57:50 +0000
Subject: [New-bugs-announce] [issue19023] ctypes docs: Unimplemented and
	undocumented features
Message-ID: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>


New submission from Sye van der Veen:

In the ctypes documentation, there's mention of a BigEndianUnion/LittleEndianUnion that isn't actually implemented, and the "Arrays and pointers" section just reads "Not yet written".

The attached patch adds the (Big|Little)EndianUnion classes (with tests), finishes the Array/_Pointer class docs (and adds missing cases to the tests), and makes some stylistic improvements to docs.

The patch was made against default, but it's quite likely it could be back-ported all the way to Python 3.1.

----------
assignee: docs at python
components: Documentation, Tests, ctypes
hgrepos: 209
messages: 197764
nosy: docs at python, syeberman
priority: normal
severity: normal
status: open
title: ctypes docs: Unimplemented and undocumented features
type: enhancement

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

From report at bugs.python.org  Sun Sep 15 15:18:38 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 15 Sep 2013 13:18:38 +0000
Subject: [New-bugs-announce] [issue19024] Document asterisk (*),
	splat or star operator
Message-ID: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

I'd say this is a critical documentation bug that leads to head bang when you try to figure out what does '*' in code means.

This bug is two fold:
1. Define a dedicated place in documentation for '*' operator with examples. I propose http://docs.python.org/3/library/stdtypes.html chapter with a name like "Special Operations" or "Function Argument Operations" or "Function Argument Operators"
 
2. Make '*', 'asterisk', 'splat', 'star' operator searchable
http://docs.python.org/3/search.html?q=*
http://docs.python.org/3/search.html?q=asterisk
http://docs.python.org/3/search.html?q=splat
http://docs.python.org/3/search.html?q=star+operator

Good?

References:
http://stackoverflow.com/questions/2322355/proper-name-for-python-operator
http://stackoverflow.com/questions/5239856/foggy-on-asterisk-in-python
http://stackoverflow.com/questions/2921847/python-once-and-for-all-what-does-the-star-operator-mean-in-python
http://stackoverflow.com/questions/287085/what-do-args-and-kwargs-mean
http://stackoverflow.com/search?q=[python]+%2Bkwargs+is%3Aquestion

----------
assignee: docs at python
components: Documentation
messages: 197772
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Document asterisk (*), splat or star operator
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Sep 15 17:15:10 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Sep 2013 15:15:10 +0000
Subject: [New-bugs-announce] [issue19025] Deleting attribute of Enum gives
	misleading error message
Message-ID: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> from enum import Enum
>>> class MyPet(Enum):
...   CUTE_CAT = 1
...   VIGOROUS_DOG = 2
...   UGLY_BLOBFISH = 3
...   PROMISCUOUS_BONOBO = 4
...   def spam(cls): pass
... 
>>> del MyPet.CUTE_CAT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: CUTE_CAT

This is misleading. I have CUTE_CAT attribute in Enum. It should throw TypeError exception.

>>> del MyPet.LONELY_WOLF
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: LONELY_WOLF

This is correct.

>>> del MyPet['CUTE_CAT']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'EnumMeta' object does not support item deletion

I think this behaviour is correct.

>>> del MyPet['LONELY_WOLF']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'EnumMeta' object does not support item deletion

This behaviour is somewhat misleading. I don't have LONELY_WOLF item.

>>> del MyPet.spam
>>> hasattr(MyPet, 'spam')
False

This is correct. We should be able to delete method from Enum class, or shouldn't we?

>>> cute_cat = MyPet.CUTE_CAT
>>> del cute_cat.name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sky/Code/python/programming_language/cpython/Lib/enum.py", line 29, in __delete__
    raise AttributeError("can't delete attribute")
AttributeError: can't delete attribute

This is *maybe" correct. But shouldn't it be TypeError exception?

All the exception messages related with deleting attribute in Python codebase are using TypeError exception (with one exception in pyexpat on which it uses RuntimeError exception).

Attached the patch to handle the attribute deletion correctly.

For now, I don't change the exception for the last case (del MyPet.CUTE_CAT.name) because maybe there is an exception case for enum.

----------
components: Library (Lib)
files: handling_attribute_deletion_correctly_in_enum.patch
keywords: patch
messages: 197775
nosy: ethan.furman, vajrasky
priority: normal
severity: normal
status: open
title: Deleting attribute of Enum gives misleading error message
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31771/handling_attribute_deletion_correctly_in_enum.patch

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

From report at bugs.python.org  Sun Sep 15 18:46:03 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 15 Sep 2013 16:46:03 +0000
Subject: [New-bugs-announce] [issue19026] OrderedDict should not accept dict
	as parameter
Message-ID: <1379263563.34.0.887004049034.issue19026@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://stackoverflow.com/questions/15733558/python-ordereddict-not-keeping-element-order

I wonder why OrderedDict accepts dict as parameter in a first place? OD is used when order is important and if plain dict is supplied, the order is lost.

    >>> d = {3:4, 1:2}
    >>> OD(d)
    OrderedDict([(1, 2), (3, 4)])

OrderedDict should not accept dict as parameter.

----------
components: Library (Lib)
messages: 197787
nosy: techtonik
priority: normal
severity: normal
status: open
title: OrderedDict should not accept dict as parameter
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Sep 15 19:20:48 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 15 Sep 2013 17:20:48 +0000
Subject: [New-bugs-announce] [issue19027] undefined symbol: _PyParser_Grammar
Message-ID: <1379265648.95.0.708128098895.issue19027@psf.upfronthosting.co.za>


New submission from Armin Rigo:

It is possible to get the working copy of Python 2.7 in a state such that any attempt to do "make" ends with the error shown in the title.  The working copy is perfectly valid; it is a matter of getting the wrong timestamps on the files.

(Despite the error message, this is not directly related to issue10013 or "make -j".)

I didn't try Python 3.x, but the same issue might apply.

How to reproduce:

- get your checkout, let's say in python/src/

- go to your build directory, say python/build/, and run "../src/configure; make".

- then, in the src dir, give Include/graminit.h a more recent timestamp than Python/graminit.c, for example by saying "touch Include/graminit.h" (this is the crux: a common mercurial checkout will order them the other way, just because of alphabetical ordering).

- remove your python/build/ directory completely, create it anew, and run again "../src/configure; make".

The cause of the message is that the Makefile rule for $(GRAMMAR_C) runs, because the GRAMMAR_H file is more recent; but the GRAMMAR_H rule does nothing, because the latter is already up-to-date.  So the only thing that runs is "touch $(GRAMMAR_C)".  But this creates an empty file build/Python/graminit.c!

----------
components: Interpreter Core
messages: 197797
nosy: arigo
priority: normal
severity: normal
status: open
title: undefined symbol: _PyParser_Grammar
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep 15 22:51:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 20:51:08 +0000
Subject: [New-bugs-announce] [issue19028] tkinter.tkapp.merge() fails on
	non-strings
Message-ID: <1379278268.95.0.270517014711.issue19028@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

tkinter.tkapp.merge() recursively merge Python data into Tcl string. When a subitem neither tuple, string or byte string, it calls str() on it. But then it use PyBytes_AsString() which always fails because accepts bytes instead of str.

The proposed patch fixes processing general objects in merge(), simplifies processing strings, and adds tests.

This is only 3.3 issue. merge() was deprecated and removed in 3.4.

----------
components: Tkinter
files: tkinter_merge.patch
keywords: patch
messages: 197833
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: tkinter.tkapp.merge() fails on non-strings
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31783/tkinter_merge.patch

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

From report at bugs.python.org  Sun Sep 15 22:59:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 20:59:44 +0000
Subject: [New-bugs-announce] [issue19029] tix.py uses StringType
Message-ID: <1379278784.45.0.495441517749.issue19029@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Lib/tkinter/tix.py uses the StringType name which is not defined. This is a remnant from 2.x where the StringType type was imported from the types module. In 3.x it gone and was replaced by str in Lib/tkinter/__init__.py.

The proposed patch fixes it also in tix.py.

----------
components: Tkinter
files: tix_StringType.patch
keywords: easy, patch
messages: 197834
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: tix.py uses StringType
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31784/tix_StringType.patch

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

From report at bugs.python.org  Mon Sep 16 02:00:54 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 00:00:54 +0000
Subject: [New-bugs-announce] [issue19030] Make inspect.getmembers and
	inspect.classify_class_attrs	Enum aware
Message-ID: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Due to the odd nature of Enum classes and instances, the normal methods used by inspect.getmembers and inspect.classify_class_attrs are insufficient.

By special casing Enum inside those two functions the correct information can be returned.

Here is an example of the problem:

=======================================================================================
--> class Test(enum.Enum):
...   this = 'that'
...   these = 'those'
...   whose = 'mine'
...   name = 'Python'
...   value = 'awesome'
...   def what(self):
...     return "%s is %s!" % (self.name, self.value)
... 

--> help(Test)
Help on Test in module __main__ object:

class Test(enum.Enum)
 |  Method resolution order:
 |      Test
 |      enum.Enum
 |      builtins.object
 |  
 |  Data and other attributes defined here:
 |  
 |  these = <Test.these: 'those'>
 |  
 |  this = <Test.this: 'that'>
 |  
 |  whose = <Test.whose: 'mine'>
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.Enum:
 |  
 |  name
 |      The name of the Enum member.
 |  
 |  value
 |      The value of the Enum member.
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.EnumMeta:
 |  
 |  __members__
 |      Returns a mapping of member name->value.
 |      
 |      This mapping lists all enum members, including aliases. Note that this
 |      is a read-only view of the internal mapping.
(END)
=======================================================================================

As can be seen, 'name' and 'value' are not showing up as enum members.

----------
messages: 197844
nosy: barry, eli.bendersky, ethan.furman, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Make inspect.getmembers and inspect.classify_class_attrs Enum aware
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 16 02:03:14 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 00:03:14 +0000
Subject: [New-bugs-announce] [issue19031] Make help() enum aware
Message-ID: <1379289794.97.0.994378932185.issue19031@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Currently, if help() is called on an Enum member, it displays help for the class.  While this is usually what one wants, it is not for Enums.

----------
messages: 197845
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: Make help() enum aware
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 16 02:43:04 2013
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 16 Sep 2013 00:43:04 +0000
Subject: [New-bugs-announce] [issue19032] __reduce_ex__ on lock object
Message-ID: <1379292184.95.0.492650505844.issue19032@psf.upfronthosting.co.za>


New submission from Ram Rachum:

>>> import threading
    >>> l = threading.Lock()
    >>> l.__reduce_ex__(3)
    (<function __newobj__ at 0x00000000026CD8C8>,
     (<class '_thread.lock'>,),
     None,
     None,
     None)

Isn't it a bug that `__reduce_ex__` works on the non-pickleable lock object?

----------
components: Library (Lib)
messages: 197850
nosy: cool-RR
priority: normal
severity: normal
status: open
title: __reduce_ex__ on lock object
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 16 04:35:35 2013
From: report at bugs.python.org (Robert M. Koretsky)
Date: Mon, 16 Sep 2013 02:35:35 +0000
Subject: [New-bugs-announce] [issue19033] Python 3 won't go on PC-BSD 9.1
Message-ID: <1379298935.78.0.614381300505.issue19033@psf.upfronthosting.co.za>


New submission from Robert M. Koretsky:

I use the instructions in the README file that gets unzipped with Python-3.0.tgz to install on PC-BSD 9.1
./configure, make, make test, sudo make install
and it does not work! Error messages too verbose to include here.
My path includes the directory that everything is unzipped into, and I'm executing the configure and makes from within that directory.
I am surprised that no one else has the same problem, or at least hasn't reported it. If the creation of python 3 is so difficult, why hasn't anyone come up with a clear, articulate set of instructions for PC-BSD or FreeBSD installs?

----------
components: Installation
messages: 197864
nosy: Bobk48
priority: normal
severity: normal
status: open
title: Python 3 won't go on PC-BSD 9.1
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 16 10:47:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 08:47:32 +0000
Subject: [New-bugs-announce] [issue19034] More useful repr for Tcl_Obj
Message-ID: <1379321252.25.0.835083719717.issue19034@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently the repr() for Tcl_Obj is not very useful. It exposes only Tcl type name and Tcl object address.

>>> import tkinter.ttk
>>> tv = tkinter.ttk.Treeview()
>>> tv.tag_configure('test', foreground='blue')
{}
>>> str(tv.tag_configure('test', 'foreground'))
'blue'
>>> tv.tag_configure('test', 'foreground')
<color object at 0xb70f84b8>

You need explicitly call str to get more useful information. This is awkward when Tcl object hidden deeply in tuples or other data structure, or reported in a backtrace. Actually every Tcl object can be represented as a string. I propose to expose this representation in repr(). With proposed patch the output of the last command will be: <color object: 'blue'>.

----------
components: Tkinter
files: tkinter_repr.patch
keywords: patch
messages: 197881
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: More useful repr for Tcl_Obj
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31791/tkinter_repr.patch

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

From report at bugs.python.org  Mon Sep 16 16:12:54 2013
From: report at bugs.python.org (Alexey Umnov)
Date: Mon, 16 Sep 2013 14:12:54 +0000
Subject: [New-bugs-announce] [issue19035] tokenize.generate_tokens treat
	'\f' symbol as the end of	file (when reading in unicode)
Message-ID: <1379340774.03.0.601384573394.issue19035@psf.upfronthosting.co.za>


New submission from Alexey Umnov:

I execute the following code on the attached file 'text.txt':


import tokenize
import codecs

with open('text.txt', 'r') as f:
    reader = codecs.getreader('utf-8')(f)
    tokens = tokenize.generate_tokens(reader.readline)


The file 'text.txt' has the following structure: first line with some text, then '\f' symbol (0x0c) on the second line and then some text on the last line. The result is that the function 'generate_tokens' ignores everything after '\f'.

I've made some debugging and found out the following. If the file is read without using codecs (in ascii-mode), there are considered to be 3 lines in the file: 'text1\n', '\f\n', 'text2\n'. However in unicode-mode there are 4 lines: 'text1\n', '\f', '\n', 'text2\n'. I guess this is an intended behaviour since 2.7.x, but this causes a bug in tokenize module.

Consider the lines 317-329 in tokenize.py:

...
column = 0
while pos < max:                   # measure leading whitespace
    if line[pos] == ' ':
        column += 1
    elif line[pos] == '\t':
        column = (column//tabsize + 1)*tabsize
    elif line[pos] == '\f':
        column = 0
    else:
        break
    pos += 1
if pos == max:
    break
...

The last 'break' corresponds to the main parsing loop and makes the parsing stop. Thus the lines that consist of (' ', '\t', '\f') characters and don't end with '\n' are treated as the end of file.

----------
components: Library (Lib)
files: tokens.txt
messages: 197899
nosy: Alexey.Umnov
priority: normal
severity: normal
status: open
title: tokenize.generate_tokens treat '\f' symbol as the end of file (when reading in unicode)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31796/tokens.txt

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

From report at bugs.python.org  Mon Sep 16 18:02:37 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 16 Sep 2013 16:02:37 +0000
Subject: [New-bugs-announce] [issue19036] setlocale fails due to locale.h
	being wrapped up in	LANGINFO check.
Message-ID: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>


New submission from Alan Hourihane:

Patch....

--- Python/fileutils.c.old	2013-09-11 07:04:42.000000000 +0000
+++ Python/fileutils.c	2013-09-11 07:05:01.000000000 +0000
@@ -4,8 +4,8 @@
 #  include <windows.h>
 #endif
 
-#ifdef HAVE_LANGINFO_H
 #include <locale.h>
+#ifdef HAVE_LANGINFO_H
 #include <langinfo.h>
 #endif

----------
components: Build
messages: 197914
nosy: alanh
priority: normal
severity: normal
status: open
title: setlocale fails due to locale.h being wrapped up in LANGINFO check.
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 16 20:58:36 2013
From: report at bugs.python.org (janzert)
Date: Mon, 16 Sep 2013 18:58:36 +0000
Subject: [New-bugs-announce] [issue19037] mailbox module modifies maildir
	file times after moving	from tmp directory
Message-ID: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>


New submission from janzert:

The Maildir.add and Maildir.__setitem__ methods in the mailbox module attempts to change the file mtime after moving the file into the new directory. This allows a race condition since other programs are can move or otherwise modify the file as soon as it is placed in the new directory. If the file is moved from the new directory before the mtime is set this results in an unexpected OSError exception.

The fix seems to simply be setting the file mtime before moving the file into its final position.

----------
components: Library (Lib)
messages: 197930
nosy: janzert, petri.lehtinen
priority: normal
severity: normal
status: open
title: mailbox module modifies maildir file times after moving from tmp directory
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep 16 23:02:14 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Mon, 16 Sep 2013 21:02:14 +0000
Subject: [New-bugs-announce] [issue19038] Fix sort order in Misc/ACKS.
Message-ID: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>


New submission from Tae-Wong SEO:

This patch fixes sort order in file Misc/ACKS.

----------
assignee: docs at python
components: Documentation
files: ACKS
messages: 197945
nosy: docs at python, taewong.seo
priority: normal
severity: normal
status: open
title: Fix sort order in Misc/ACKS.
type: enhancement
Added file: http://bugs.python.org/file31803/ACKS

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

From report at bugs.python.org  Tue Sep 17 09:01:40 2013
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 17 Sep 2013 07:01:40 +0000
Subject: [New-bugs-announce] [issue19039] sphinx search, result sorting
Message-ID: <1379401300.31.0.855533984181.issue19039@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

If you search for "printf" in the docs you get this result:

http://docs.python.org/3.3/search.html?q=printf&check_keywords=yes&area=default

Please have a look at the first results. I guess most people don't want to see docs about "PyOS_snprintf"

Most people want to see this: http://docs.python.org/3.3/library/stdtypes.html?highlight=printf#printf-style-string-formatting

The good page (stdtypes.html) is the fourth search result.
And this page is huge. Unfortunately the link from the search result does not link to the section, it links to the top of the page.

 Since "printf" is in the heading, sphinx should be able to create a link to the relevant section in this page (in this example #printf-style-string-formatting).


Thank you

----------
assignee: docs at python
components: Documentation
messages: 197963
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: sphinx search, result sorting

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

From report at bugs.python.org  Tue Sep 17 12:10:37 2013
From: report at bugs.python.org (Drekin)
Date: Tue, 17 Sep 2013 10:10:37 +0000
Subject: [New-bugs-announce] [issue19040] Problems with overriding
	Enum.__new__
Message-ID: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>


New submission from Drekin:

I tried to implement an Enum variant OptionalEnum such that OptionalEnum(value) leaves value alone and returnes it (if there is no corresponding enum member) rather than raising ValueError. My use case is following: I'm trying to parse some keyboard layout related data. There is a table which maps virtual keys to unicode codepoints, however there are some special values which don't represent a codepoint but the fact that the key is a deadkey and more information is provided in the next table entry. Or that the key produces a ligature. So I wanted to define enums for those special values.

This brought me to the following naive approach:
class OptionalEnum(Enum):
    def __new__(cls, value):
        try:
            return super(cls, cls).__new__(cls, value)
        except ValueError:
            return value

This ends with a weird exception. As I ran through enum code I found out that there are actually two flavors of EnumSubclass.__new__. The first one is for precreating the enum members (during creation of EnumSubclass). This is the intended usage. The second flavor is what happens when EnumSubclass(value) is called later. This flavor is represented by Enum.__new__ which returns existing member corresponding to the value or raises ValueError. However this Enum.__new__ is rather special. It doesn't take place in the process of the first flavor, it is explicitly by-passed. On the other hand it is forced behavior of the second flavor since it is explicitly assigned to EnumSubclass.__new__. So there seems to be no way to customize the second flavor (as I tried in my use case).

So could the customization of the second flavor of __new__ be added? (One maybe naive solution would be to let user explicitly define __new_member__ rather than __new__ to customize the first flavor and leave __new__ for the second flavor.) Or could at least be done something with the exceptions produced when one tries to? (The exception in my case was 'TypeError: object() takes no parameters' and was result of having custom __new__ and hence use_args==True but having member_type==object and __new__ not creating member with _value_ attribute so object(*args) was called.)

In any case additional documentation on customizing __new__ could help. There are points like that one should avoid the pattern of falling back to super().__new__ since that is Enum.__new__ which is for something else. Also the custom __new__ should return an object with _value_ attribute or object() with some argument may be called which leads to uninformative exception.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 197979
nosy: Drekin, docs at python
priority: normal
severity: normal
status: open
title: Problems with overriding Enum.__new__
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Sep 17 17:51:26 2013
From: report at bugs.python.org (Tcll)
Date: Tue, 17 Sep 2013 15:51:26 +0000
Subject: [New-bugs-announce] [issue19041] requested (DLL) module could not
	be found
Message-ID: <1379433086.01.0.0639990242441.issue19041@psf.upfronthosting.co.za>


New submission from Tcll:

I think this issue more revolves around PyGLEW, but LaunchPad won't let me report to them...

I've taken a screenshot of the issue rather than trying to explain it:
http://lh3.ggpht.com/-d6gM0Qlq9Ek/UjhxFDFOmAI/AAAAAAAAFIU/Vwell0V1Vo8/s1400/error.jpg

I've also notified the PyGPU developers who require the installation for their project.

----------
components: Extension Modules
messages: 197994
nosy: Tcll
priority: normal
severity: normal
status: open
title: requested (DLL) module could not be found
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 17 19:20:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Sep 2013 17:20:54 +0000
Subject: [New-bugs-announce] [issue19042] Idle: add option to autosave
	'Untitled' edit window
Message-ID: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The General tab of the IDLE Preferences dialog has this section with two radiobuttons:

Autosave Preferences
At Start of Run (F5)  () Prompt to Save   () No Prompt

The latter option actually means "No prompt unless the window is a new window ('Untitled') that has never been saved." In the latter case, there is a prompt anyway.

This issue proposes that the current No Prompt option be more truthfully labelled and that a true no-prompt option be added. Currently in .cnf configuration files, autosave = 0 or 1. The new option would be 2 ('really true' ;-).

The motivation is to provide a default scratch file for throwaway code and thereby encourage more use of the editor even for single multi-line statements, which are harder to edit in the Shell than single-line statements. The behavior of Untitled windows would not otherwise change.

----------------
Possible dialog forms

Autosave Preferences
When Running (F5) a window with unsaved changes, prompt to save
() Always   () Only for Untitled    () Never

I find it slightly confusing that Autosave yes is selected in the negative with 'no prompt'. An alternative:

Autosave Preferences
When Running (F5) a window with unsaved changes,
autosave instead of prompting to save
() Never   () Always except for Untitled    () Always

Another alternative is to retitle the section

Prompt to Save versus Autosave
When Running (F5) a window with unsaved changes, prompt to save
() Always   () Only for Untitled    () Never
--------------

However the dialog is worded, the new option would mean that unsaved new windows would be autosaved on Run to .idlerc/untitled.py. (I picked this directory because it already contains 4 per-user files, including recent-files.lst, and has to be writable.) This would be a common scratch file for all Untitled windows.

The particular Untitled window saved should not be 'associated' with that path. Its title would not change to 'untitled.py'. Idle allows only one edit window per disk file (path) but allows multiple Untitled windows not associated with any path.

The 'unsaved' flag on the window would not be cleared, so that closing the window would still bring up the 'save this untitled window' message box. (The alternative would be to clear it, but unclear it if any other Untitled window were saved.)

The full path to untitled.py would be added (or moved) to the top of the Recent Files list, just as with any other file. The file could then be retrieved (if not overwritten) in a later session. This would be particularly useful if running it caused a crash or freeze.
------------------

This proposal is based on Bruce Sherwood's vague description of a feature coded by G. Polo. I could not find a tracker issue for it. One apparent difference is that I propose adding a third option to the existing set instead of a new binary option. I have no idea whether Polo proposed to silently save the file (as I propose) or add a mechanism to truly run without saving (which is how a user will see it unless they look at Recent Files). In any case, my proposal is for a pretty minimal change. I believe it would take extra code to prevent the Recent Files listing.

----------
components: IDLE
messages: 197997
nosy: bsherwood, roger.serwy, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: add option to autosave 'Untitled' edit window
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep 19 02:59:57 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 19 Sep 2013 00:59:57 +0000
Subject: [New-bugs-announce] [issue19043] Remove detailed listing of all
	versions from LICENSE, Doc/license.rst
Message-ID: <1379552397.42.0.802042689988.issue19043@psf.upfronthosting.co.za>


New submission from Georg Brandl:

As discussed on python-dev.

----------
assignee: docs at python
components: Documentation
files: license_fixup_33.patch
keywords: patch
messages: 198036
nosy: docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: Remove detailed listing of all versions from LICENSE, Doc/license.rst
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31810/license_fixup_33.patch

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

From report at bugs.python.org  Thu Sep 19 05:38:52 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Thu, 19 Sep 2013 03:38:52 +0000
Subject: [New-bugs-announce] [issue19044] getaddrinfo raises near-useless
	exception
Message-ID: <1379561932.98.0.549572888497.issue19044@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

I received a bugreport for a Python application that contains the following stacktrace:

>   File "/usr/lib/python3.3/http/client.py", line 1057, in endheaders
>     self._send_output(message_body)
>   File "/usr/lib/python3.3/http/client.py", line 902, in _send_output
>     self.send(msg)
>   File "/usr/lib/python3.3/http/client.py", line 840, in send
>     self.connect()
>   File "/usr/lib/python3.3/http/client.py", line 1194, in connect
>     self.timeout, self.source_address)
>   File "/usr/lib/python3.3/socket.py", line 417, in create_connection
>     for res in getaddrinfo(host, port, 0, SOCK_STREAM):
> OSError: [Errno 0] Error

My guess is that something went wrong with the name resolution, but it seems near impossible to handle this in the application because apparently the exception contains no machine usable useful informaton at all. 


It would be nice if whatever information Python used to determine that the getaddrinfo call failed could be included in the exception, so that it can be properly caught and handled.

----------
components: Library (Lib)
messages: 198039
nosy: Nikratio
priority: normal
severity: normal
status: open
title: getaddrinfo raises near-useless exception
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 19 09:02:59 2013
From: report at bugs.python.org (Borut Podlipnik)
Date: Thu, 19 Sep 2013 07:02:59 +0000
Subject: [New-bugs-announce] [issue19045] Make on Solaris 11 x64 with
	OracleStudio12.3 failed
Message-ID: <1379574179.05.0.180767783928.issue19045@psf.upfronthosting.co.za>


New submission from Borut Podlipnik:

# make
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c
"Parser/grammar1.c", line 39: Warning: String literal converted to char* in initialization.
1 Warning(s) detected.
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/listnode.o Parser/listnode.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/node.o Parser/node.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/parser.o Parser/parser.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o Parser/parsetok.c
"Parser/parsetok.c", line 250: Error: Cannot assign void* to char*.
1 Error(s) detected.
*** Error code 2
make: Fatal error: Command failed for target `Parser/parsetok.o'

----------
components: Build
messages: 198042
nosy: podlipnik
priority: normal
severity: normal
status: open
title: Make on Solaris 11 x64 with OracleStudio12.3 failed
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 19 09:14:58 2013
From: report at bugs.python.org (Michael Herrmann)
Date: Thu, 19 Sep 2013 07:14:58 +0000
Subject: [New-bugs-announce] [issue19046] SystemError:
	..\Objects\weakrefobject.c:903: bad	argument to internal function
Message-ID: <1379574898.14.0.174335958635.issue19046@psf.upfronthosting.co.za>


New submission from Michael Herrmann:

I'm on 32 bit Python 2.7.3 and 64 bit Windows 7. I am working on a complex, multithreaded application which uses COM to communicate with other processes.

My application uses regular expressions in a few (but not very many) places. An example re I am trying to match is 'quit(\\(.*\\))?', an example input would be 'quit()'. Nothing exciting.

Very frustratingly, even though the regular expressions and inputs are the same, I spuriously get errors of the following form:

Traceback (most recent call last):
  ...
  File "re.pyc", line 137, in match
SystemError: ..\Objects\weakrefobject.c:903: bad argument to internal function

I have seen the bug many times on 2.7.3. I briefly tried to reproduce it on 2.7.5 and it did not occur. This may be because the bug only occurs spuriously and I was unlucky, or because the bug no longer exists in 2.7.5. My (unverified) hunch is that the bug is not in 2.7.5 anymore. 

I have a C unhandled exception handler installed in my application. What's interesting is that the bug frequently seems to occur together with an unhandled memory access violation (exception code C0000005). When this is the case, the Python interpreter hangs or crashes.

I have not seen similar crashes in my application at other points; only when working with regular expressions and seeing the above stack trace.

----------
components: Regular Expressions, Windows
messages: 198045
nosy: ezio.melotti, mherrmann.at, mrabarnett
priority: normal
severity: normal
status: open
title: SystemError: ..\Objects\weakrefobject.c:903: bad argument to internal function
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 19 10:03:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Sep 2013 08:03:54 +0000
Subject: [New-bugs-announce] [issue19047] Clarify weakref.finalize objects
	are kept alive	automatically
Message-ID: <1379577834.67.0.113922099701.issue19047@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I was just looking at weakref.finalize objects trying to figure out if they solve a problem I'm thinking about (they do), and I couldn't figure out from the class documentation ([1]) whether or not I needed to take care of keeping the object returned from weakref.finalize alive.

I don't (the module keeps finalizers alive automatically), but this critical piece of information is only mentioned in the example much further down in the documentation ([2]).

[1] http://docs.python.org/dev/library/weakref#weakref.finalize
[2] http://docs.python.org/dev/library/weakref#finalizer-objects

The 3.4 What's New should also explicitly mention weakref.finalize as an alternative to __del__ methods (perhaps as a comment in the section on PEP 422, perhaps just in the weakref section)

----------
assignee: docs at python
components: Documentation
messages: 198046
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify weakref.finalize objects are kept alive automatically
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 19 11:19:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 09:19:50 +0000
Subject: [New-bugs-announce] [issue19048] itertools.tee doesn't have a
	__sizeof__ method
Message-ID: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

An itertools.tee object can cache an arbitrary number of objects (pointers), but its sys.getsizeof() value will always remain the same.

----------
components: Library (Lib)
messages: 198048
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: itertools.tee doesn't have a __sizeof__ method
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep 19 11:21:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 09:21:08 +0000
Subject: [New-bugs-announce] [issue19049] itertools.tee isn't 64-bit
	compliant
Message-ID: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

itertools.tee uses ints rather than Py_ssize_t for indices. Using Py_ssize_t would not make the object bigger, since other fields will already be pointer-aligned.

----------
messages: 198049
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: itertools.tee isn't 64-bit compliant
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep 19 14:58:29 2013
From: report at bugs.python.org (Daniel Rohlfing)
Date: Thu, 19 Sep 2013 12:58:29 +0000
Subject: [New-bugs-announce] [issue19050] crash while writing to a closed
	file descriptor
Message-ID: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>


New submission from Daniel Rohlfing:

This snippet let my interpreter crash immediately:

> import sys, io
> io.open(sys.stdout.fileno(), 'wb')
> fd.close()
> sys.stdout.write("now writing on stdout will cause a crash")

That's happened on
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Windows 7 SP1 x64

The same code let Python 3.3.2 throw an exception like this:
Exception OSError: OSError(9, 'Bad file descriptor') in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp850'> ignored

----------
components: Library (Lib)
messages: 198063
nosy: damiro
priority: normal
severity: normal
status: open
title: crash while writing to a closed file descriptor
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 19 16:22:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 14:22:09 +0000
Subject: [New-bugs-announce] [issue19051] Unify buffered readers
Message-ID: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are some classes in gzip, bz2, lzma, and zipfile modules which implement buffered reader interface. They read chunks of data from underlied file object, decompress it, save in internal buffer, and provide common methods to read from this buffer. Maintaining of duplicated code is cumbersome and error prone. Proposed preliminary patch moves common code into new private class _io2._BufferedReaderMixin. If the proposition will be accepted in general, I'm going to write C version and move it into the io module. Perhaps even then merge it with io.BufferedIOBase.

The idea is that all buffered reading functions (read(), read1(), readline(), peek(), etc) can be expressed in the term of one function which returns raw unbuffered data. Subclasses need define only one such function and will got all buffered reader interface. In case of mentioned above classes this functions reads and decompresses a chunk of data from underlied file. The HTTPResponse class perhaps will benefit too (issue19009).

----------
components: IO, Library (Lib)
files: buffered_reader.diff
keywords: patch
messages: 198075
nosy: alanmcintyre, benjamin.peterson, nadeem.vawda, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Unify buffered readers
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31815/buffered_reader.diff

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

From report at bugs.python.org  Thu Sep 19 17:26:56 2013
From: report at bugs.python.org (Joseph Warren)
Date: Thu, 19 Sep 2013 15:26:56 +0000
Subject: [New-bugs-announce] [issue19052] Python's CGIHTTPServer does not
	handle Expect:	100-continue gracefully which results in some
	Post requests	being handled slowly.
Message-ID: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>


New submission from Joseph Warren:

I will add as a disclaimer to this bug report that I am relatively new to both the http spec, and Python programming, so I may have completely misunderstood something.

When I make a post request with some data (using libCurl), It sends the headers first, including one header, "Expect: 100-continue" and then waits for around a second, or until receiving a "100 Continue" response, before sending the rest of the data. (I have attached WireShark capture data as html to show this, I've also attached a dump showing how Apache behaves given the same request). 

This means that when I make such a request to a CGI script, hosted using CGIHTTPServer, and the script tries to read in the data, (for instance, using cgi.FieldStorage() ). Then the CGI script takes around a second to parse the data, since it hasn't been sent yet.

I currently have a work-around for this, which is to override CGIHTTPRequestHandler, and have it send a "100 Continue" response before doing anything else. A dump showing this is attached, this makes the connection much faster. This is fine for my application, as all CGI requests will be made in the same way, However it is not a general solution. 

The W3C, when defining Expect Headers, state (taken from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html);

A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status. 


I would like to offer to implement handling of the Expect header in BaseHTTPServer, however I would like some feedback before doing this, and to check that the current behaviour is not intended for some reason.

This change would make CGIHTTPServer much faster in my use case, and I suspect it would help other people.

----------
components: Library (Lib)
files: Wireshark_Captures.html
messages: 198084
nosy: Joseph.Warren
priority: normal
severity: normal
status: open
title: Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31818/Wireshark_Captures.html

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

From report at bugs.python.org  Thu Sep 19 17:29:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 15:29:16 +0000
Subject: [New-bugs-announce] [issue19053] read1() from zipfile returns empty
	data
Message-ID: <1379604556.3.0.19871630565.issue19053@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Bzip2 is block-based compression with large (up to 800 Kb) size of block. It means that while decompressor not read enough data it can't produce any output (actually this issue exists for other compression algorithms too, but less frequent). And the read1() method which makes only one low-level read can return empty bytes when there is still data available. This issue was fixed for gzip, bz2, and lzma modules in issue15546, but left in the zipfile module. In zipfile this bug less catastrophic because other read functions do not use read1() directly, but use lower level internal function.

----------
assignee: serhiy.storchaka
components: Library (Lib)
messages: 198085
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: read1() from zipfile returns empty data
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep 19 19:26:26 2013
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 19 Sep 2013 17:26:26 +0000
Subject: [New-bugs-announce] [issue19054] Descriptors howto
Message-ID: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>


New submission from Marco Buttu:

I think in the descriptor howto, at this point:

>>> class MyClass(object):
    x = RevealAccess(10, 'var "x"')
    y = 5

or the prompt should not have been, or there is a wrong indentation.
Furthermore, in Python 3:

http://docs.python.org/3/howto/descriptor.html

we can remove the explicit derivation from `object`

----------
assignee: docs at python
components: Documentation
messages: 198096
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Descriptors howto
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Sep 20 00:28:43 2013
From: report at bugs.python.org (Jason Stumpf)
Date: Thu, 19 Sep 2013 22:28:43 +0000
Subject: [New-bugs-announce] [issue19055] Regular expressions: * does not
	match as many	repetitions as possible.
Message-ID: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>


New submission from Jason Stumpf:

>>> re.match('(a|ab)*',('aba')).group(0)
'a'

According to the documentation, the * should match as many repetitions as possible.  2 are possible, it matches 1.

Reversing the order of the operands of | changes the behaviour.

>>> re.match('(ab|a)*',('aba')).group(0)
'aba'

----------
messages: 198116
nosy: Jason.Stumpf
priority: normal
severity: normal
status: open
title: Regular expressions: * does not match as many repetitions as possible.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 20 11:28:48 2013
From: report at bugs.python.org (Thierry Seunevel)
Date: Fri, 20 Sep 2013 09:28:48 +0000
Subject: [New-bugs-announce] [issue19056] Windows 7,
	script exec not working without explicit cal of python.exe
Message-ID: <1379669328.14.0.507303810717.issue19056@psf.upfronthosting.co.za>


New submission from Thierry Seunevel:

Executing a script from the command prompt works if Python.exe called explicitly, doesn't work if script name only.
Example :
python.exe script.py is ok
script.py gives the following :
Traceback (most recent call last):
  File "D:\soft\python\lib\site.py", line 548, in <module>
    main()
  File "D:\soft\python\lib\site.py", line 530, in main
    known_paths = addusersitepackages(known_paths)
  File "D:\soft\python\lib\site.py", line 266, in addusersitepackages
    user_site = getusersitepackages()
  File "D:\soft\python\lib\site.py", line 241, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "D:\soft\python\lib\site.py", line 231, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "D:\soft\python\lib\sysconfig.py", line 516, in get_config_var
    return get_config_vars().get(name)
  File "D:\soft\python\lib\sysconfig.py", line 449, in get_config_vars
    import re
  File "D:\soft\python\lib\re.py", line 105, in <module>
    import sre_compile
  File "D:\soft\python\lib\sre_compile.py", line 14, in <module>
    import sre_parse
  File "D:\soft\python\lib\sre_parse.py", line 17, in <module>
    from sre_constants import *
  File "D:\soft\python\lib\sre_constants.py", line 18, in <module>
    from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT
Association of py extension to the python.exe is ok, Path contains the path for python directory (and also to \lib) and is the first dir in path.
Why is there a difference between the 2 invocations as they are calling the same exe?

----------
components: Windows
messages: 198136
nosy: tsunwell
priority: normal
severity: normal
status: open
title: Windows 7, script exec not working without explicit cal of python.exe
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 20 12:55:37 2013
From: report at bugs.python.org (mrDoctorWho0 .)
Date: Fri, 20 Sep 2013 10:55:37 +0000
Subject: [New-bugs-announce] [issue19057] Sometimes urllib2 raises URLError
	when trying POST with	httpS
Message-ID: <1379674537.84.0.951539433247.issue19057@psf.upfronthosting.co.za>


New submission from mrDoctorWho0 .:

Trying to use POST-request to https://vk.com and sometimes library raise an error.
  File "library/vkApi.py", line 31, in post
    response = self.Opener.open(request)
  File "/usr/lib/python2.7/urllib2.py", line 404, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 422, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1222, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
    raise URLError(err)
URLError: <urlopen error _ssl.c:489: The handshake operation timed out>

This exception appears randomly, connection is ok 100%. I tried it on different machines with python 2.7.4 and 2.7.3.

----------
components: Library (Lib)
files: code.py
messages: 198141
nosy: mrDoctorWho0..
priority: normal
severity: normal
status: open
title: Sometimes urllib2 raises URLError when trying POST with httpS
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31825/code.py

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

From report at bugs.python.org  Fri Sep 20 23:29:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 21:29:35 +0000
Subject: [New-bugs-announce] [issue19058] test_ioencoding_nonascii
	(test_sys) fails on Snow Leopard
Message-ID: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The test added in issue18818 fails on the new OS X buildbot:

======================================================================
FAIL: test_ioencoding_nonascii (test.test_sys.SysModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_sys.py", line 581, in test_ioencoding_nonascii
    self.assertEqual(out, os.fsencode(test.support.FS_NONASCII))
AssertionError: b'' != b'\xc3\xa6'

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/4

----------
components: Tests
messages: 198174
nosy: haypo, pitrou, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ioencoding_nonascii (test_sys) fails on Snow Leopard
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 21 00:32:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Sep 2013 22:32:24 +0000
Subject: [New-bugs-announce] [issue19059] test_posix failure on OS X snow
	leopord buildbot
Message-ID: <1379716344.12.0.400926462702.issue19059@psf.upfronthosting.co.za>


New submission from R. David Murray:

The new OS X buildbot is failing in test_posix:

======================================================================
FAIL: test_getgroups (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_posix.py", line 734, in test_getgroups
    set(posix.getgroups() + [posix.getegid()]))
AssertionError: Items in the second set but not the first:
1

I can't reproduce this at the command line, so it probably has something to do with the fact that buildbot is running in daemon mode.

----------
components: Tests
keywords: buildbot
messages: 198177
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: test_posix failure on OS X snow leopord buildbot
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 21 09:29:55 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 21 Sep 2013 07:29:55 +0000
Subject: [New-bugs-announce] [issue19060] docs: note that subprocess doesn't
	replace os.exec*
Message-ID: <1379748595.57.0.00736365306091.issue19060@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

I always thought that subprocess is replacing all other methods of executing external programs from Python and it is a preferred way. Perhaps I was not attentive that people isolate:
  os.system
  os.spawn*
  os.popen*
and
  os.exec*

While subprocess replaces three first, it doesn't do this with the last one. The documentation should mention this in the header block. Proposed edit:

  ...
  replace several other, older modules and functions, such as:

     os.system
     os.spawn*
     os.popen*
     popen2.*
     commands.*

+ Note that it doesn't replace other ways of executing external
+ processes from Python, such as:
+
+    os.exec*

  Information about how the subprocess module can be used
  ...

----------
assignee: docs at python
components: Documentation
messages: 198188
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: docs: note that subprocess doesn't replace os.exec*
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Sep 21 14:44:28 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 21 Sep 2013 12:44:28 +0000
Subject: [New-bugs-announce] [issue19061] Shelve documentation security
	warning is not visible
Message-ID: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

This is a follow up to issue #8855. Currently the security warning is completely invisible from Python 2 docs http://docs.python.org/2/library/shelve.html and is located under screen border on Python 3 docs.

The proposal is to move warning out of the description of open() function to paragraph following module description, the same way is it is done for pickle http://docs.python.org/3.3/library/pickle.html

----------
assignee: docs at python
components: Documentation
messages: 198194
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Shelve documentation security warning is not visible
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Sep 21 17:39:03 2013
From: report at bugs.python.org (patrick wai)
Date: Sat, 21 Sep 2013 15:39:03 +0000
Subject: [New-bugs-announce] [issue19062] problems with pyshell to get
	userdir
Message-ID: <1379777943.19.0.474410652516.issue19062@psf.upfronthosting.co.za>


New submission from patrick wai:

#file
idlelib/configHandler.py

#code
userDir = os.path.expanduser('~') 

#os
windows 7 sp1

it doesnt get final userdir path. it doesnt work correctly for userdir . 
this cause python3.3 IDLE GUI can not be opened on my pc . 
as per the docment says as follows:

help(os.path.expanduser)
Help on function expanduser in module ntpath:

expanduser(path)
    Expand ~ and ~user constructs.
    
    If user or $HOME is unknown, do nothing.

help(os.path.expandvars)
Help on function expandvars in module ntpath:

expandvars(path)
    Expand shell variables of the forms $var, ${var} and %var%.
    
    Unknown variables are left unchanged.

the right code may be:

userDir = os.path.expandvars(os.path.expanduser('~'))

----------
components: IDLE
messages: 198210
nosy: weizhao
priority: normal
severity: normal
status: open
title: problems with pyshell to get userdir
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Sep 21 21:22:28 2013
From: report at bugs.python.org (Florian Apolloner)
Date: Sat, 21 Sep 2013 19:22:28 +0000
Subject: [New-bugs-announce] [issue19063] Python 3.3.3 encodes emails
	containing non-ascii data as	7bit
Message-ID: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>


New submission from Florian Apolloner:

Take the following example:

>>> from email.mime.nonmultipart import *
>>> from email.charset import *
>>> msg = MIMENonMultipart('text', 'plain')
>>> cs = Charset('utf-8')
>>> cs.body_encoding = None
>>> msg.set_payload('? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.', cs)
>>> msg.as_string()
'MIME-Version: 1.0\nContent-Type: text/plain; charset="utf-8"\nContent-Transfer-Encoding: 7bit\n\n? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.'

Till python 3.3.2 this created the email as 8bit, which is in line with what Thunderbird creates on my box. And if I understand the RFC correctly (https://tools.ietf.org/html/rfc2045#section-2.7) 7bit should only be used for ASCII. This issue was introduced by http://hg.python.org/cpython/rev/64e004737837 -- I changed orig = msg.get_payload(decode=True) back to it's original value (decode=False) in encode_7or8bit and get the "correct" behavior again. Running the tests didn't cause any errors (I hope I ran the correct one).

----------
components: Library (Lib)
messages: 198217
nosy: apollo13
priority: normal
severity: normal
status: open
title: Python 3.3.3  encodes emails containing non-ascii data as 7bit
versions: Python 3.3

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

From report at bugs.python.org  Sat Sep 21 23:05:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Sep 2013 21:05:42 +0000
Subject: [New-bugs-announce] [issue19064] can't run py3 benchmarks
Message-ID: <1379797542.04.0.297069856882.issue19064@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

After the latest changes I don't understand how I'm supposed to run translated Python 3 benchmarks:

$ ./perf.py -fb mako_v2 ../opt/python ../x32opt/python 
Running mako_v2...
INFO:root:Running ../x32opt/python ./performance/bm_mako_v2.py -n 50
Traceback (most recent call last):
  File "./perf.py", line 2460, in <module>
    main(sys.argv[1:])
  File "./perf.py", line 2416, in main
    options)))
  File "./perf.py", line 1528, in BM_mako_v2
    return SimpleBenchmark(MeasureMakoV2, *args, **kwargs)
  File "./perf.py", line 714, in SimpleBenchmark
    *args, **kwargs)
  File "./perf.py", line 1524, in MeasureMakoV2
    iteration_scaling=10)
  File "./perf.py", line 1113, in MeasureGeneric
    inherit_env=options.inherit_env)
  File "./perf.py", line 1071, in CallAndCaptureOutput
    raise RuntimeError("Benchmark died: " + stderr.decode('latin1'))
RuntimeError: Benchmark died: Traceback (most recent call last):
  File "./performance/bm_mako_v2.py", line 26, in <module>
    from mako.template import Template
  File "/home/antoine/cpython/benchmarks/lib/Mako-0.7.3/mako/template.py", line 622
    exec code in module.__dict__, module.__dict__
            ^
SyntaxError: invalid syntax

----------
assignee: brett.cannon
components: Benchmarks
messages: 198224
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: can't run py3 benchmarks
versions: 3rd party

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

From report at bugs.python.org  Sun Sep 22 02:03:21 2013
From: report at bugs.python.org (Chris Adams)
Date: Sun, 22 Sep 2013 00:03:21 +0000
Subject: [New-bugs-announce] [issue19065] sqlite3 timestamp adapter chokes
	on timezones
Message-ID: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za>


New submission from Chris Adams:

If you use detect_types=sqlite3.PARSE_DECLTYPES with sqlite3 and insert a timezone-aware datetime instance, you will get a ValueError if you attempt to read it back out: 

 File "/usr/local/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/sqlite3/dbapi2.py", line 68, in convert_timestamp
    hours, minutes, seconds = map(int, timepart_full[0].split(b":"))
ValueError: invalid literal for int() with base 10: '03+00'

Although this immediately gets into the thorny stdlib timezone support situation, it's extremely annoying to have the out-of-the-box module break round-tripping data and it looks like support for simple UTC offsets isn't too horrible ? something like https://gist.github.com/acdha/6655391 works in very limited testing:

def tz_aware_timestamp_adapter(val):
    datepart, timepart = val.split(b" ")
    year, month, day = map(int, datepart.split(b"-"))

    if b"+" in timepart:
        timepart, tz_offset = timepart.rsplit(b"+", 1)
        if tz_offset == b'00:00':
            tzinfo = datetime.timezone.utc
        else:
            hours, minutes = map(int, tz_offset.split(b':', 1))
            tzinfo = datetime.timezone(datetime.timedelta(hours=hours, minutes=minutes))
    else:
        tzinfo = None

    timepart_full = timepart.split(b".")
    hours, minutes, seconds = map(int, timepart_full[0].split(b":"))

    if len(timepart_full) == 2:
        microseconds = int('{:0<6.6}'.format(timepart_full[1].decode()))
    else:
        microseconds = 0

    val = datetime.datetime(year, month, day, hours, minutes, seconds, microseconds, tzinfo)

    return val

sqlite3.register_converter('timestamp', tz_aware_timestamp_adapter)

----------
components: Library (Lib)
messages: 198234
nosy: acdha
priority: normal
severity: normal
status: open
title: sqlite3 timestamp adapter chokes on timezones
versions: Python 3.3

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

From report at bugs.python.org  Sun Sep 22 04:21:28 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 02:21:28 +0000
Subject: [New-bugs-announce] [issue19066] os.execv fails with spaced names
	on Windows
Message-ID: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

If file to be executed with os.execv on Windows is located in directory with spaces, Python fails. This doesn't fail on Linux. To test, run:

  testexecv.py spaced

testexecv.py is attached.

----------
components: Library (Lib), Windows
files: testexecv.py
messages: 198242
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.execv fails with spaced names on  Windows
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31837/testexecv.py

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

From report at bugs.python.org  Sun Sep 22 09:01:15 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 22 Sep 2013 07:01:15 +0000
Subject: [New-bugs-announce] [issue19067] Built-in range docstrings are not
	PEP-8 compatible
Message-ID: <1379833275.25.0.770459256521.issue19067@psf.upfronthosting.co.za>


New submission from Marco Buttu:

The range documentation is not PEP-8 compatible:

>>> range.__doc__.splitlines()[-1]
'Returns a virtual sequence of numbers from start to stop by step.'
>>> range.__reversed__.__doc__
'Returns a reverse iterator.'
>>> range.index.__doc__.splitlines()[-1]
'Raises ValueError if the value is not present.'

They should have been 'Return...' and 'Raise...'. Patch is attached

----------
assignee: docs at python
components: Documentation
files: rangeobject.patch
keywords: patch
messages: 198244
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Built-in range docstrings are not PEP-8 compatible
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31838/rangeobject.patch

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

From report at bugs.python.org  Sun Sep 22 09:09:02 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 22 Sep 2013 07:09:02 +0000
Subject: [New-bugs-announce] [issue19068] Some built-in complex docstrings
	are not PEP-8 compatible
Message-ID: <1379833742.32.0.289149108308.issue19068@psf.upfronthosting.co.za>


New submission from Marco Buttu:

As reported in the title: 

>>> complex.conjugate.__doc__.splitlines()[-1]
'Returns the complex conjugate of its argument. (3-4j).conjugate() == 3+4j.'
>>> complex.__format__.__doc__.splitlines()[-1]
'Converts to a string according to format_spec.'

They should have been 'Return...' and 'Convert...'. Patch is attached

----------
assignee: docs at python
components: Documentation
files: complexobject.patch
keywords: patch
messages: 198245
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Some built-in complex docstrings are not PEP-8 compatible
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31839/complexobject.patch

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

From report at bugs.python.org  Sun Sep 22 09:18:11 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 22 Sep 2013 07:18:11 +0000
Subject: [New-bugs-announce] [issue19069] Built-in float docstrings are not
	PEP-8 compatible
Message-ID: <1379834291.01.0.660875879281.issue19069@psf.upfronthosting.co.za>


New submission from Marco Buttu:

As reported in the title: 

>>> float.as_integer_ratio.__doc__.splitlines()[2]
'Returns a pair of integers, whose ratio is exactly equal to the original'
>>> float.as_integer_ratio.__doc__.splitlines()[4]
'Raises OverflowError on infinities and a ValueError on NaNs.'
>>> float.conjugate.__doc__
'Returns self, the complex conjugate of any float.'
>>> float.is_integer.__doc__
'Returns True if the float is an integer.'
>>> float.__setformat__.__doc__.splitlines()[-2]
'Overrides the automatic determination of C-level floating point type.'
...

They should have been 'Return...', 'Raise...' and 'Override...'
Patch is attached

----------
assignee: docs at python
components: Documentation
files: floatobject.patch
keywords: patch
messages: 198246
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Built-in float docstrings are not PEP-8 compatible
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31840/floatobject.patch

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

From report at bugs.python.org  Sun Sep 22 12:35:43 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 22 Sep 2013 10:35:43 +0000
Subject: [New-bugs-announce] [issue19070] In place operators of
	weakref.proxy() not returning self.
Message-ID: <1379846143.45.0.326809671068.issue19070@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

When a weakref.proxy() is used to wrap a class instance which implements in place operators, when one applies the in place operator to the proxy, one could argue the variable holding the proxy should still be a reference to the proxy after the in place operator has been done. Instead the variable is replaced with the class instance the proxy was wrapping.

So for the code:

from __future__ import print_function

import weakref

class Class(object):
     def __init__(self, value):
         self.value = value
     def __iadd__(self, value):
         self.value += value
         return self

c = Class(1)

p = weakref.proxy(c)

print('p.value', p.value)
print('type(p)', type(p))

p += 1

print('p.value', p.value)
print('type(p)', type(p))

one gets:

$ python3.3 weakproxytest.py
p.value 1
type(p) <class 'weakproxy'>
p.value 2
type(p) <class '__main__.Class'>

One might expect type(p) at the end to still be <class 'weakproxy'>.

In the weakref.proxy() C code, all the operators are set up with preprocessor macros.

#define WRAP_BINARY(method, generic) \
    static PyObject * \
    method(PyObject *x, PyObject *y) { \
        UNWRAP(x); \
        UNWRAP(y); \
        return generic(x, y); \
    }

#define WRAP_TERNARY(method, generic) \
    static PyObject * \
    method(PyObject *proxy, PyObject *v, PyObject *w) { \
        UNWRAP(proxy); \
        UNWRAP(v); \
        if (w != NULL) \
            UNWRAP(w); \
        return generic(proxy, v, w); \
    }

These are fine for:

WRAP_BINARY(proxy_add, PyNumber_Add)
WRAP_BINARY(proxy_sub, PyNumber_Subtract)
WRAP_BINARY(proxy_mul, PyNumber_Multiply)
WRAP_BINARY(proxy_div, PyNumber_Divide)
WRAP_BINARY(proxy_floor_div, PyNumber_FloorDivide)
WRAP_BINARY(proxy_true_div, PyNumber_TrueDivide)
WRAP_BINARY(proxy_mod, PyNumber_Remainder)
WRAP_BINARY(proxy_divmod, PyNumber_Divmod)
WRAP_TERNARY(proxy_pow, PyNumber_Power)
WRAP_BINARY(proxy_lshift, PyNumber_Lshift)
WRAP_BINARY(proxy_rshift, PyNumber_Rshift)
WRAP_BINARY(proxy_and, PyNumber_And)
WRAP_BINARY(proxy_xor, PyNumber_Xor)
WRAP_BINARY(proxy_or, PyNumber_Or)

Because a result is being returned and the original is not modified.

Use of those macros gives the unexpected result for:

WRAP_BINARY(proxy_iadd, PyNumber_InPlaceAdd)
WRAP_BINARY(proxy_isub, PyNumber_InPlaceSubtract)
WRAP_BINARY(proxy_imul, PyNumber_InPlaceMultiply)
WRAP_BINARY(proxy_idiv, PyNumber_InPlaceDivide)
WRAP_BINARY(proxy_ifloor_div, PyNumber_InPlaceFloorDivide)
WRAP_BINARY(proxy_itrue_div, PyNumber_InPlaceTrueDivide)
WRAP_BINARY(proxy_imod, PyNumber_InPlaceRemainder)
WRAP_TERNARY(proxy_ipow, PyNumber_InPlacePower)
WRAP_BINARY(proxy_ilshift, PyNumber_InPlaceLshift)
WRAP_BINARY(proxy_irshift, PyNumber_InPlaceRshift)
WRAP_BINARY(proxy_iand, PyNumber_InPlaceAnd)
WRAP_BINARY(proxy_ixor, PyNumber_InPlaceXor)
WRAP_BINARY(proxy_ior, PyNumber_InPlaceOr)

This is because the macro returns the result from the API call, such as PyNumber_InPlaceAdd() where as it should notionally be returning 'proxy' so that the variable holding the weakref proxy instance is set to the proxy object again and not the result of the inner API call.

In changing this though there is a complication which one would have to deal with.

If the result of the inner API call such as PyNumber_InPlaceAdd() is the same as the original object wrapped by the weakref proxy, then all is fine.

What though should be done if it is different as notionally this means that the reference to the wrapped object would need to be changed to the new value.

The issue is that if one had to replace the reference to the wrapped object with a different one due to the in place operator, then notionally the whole existence of that weakref is invalidated as you would no longer be tracking the same object the weakref proxy was created for.

This odd situation is perhaps why the code was originally written the way it was, although that then sees the weakref proxy being replaced which could cause different problems with the callback not later being called since the weakref proxy can be destroyed before the object it wrapped. As there is nothing in the documentation of the code which calls out such a decision, not sure if it was deliberate or simply an oversight.

Overall I am not completely sure what the answer should be, so I am logging it as interesting behaviour. Maybe this odd case needs to be called out in the documentation in some way at least. That or in place operators simply shouldn't be allowed on a weakref proxy because of the issues it can cause either way.

----------
components: Library (Lib)
messages: 198257
nosy: grahamd
priority: normal
severity: normal
status: open
title: In place operators of weakref.proxy() not returning self.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Sep 22 13:39:56 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 22 Sep 2013 11:39:56 +0000
Subject: [New-bugs-announce] [issue19071] Documentation on what self is for
	module-level functions	is misleading/wrong.
Message-ID: <1379849996.18.0.35390897499.issue19071@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

In the documentation for Python 2.X at:

http://docs.python.org/2/extending/extending.html#a-simple-example

it says:

"""
The self argument points to the module object for module-level functions; for a method it would point to the object instance.
"""

In respect of module-level functions this is misleading or arguably wrong.

If one uses Py_InitModule() or Py_InitModule3(), then self is actually passed through as NULL for module-level functions in Python 2.

There is a caveat on use of Py_InitModule4() which used to be mentioned in documentation for Python 2.6 at:

http://docs.python.org/release/2.6.7/c-api/structures.html#METH_VARARGS

where it says:

"""
This is the typical calling convention, where the methods have the type PyCFunction. The function expects two PyObject* values. The first one is the self object for methods; for module functions, it has the value given to Py_InitModule4() (or NULL if Py_InitModule() was used).
"""

Although one can supply a special argument to Py_InitModule4() which will be supplied as self, this still isn't the module object and in fact the module object for the module will not even exist at the point Py_InitModule4() is called so it is not possible to pass it in. Plus within the init function of an extension, the module object is not that which would end up being used in a specific interpreter due to how the init function is only called once and a copy then made of the module for each interpreter.

This actual page in the documentation was changed in Python 2.7 and now in:

http://docs.python.org/2/c-api/structures.html#METH_VARARGS

says:

"""
The function expects two PyObject* values. The first one is the self object for methods; for module functions, it is the module object.
"""

So the reference to Py_InitModule4() was removed and simply says that module object is supplied, which isn't actually the case.

Now, that NULL is always passed for Py_InitModule() and Py_InitModule3() is the case with Python 2. In Python 3 at some point, the code in Python internals was changed so the module object is actually passed as documented.

So, maybe the intent was that when in Python 3 the code was changed to pass the module object to module-level functions that it be back ported to Python 2.7 and the documentation so changed, but looks like that back porting was never done, or if it was, it has been broken somewhere along the way.

Code used to verify this is all attached.

If compiled and installed for Python 3 one gets:

>>> import mymodule._extension
>>> id(mymodule._extension)
4480540328
>>> mymodule._extension.function()
<module 'mymodule._extension' from '/Users/graham/Projects/python-c-extension-template/lib/python3.3/site-packages/mymodule/_extension.so'>
>>> id(mymodule._extension.function())
4480540328

If compiled and installed for Python 2.7 one gets:

>>> import mymodule._extension
>>> id(mymodule._extension)
4554745960
>>> mymodule._extension.function()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: no module supplied for self

The function in the extension module was doing:

static PyObject *extension_function(PyObject *self, PyObject *args)
{
    if (!self) {
        PyErr_SetString(PyExc_TypeError, "no module supplied for self");
        return NULL;
    }

    Py_INCREF(self);
    return self;
}

----------
assignee: docs at python
components: Documentation
files: example.tar
messages: 198265
nosy: docs at python, grahamd
priority: normal
severity: normal
status: open
title: Documentation on what self is for module-level functions is misleading/wrong.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31841/example.tar

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

From report at bugs.python.org  Sun Sep 22 15:22:44 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 22 Sep 2013 13:22:44 +0000
Subject: [New-bugs-announce] [issue19072] classmethod doesn't honour
	descriptor protocol of	wrapped callable
Message-ID: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

The classmethod decorator when applied to a function of a class, does not honour the descriptor binding protocol for whatever it wraps. This means it will fail when applied around a function which has a decorator already applied to it and where that decorator expects that the descriptor binding protocol is executed in order to properly bind the function to the class.

A decorator may want to do this where it is implemented so as to be able to determine automatically the context it is used in. That is, one magic decorator that can work around functions, instance methods, class methods and classes, thereby avoiding the need to have multiple distinct decorator implementations for the different use case.

So in the following example code:

class BoundWrapper(object):
    def __init__(self, wrapped):
        self.__wrapped__ = wrapped
    def __call__(self, *args, **kwargs):
        print('BoundWrapper.__call__()', args, kwargs)
        print('__wrapped__.__self__', self.__wrapped__.__self__)
        return self.__wrapped__(*args, **kwargs)

class Wrapper(object):
    def __init__(self, wrapped):
        self.__wrapped__ = wrapped
    def __get__(self, instance, owner):
        bound_function = self.__wrapped__.__get__(instance, owner)
        return BoundWrapper(bound_function)

def decorator(wrapped):
    return Wrapper(wrapped)

class Class(object):
    @decorator
    def function_im(self):
        print('Class.function_im()', self)

    @decorator
    @classmethod
    def function_cm_inner(cls):
        print('Class.function_cm_inner()', cls)

    @classmethod
    @decorator
    def function_cm_outer(cls):
        print('Class.function_cm_outer()', cls)

c = Class()

c.function_im()
print()
Class.function_cm_inner()
print()
Class.function_cm_outer()

A failure is encountered of:

$ python3.3 cmgettest.py
BoundWrapper.__call__() () {}
__wrapped__.__self__ <__main__.Class object at 0x1029fc150>
Class.function_im() <__main__.Class object at 0x1029fc150>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

Traceback (most recent call last):
  File "cmgettest.py", line 40, in <module>
    Class.function_cm_outer()
TypeError: 'Wrapper' object is not callable

IOW, everything is fine when the decorator is applied around the classmethod, but when it is placed inside of the classmethod, a failure occurs because the decorator object is not callable.

One could argue that the error is easily avoided by adding a __call__() method to the Wrapper class, but that defeats the purpose of what is trying to be achieved in using this pattern. That is that one can within the bound wrapper after binding occurs, determine from the __self__ of the bound function, the fact that it was a class method. This can be inferred from the fact that __self__ is a class type.

If the classmethod decorator tp_descr_get implementation is changed so as to properly apply the descriptor binding protocol to the wrapped object, then what is being described is possible.

Having it honour the descriptor binding protocol also seems to make application of the Python object model more consistent.

A patch is attached which does exactly this.

The result for the above test after the patch is applied is:

BoundWrapper.__call__() () {}
__wrapped__.__self__ <__main__.Class object at 0x10ad237d0>
Class.function_im() <__main__.Class object at 0x10ad237d0>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_outer() <class '__main__.Class'>

That is, the decorator whether it is inside or outside now sees things in the same way.

If one also tests for calling of the classmethod via the instance:

print()
c.function_cm_inner()
print()
c.function_cm_outer()

Everything again also works out how want it:

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_outer() <class '__main__.Class'>

FWIW, the shortcoming of classmethod not applying the descriptor binding protocol to the wrapped object, was found in writing a new object proxy and decorator library called 'wrapt'. This issue in the classmethod implementation is the one thing that has prevented wrapt having a system of writing decorators that can magically work out the context it is used in all the time. Would be nice to see it fixed. :-)

The wrapt library can be found at:

https://github.com/GrahamDumpleton/wrapt
http://wrapt.readthedocs.org

The limitation in the classmethod implementation is noted in the wrapt documentation at:

http://wrapt.readthedocs.org/en/v1.1.2/issues.html#classmethod-get

----------
components: Interpreter Core
files: funcobject.c.diff
keywords: patch
messages: 198274
nosy: grahamd
priority: normal
severity: normal
status: open
title: classmethod doesn't honour descriptor protocol of wrapped callable
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file31842/funcobject.c.diff

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

From report at bugs.python.org  Sun Sep 22 15:37:01 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 22 Sep 2013 13:37:01 +0000
Subject: [New-bugs-announce] [issue19073] Inability to specific __qualname__
	as a property on a	class instance.
Message-ID: <1379857021.17.0.738971350638.issue19073@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

Python 3 introduced __qualname__. This attribute exists on class types and also instances of certain class types, such as functions. For example:

def f(): pass

print(f.__name__)
print(f.__qualname__)

class Class: pass

print(Class.__name__)
print(Class.__qualname__)

yields:

f
f
Class
Class

An instance of a class however does not have __name__ or __qualname__ attributes. With:

c = Class()

print(c.__name__)
print(c.__qualname__)

yielding:

Traceback (most recent call last):
  File "qualnametest.py", line 13, in <module>
    print(c.__name__)
AttributeError: 'Class' object has no attribute '__name__'

Traceback (most recent call last):
  File "qualnametest.py", line 14, in <module>
    print(c.__qualname__)
AttributeError: 'Class' object has no attribute '__qualname__'

For a class, it is possible to override the __name__ attribute using a property.

class Class:
    @property
    def __name__(self):
        return 'override'

c = Class()

print(c.__name__)

With the result being:

override

This is useful in writing object proxies or function wrappers for decorators as rather than having to copy the __name__ attribute into the wrapper, the lookup can be deferred until when it is required.

The same though cannot be done for __qualname__. With:

class Class:
    @property
    def __qualname__(self):
        return 'override'

yielding an error when the class definition is being processed:

Traceback (most recent call last):
  File "qualnametest.py", line 16, in <module>
    class Class:
TypeError: type __qualname__ must be a str, not property

This means the same trick cannot be used in object proxies and function wrappers and instead __qualname__ must be copied and assigned explicitly as a string attribute in the __init__() function of the object proxy or function wrapper.

I can sort of understand a prohibition on __qualname__ being a string attribute in certain cases, especially if overriding it on a type or instance where __qualname__ attribute already exists, but I don't understand why a limitation would be imposed to prevent using a property as a means of generating the value for a class instance which doesn't otherwise have a __qualname__ attribute. There is no similar restriction for __name__.

Unless there is a good specific reason for this behaviour, the ability to override it with a property in cases where the __qualname__ attribute didn't already exist, would be handy for proxies and wrappers.

----------
components: Interpreter Core
messages: 198275
nosy: grahamd
priority: normal
severity: normal
status: open
title: Inability to specific __qualname__ as a property on a class instance.
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Sep 22 16:16:17 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 14:16:17 +0000
Subject: [New-bugs-announce] [issue19074] Add PySide to GUI FAQ
Message-ID: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/2/faq/gui.html - this page misses info about PySide.

----------
assignee: docs at python
components: Documentation
messages: 198279
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Add PySide to GUI FAQ
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Sep 22 20:02:22 2013
From: report at bugs.python.org (Jason Yeo)
Date: Sun, 22 Sep 2013 18:02:22 +0000
Subject: [New-bugs-announce] [issue19075] Add sorting algorithm
	visualization to turtledemo
Message-ID: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za>


New submission from Jason Yeo:

My university uses python to teach sorting algorithms. It will be great if the turtledemo comes with a visualization of some of the algorithms. I have attached a patch for it.

----------
components: Demos and Tools
files: animation.diff
keywords: patch
messages: 198295
nosy: Jason.Yeo
priority: normal
severity: normal
status: open
title: Add sorting algorithm visualization to turtledemo
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file31845/animation.diff

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

From report at bugs.python.org  Mon Sep 23 02:29:21 2013
From: report at bugs.python.org (Michael Smith)
Date: Mon, 23 Sep 2013 00:29:21 +0000
Subject: [New-bugs-announce] [issue19076] Pdb.do_break calls error with
	obsolete file kwarg
Message-ID: <1379896161.02.0.342769344307.issue19076@psf.upfronthosting.co.za>


New submission from Michael Smith:

Pretty straightforward:

File "/usr/local/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/pdb.py", line 675, in do_break
    self.error(err, file=self.stdout)
TypeError: error() got an unexpected keyword argument 'file'

Sure enough, line 675 reads:
                self.error(err, file=self.stdout)

but line 448:
    def error(self, msg):

----------
components: Extension Modules
messages: 198309
nosy: Michael.Smith
priority: normal
severity: normal
status: open
title: Pdb.do_break calls error with obsolete file kwarg
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 23 16:58:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 14:58:46 +0000
Subject: [New-bugs-announce] [issue19077] More robust TemporaryDirectory
	cleanup
Message-ID: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch solves the problem with TemporaryDirectory cleanup. If shutil.rmtree() failed because module globals are set to None, TemporaryDirectory now uses own rmtree implementation which does not depends from globals. The patch also fixes other minor problems related to __del__ and fixes do_create() in tests (it deleted subdirectories just after creation).

See also issue10188.

----------
components: Library (Lib)
files: tempfile_tempdir_cleanup.patch
keywords: patch
messages: 198321
nosy: georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: More robust TemporaryDirectory cleanup
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31848/tempfile_tempdir_cleanup.patch

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

From report at bugs.python.org  Mon Sep 23 18:27:16 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 23 Sep 2013 16:27:16 +0000
Subject: [New-bugs-announce] [issue19078] Allow reversed(memoryview),
	like memoryview[::-1]
Message-ID: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello. The following seems a little weird:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32
>>> m = memoryview(b'123')
>>> list(m[::-1])
[51, 50, 49]
>>> list(reversed(m))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object of type 'memoryview' has no len()
>>>

The attached patch allows `reversed` to be called with memoryviews and it could potentially fix issue18690.

----------
components: Interpreter Core
files: memoryview.patch
keywords: patch
messages: 198324
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Allow reversed(memoryview), like memoryview[::-1]
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31850/memoryview.patch

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

From report at bugs.python.org  Mon Sep 23 21:42:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 19:42:22 +0000
Subject: [New-bugs-announce] [issue19079] chameleon benchmark fails on 3.4
Message-ID: <1379965342.66.0.0193650788884.issue19079@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Not sure what to do about this, but it seems the bundled Chameleon lib doesn't work on 3.4:

RuntimeError: Benchmark died: Traceback (most recent call last):
  File "./performance/bm_chameleon.py", line 38, in <module>
    util.run_benchmark(options, options.num_runs, main)
  File "/home/antoine/cpython/benchmarks/performance/util.py", line 30, in run_benchmark
    data = bench_func(num_runs, *args)
  File "./performance/bm_chameleon.py", line 19, in main
    tmpl = PageTemplate(BIGTABLE_ZPT)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/zpt/template.py", line 163, in __init__
    super(PageTemplate, self).__init__(body, **config)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 117, in __init__
    self.write(body)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 208, in write
    self.cook(body)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 147, in cook
    program = self._cook(body, digest, names)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 218, in _cook
    source = self._make(body, builtins)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 251, in _make
    return self._compile(module, builtins)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 245, in _compile
    compiler = Compiler(self.engine, program, builtins, strict=self.strict)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/compiler.py", line 886, in __init__
    generator = TemplateCodeGenerator(module)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 107, in __init__
    super(TemplateCodeGenerator, self).__init__(tree)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 172, in __init__
    self.visit(tree)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 110, in visit_Module
    super(TemplateCodeGenerator, self).visit_Module(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 239, in visit_Module
    self.visit(n)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 290, in visit_FunctionDef
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 290, in visit_FunctionDef
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 371, in visit_For
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 371, in visit_For
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 458, in visit_Try
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 403, in visit_If
    self.visit(node.test)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 621, in _f
    f(self, node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 763, in visit_Compare
    self.visit(comparator)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 231, in visit
    node.__class__.__name__, repr(node)))
Exception: No handler for ``NameConstant`` (<_ast.NameConstant object at 0x7f4a6a733dd8>).

----------
components: Benchmarks
messages: 198330
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: chameleon benchmark fails on 3.4
versions: 3rd party

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

From report at bugs.python.org  Mon Sep 23 22:42:05 2013
From: report at bugs.python.org (alon horev)
Date: Mon, 23 Sep 2013 20:42:05 +0000
Subject: [New-bugs-announce] [issue19080] Enrich SyntaxError with additional
	information
Message-ID: <1379968925.72.0.669299760684.issue19080@psf.upfronthosting.co.za>


New submission from alon horev:

Some context for this feature request:
I'm using the wonderful ast module for a library that translates python code to MongoDB queries (https://github.com/alonho/pql). I also did the same for SQL queries using sqlalchemy as a part of another project (https://github.com/alonho/pytrace).

One of the things I find lacking in python's parser is additional information about SyntaxErrors. This could help users of the 'ast' module, IDE and developers.

Here are some examples of what I'd like to see
1. ast.parse('* 2') -> SyntaxError('Unexpected operator at start of an expression')
2. ast.parse('2 *') -> SyntaxError('Missing right hand side operand')
3. ast.parse('if a = 1: pass') -> SyntaxError('Cannot assign inside an expression')

There are several challenges here:
1. Does the parser have this information and doesn't surface it?
2. Can such messages be automatically generated without filling the code with error handling code? 3. Which part of the code could be responsible for this kind of a task? I've looked at the BNF and it contains more than just syntax legality but operator precedence and such. Perhaps there's another (simpler) grammar definition somewhere?

I was curious to see what Ruby does, and it uses a simple solution of providing raw information along with the exception:
>> a == * 1
SyntaxError: compile error
(irb):17: syntax error, unexpected tSTAR
a == * 1
      ^
	from (irb):17

----------
components: Interpreter Core
messages: 198341
nosy: alonho
priority: normal
severity: normal
status: open
title: Enrich SyntaxError with additional information
type: enhancement

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

From report at bugs.python.org  Tue Sep 24 06:00:03 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 24 Sep 2013 04:00:03 +0000
Subject: [New-bugs-announce] [issue19081] zipimport behaves badly when the
	zip file changes while	the process is running
Message-ID: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

If you are

1) using zipimport
2) zipimport.c has cached the zip file's central index during an import.
3) the .zip file is modified or replaced while the process is running
4) you try to import something new from that .zip file.

you're gonna have a bad time... Typically a ZipImportError or some other form of ImportError.

What happen's is that Modules/zipimport.c is caching the end-of-zipfile central index for the .zip file and reusing that data on subsequent imports from that .zip without either (a) keeping the file handle open or (b) confirming that the .zip file has not changed.

I doubt many users are running into this.  But one situation where you do is when you zip up the Python standard library for your installed python and a long running process encounters data using a different encoding which triggers an import of an encodings.foo module after another process has come along and upgraded the standard library .zip file as part of updating your python installation...

I've got a fix in the works.  Test attached.

For the fix I am going with option (b) to reconfirm the validity of the .zip file any time something is imported from it rather than option (a) as leaving a new file handle open for the duration of the process, while the _correct ideal design_ seems intrusive for stable bug fix release.

I have only confirmed the bug on Python 2.7 & 3.3; i'll test default (3.4) after working on those two.

----------
assignee: gregory.p.smith
files: zipimport_modify_zip_test.patch
keywords: patch
messages: 198351
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: zipimport behaves badly when the zip file changes while the process is running
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31854/zipimport_modify_zip_test.patch

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

From report at bugs.python.org  Tue Sep 24 16:48:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 24 Sep 2013 14:48:46 +0000
Subject: [New-bugs-announce] [issue19082] Lib/xmlrpc/client.py demo code
	points to the dead server
Message-ID: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Lib/xmlrpc/client.py tries to connect to http://time.xmlrpc.com/RPC2 which has been dead for a "while". I see there is no light in the end of tunnel. Since this code is meant to be a demo not a general purpose tool, I say why don't we direct it to localhost (which can be provided by Lib/xmlrpc/server.py).

After applying this patch, you can start the server:
$ python Lib/xmlrpc/server.py
Serving XML-RPC on localhost port 8000

Then in another place, you can start the client and get result straight away:
$ python Lib/xmlrpc/client.py
2013-09-24T22:35:27
2013-09-24T22:35:27
512
3

Isn't that beautiful?

----------
components: Library (Lib)
files: xmlrpc_server_client_demo.patch
keywords: patch
messages: 198359
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Lib/xmlrpc/client.py demo code points to the dead server
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31856/xmlrpc_server_client_demo.patch

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

From report at bugs.python.org  Tue Sep 24 17:20:51 2013
From: report at bugs.python.org (Pepijn de Vos)
Date: Tue, 24 Sep 2013 15:20:51 +0000
Subject: [New-bugs-announce] [issue19083] IDNA prefix should be case
	insensitive
Message-ID: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>


New submission from Pepijn de Vos:

RFC 3490 states that "The ACE prefix for IDNA is "xn--" or any capitalization thereof."

But the following does not work

>>> str(b"XN--pythn-mua.org.", "idna")

----------
components: Library (Lib)
files: upper-idna.patch
keywords: patch
messages: 198360
nosy: Pepijn.de.Vos
priority: normal
severity: normal
status: open
title: IDNA prefix should be case insensitive
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file31858/upper-idna.patch

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

From report at bugs.python.org  Tue Sep 24 17:32:28 2013
From: report at bugs.python.org (Karl Palsson)
Date: Tue, 24 Sep 2013 15:32:28 +0000
Subject: [New-bugs-announce] [issue19084] No way to use TLS-PSK from python
	ssl
Message-ID: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za>


New submission from Karl Palsson:

OpenSSL supports TLS-PSK which some people (myself obviously) find to be substantially easier to use than setting up certs.

However, there's no way to use PSK via the current SSL api in python.  It would be very nice to be able to use PSK from python.

For OpenSSL, even the C API is particularly easy.  Attached is the implementation used in Mosquitto, a MQTT message broker that supports both cert based and PSK based TLS.

----------
components: Library (Lib)
files: 5bcfpEKD.txt
messages: 198362
nosy: karlp
priority: normal
severity: normal
status: open
title: No way to use TLS-PSK from python ssl
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file31859/5bcfpEKD.txt

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

From report at bugs.python.org  Tue Sep 24 22:30:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Sep 2013 20:30:32 +0000
Subject: [New-bugs-announce] [issue19085] Add tkinter basic options tests
Message-ID: <1380054632.03.0.105033569087.issue19085@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds tests for all options of all widgets. They test that widgets support all documented options, accepts valid values in different formats, reject invalid values, and return values in expected format. This would be helpful for regression testing.

The patch tested with Tcl/Tk 8.5 and 8.6 on Linux. All new tests are compatible with wantobjects=1 and wantobjects=0.

It will be good to test it with Tcl/Tk 8.4 (or even 8.3) and on Windows.

----------
components: Tests, Tkinter
files: tkinter_options_tests.patch
keywords: patch
messages: 198366
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Add tkinter basic options tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31861/tkinter_options_tests.patch

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

From report at bugs.python.org  Wed Sep 25 12:46:10 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Wed, 25 Sep 2013 10:46:10 +0000
Subject: [New-bugs-announce] [issue19086] Make fsum usable incrementally.
Message-ID: <1380105970.25.0.603787186965.issue19086@psf.upfronthosting.co.za>


New submission from Oscar Benjamin:

I would like to be able use fsum incrementally however it is not currently possible.

With sum() you can do:

subtotal = sum(nums)
subtotal = sum(othernums, subtotal)

This wouldn't work for fsum() because the returned float is not the same as the state maintained internally which is a list of floats. I propose instead that a fsum() could take an optional second argument which is a list of floats and in this case return the updated list of floats.

I have modified Raymond Hettinger's msum() recipe to do what I want:

def fsum(iterable, carry=None):
    "Full precision summation using multiple floats for intermediate values"
    partials = list(carry) if carry else []
    for x in iterable:
        i = 0
        for y in partials:
            if abs(x) < abs(y):
                x, y = y, x
            hi = x + y
            lo = y - (hi - x)
            if lo:
                partials[i] = lo
                i += 1
            x = hi
        partials[i:] = [x]
    if carry is None:
        return sum(partials, 0.0)
    else:
        return partials


Here's an interactive session showing how you might use it:

>>> from fsum import fsum
>>> fsum([1e20, 1, -1e20])
1.0
>>> fsum([1e20, 1, -1e20], [])
[1.0, 0.0]
>>> fsum([1e20, 1, -1e20], [])
[1.0, 0.0]
>>> fsum([1e20, 1, -1e20], [])
[1.0, 0.0]
>>> fsum([1e20, 1], [])
[1.0, 1e+20]
>>> carry = fsum([1e20, 1], [])
>>> fsum([-1e20], carry)
[1.0, 0.0]
>>> nums = [7, 1e100, -7, -1e100, -9e-20, 8e-20] * 10
>>> subtotal = []
>>> for n in nums:
...     subtotal = fsum([n], subtotal)
...
>>> subtotal
[-1.0000000000000007e-19]
>>> fsum(subtotal)
-1.0000000000000007e-19


My motivation for this is that I want to be able to write an efficient sum function that is accurate for a mix of ints and floats while being as fast as possible in the case that I have a list of only floats (or only ints). What I have so far looks a bit like:

def sum(numbers):
    exact_total = 0
    float_total = 0.0
    for T, nums in groupby(numbers):
        if T is int:
            exact_total = sum(nums, exact_total)
        elif T is float:
            # This doesn't really work:
            float_total += fsum(float_total)
        # ...


However fsum is only exact if it adds all the numbers in a single pass. The above would have order-dependent results given a mixed list of ints and floats e.g.:

[1e20, -1e20, 1, -1, 1.0, -1.0]
  vs
[1e20, 1.0, -1e20, 1, -1, -1.0]

Although fsum is internally very accurate it always discards information on output. Even if I build a list of all floats and fsum those at the end it can still be inaccurate if the exact_total cannot be exactly coerced to float and passed to fsum.

If I could get fsum to return the exact float expansion then I could use that in a number of different ways. Given the partials list I can combine all of the different subtotals with Fraction arithmetic and coerce to float only at the very end. If I can also get fsum to accept a float expansion on input then I can use it incrementally and there is no need to build a list of all floats.

I am prepared to write a patch for this if the idea is deemed acceptable.

----------
components: Library (Lib)
messages: 198381
nosy: mark.dickinson, oscarbenjamin, rhettinger
priority: normal
severity: normal
status: open
title: Make fsum usable incrementally.
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 25 16:03:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Sep 2013 14:03:50 +0000
Subject: [New-bugs-announce] [issue19087] bytearray front-slicing not
	optimized
Message-ID: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you delete a slice at the end of a bytearray, it is naturally optimized (thanks to the resizing strategy). However, if you delete a slice at the front of a bytearray, it is not: a memmove() gets done every time.

$ ./python -m timeit "b=bytearray(10000)" "while b: b[-1:] = b''"
100 loops, best of 3: 5.67 msec per loop
$ ./python -m timeit "b=bytearray(10000)" "while b: b[:1] = b''"
100 loops, best of 3: 6.67 msec per loop

$ ./python -m timeit "b=bytearray(50000)" "while b: b[-1:] = b''"
10 loops, best of 3: 28.3 msec per loop
$ ./python -m timeit "b=bytearray(50000)" "while b: b[:1] = b''"
10 loops, best of 3: 61.1 msec per loop

$ ./python -m timeit "b=bytearray(100000)" "while b: b[-1:] = b''"
10 loops, best of 3: 59.4 msec per loop
$ ./python -m timeit "b=bytearray(100000)" "while b: b[:1] = b''"
10 loops, best of 3: 198 msec per loop

This makes implementing a fifo using bytearray a bit suboptimal. It shouldn't be very hard to improve.

----------
components: Interpreter Core
messages: 198385
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: bytearray front-slicing not optimized
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep 25 16:11:14 2013
From: report at bugs.python.org (Larry Pete)
Date: Wed, 25 Sep 2013 14:11:14 +0000
Subject: [New-bugs-announce] [issue19088] TypeError with pickle in embedded
	python3.3 when	starting multiple Interpreters.
Message-ID: <1380118274.37.0.850286724138.issue19088@psf.upfronthosting.co.za>


New submission from Larry Pete:

Hexchat (fork of XChat IRC Client) switched with version 2.9.6 to Python 3.3 for their Python plugins.
Hexchat loads plugins in a similar fashion like the attached C file (not entirely sure I used the C-API right though). For every plugin a new interpreter is started and Py_EndInterpreter is used to unload the plugin.
When using pickle in such a python plugin, it raises the Exception (in the attached example):

Traceback (most recent call last):
  File "<string>", line 7, in <module>
TypeError: attribute of type 'NoneType' is not callable

when trying to pickle an object (using pickle.dump or pickle.dumps).
The Exception happens on the line where pickle.dumps is called, though pickle.dumps is not None.

It happens:
- with python3.3.2 (I also tested it with python3.4.0a2 since I happened to have it installed, same issue). No issue with python2.7. I did not test it with 3.x versions prior to 3.3.2
- when trying to pickle a user defined class. Python objects like dictionaries and lists work fine.
- only with the second (and any additional) interpreter.
- when destroying the interpreter and starting a new one, in that order. When two interpreters are started and execute the code before any of them is destroyed, it works fine.

The full output of the attached file when executed is btw:

First output:
Pickle dumps:
b'\x80\x03c__main__\nSomeClass\nq\x00)\x81q\x01}q\x02X\x08\x00\x00\x00some_varq\x03K{sb.'

Second output:
Pickle dumps:
Traceback (most recent call last):
  File "<string>", line 7, in <module>
TypeError: attribute of type 'NoneType' is not callable

----------
components: Extension Modules
files: fail.c
messages: 198386
nosy: Larry.Pete, alexandre.vassalotti, pitrou
priority: normal
severity: normal
status: open
title: TypeError with pickle in embedded python3.3 when starting multiple Interpreters.
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31867/fail.c

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

From report at bugs.python.org  Wed Sep 25 18:32:35 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 25 Sep 2013 16:32:35 +0000
Subject: [New-bugs-announce] [issue19089] Windows: Broken Ctrl-D shortcut on
	Python 3
Message-ID: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Ctrl-D shortcut works to terminate session in Python 2 on Windows, and doesn't work with Python 3.

----------
components: Windows
messages: 198393
nosy: techtonik
priority: normal
severity: normal
status: open
title: Windows: Broken Ctrl-D shortcut on Python 3
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 25 20:28:29 2013
From: report at bugs.python.org (Aivar Annamaa)
Date: Wed, 25 Sep 2013 18:28:29 +0000
Subject: [New-bugs-announce] [issue19091] ast.parse gives wrong position for
	some Names when	non-ascii characters occur before
Message-ID: <1380133709.64.0.537787667021.issue19091@psf.upfronthosting.co.za>


New submission from Aivar Annamaa:

ast.parse gives col_offset=4 for Name x when given program "a + x" vs. col_offset=5 for x when Name a is replaced with a-umlaut (I can't write that character here, because it seems that the issue system doesn't handle non-ascii characters either).

See the attached Python shell transcript for explanation (it's in UTF-8).

----------
components: Interpreter Core
files: bug.txt
messages: 198406
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: ast.parse gives wrong position for some Names when non-ascii characters occur before
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31870/bug.txt

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

From report at bugs.python.org  Wed Sep 25 21:09:47 2013
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Wed, 25 Sep 2013 19:09:47 +0000
Subject: [New-bugs-announce] [issue19092] ExitStack.__exit__ incorrectly
	suppresses exceptions in	__exit__ callbacks of inner context
	managers
Message-ID: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i?:

While using contextlib.ExitStack in our project, we noticed that its __exit__ method of contextlib.ExitStack suppresses the exception raised in any contextmanager's __exit__ except the outermost one. Here is a test case to reproduce the problem:

class Err:
  def __enter__(self): pass
  def __exit__(self, *exc): 1/0

class Ok:
  def __enter__(self): pass
  def __exit__(self, *exc): pass


import contextlib
s = contextlib.ExitStack()
s.push(Ok())
s.push(Err())
with s:
  pass

Since the inner context manager raises in __exit__ and neither context manager requests suppression, I would expect to see a ZeroDivisionError raised. What actually happens is that the exception is suppressed. This behavior caused us quite a few headaches before we figured out why we the exceptions raised in during __exit__ went silently undetected in production.

The problem is in ExitStack.__exit__, which explicitly propagates the exception only if it occurs in the outermost exit callback. The idea behind it appears to be to simply record the raised exception in order to allow exit callbacks of the outer context managers to see the it -- and get a chance to suppress it. The only exception that is directly re-raised is the one occurring in the outermost exit callback, because it certainly cannot be seen nor suppressed by anyone else.

But this reasoning is flawed because if an exception happens in an inner cm and none of the outer cm's chooses to suppress it, then there will be no one left to raise it. Simply returning True from ExitStack.__exit__ is of no help, as that only has an effect when an exception was passed into the function in the first place, and even then, the caller can only re-raise the earlier exception, not the exception that occurred in the exit callback. And if no exception was sent to ExitStack.__exit__, as is the case in the above code, then no exception will be re-raised at all, effectively suppressing it.

I believe the correct way to handle this is by keeping track of whether an exception actually occurred in one of the _exit_callbacks. As before, the exception is forwarded to next cm's exit callbacks, but if none of them suppresses it, then the exception is re-raised instead of returning from the function. I am attaching a patch to contextlib.py that implements this change.

The patch also makes sure that True is returned from ExitStack.__exit__ only if an exception was actually passed into it.

----------
components: Library (Lib)
files: exitstack.diff
keywords: patch
messages: 198411
nosy: hniksic
priority: normal
severity: normal
status: open
title: ExitStack.__exit__ incorrectly suppresses exceptions in __exit__ callbacks of inner context managers
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31872/exitstack.diff

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

From report at bugs.python.org  Wed Sep 25 21:30:01 2013
From: report at bugs.python.org (Roman)
Date: Wed, 25 Sep 2013 19:30:01 +0000
Subject: [New-bugs-announce] [issue19093] RE
Message-ID: <2DE46778-8EC6-48FD-A490-6BA930F75E6C@aol.com>


New submission from Roman:

complete my registration

----------
messages: 198412
nosy: bjimnen
priority: normal
severity: normal
status: open
title: RE

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

From report at bugs.python.org  Wed Sep 25 22:55:41 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 25 Sep 2013 20:55:41 +0000
Subject: [New-bugs-announce] [issue19094] urljoin should raise a TypeError
	if URL is not a string
Message-ID: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

>>> import urllib.parse
>>> urllib.parse.urljoin('foo', [])
'foo'

That should raise a TypeError, not succeed quietly as if an empty string were passed.

----------
components: Library (Lib)
messages: 198418
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: urljoin should raise a TypeError if URL is not a string
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep 26 01:33:02 2013
From: report at bugs.python.org (Dariusz Suchojad)
Date: Wed, 25 Sep 2013 23:33:02 +0000
Subject: [New-bugs-announce] [issue19095] Document SSLSocket.getpeercert
	always returns None	without do_handshake
Message-ID: <1380151982.82.0.304891420803.issue19095@psf.upfronthosting.co.za>


New submission from Dariusz Suchojad:

Hello,

I'd like to suggest adding a simple note to SSLSocket.getpeercert stating that it will always return None if do_handshake has never been called.

This is not the default behaviour, by default SSLSocket.__init__'s do_handshake_on_connect is True so .getpeercert nicely returns a cert (assuming the usual caveats - the other side offers a certificate and cert_reqs is not CERT_NONE).

However, I've just been debugging a someone else's server and I spent some time figuring out why client certificates weren't available - turned out this was because do_handshake was never called (PySSL_SSLdo_handshake in _ssl.c).

Adding a single-sentence line will certainly be very helpful.

Many thanks!

----------
assignee: docs at python
components: Documentation
messages: 198425
nosy: docs at python, dsuch
priority: normal
severity: normal
status: open
title: Document SSLSocket.getpeercert always returns None without do_handshake
type: enhancement

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

From report at bugs.python.org  Thu Sep 26 10:53:28 2013
From: report at bugs.python.org (Edward Catmur)
Date: Thu, 26 Sep 2013 08:53:28 +0000
Subject: [New-bugs-announce] [issue19096]
	multiprocessing.Pool._terminate_pool restarts workers	during
	shutdown
Message-ID: <1380185608.1.0.822768887665.issue19096@psf.upfronthosting.co.za>


New submission from Edward Catmur:

There is a race condition in multiprocessing.Pool._terminate_pool that can result in workers being restarted during shutdown (process shutdown or pool.terminate()).

        worker_handler._state = TERMINATE    # <~~~~ race from here
        task_handler._state = TERMINATE

        debug('helping task handler/workers to finish')
        cls._help_stuff_finish(inqueue, task_handler, len(pool))

        assert result_handler.is_alive() or len(cache) == 0

        result_handler._state = TERMINATE
        outqueue.put(None)                  # sentinel

        # We must wait for the worker handler to exit before terminating
        # workers because we don't want workers to be restarted behind our back.
        debug('joining worker handler')
        worker_handler.join()                # <~~~~~ race to here

At any point between setting worker_handler._state = TERMINATE and joining the worker handler, if the intervening code causes a worker to exit then it is possible for the worker handler to fail to notice that it has been shutdown and so attempt to restart the worker:

    @staticmethod
    def _handle_workers(pool):
        thread = threading.current_thread()

        # Keep maintaining workers until the cache gets drained, unless the pool
        # is terminated.
        while thread._state == RUN or (pool._cache and thread._state != TERMINATE):
            # <~~~~~~ race here
            pool._maintain_pool()
            time.sleep(0.1)
        # send sentinel to stop workers
        pool._taskqueue.put(None)
        util.debug('worker handler exiting')

We noticed this initially because in the absence of the fix to #14881 a ThreadPool trying to restart a worker fails and hangs the process.  In the presence of the fix to #14881 there is no immediate issue, but trying to restart a worker process/thread on pool shutdown is clearly unwanted and could result in bad things happening e.g. at process shutdown.

To trigger the race with ThreadPool, it is enough just to pause the _handle_workers thread after checking its state and before calling _maintain_pool:

import multiprocessing.pool
import time
class ThreadPool(multiprocessing.pool.ThreadPool):
    def _maintain_pool(self):
        time.sleep(1)
        super(ThreadPool, self)._maintain_pool()
    def _repopulate_pool(self):
        assert self._state == multiprocessing.pool.RUN
        super(ThreadPool, self)._repopulate_pool()
pool = ThreadPool(4)
pool.map(lambda x: x, range(5))
pool.terminate()
pool.join()

Exception in thread Thread-5:
Traceback (most recent call last):
  File ".../cpython/Lib/threading.py", line 657, in _bootstrap_inner
    self.run()
  File ".../cpython/Lib/threading.py", line 605, in run
    self._target(*self._args, **self._kwargs)
  File ".../cpython/Lib/multiprocessing/pool.py", line 358, in _handle_workers
    pool._maintain_pool()
  File ".../bug.py", line 6, in _maintain_pool
    super(ThreadPool, self)._maintain_pool()
  File ".../cpython/Lib/multiprocessing/pool.py", line 232, in _maintain_pool
    self._repopulate_pool()
  File ".../bug.py", line 8, in _repopulate_pool
    assert self._state == multiprocessing.pool.RUN
AssertionError

In this case, the race occurs when ThreadPool._help_stuff_finish puts sentinels on inqueue to make the workers finish.

It is also possible to trigger the bug with multiprocessing.pool.Pool:

import multiprocessing.pool
import time
class Pool(multiprocessing.pool.Pool):
    def _maintain_pool(self):
        time.sleep(2)
        super(Pool, self)._maintain_pool()
    def _repopulate_pool(self):
        assert self._state == multiprocessing.pool.RUN
        super(Pool, self)._repopulate_pool()
    @staticmethod
    def _handle_tasks(taskqueue, put, outqueue, pool):
        time.sleep(1)
        _real_handle_tasks(taskqueue, put, outqueue, pool)
_real_handle_tasks = multiprocessing.pool.Pool._handle_tasks
multiprocessing.pool.Pool._handle_tasks = Pool._handle_tasks
pool = Pool(4)
pool.map(str, range(10))
pool.map_async(str, range(10))
pool.terminate()
pool.join()

In this case, the race occurs when _handle_tasks checks thread._state, breaks out of its first loop, and sends sentinels to the workers.

The terminate/join can be omitted, in which case the bug will occur at gc or process shutdown when the pool's atexit handler runs.  The bug is avoided if terminate is replaced with close, and we are using this workaround.

----------
components: Library (Lib)
messages: 198432
nosy: ecatmur
priority: normal
severity: normal
status: open
title: multiprocessing.Pool._terminate_pool restarts workers during shutdown
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Sep 27 01:54:42 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 26 Sep 2013 23:54:42 +0000
Subject: [New-bugs-announce] [issue19097] bool(cgi.FieldStorage(...)) may be
	False unexpectedly
Message-ID: <1380239682.41.0.674159694258.issue19097@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Check out http://stackoverflow.com/questions/9327597/python-get-does-not-evaluate-to-true-even-though-there-is-an-object 

It turns out a cgi.FieldStorage object may consider itself False even when it has data.  This happens when the initialization decided to use read_single() instead of one of the other ways of reading the field value (read_urlencoded() or read_multi()).  Then self.list remains None, and __nonzero__ returns False no matter what the contents of self.file is.

To make things worse -- or better? -- the Python 3 version still defines __nonzero__() instead of __bool__().

----------
messages: 198457
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: bool(cgi.FieldStorage(...)) may be False unexpectedly
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Sep 27 03:44:24 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 27 Sep 2013 01:44:24 +0000
Subject: [New-bugs-announce] [issue19098] sys.setrecursionlimit(2**30)
	breaks interactive shell
Message-ID: <1380246264.16.0.783990166061.issue19098@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

sys.setrecursionlimit(2**30) breaks interactive shell in Python >=3.3.
This bug does not occur during non-interactive execution of scripts / modules.
This bug does not occur in versions of Python older than 3.3.

This bug occurs only for some range of values of recursion limit. There are higher values, which do not cause this bug.
sys.setrecursionlimit(2**31), as expected, raises OverflowError.
Values like 2**31-1 (i.e. 2147483647) cause no problem:

$ python3.4 -q
>>> import sys
>>> sys.setrecursionlimit(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> sys.setrecursionlimit(2**31-1)
>>> sys.getrecursionlimit()
2147483647
>>> 0
0
>>> 

Lower limit of values of recursion limit, which cause this bug: 715827883 == 2**29 + 2**27 + 2**25 + 2**23 + 2**21 + 2**19 + 2**17 + 2**15 + 2**13 + 2**11 + 2**9 + 2**7 + 2**5 + 2**3 + 2**1 + 1
Upper limit of values of recursion limit, which cause this bug: 1431655765 == 2**30 + 2**28 + 2**26 + 2**24 + 2**22 + 2**20 + 2**18 + 2**16 + 2**14 + 2**12 + 2**10 + 2**8 + 2**6 + 2**4 + 2**2 + 1

Example of this bug:

$ python3.4 -q
>>> import sys
>>> sys.setrecursionlimit(2**30)
>>> 0
RuntimeError: maximum recursion depth exceeded during compilation
>>> "a"
RuntimeError: maximum recursion depth exceeded during compilation
>>> 
RuntimeError: maximum recursion depth exceeded during compilation
>>>

RuntimeError occurs for each line (even empty). Ctrl+D still works.

I use 64-bit GNU/Linux.

----------
components: Interpreter Core
keywords: 3.3regression
messages: 198460
nosy: Arfrever
priority: normal
severity: normal
status: open
title: sys.setrecursionlimit(2**30) breaks interactive shell
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Sep 27 10:28:07 2013
From: report at bugs.python.org (Musashi Tamura)
Date: Fri, 27 Sep 2013 08:28:07 +0000
Subject: [New-bugs-announce] [issue19099] struct.pack fails first time with
	unicode fmt
Message-ID: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>


New submission from Musashi Tamura:

C:\>python
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack(u'B',1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be string, not unicode
>>> struct.pack(u'B',1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be string, not unicode
>>> struct.pack('B',1) # this is ok
'\x01'
>>> struct.pack(u'B',1)
'\x01'

----------
components: Unicode
messages: 198464
nosy: ezio.melotti, miwa
priority: normal
severity: normal
status: open
title: struct.pack fails first time with unicode fmt
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 27 13:05:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 11:05:10 +0000
Subject: [New-bugs-announce] [issue19100] Use backslashreplace in pprint
Message-ID: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently pprint.pprint() fails on unencodable characters.

$ LANG=en_US.utf8 ./python -c "import pprint; pprint.pprint('\u20ac')"
'?'
$ LANG= ./python -c "import pprint; pprint.pprint('\u20ac')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pprint.py", line 56, in pprint
    printer.pprint(object)
  File "/home/serhiy/py/cpython/Lib/pprint.py", line 137, in pprint
    self._format(object, self._stream, 0, 0, {}, 0)
  File "/home/serhiy/py/cpython/Lib/pprint.py", line 274, in _format
    write(rep)
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 1: ordinal not in range(128)

This is a regression from Python 2 in which repr() always returns ascii string.

$ LANG= python2.7 -c "import pprint; pprint.pprint(u'\u20ac')"
u'\u20ac'

Perhaps pprint() should use the backslashreplace error handler (as sys.displayhook()). With the proposed patch:

$ LANG= ./python -c "import pprint; pprint.pprint('\u20ac')"
'\u20ac'

----------
components: Library (Lib), Unicode
files: pprint_unencodable.patch
keywords: patch
messages: 198465
nosy: ezio.melotti, fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use backslashreplace in pprint
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31881/pprint_unencodable.patch

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

From report at bugs.python.org  Fri Sep 27 13:15:34 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 27 Sep 2013 11:15:34 +0000
Subject: [New-bugs-announce] [issue19101] "make touch" broke "x86 Ubuntu
	Shared 3.x" buildbot
Message-ID: <1380280534.57.0.0092887507305.issue19101@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Can you fix this before I tag 3.4a3 please?

----------
assignee: pitrou
components: Build
keywords: buildbot
messages: 198466
nosy: larry, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 27 13:41:08 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Sep 2013 11:41:08 +0000
Subject: [New-bugs-announce] [issue19102] Add tests for CLI of the tabnanny
	module
Message-ID: <1380282068.15.0.580247887303.issue19102@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I was trying to use the argparse module instead of getopt and I couldn't find any tests for CLI of the tabnanny module.

----------
components: Tests
files: test_tabnanny.diff
keywords: patch
messages: 198467
nosy: berker.peksag
priority: low
severity: normal
stage: patch review
status: open
title: Add tests for CLI of the tabnanny module
versions: Python 3.4
Added file: http://bugs.python.org/file31882/test_tabnanny.diff

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

From report at bugs.python.org  Fri Sep 27 13:41:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 11:41:47 +0000
Subject: [New-bugs-announce] [issue19103] Use pprint in displayhook
Message-ID: <1380282107.38.0.301660122877.issue19103@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

pprint.pprint() produces more human readable output than print(repr()) which is used in sys.displayhook(). The proposed patch changes sys.displayhook in site.py. You still can access original displayhook as sys.__displayhook__.

----------
files: displayhook_pprint.patch
keywords: patch
messages: 198468
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use pprint in displayhook
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31883/displayhook_pprint.patch

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

From report at bugs.python.org  Fri Sep 27 15:40:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 13:40:50 +0000
Subject: [New-bugs-announce] [issue19104] pprint produces invalid output for
	long strings
Message-ID: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The documentation says:
"""The pprint module provides a capability to ?pretty-print? arbitrary Python data structures in a form which can be used as input to the interpreter."""

But #since issue17150 long lines are splitted on shorter lines without continuation character and the result can't be used as input to the interpreter.

>>> pprint.pprint('abc '*20)
'abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc '\
'abc '

----------
components: Library (Lib)
keywords: easy
messages: 198474
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: pprint produces invalid output for long strings
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 27 15:50:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 13:50:34 +0000
Subject: [New-bugs-announce] [issue19105] pprint doesn't use all width
Message-ID: <1380289834.62.0.88627838079.issue19105@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

pprint not only adds indentation, but also increases right margin for nested items.

>>> pprint.pprint([' '.join(str(i) for i in range(30))]*2)
['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 '
 '28 29',
 '0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 '
 '28 29']
>>> pprint.pprint([[[[[[[[[[[[' '.join(str(i) for i in range(30))]]]]]]]]]]]]*2)
[[[[[[[[[[[['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 '
            '21 22 23 24 25 26 27 28 29']]]]]]]]]]],
 [[[[[[[[[[['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 '
            '21 22 23 24 25 26 27 28 29']]]]]]]]]]]]

As you can see in second example there is a place for at least '21 22 23 ' at the right. In case of multiline representation of nested items pprint can reserve space only at the end of last line and continue inner lines to full width.

----------
components: Library (Lib)
messages: 198475
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: pprint doesn't use all width
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 27 17:25:57 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 Sep 2013 15:25:57 +0000
Subject: [New-bugs-announce] [issue19106] Prepare .hgtouch and
	Tools/hg/hgtouch.py to run on the	bots
Message-ID: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

Background: we'd like to enable running 'make touch' on the bots before 'make -jN', to avoid problems with scripts that auto-generate code for the Python build (bootstrapping). pydev thread: https://mail.python.org/pipermail/python-dev/2013-September/128992.html

A couple of issues are prerequisites:

1. Fix the asdl dependencies in .hgtouch:

Include/ast.h: Parser/Python.asdl Parser/asdl.py Parser/asdl_c.py
Python/Python-ast.c: Include/ast.h

The file Include/ast.h is not, in fact, auto-generated. But Include/Python-ast.h *is*, and it does not appear in this file.

2. Make sure 'hg touch' itself runs on Python 2.4 because that's what some bots have (and other older systems like RHEL 5)

----------
assignee: eli.bendersky
components: Build
messages: 198482
nosy: eli.bendersky, ezio.melotti, loewis, pitrou
priority: normal
severity: normal
status: open
title: Prepare .hgtouch and Tools/hg/hgtouch.py to run on the bots
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 27 17:45:18 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 27 Sep 2013 15:45:18 +0000
Subject: [New-bugs-announce] [issue19107] CSV output of benchmark runner
	tries to write to binary	file
Message-ID: <1380296718.47.0.355256132109.issue19107@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The perf.py script opens the file for CSV output in binary mode, which no longer works in Py3:

Index: perf.py
===================================================================
--- perf.py     (Revision 80409)
+++ perf.py     (Arbeitskopie)
@@ -2443,7 +2448,7 @@
         raise ValueError("Invalid output_style: %r" % options.output_style)
 
     if options.csv:
-        with open(options.csv, "wb") as f:
+        with open(options.csv, "w") as f:
             writer = csv.writer(f)
             writer.writerow(['Benchmark', 'Base', 'Changed'])
             for name, result in results:

----------
components: Benchmarks
messages: 198483
nosy: scoder
priority: normal
severity: normal
status: open
title: CSV output of benchmark runner tries to write to binary file
type: behavior

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

From report at bugs.python.org  Fri Sep 27 18:00:36 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 27 Sep 2013 16:00:36 +0000
Subject: [New-bugs-announce] [issue19108] Benchmark runner tries to execute
	external Python	command and fails on error reporting
Message-ID: <1380297636.45.0.339184347104.issue19108@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

In changeset 88b6ef9aa9e9, a new function ported_lib() was added that crashes on error reporting in Py3 because it tries to do this:

    raise RuntimeError("Benchmark died: " + err)

"err" is a bytes object that comes straight from the subprocess pipe.

The reason why I noticed this is because the new function assumes that it can run "python" with the "-c" option and pass an arbitrary Python command string. That may not be true if it is actually executing some wrapper script (as we do for Cython, for example). Currently, the only requirement for the external Python command is that it can run a Python script that it receives on the command line. We shouldn't unnecessarily extend that interface.

I'm not sure how to best fix this, but the only way I can currently see is to run an external Python script that prints the requested information.

----------
components: Benchmarks
messages: 198487
nosy: brett.cannon, pitrou, scoder
priority: normal
severity: normal
status: open
title: Benchmark runner tries to execute external Python command and fails on error reporting
type: behavior

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

From report at bugs.python.org  Fri Sep 27 20:50:24 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 27 Sep 2013 18:50:24 +0000
Subject: [New-bugs-announce] [issue19109] 'TestTCPServer' is not defined
Message-ID: <1380307824.33.0.292776020503.issue19109@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The Win32 buildbots just started failing:

http://buildbot.python.org/all/waterfall?category=3.x.stable

They fail with this traceback:

test test_logging crashed -- Traceback (most recent call last):
  File "../lib/test/regrtest.py", line 1269, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\importlib\__init__.py", line 95, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1613, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1594, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1561, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 607, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1056, in load_module
  File "<frozen importlib._bootstrap>", line 926, in load_module
  File "<frozen importlib._bootstrap>", line 274, in _call_with_frames_removed
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_logging.py", line 1365, in <module>
    class SocketHandlerTest(BaseTest):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_logging.py", line 1369, in SocketHandlerTest
    server_class = TestTCPServer
NameError: name 'TestTCPServer' is not defined

I took a quick look at it and the code seemed fine... but obviously there's something going on.

Can you try to fix this before I cut 3.4a3 tomorrow?

----------
assignee: vinay.sajip
components: Tests
keywords: buildbot
messages: 198498
nosy: larry, vinay.sajip
priority: high
severity: normal
stage: needs patch
status: open
title: 'TestTCPServer' is not defined
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 28 10:37:16 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 28 Sep 2013 08:37:16 +0000
Subject: [New-bugs-announce] [issue19110] PEP-0 history link is broken
Message-ID: <1380357436.7.0.673838286664.issue19110@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

See http://www.python.org/dev/peps/, click Last-Modified.

----------
assignee: docs at python
components: Documentation
messages: 198509
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: PEP-0 history link is broken

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

From report at bugs.python.org  Sat Sep 28 16:52:33 2013
From: report at bugs.python.org (Peter)
Date: Sat, 28 Sep 2013 14:52:33 +0000
Subject: [New-bugs-announce] [issue19111] 2to3 should remove from
	future_builtins import *
Message-ID: <1380379953.79.0.934483665034.issue19111@psf.upfronthosting.co.za>


New submission from Peter:

The 2to3 script should remove lines like this:

from future_builtins import zip

after running the zip fixer which respects the meaning of this command (issue 217). It does not, which results in an ImportError when trying to use the converted code under Python 3.

Similarly for lines like this after running the map fixer etc:

from future_builtins import map

Background:

Python 2.6 and 2.7 have an iterator-style zip function in future_builtins (and other things):

$ python2.6
Python 2.6.8 (unknown, Sep 28 2013, 12:09:28) 
[GCC 4.6.3] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
>>> dir(future_builtins)
['__doc__', '__file__', '__name__', '__package__', 'ascii', 'filter', 'hex', 'map', 'oct', 'zip']
>>> quit()

$ python2.7
Python 2.7.1 (r271:86832, Dec 26 2010, 19:03:20) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
>>> dir(future_builtins)
['__doc__', '__file__', '__name__', '__package__', 'ascii', 'filter', 'hex', 'map', 'oct', 'zip']
>>> quit()

The future_builtins module does not exist under Python 3, in particular its zip and map functions do not exist.

$ python3.3
Python 3.3.2 (default, Sep 28 2013, 12:00:20) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'future_builtins'

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

Sample script using zip which works under Python 2.6 and 2.7,

$ more zip_2to3_bug.py 
from future_builtins import zip
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print "Done"

$ python2.6 zip_2to3_bug.py 
Done

$ python2.7 zip_2to3_bug.py 
Done

Now let's use the 2to3 script (in place):

$ 2to3 -w zip_2to3_bug.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored zip_2to3_bug.py
--- zip_2to3_bug.py	(original)
+++ zip_2to3_bug.py	(refactored)
@@ -1,3 +1,3 @@
 from future_builtins import zip
 assert next(zip("abc", [1, 2, 3])) == ("a", 1)
-print "Done"
+print("Done")

Here's the (broken) output:

$ more zip_2to3_bug.py
from future_builtins import zip
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print("Done")

This breaks:

$ python3.3 zip_2to3_bug.py
Traceback (most recent call last):
  File "zip_2to3_bug.py", line 1, in <module>
    from future_builtins import zip
ImportError: No module named 'future_builtins'

Expected output should respect the fact I am using "from future_builtins import zip" therefore zip as an iterator already (this is working), and then remove the line "from future_builtins import zip":

$ more zip_2to3_bug.py
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print("Done")

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


Sample script using zip which works under Python 2.6 and 2.7,

$ more map_2to3_bug.py 
from future_builtins import map
x = [-2, -1, 0, 1, 2, 3]
y = next(map(abs, x))
assert y == 2 
print "Done"

$ python2.6 map_2to3_bug.py 
Done

$ python2.7 map_2to3_bug.py 
Done

Now let's use the 2to3 script (in place):

$ 2to3 -w map_2to3_bug.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored map_2to3_bug.py
--- map_2to3_bug.py	(original)
+++ map_2to3_bug.py	(refactored)
@@ -2,4 +2,4 @@
 x = [-2, -1, 0, 1, 2, 3]
 y = next(map(abs, x))
 assert y == 2 
-print "Done"
+print("Done")
RefactoringTool: Files that were modified:
RefactoringTool: map_2to3_bug.py

Here's the (broken) output:

$ more map_2to3_bug.py
from future_builtins import map
x = [-2, -1, 0, 1, 2, 3]
y = next(map(abs, x))
assert y == 2 
print("Done")

This breaks:

$ python3.3 map_2to3_bug.py
Traceback (most recent call last):
  File "map_2to3_bug.py", line 1, in <module>
    from future_builtins import map
ImportError: No module named 'future_builtins'


Expected output should respect the fact I am using "from future_builtins import map" and therefore treat map according (this is working), and then remove the line "from future_builtins import map":

$ more zip_2to3_bug.py
x = [-2, -1, 0, 1, 2, 3]
y = next(map(abs, x))
assert y == 2 
print("Done")

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 198521
nosy: maubp
priority: normal
severity: normal
status: open
title: 2to3 should remove from future_builtins import *
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Sep 28 17:51:47 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 15:51:47 +0000
Subject: [New-bugs-announce] [issue19112] tests of _TestProcess are not run
	by the multiprocessing	test suite
Message-ID: <1380383507.04.0.708798356972.issue19112@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

class _TestProcess in Lib/test/_test_multiprocessing.py is
overshadowed by a function of the same name.  And test_current is its
first method:

$ ./python -m test -v test_multiprocessing_fork | grep test_current
$

With the attached patch:

$ ./python -m test -v test_multiprocessing_fork | grep test_current
test_current (test.test_multiprocessing_fork.WithProcessesTestProcess) ... ok
test_current (test.test_multiprocessing_fork.WithThreadsTestProcess) ... ok
$

----------
components: Library (Lib)
files: testprocess.patch
keywords: patch
messages: 198528
nosy: jnoller, xdegaye
priority: normal
severity: normal
status: open
title: tests of _TestProcess are not run by the multiprocessing test suite
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31893/testprocess.patch

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

From report at bugs.python.org  Sat Sep 28 18:23:39 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 16:23:39 +0000
Subject: [New-bugs-announce] [issue19113] duplicate test names in
	Lib/ctypes/test/test_functions.py
Message-ID: <1380385419.52.0.767012097586.issue19113@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

After renaming the first test_errors method to test_errors_1 and the
second one to test_errors_2:

$ /bin/sh -c "cd Lib/ctypes/test; ../../../python runtests.py test_functions.py"
....F................
======================================================================
FAIL: test_errors_1 (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/ctypes/test/test_functions.py", line 227, in test_errors_1
    self.assertRaises(TypeError, f, X()) #cannot convert parameter
AssertionError: TypeError not raised by _testfunc_p_p

----------------------------------------------------------------------
Ran 21 tests in 0.007s

FAILED (failures=1)

----------
components: Library (Lib)
messages: 198529
nosy: amaury.forgeotdarc, belopolsky, meador.inge, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/ctypes/test/test_functions.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 28 18:37:12 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 16:37:12 +0000
Subject: [New-bugs-announce] [issue19114] duplicate test names in
	Lib/distutils/tests/test_cmd.py
Message-ID: <1380386232.47.0.0199023087976.issue19114@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

$ ./python -m unittest -v Lib/distutils/tests/test_cmd.py 2>&1 | grep test_ensure_string_list
test_ensure_string_list (Lib.distutils.tests.test_cmd.CommandTestCase) ... ok
$

And after renaming the first test_ensure_string_list to
test_ensure_string_list_1 and the second one to
test_ensure_string_list_2:

$ ./python -m unittest -v Lib/distutils/tests/test_cmd.py 2>&1 | grep test_ensure_string_list
test_ensure_string_list_1 (Lib.distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_string_list_2 (Lib.distutils.tests.test_cmd.CommandTestCase) ... ok
$

----------
components: Library (Lib)
messages: 198530
nosy: eric.araujo, tarek, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/distutils/tests/test_cmd.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 28 18:52:57 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 16:52:57 +0000
Subject: [New-bugs-announce] [issue19115] duplicate test names in
	Lib/lib2to3/tests/test_fixers.py
Message-ID: <1380387177.92.0.945417073814.issue19115@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

There are 5 duplicate test names in this file.

$ ./python -m unittest Lib/lib2to3/tests/test_fixers.py
......................................................................
----------------------------------------------------------------------
Ran 451 tests in 8.770s

OK

With the patch applied:

$ ./python -m unittest Lib/lib2to3/tests/test_fixers.py
......................................................................
----------------------------------------------------------------------
Ran 456 tests in 8.810s

OK

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198531
nosy: benjamin.peterson, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/lib2to3/tests/test_fixers.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31894/duplicate_test_name.patch

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

From report at bugs.python.org  Sat Sep 28 20:56:06 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 18:56:06 +0000
Subject: [New-bugs-announce] [issue19116] duplicate test names in
	Lib/test/test_complex.py
Message-ID: <1380394566.75.0.788169311559.issue19116@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

$ ./python -m test -v test_complex | grep test_truediv
test_truediv (test.test_complex.ComplexTest) ... ok

After renaming the first test_truediv to test_truediv_1 and the second
one to test_truediv_2:

$ ./python -m test -v test_complex | grep test_truediv
test_truediv_1 (test.test_complex.ComplexTest) ... ok
test_truediv_2 (test.test_complex.ComplexTest) ... ok

----------
components: Library (Lib)
messages: 198539
nosy: xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/test/test_complex.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 28 21:13:56 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 19:13:56 +0000
Subject: [New-bugs-announce] [issue19117] duplicate test names in
	Lib/test/test_dis.py
Message-ID: <1380395636.95.0.580453095292.issue19117@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_dis.py:250 DisTests.test_big_linenos
./Lib/test/test_dis.py:294 DisTests.test_dis_object

The attached patch fixes this.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198542
nosy: ncoghlan, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/test/test_dis.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31895/duplicate_test_name.patch

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

From report at bugs.python.org  Sat Sep 28 21:19:06 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 19:19:06 +0000
Subject: [New-bugs-announce] [issue19118] duplicate test names in
	Lib/test/test_ftplib.py
Message-ID: <1380395946.78.0.131314342439.issue19118@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_ftplib.py:537 TestFTPClass.test_mkd

The attached patch fixes this.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198543
nosy: giampaolo.rodola, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/test/test_ftplib.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31896/duplicate_test_name.patch

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

From report at bugs.python.org  Sat Sep 28 22:53:22 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 20:53:22 +0000
Subject: [New-bugs-announce] [issue19119] duplicate test name in
	Lib/test/test_heapq.py
Message-ID: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

There are two test_get_only methods. The patch provides a partial
fix, but removes the following two lines from the first method as the
execution of these lines fails:

  for f in (self.module.nlargest, self.module.nsmallest):
      self.assertRaises(TypeError, f, 2, GetOnly())

because heapq.nlargest is stuck in an infinite loop when the sequence
does not have a length. This seems to be a bug in nlargest. See the
following test that runs with 100 % cpu usage.

$ ./python
Python 3.4.0a2+ (default:f6792f734fcc, Sep 28 2013, 17:09:46) 
[GCC 4.3.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class GetOnly:
...     "Dummy sequence class defining __getitem__ but not __len__."
...     def __getitem__(self, ndx):
...         return 10
... 
>>> import heapq
>>> heapq.nlargest(2, GetOnly())
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Lib/heapq.py", line 455, in nlargest
    result = _nlargest(n, it)
  File "<stdin>", line 3, in __getitem__
KeyboardInterrupt
>>>

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198550
nosy: rhettinger, stutzbach, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_heapq.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31898/duplicate_test_name.patch

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

From report at bugs.python.org  Sun Sep 29 04:35:13 2013
From: report at bugs.python.org (Daniel)
Date: Sun, 29 Sep 2013 02:35:13 +0000
Subject: [New-bugs-announce] [issue19120] shlex.shlex.lineno reports a
	different number depending	on the previous token
Message-ID: <1380422113.39.0.502795028764.issue19120@psf.upfronthosting.co.za>


New submission from Daniel:

See the example below (also attached).

First example: The lineno reported just after "word2" is pulled is 2.
Second example: The lineno reported just after "," is pulled is still 1.

This behaviour seems inconsistent. The lineno should increment either when the last token of a line is pulled, or after the first token from the next line (in my opinion preferably the former). It should not have different bahaviour depending on what type of token that is (alpha vs. comma).

I have repeated this on 

Also, does Issue 16121 relate to this?


#!/usr/bin/env python
import shlex

first = shlex.shlex("word1 word2\nword3")
print (first.get_token())
print (first.get_token())
print ("line no", first.lineno)
print ("")

second = shlex.shlex("word1 word2,\nword3")
print (second.get_token())
print (second.get_token())
print (second.get_token())
print ("line no", second.lineno)


# Output:
# word1
# word2
# line no 2
#
# word1
# word2
# ,
# line no 1

----------
files: shlex_line.py
messages: 198561
nosy: daniel-s
priority: normal
severity: normal
status: open
title: shlex.shlex.lineno reports a different number depending on the previous token
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31900/shlex_line.py

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

From report at bugs.python.org  Sun Sep 29 11:25:58 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 09:25:58 +0000
Subject: [New-bugs-announce] [issue19121] Documentation guidelines
	enhancements
Message-ID: <1380446758.24.0.414615784712.issue19121@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

I'll raise some points and then suggest how to fix that.

issue19060 it appeared that list of functions that subprocess replaces imbues readers with uncertainty, because this list is not complete.

Current http://docs.python.org/devguide/documenting.html guide doesn't pay attention that information should be "complete and unambiguous". issue19060 is a good example of completeness requirement - user should not be left guessing what other functions can be or can not be replaced by subprocess. Unambiguous means that there should also be answer why they can or can not be replaced. For subprocess this info is partially provided in "replacing older functions" chapter. There also should not be a place for subjective judgement, fear and desperation. If something can not be done with subprocess, users should not be discouraged (left in fear) to use older functions. If there are valid points where subprocess is not good, they should be described in advanced section. If the description is too long to read, it should be linked.

Somebody may raise the point that subprocess docs is not the best place for such list. But between choice to be complete and structured, the former should take precedence. When documentation is complete enough, it's text can be restructured. This further raises a point about structure of docs. Both main docs and guidelines itself.


Main docs structure.

The more unambiguous, complete and concise documentation is, the better it is for understanding. Currently our docs really miss overviews and summaries. Some may argue that there is no place for that in official docs, especially if such summaries will contain info about history and changes between Python versions. But I'd say that if there is no place, we need to find it for them. Just two examples. MSDN and Python Cookbook both are examples of perfect documentation and these both include overview chapters before function reference. When where is a critical mass of info related to child process execution and management, it is worth to make an overview.


Guidelines structure.

ToC.
Sphinx ToCs are too narrow - they are hard to read. If ToC is present in side panel for navigation, it is not the reason not to include it below the page header for human readers to see the structure of the doc. I find it extremely hard (unnatural) to scan the side panel for the doc structure.

This should be split between markup and content guidelines. Right now the structure of docs is:

7. Documenting Python
7.1. Introduction
7.2. Style guide
7.2.1. Use of whitespace
7.2.2. Footnotes
7.2.3. Capitalization
7.2.4. Affirmative Tone
7.2.5. Economy of Expression
7.2.6. Code Examples
7.2.7. Code Equivalents
7.2.8. Audience
7.3. reStructuredText Primer
7.3.1. Paragraphs
7.3.2. Inline markup
7.3.3. Lists and Quotes
7.3.4. Source Code
7.3.5. Hyperlinks
7.3.5.1. External links
7.3.5.2. Internal links
7.3.6. Sections
7.3.7. Explicit Markup
7.3.8. Directives
7.3.9. Footnotes
7.3.10. Comments
7.3.11. Source encoding
7.3.12. Gotchas
7.4. Additional Markup Constructs
7.4.1. Meta-information markup
7.4.2. Module-specific markup
7.4.3. Information units
7.4.4. Showing code examples
7.4.5. Inline markup
7.4.6. Cross-linking markup
7.4.7. Paragraph-level markup
7.4.8. Table-of-contents markup
7.4.9. Index-generating markup
7.4.10. Grammar production displays
7.4.11. Substitutions
7.5. Differences to the LaTeX markup
7.5.1. Inline markup
7.5.2. Information units
7.5.3. Structure
7.6. Building the documentation
7.6.1. Using make
7.6.2. Without make

As you may see the 90% of the ToC is markup reference. Some topics like "Hyperlinks" are oversplit. Making two chapter for just one sentence is an obsession with structure. That's ok for coding, but for readability I would just make it into a list in one chapter, renamed to "Linking" and merged "cross-linking markup" section into it.


7.2.3. Capitalization
7.2.4. Affirmative Tone
7.2.5. Economy of Expression
7.2.6. Code Examples

As you may see, the "Content writing" is perfectly mixed with "Content formatting" into the mix of rules for proper whitespace formatting. This perfectly characterizes us coders, who often mix the concept of "good code which is bug-free" with concept of "good code which is PEP-8 compliant". I mean that it leaves expression that most of the document is about rules, regulations and nitpicking about how you should format the text, not how you should write. 

Let's make this unambiguous - "Content" of documentation is essential info that readers need to know. "Format" of docs is the markup, whitespace, examples, footnotes and other stuff. "Content guidelines" say that you should insert footnotes, "Format guidelines" show how to do this. "Content guidelines" should not distract from the content aspects.

So, the "Style Guide" should be split into "Content Writing" and "Formatting Guidelines" [ ]. Or moves into separate file at all.


The "Content Writing" chapter.
Should include chapter that docs should be complete and unambiguous, with the points raised above, probably with a link to the linked issue.

I don't get what "affirmative tone" is. I don't get it, because header "affirmative tone" for non-native non-speaker doesn't contain the answer what and why. To me chapters like "avoid uncertainty" are more concise and valid.

"Documentation is a place for facts. Make sure that facts are complete. That after reading the documentation users are not left with doubts and fears. Make sure that if is there is a recommendation, there is also a link to reasons."

"establishing confident knowledge" and "affirmative tone" are phrases from NLP psychotherapy courses. It looks like guideline to program the readers for positive emotions, not to provide them with facts. I am not saying that docs should be dry and lawfully correct. Just the focus should be on the side of facts.

I hope that this feedback is useful.

----------
assignee: docs at python
components: Devguide, Documentation
messages: 198571
nosy: docs at python, ezio.melotti, techtonik
priority: normal
severity: normal
status: open
title: Documentation guidelines enhancements

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

From report at bugs.python.org  Sun Sep 29 12:15:53 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 10:15:53 +0000
Subject: [New-bugs-announce] [issue19122] duplicate test name in
	Lib/test/test_import.py
Message-ID: <1380449753.39.0.561923612283.issue19122@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_import.py:255 ImportTests.test_import_name_binding

Attached patch fixes it.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198576
nosy: brett.cannon, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_import.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31903/duplicate_test_name.patch

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

From report at bugs.python.org  Sun Sep 29 12:24:06 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 10:24:06 +0000
Subject: [New-bugs-announce] [issue19123] duplicate test name in
	Lib/test/test_regrtest.py
Message-ID: <1380450246.86.0.728804280049.issue19123@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_regrtest.py:210 ParseArgsTestCase.test_findleaks

Attached patch fixes it.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198577
nosy: ezio.melotti, michael.foord, pitrou, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_regrtest.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31904/duplicate_test_name.patch

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

From report at bugs.python.org  Sun Sep 29 12:46:42 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 10:46:42 +0000
Subject: [New-bugs-announce] [issue19124] os.execv executes in background on
	Windows
Message-ID: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

os.execv() starts process in background on Windows. Because it inherits stdin/stdout handlers from the process that launched Python interpreter, this becomes a source of numerous weird bugs, from polluting the stdout stream of parent to completely blocking its input.

Example session on Windows. Open cmd.exe and run attached testexecvchild.py. It starts child process with execv(). Child pauses for 2 seconds during which I type 'echo "Hello"' and hit Enter.

With Python 3 is pollutes parent output after 3 seconds:
    >python testexecvchild.py
    
    >echo "Hello"
    "Hello"
    
    >Traceback (most recent call last):
    File "testexecvchild.py", line 7, in <module>
    raw_input('xxx')
    NameError: name 'raw_input' is not defined

With Python 2 the stdin of cmd.exe is blocked:
    >py testexecvchild.py
    
    >echo "Hello"
    "Hello"
    
    >xxxecho "Hello"
    "Hello"
    
    >echo "Hello"
      testexecvchild.py
      passed
    echo "Hello"
    "Hello"

The same behavior on Linux:

    $ python testexecvchild.py
    echo "Hello"
    xxx  testexecvchild.py
      passed

----------
components: Library (Lib)
messages: 198578
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.execv executes in background on Windows
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Sep 29 13:18:58 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:18:58 +0000
Subject: [New-bugs-announce] [issue19125] duplicate test name in
	Lib/test/test_smtplib.py
Message-ID: <1380453538.83.0.118703506889.issue19125@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_smtplib.py:249 DebuggingServerTests.testNotImplemented

Attached patch fixes this: the first method has been renamed to
testEHLO since the channel_class of the DebuggingServer is
SMTPChannel, and SMTPChannel does support EHLO.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198582
nosy: giampaolo.rodola, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_smtplib.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31906/duplicate_test_name.patch

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

From report at bugs.python.org  Sun Sep 29 13:24:09 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:24:09 +0000
Subject: [New-bugs-announce] [issue19126] duplicate test name in
	Lib/test/test_webbrowser.py
Message-ID: <1380453849.08.0.0119918411206.issue19126@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_webbrowser.py:161 OperaCommandTest.test_open_new

Attached patch fixes it.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198583
nosy: georg.brandl, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_webbrowser.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31907/duplicate_test_name.patch

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

From report at bugs.python.org  Sun Sep 29 13:35:45 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:35:45 +0000
Subject: [New-bugs-announce] [issue19127] duplicate test name in
	Lib/xml/dom/minidom.py
Message-ID: <1380454545.89.0.34264409001.issue19127@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/xml/dom/minidom.py:379 Attr._get_name

----------
components: Library (Lib)
messages: 198584
nosy: xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/xml/dom/minidom.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 29 13:39:03 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:39:03 +0000
Subject: [New-bugs-announce] [issue19128] duplicate test name in
	Mac/Tools/Doc/setup.py
Message-ID: <1380454743.3.0.0899741731446.issue19128@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Mac/Tools/Doc/setup.py:123 DocBuild.makeHelpIndex

----------
components: Library (Lib)
messages: 198585
nosy: hynek, ned.deily, ronaldoussoren, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Mac/Tools/Doc/setup.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 29 18:09:07 2013
From: report at bugs.python.org (Jason Smestad)
Date: Sun, 29 Sep 2013 16:09:07 +0000
Subject: [New-bugs-announce] [issue19129] 6.2.1. Regular Expression Syntax
	flags
Message-ID: <1380470947.27.0.0292455287204.issue19129@psf.upfronthosting.co.za>


New submission from Jason Smestad:

In the Python 3.3.2 documentation in the section "6.2.1. Regular Expression Syntax" subsection "(?aiLmsux)" it describes flags that are set by extention notation. 6 of the flags are described in detail with links for each flag, but the "u" flag is not described or linked to in this subsection. 

When reading this subsection, you may be confused as to what the "u" flag is for, or if it even belongs there, since there is no link. I suggest that a link be added in that subsection to the re.A section in 6.2.2, and that re.U be added as a title for the re.A subsection in 6.2.2.

----------
assignee: docs at python
components: Documentation
messages: 198600
nosy: docs at python, endoalir
priority: normal
severity: normal
status: open
title: 6.2.1. Regular Expression Syntax flags
versions: Python 3.3

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

From report at bugs.python.org  Sun Sep 29 18:58:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 16:58:41 +0000
Subject: [New-bugs-announce] [issue19130] PCbuild/readme.txt not up-to-date
Message-ID: <1380473921.46.0.878582120992.issue19130@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

PCbuild/readme.txt mentions VS2008 while VS2010 is required to build 3.4. Am I missing something?

----------
assignee: docs at python
components: Documentation
messages: 198602
nosy: brian.curtin, docs at python, loewis, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: PCbuild/readme.txt not up-to-date
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 29 21:24:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 19:24:02 +0000
Subject: [New-bugs-announce] [issue19131] Broken support of compressed AIFC
	files
Message-ID: <1380482642.92.0.440951147189.issue19131@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In u-law and A-law compressed AIFC files the sampleSize field is equal to 8 (bits). The aifc module transparently compress/uncompress audio data to 16-bit, but doesn't support the samplewidth parameter in consistency. This causes two bugs:

1. On read getsampwidth() returns 1, but should return 2 (bytes per sample in uncompressed audio data). readframes() returns twice less data than expected.

>>> import aifc
>>> f = aifc.open('pluck-ulaw.aifc', 'r')
>>> f.getparams()
_aifc_params(nchannels=2, sampwidth=1, framerate=11025, nframes=3307, comptype=b'ulaw', compname=b'')
>>> f.readframes(1)
b',\x02'

f.readframes(1) should return 4 bytes (2 channels, 16-bit uncompressed data).

2. On write wrong value 2 is saved in the sampleSize field. Resulting file is invalid and can't be read in other programs.

Here is a patch and sample file. For tests see issue18919.

I'm sure G722 support is broken too, but I have no any testing files.

----------
components: Library (Lib)
files: aifc_sampwidth.patch
keywords: patch
messages: 198631
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Broken support of compressed AIFC files
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31909/aifc_sampwidth.patch

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

From report at bugs.python.org  Sun Sep 29 22:05:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 20:05:49 +0000
Subject: [New-bugs-announce] [issue19132] Add compact mode to pprint
Message-ID: <1380485149.97.0.648520685176.issue19132@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

pprint produces not very nice output for collections with a large number of short elements (see msg198556). For example pprint.pprint(list(range(40))) outputs more than 40 short lines, while print(repr(list(range(40)))) takes only 2 lines on 80-column terminal.

I propose to add new boolean option "compact". With compact=True pprint will try combine as much short one-line subelements in one line as possible. Every multiline element will be printed on separated lines.

Examples:

>>> pprint.pprint(list(range(40)), width=50, compact=True)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
 38, 39]
>>> pprint.pprint(['one string', 'other string', 'very very long string which continued on several lines', 'and again', 'and again', 'and again', 'and again'], width=50, compact=True)
['one string', 'other string',
 'very very long string which is continued on '
 'several lines',
 'and again', 'and again', 'and again',
 'and again']

----------
components: Library (Lib)
messages: 198641
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add compact mode to pprint
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 30 11:27:30 2013
From: report at bugs.python.org (koobs)
Date: Mon, 30 Sep 2013 09:27:30 +0000
Subject: [New-bugs-announce] [issue19133] Transient test failure:
	test_with_statement (test_ftplib)
Message-ID: <1380533250.94.0.739399137718.issue19133@psf.upfronthosting.co.za>


New submission from koobs:

Test failure observed on koobs-freebsd9 on default branch with changeset: 220b34cbd711c28938ea5d980636202c51ab1fbb

Subsequent forced rebuild succeeded with no failure.
 
======================================================================
FAIL: test_with_statement (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_ftplib.py", line 723, in test_with_statement
    self.assertEqual(self.server.handler_instance.last_received_cmd, 'quit')
AssertionError: 'noop' != 'quit'
- noop
+ quit

----------
components: Tests
messages: 198686
nosy: koobs
priority: normal
severity: normal
status: open
title: Transient test failure: test_with_statement (test_ftplib)

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

From report at bugs.python.org  Mon Sep 30 16:15:42 2013
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 30 Sep 2013 14:15:42 +0000
Subject: [New-bugs-announce] [issue19134] test_inspect.py failed if module
	_multiprocessing not	available
Message-ID: <1380550542.93.0.175157800121.issue19134@psf.upfronthosting.co.za>


New submission from Remi Pointel:

When I run the regress tests on OpenBSD 5.4-current, the test test_inspect.py failed because the module _multiprocessing is not available, instead of skipping the test:

FAILED (errors=1)
Traceback (most recent call last):
  File "./Lib/test/test_inspect.py", line 2453, in <module>
    test_main()
  File "./Lib/test/test_inspect.py", line 2449, in test_main
    TestBoundArguments, TestGetClosureVars, TestUnwrap, TestMain
  File "/tmp/Python-3.4.0a3/Lib/test/support/__init__.py", line 1696, in run_unittest
    _run_suite(suite)
  File "/tmp/Python-3.4.0a3/Lib/test/support/__init__.py", line 1671, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "./Lib/test/test_inspect.py", line 2411, in test_qualname_source
    module = importlib.import_module('concurrent.futures')
  File "/tmp/Python-3.4.0a3/Lib/importlib/__init__.py", line 95, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1613, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1594, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1561, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 607, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1056, in load_module
  File "<frozen importlib._bootstrap>", line 926, in load_module
  File "<frozen importlib._bootstrap>", line 274, in _call_with_frames_removed
  File "/tmp/Python-3.4.0a3/Lib/concurrent/futures/__init__.py", line 17, in <module>
    from concurrent.futures.process import ProcessPoolExecutor
  File "/tmp/Python-3.4.0a3/Lib/concurrent/futures/process.py", line 53, in <module>
    from multiprocessing.queues import SimpleQueue, Full
  File "/tmp/Python-3.4.0a3/Lib/multiprocessing/queues.py", line 22, in <module>
    import _multiprocessing
ImportError: No module named '_multiprocessing'


Diff to skip test_qualname_source if _multiprocessing is not available is attached. Is it ok?

Remi.

----------
components: Tests
files: Lib_test_test_inspect_py.diff
keywords: patch
messages: 198698
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_inspect.py failed if module _multiprocessing not available
versions: Python 3.4
Added file: http://bugs.python.org/file31921/Lib_test_test_inspect_py.diff

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