From report at bugs.python.org  Sun Mar  1 01:50:38 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 00:50:38 +0000
Subject: [New-bugs-announce] [issue23553] Reduce the number of comparison
	for range checking.
Message-ID: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Python's core is full of bound checks like this one in Objects/listobject.c:

static PyObject *
list_item(PyListObject *a, Py_ssize_t i)
{
    if (i < 0 || i >= Py_SIZE(a)) {
    ...

Abner Fog's high-level language optimization guide,  http://www.agner.org/optimize/optimizing_cpp.pdf in section 14.2 Bounds Checking, shows a way to fold this into a single check:

-    if (i < 0 || i >= Py_SIZE(a)) {
+    if ((unsigned)i >= (unsigned)(Py_SIZE(a))) {
         if (indexerr == NULL) {
             indexerr = PyUnicode_FromString(
                 "list index out of range");

The old generated assembly code looks like this:

_list_item:
    subq    $8, %rsp
    testq   %rsi, %rsi
    js  L227
    cmpq    16(%rdi), %rsi
    jl  L228
L227:
    ... <error reporting and exit > ...
L228:
    movq    24(%rdi), %rax
    movq    (%rax,%rsi,8), %rax
    addq    $1, (%rax)
    addq    $8, %rsp
    ret

The new disassembly looks like this:

_list_item:
    cmpl    %esi, 16(%rdi)
    ja  L227
    ... <error reporting and exit > ...
L227:
    movq    24(%rdi), %rax
    movq    (%rax,%rsi,8), %rax
    addq    $1, (%rax)
    ret

Note, the new code not only saves a comparison/conditional-jump pair, it also avoids the need to adjust %rsp on the way in and the way out for a net savings of four instructions along the critical path.

When we have good branch prediction, the current approach is very low cost; however, Abner Fog's recommendation is never more expensive, is sometimes cheaper, saves a possible misprediction, and reduces the total code generated.  All in all, it is a net win.

I recommend we put in a macro of some sort so that this optimization gets expressed exactly once in the code and so that it has a good clear name with an explanation of what it does.

----------
components: Interpreter Core
messages: 236928
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Reduce the number of comparison for range checking.
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar  1 06:59:32 2015
From: report at bugs.python.org (Giovanni Cannata)
Date: Sun, 01 Mar 2015 05:59:32 +0000
Subject: [New-bugs-announce] [issue23554] EchoServerClientProtocol class
	should be called	EchoServerProtocol
Message-ID: <1425189572.41.0.939168822868.issue23554@psf.upfronthosting.co.za>


New submission from Giovanni Cannata:

In 18.5.4.3.2. TCP echo server protocol the class in the example code is called EchoServerClientProtocol.  It should be EchoServerProtocol. (The client protocol example is correctly called EchoClientProtocol).

----------
assignee: docs at python
components: Documentation
messages: 236932
nosy: docs at python, gc
priority: normal
severity: normal
status: open
title: EchoServerClientProtocol class should be called EchoServerProtocol
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  1 12:32:36 2015
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 01 Mar 2015 11:32:36 +0000
Subject: [New-bugs-announce] [issue23555] behavioural change in argparse
	set_defaults in python	2.7.9
Message-ID: <1425209556.02.0.589190597278.issue23555@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen with ceph, https://launchpad.net/bugs/1413321

This appears to be a regression in the argparse package in python; under trusty ceph-disk works just fine, however in vivid, the cluster attribute remains unset (despite having a default of 'ceph'). Attached python demonstrates the problem.

----------
components: Library (Lib)
files: test.py
messages: 236956
nosy: doko
priority: normal
severity: normal
status: open
title: behavioural change in argparse set_defaults in python 2.7.9
versions: Python 2.7
Added file: http://bugs.python.org/file38284/test.py

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

From report at bugs.python.org  Sun Mar  1 13:14:32 2015
From: report at bugs.python.org (Antoine Amarilli)
Date: Sun, 01 Mar 2015 12:14:32 +0000
Subject: [New-bugs-announce] [issue23556] Scope for raise without argument
	is different in Python	2 and 3
Message-ID: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>


New submission from Antoine Amarilli:

Hello,

Python 2.7.8 and Python 3.4.2 (from Debian testing) have a different behavior on the attached file. Python 2 raises "bar", Python 3 raises "foo".

I can't find an adequate explanation in the documentation for this behavior difference. It probably relates to https://docs.python.org/3/reference/compound_stmts.html#try (search for "When an exception has been assigned") but this is unsatisfying because it only talks about the "as target" construction, which is not used in the example.

I think that at least the documentation should be clarified to point out what "raise" without arguments will do. Currently the documentation of this in Python 2 and 3 is the same even though the behavior is different https://docs.python.org/2/reference/simple_stmts.html#raise https://docs.python.org/3/reference/simple_stmts.html#raise.

Note: this question was originally asked on SO: http://stackoverflow.com/q/28698622/414272. I reported this as a bug at Terry Jan Reedy's request https://stackoverflow.com/q/28698622/414272#comment45707744_28698622.

----------
files: raise.py
messages: 236957
nosy: a3nm
priority: normal
severity: normal
status: open
title: Scope for raise without argument is different in Python 2 and 3
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38285/raise.py

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

From report at bugs.python.org  Sun Mar  1 13:17:22 2015
From: report at bugs.python.org (Jakub Klama)
Date: Sun, 01 Mar 2015 12:17:22 +0000
Subject: [New-bugs-announce] [issue23557] Misc/SpecialBuilds.txt contains
	outdated information	about PYMALLOC_DEBUG
Message-ID: <1425212242.29.0.401382556458.issue23557@psf.upfronthosting.co.za>


New submission from Jakub Klama:

Section describing block layout under PYMALLOC_DEBUG is wrong - it doesn't contain information about API type byte instead of one of forbidden bytes. That may lead to wrong assumption that one of forbidden bytes is being overwritten until you dig into obmalloc.c code.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 236958
nosy: Jakub Klama, docs at python
priority: normal
severity: normal
status: open
title: Misc/SpecialBuilds.txt contains outdated information about PYMALLOC_DEBUG
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  1 16:50:58 2015
From: report at bugs.python.org (Ryan Neve)
Date: Sun, 01 Mar 2015 15:50:58 +0000
Subject: [New-bugs-announce] [issue23558] Unable to install Python 3.4.3
	amd64 on Windows 8.1
Message-ID: <1425225058.12.0.9521786559.issue23558@psf.upfronthosting.co.za>


New submission from Ryan Neve:

Much like issue 22648. Windows 8.1, I had version 3.4.1 and installed 3.4.3 without first uninstalling earlier version. Tried uninstalling older versions and it failed with:
 A program required for this install to complete could not be run.

Windows uninstall window showing 3.4.3 installed when it isn't really.
Tried re-installing 3.4.1 to then uninstall it, but install failed as well. Also tried repair, but that failed as well. Nothing will install or uninstall now. stuck.

----------
components: Installation, Windows
files: log.txt
messages: 236965
nosy: Ryan Neve, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to install Python 3.4.3 amd64 on Windows 8.1
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38286/log.txt

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

From report at bugs.python.org  Mon Mar  2 09:21:16 2015
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Bleuse?=)
Date: Mon, 02 Mar 2015 08:21:16 +0000
Subject: [New-bugs-announce] [issue23559] [doc] inconsistent range example
	output
Message-ID: <1425284476.5.0.408396499523.issue23559@psf.upfronthosting.co.za>


New submission from Rapha?l Bleuse:

Reading the documentation for ranges (see https://docs.python.org/3.5/library/stdtypes.html#ranges), the example using a negative index output is inconsistent with the range effective behaviour.

One can read:
"
>>> r[-1]
18
"

while (in my understanding) it should be:
"
>>> r[-1]
8
"

Note the output should be 8 and not 18.

Rapha?l

----------
assignee: docs at python
components: Documentation
messages: 237029
nosy: bleuse, docs at python
priority: normal
severity: normal
status: open
title: [doc] inconsistent range example output
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar  2 10:28:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 09:28:10 +0000
Subject: [New-bugs-announce] [issue23560] Group the docs of similar methods
	in stdtypes.rst
Message-ID: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The Doc/library/stdtypes.rst page describes in detail the built-in types and their methods.  As suggested in #21777 (see the comments on Rietveld), it might be a good idea to group the documentation of some similar methods, such as {r|l|}just, {r|l|}strip, {r|}partition, {r|}index, and {r|}find.

This will remove some duplication, make the page shorter and easier to navigate, and make the methods easier to discover.  Adding tables containing the methods for each types has also been proposed.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 237036
nosy: docs at python, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Group the docs of similar methods in stdtypes.rst
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar  2 11:42:30 2015
From: report at bugs.python.org (Novice Live)
Date: Mon, 02 Mar 2015 10:42:30 +0000
Subject: [New-bugs-announce] [issue23561] a little typo in dis.rst;
	need a non-trivial preceding dot
Message-ID: <1425292950.76.0.483712370522.issue23561@psf.upfronthosting.co.za>


New submission from Novice Live:

it is likely that the author of dis.rst omitted two non-trivial preceding dots.

in the 'Bytecode analysis' section,
both :meth:`dis` and :func:`dis` have no preceding dots before 'dis'.

the dots may be trivial elsewhere, but they are non-trivial here. 
otherwise, the hyperlinks will be unexpectedly targeted to the top of the dis module, rather than the corresponding dis method or function.

ref.
:meth:`.timeit`, where the 'timeit' was preceded by a dot, in timeit.rst.

:)

----------
assignee: docs at python
components: Documentation
files: dis_typo.patch
keywords: patch
messages: 237039
nosy: docs at python, n0vicelive
priority: normal
severity: normal
status: open
title: a little typo in dis.rst; need a non-trivial preceding dot
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38297/dis_typo.patch

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

From report at bugs.python.org  Mon Mar  2 15:37:41 2015
From: report at bugs.python.org (Maxime S)
Date: Mon, 02 Mar 2015 14:37:41 +0000
Subject: [New-bugs-announce] [issue23562] file.read() followed by
	file.write() result in incorrect	behavior
Message-ID: <1425307061.83.0.558328246639.issue23562@psf.upfronthosting.co.za>


New submission from Maxime S:

Observed Behavior:

$python3
Python 3.5.0a1+ (default, Mar  2 2015, 14:30:05) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("test", "w+")
>>> f.write("Hello World")
11
>>> f.seek(0)
0
>>> f.read(5)
'Hello'
>>> f.write(" people")
7
>>> f.seek(0)
0
>>> f.read()
'Hello World people'


Expected Behavior

According to POSIX, the last f.read() should return "Hello people", like in Python 2:


$ python2
Python 2.7.3 (default, Feb 27 2014, 20:00:17) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("test", "w+")
>>> f.write("Hello World")
>>> f.seek(0)
>>> f.read(5)
'Hello'
>>> f.write(" people")
>>> f.seek(0)
>>> f.read()
'Hello people'

Workaround:

f.seek(f.tell()) immediately after f.read(5) restore the correct behavior.

----------
components: IO
messages: 237046
nosy: Maxime S
priority: normal
severity: normal
status: open
title: file.read() followed by file.write() result in incorrect 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/issue23562>
_______________________________________

From report at bugs.python.org  Mon Mar  2 16:05:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 15:05:03 +0000
Subject: [New-bugs-announce] [issue23563] Faster urllib.urlparse utility
	functions
Message-ID: <1425308703.33.0.595640490502.issue23563@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch optimizes utility functions in the urllib.parse module.

$ ./python -m timeit -s "from urllib.parse import splittype" -- "splittype('type:'+'x'*1000)"
Unpatched: 100000 loops, best of 3: 17 usec per loop
Patched:   100000 loops, best of 3: 15 usec per loop

$ ./python -m timeit -s "from urllib.parse import splithost" -- "splithost('//www.example.org:80/foo/bar/baz.html')"
Unpatched: 100000 loops, best of 3: 12.7 usec per loop
Patched:   100000 loops, best of 3: 10.6 usec per loop

$ ./python -m timeit -s "from urllib.parse import splithost" -- "splithost('//www.example.org:80')"
Unpatched: 100000 loops, best of 3: 9.34 usec per loop
Patched:   100000 loops, best of 3: 9.09 usec per loop

$ ./python -m timeit -s "from urllib.parse import splituser" -- "splituser('username:password at example.org:80')"
Unpatched: 100000 loops, best of 3: 8.76 usec per loop
Patched:   100000 loops, best of 3: 3.1 usec per loop

$ ./python -m timeit -s "from urllib.parse import splituser" -- "splituser('example.org:80')"
Unpatched: 100000 loops, best of 3: 5.89 usec per loop
Patched:   100000 loops, best of 3: 1.98 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitpasswd" -- "splitpasswd('username:password')"
Unpatched: 100000 loops, best of 3: 7.38 usec per loop
Patched:   100000 loops, best of 3: 3.08 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitpasswd" -- "splitpasswd('username')"
Unpatched: 100000 loops, best of 3: 5.35 usec per loop
Patched:   100000 loops, best of 3: 1.92 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitnport" -- "splitnport('example.org:80')"
Unpatched: 100000 loops, best of 3: 13.2 usec per loop
Patched:   100000 loops, best of 3: 6.58 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitnport" -- "splitnport('example.org')"
Unpatched: 100000 loops, best of 3: 6.03 usec per loop
Patched:   100000 loops, best of 3: 2.37 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitquery" -- "splitquery('/path?query')"
Unpatched: 100000 loops, best of 3: 8.03 usec per loop
Patched:   100000 loops, best of 3: 3.01 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitquery" -- "splitquery('/path')"
Unpatched: 100000 loops, best of 3: 5.21 usec per loop
Patched:   1000000 loops, best of 3: 1.91 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitvalue" -- "splitvalue('attr=value')"
Unpatched: 100000 loops, best of 3: 7.37 usec per loop
Patched:   100000 loops, best of 3: 2.97 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitvalue" -- "splitvalue('attr')"
Unpatched: 100000 loops, best of 3: 5.13 usec per loop
Patched:   1000000 loops, best of 3: 1.9 usec per loop

This functions are not documented but used in the stdlib and third-party code.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: urlparse_split_faster.patch
keywords: patch
messages: 237048
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster urllib.urlparse utility functions
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file38300/urlparse_split_faster.patch

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

From report at bugs.python.org  Mon Mar  2 17:50:12 2015
From: report at bugs.python.org (Hisham Muhammad)
Date: Mon, 02 Mar 2015 16:50:12 +0000
Subject: [New-bugs-announce] [issue23564] Patch fixing sanity check for
	ordered fd sequence in	_posixsubprocess.c
Message-ID: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za>


New submission from Hisham Muhammad:

In Modules/_posixsubprocess.c, (the helper module for Lib/subprocess.py) there's a function called _sanity_check_python_fd_sequence which checks, as its comment says, if the fds in the sequence are all positive and sorted.

The check to verify if it is sorted is incorrect (missing the update to the prev_fd variable), and also it is missing a test to see if fd's are repeated (which they shouldn't be, so the test should use <= rather than <). 

The attached patch, written against Python 3.4.3 source code, fixes it.

----------
components: Extension Modules
files: python-3.4.3-_posixsubprocess.c.fix.patch
keywords: patch
messages: 237061
nosy: Hisham Muhammad
priority: normal
severity: normal
status: open
title: Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c
versions: Python 3.4
Added file: http://bugs.python.org/file38302/python-3.4.3-_posixsubprocess.c.fix.patch

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

From report at bugs.python.org  Mon Mar  2 20:45:23 2015
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 02 Mar 2015 19:45:23 +0000
Subject: [New-bugs-announce] [issue23565] local_clear walks the list of
	threads without holding	head_lock.
Message-ID: <1425325523.34.0.879276411027.issue23565@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach:

local_clear in _threadmodule.c walks the list of threads without holding head_mutex.  Since the list of threads can change when holding only head_mutex and not on the GIL, the list can change while local_clear is executing, which may cause Bad Things to happen.

----------
components: Library (Lib)
messages: 237078
nosy: stutzbach
priority: normal
severity: normal
status: open
title: local_clear walks the list of threads without holding head_lock.
type: behavior

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

From report at bugs.python.org  Tue Mar  3 01:00:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 00:00:15 +0000
Subject: [New-bugs-announce] [issue23566] RFE: faulthandler.register()
	should support file	descriptors
Message-ID: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, functions of the faulthandler module require a file-like object (with a fileno() method). It would be nice to accept also file descriptors (int).

Example of code using faulthandler which creates an useless file object just to pass a file descriptor:
https://github.com/nicoddemus/pytest-faulthandler/blob/master/pytest_faulthandler.py#L13

----------
keywords: easy
messages: 237091
nosy: haypo
priority: normal
severity: normal
status: open
title: RFE: faulthandler.register() should support file descriptors
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  3 02:16:11 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 03 Mar 2015 01:16:11 +0000
Subject: [New-bugs-announce] [issue23567] os.stat() tuple access vs named
	attribute access int vs	float
Message-ID: <1425345371.02.0.709789700046.issue23567@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
>>> import os, stat
>>> os.stat('/')
posix.stat_result(st_mode=16877, st_ino=2, st_dev=64513L, st_nlink=29, st_uid=0, st_gid=0, st_size=4096, st_atime=1425341751, st_mtime=1424824650, st_ctime=1424824650)
>>> x =os.stat('/')
>>> x.st_mtime
1424824650.653934
>>> x[stat.ST_MTIME]
1424824650
>>> os.stat_result
<type 'posix.stat_result'>


I have also confirmed the same behavior in 3.4.2.

This may be intentional.  Tuple [stat.ST_XXX] access to the stat return value is the old legacy way to access these prior to Python 2.2 when the stat_result object was introduced.  At that point they were likely all ints.

The os.stat_float_times() API exists to change the behavior of stat_result objects to return ints instead of floats by default, but the behavior of the tuple indexed values is always ints.

We need to explicitly document this behavior difference.  Changing the legacy tuple indexing behavior to return a float would likely break code.

Why file this?  We just ran into a bug due to code comparing a [stat.ST_MTIME] value to a stored stat_result.st_mtime thus continually reporting a difference due to the precision difference between the two but the numeric comparison doing its job regardless.

----------
components: Library (Lib)
messages: 237099
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: os.stat() tuple access vs named attribute access int vs float
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 09:36:25 2015
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Tue, 03 Mar 2015 08:36:25 +0000
Subject: [New-bugs-announce] [issue23568] unittest.mock.MagicMock doesn't
	support __rdivmod__t
Message-ID: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>


New submission from Zygmunt Krynicki:

Hey.

I'm the upstream developer of padme https://github.com/zyga/padme -- the mostly transparent proxy class for Python. While working on unit tests for proxying numeric methods I realized that there are a few bugs in the mock library.

The bug I'd like to report now is that __rdivmod__ cannot be mocked by MagicMock. This seems to be caused by the fact that it is listed as magic but not as numeric (for which right-hand-side variants are created).

Note that it cannot be simply added to numeric as it doesn't have the augmented assignment variant (there is no __idivmod__).

The bug is present in all versions of Python that come with unittest.mock (3.3, 3.4 and 3.5) and it is also present in the upstream/standalone version of mock

----------
components: Library (Lib)
messages: 237112
nosy: zkrynicki
priority: normal
severity: normal
status: open
title: unittest.mock.MagicMock doesn't support __rdivmod__t
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 09:41:21 2015
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Tue, 03 Mar 2015 08:41:21 +0000
Subject: [New-bugs-announce] [issue23569] unittest.mock.MagicMock.__div__
	works but __truediv__	doesn't (3.3 only)
Message-ID: <1425372081.7.0.586383148765.issue23569@psf.upfronthosting.co.za>


New submission from Zygmunt Krynicki:

Hey.

I'm the upstream developer of padme https://github.com/zyga/padme -- the mostly transparent proxy class for Python. While working on unit tests for proxying numeric methods I realized that there are a few bugs in the mock library.

The bug I'd like to report now is that __truemod__ cannot be mocked by MagicMock but __div__ can (despite __div__ being gone from Python 3 entirely). This bug is specific to Python 3.3 and it is fixed in 3.4 and 3.5a1

----------
messages: 237113
nosy: zkrynicki
priority: normal
severity: normal
status: open
title: unittest.mock.MagicMock.__div__ works  but  __truediv__ doesn't (3.3 only)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar  3 10:49:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 09:49:16 +0000
Subject: [New-bugs-announce] [issue23570] Change "with subprocess.Popen():"
	(context manager) to	ignore broken pipe error
Message-ID: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The Popen.communicate() method ignores broken pipe error when writing to stdin. I propose to modify Popen.__exit__() to do the same in Python 3.5.

Attached patch implements this suggestion and document it. I added this paragraph to Popen doc:

"The context manager ignores broken pipe errors when closing the process?s stdin: call explicitly proc.stdin.flush() and proc.stdin.close() to get broken pipe errors."

So it's still possible to get broken pipe errors if you need them.

Do you know applications or libraries which rely on broken pipe errors and do something different than just ignoring them?

I prefer to leave Python 3.4 unchanged to avoid subtle behaviour changes in minor Python releases.

See also:

- issue #21619 which modified Popen.__exit__() to call wait() even if stdin.close() raised an exception
- issue #19612 which modified communicate() to handle EINVAL on stdin.write() on Windows

----------
files: popen_exit.patch
keywords: patch
messages: 237115
nosy: haypo, serhiy.storchaka, vadmium
priority: normal
severity: normal
status: open
title: Change "with subprocess.Popen():" (context manager) to ignore broken pipe error
versions: Python 3.5
Added file: http://bugs.python.org/file38311/popen_exit.patch

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

From report at bugs.python.org  Tue Mar  3 12:58:41 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 11:58:41 +0000
Subject: [New-bugs-announce] [issue23571] Raise SystemError if a function
	returns a result with an	exception set
Message-ID: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch changes PyObject_Call() and PyCFunction_Call() to raise a SystemError and destroy the result (Py_DECREF) if a function returns a result with an exception set.

I also refactored PyCFunction_Call() and added "assert(!PyErr_Occurred());" at the beginning of PyCFunction_Call().

I removed duplicate checks in ceval.c.

--

I didn't check the impact on performances.

If the patch has a significant overhead: _Py_CheckFunctionResult() may be marked to be inlined, and PyCFunction_Call() and PyObject_Call() checks may be marked as unlikely using GCC __builtin_expect(), something like:

#ifdef __GNUC__
#  define Py_likely(x)       __builtin_expect((x),1)
#  define Py_unlikely(x)     __builtin_expect((x),0)
#else
#  define Py_likely(x)       x
#  define Py_unlikely(x)     x
#endif

Be careful of __builtin_expect(), misused it can make the code slower! (benchmark, benchmark, benchmark!)

----------
components: Interpreter Core
messages: 237123
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Raise SystemError if a function returns a result with an exception set
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  3 13:17:09 2015
From: report at bugs.python.org (Sergio Pascual)
Date: Tue, 03 Mar 2015 12:17:09 +0000
Subject: [New-bugs-announce] [issue23572] functools.singledispatch fails
	when "not BaseClass" is	True
Message-ID: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>


New submission from Sergio Pascual:

I admit this case is rather convoluted, but I have been debugging a few hours so I think I should share my findings.

I have a metaclass MetaA that provides to the classes constructed with it have a dictionary interface. Of all the functions only __len__ is important. In some cases, the result of __len__ is 0 and that is what triggers the error

class MetaA(type):
    def __len__(self):
        return 0

class A(metaclass=MetaA):
    pass

class AA(A):
    pass

Now, I construct a function with single dispatch and register the case of class A but not the class AA

@singledispatch
def fun(a):
    print('base case')

@fun.register(A)
def _(a):
    print('fun A')

And then, call fun with an object of class AA

fun(AA())

This should call the function for the class up in the hierarchy, A
Instead it raises an exception 

RuntimeError: Inconsistent hierarchy

in function functools._c3_merge
because in the line

if not candidate:
    raise RuntimeError("Inconsistent hierarchy")

"not candidate" evaluates to True due to __len__ returning 0


This can be avoided by:

* adding __nonzero__ to MetaA

* not adding the map interface to a class in the first place

* changing the code in _c3_merge 

I'm not really sure, but instead of:

if not candidate:
    raise RuntimeError("Inconsistent hierarchy")

would this work?

if candidate is None:
    raise RuntimeError("Inconsistent hierarchy")


I attach a test case

----------
components: Library (Lib)
files: singledispatch-test.py
messages: 237126
nosy: Sergio Pascual
priority: normal
severity: normal
status: open
title: functools.singledispatch fails when "not BaseClass" is True
versions: Python 3.4
Added file: http://bugs.python.org/file38314/singledispatch-test.py

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

From report at bugs.python.org  Tue Mar  3 14:53:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 13:53:30 +0000
Subject: [New-bugs-announce] [issue23573] Avoid redundant allocations in
	str.find and like
Message-ID: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently str.find() and similar methods can make a copy of self or searched string if they have different kinds. In some cases this is redundant because the result can be known before trying to search. Longer string can't be found in shorter string and wider string can't be found in narrower string. Proposed patch avoid creating temporary widened copies in such corner cases. It also adds special cases for searching 1-character strings.

Some sample microbenchmark results:

$ ./python -m timeit -s "a = 'x'; b = 'x\U00012345'" -- "b.find(a)"
Unpatched: 1000000 loops, best of 3: 1.92 usec per loop
Patched:   1000000 loops, best of 3: 1.03 usec per loop

$ ./python -m timeit -s "a = 'x'; b = 'x\U00012345'" -- "a in b"
Unpatched: 1000000 loops, best of 3: 0.543 usec per loop
Patched:   1000000 loops, best of 3: 0.25 usec per loop

$ ./python -m timeit -s "a = '\U00012345'; b = 'x'*1000" -- "b.find(a)"
Unpatched: 100000 loops, best of 3: 4.58 usec per loop
Patched:   1000000 loops, best of 3: 0.969 usec per loop

$ ./python -m timeit -s "a = 'x'*1000; b = '\U00012345'" -- "b.find(a)"
Unpatched: 100000 loops, best of 3: 3.77 usec per loop
Patched:   1000000 loops, best of 3: 0.97 usec per loop

$ ./python -m timeit -s "a = 'x'*1000; b = '\U00012345'" -- "a in b"
Unpatched: 100000 loops, best of 3: 2.4 usec per loop
Patched:   1000000 loops, best of 3: 0.225 usec per loop

----------
components: Interpreter Core
files: str_find_faster.patch
keywords: patch
messages: 237137
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid redundant allocations in str.find and like
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file38315/str_find_faster.patch

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

From report at bugs.python.org  Tue Mar  3 15:42:23 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 14:42:23 +0000
Subject: [New-bugs-announce] [issue23574] datetime: support leap seconds
Message-ID: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>


New submission from STINNER Victor:

A leap second will be added in June 2015:
http://www.usatoday.com/story/tech/2015/01/08/computer-chaos-feares/21433363/

The datetime module explicitly doesn't support leap seconds:
https://docs.python.org/dev/library/datetime.html#datetime.date.fromtimestamp
"Note that on non-POSIX systems that include leap seconds in their notion of a timestamp, leap seconds are ignored by fromtimestamp()."

The following bug in oslo.utils was reported because datetime is indirectly used to unserialize a date, but it fails with ValueError("second must be in 0..59") if the second is 60:
https://bugs.launchpad.net/oslo.utils/+bug/1427212

Would it be possible to silently drop ignore leap seconds in datetime.datetime constructor, as already done in datetime.datetime.fromtimestamp?

Attached patch modified datetime constructor to drop leap seconds: replace second=60 with second=59. I also changed the error message for second (valid range is now 0..60).

----------
components: Library (Lib)
messages: 237142
nosy: belopolsky, haypo
priority: normal
severity: normal
status: open
title: datetime: support leap seconds
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  3 17:27:17 2015
From: report at bugs.python.org (Simon Hoinkis)
Date: Tue, 03 Mar 2015 16:27:17 +0000
Subject: [New-bugs-announce] [issue23575] MIPS64 needs ffi's n32.S
Message-ID: <1425400037.86.0.872792301422.issue23575@psf.upfronthosting.co.za>


New submission from Simon Hoinkis:

MIPS64 needs ffi's n32.S linking in for _ctypes to work otherwise build errors will occur (e.g. python-setuptools).

----------
components: ctypes
files: mips64.patch
keywords: patch
messages: 237150
nosy: Simon Hoinkis
priority: normal
severity: normal
status: open
title: MIPS64 needs ffi's n32.S
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file38320/mips64.patch

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

From report at bugs.python.org  Tue Mar  3 17:56:13 2015
From: report at bugs.python.org (Cory Benfield)
Date: Tue, 03 Mar 2015 16:56:13 +0000
Subject: [New-bugs-announce] [issue23576] HTTPS reads can block when content
	length not available	and timeout set.
Message-ID: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>


New submission from Cory Benfield:

Initially reported on the requests bug list at https://github.com/kennethreitz/requests/issues/2467

In cases when a remote web server sends a non-chunked response that does not have a content length, it is possible to get http.client to hang on a read. To hit it requires a specific set of circumstances:

- Python 3 (this bug is not seen on Python 2 in my testing)
- HTTPS (using plaintext HTTP resolves the problem)
- A socket timeout must be set (leaving it unset, i.e. leaving the socket in blocking mode, resolves this problem)
- The server must not send a content-length or set Transfer-Coding: chunked.
- The reads must not be an even divisor of the content's length.
- The timeout must be longer than the time the server is willing to keep the connection open (otherwise an exception is thrown).

The following code can be used as a sample to demonstrate the bug:

import http.client
import time

def test(connection_class=http.client.HTTPSConnection, timeout=10, read_size=7):
    start = time.time()
    c = connection_class('sleepy-reaches-6892.herokuapp.com')
    c.connect()
    if timeout is not None:
        c.sock.settimeout(timeout)
    c.request('GET', '/test')
    r = c.getresponse()
    while True:
        data = r.read(read_size)
        if not data:
            break
    print('Finished in {}'.format(time.time() - start))


Below are the results from several different runs:

test(): Finished in 4.8294830322265625
test(connection_class=http.client.HTTPConnection): Finished in 0.3060309886932373
test(timeout=None): Finished in 0.6070599555969238
test(read_size=2): Finished in 0.6600658893585205

As you can see, only this particular set of features causes the bug. Note that if you change the URL to one that does return a Content-Length (e.g. http2bin.org/get), this bug also goes away.

This is a really weird edge case bug. There's some extensive investigation over at the requests bug report, but I've not been able to convincingly point at the problem yet.

----------
components: Library (Lib)
messages: 237151
nosy: Lukasa
priority: normal
severity: normal
status: open
title: HTTPS reads can block when content length not available and timeout set.
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  3 17:58:55 2015
From: report at bugs.python.org (Alex Shkop)
Date: Tue, 03 Mar 2015 16:58:55 +0000
Subject: [New-bugs-announce] [issue23577] Add tests for wsgiref.validate
Message-ID: <1425401935.54.0.320750128573.issue23577@psf.upfronthosting.co.za>


New submission from Alex Shkop:

These tests increase coverage of wsgiref.validate module. They test InputWrapper and ErrorWrapper used to validate env['wsgi.input'] and env['wsgi.errors'].

----------
components: Tests
files: wsgiref_test_wrappers.patch
keywords: patch
messages: 237152
nosy: ashkop
priority: normal
severity: normal
status: open
title: Add tests for wsgiref.validate
versions: Python 3.5
Added file: http://bugs.python.org/file38321/wsgiref_test_wrappers.patch

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

From report at bugs.python.org  Tue Mar  3 18:03:05 2015
From: report at bugs.python.org (Alistair Lynn)
Date: Tue, 03 Mar 2015 17:03:05 +0000
Subject: [New-bugs-announce] [issue23578] struct.pack error messages do not
	indicate which	argument was invalid
Message-ID: <1425402185.63.0.203193056814.issue23578@psf.upfronthosting.co.za>


New submission from Alistair Lynn:

In this example:

  struct.pack('!hhhh', 0x5FFF, 0x6FFF, 0x7FFF, 0x8FFF)

Python errors that the 'h' format requires -32768 <= number <= 32767, but it does not indicate which of the arguments is at fault. In this contrived example it's clearly the fourth one, but in dealing with large amounts of data it would be useful to indicate which argument was invalid.

This would hopefully not be a functional change, just a slightly more helpful error message.

----------
components: Library (Lib)
messages: 237153
nosy: alynn
priority: normal
severity: normal
status: open
title: struct.pack error messages do not indicate which argument was invalid
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Mar  3 22:43:51 2015
From: report at bugs.python.org (Edrie Ddrie)
Date: Tue, 03 Mar 2015 21:43:51 +0000
Subject: [New-bugs-announce] [issue23579] Amazon.com links
Message-ID: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>


New submission from Edrie Ddrie:

Keywords:easy
Priority: normal

----------
assignee: docs at python
components: Documentation
messages: 237160
nosy: Edrie Ddrie, docs at python
priority: normal
severity: normal
status: open
title: Amazon.com links
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  3 22:44:50 2015
From: report at bugs.python.org (Edrie Ddrie)
Date: Tue, 03 Mar 2015 21:44:50 +0000
Subject: [New-bugs-announce] [issue23580] Amazon.com links
Message-ID: <1425419090.93.0.681413466025.issue23580@psf.upfronthosting.co.za>


New submission from Edrie Ddrie:

Keywords: easy
Priority: normal

----------
assignee: docs at python
components: Documentation
messages: 237161
nosy: Edrie Ddrie, docs at python
priority: normal
severity: normal
status: open
title: Amazon.com links
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar  4 10:27:01 2015
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Wed, 04 Mar 2015 09:27:01 +0000
Subject: [New-bugs-announce] [issue23581] unittest.mock.MagicMock doesn't
	support matmul (@)	operator
Message-ID: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>


New submission from Zygmunt Krynicki:

Hi. I'm the upstream of Padme, a mostly transparent proxy library for Python. I was adding support for the new matmul/@ operator when I noticed that MagicMock doens't support it yet.

>>> form unittest.mock import MagicMock
>>> MagicMock() @ 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for @: 'MagicMock' and 'int'

To add support simply add 'matmul' to unittest.mock.numerics.

----------
components: Library (Lib)
messages: 237176
nosy: zkrynicki
priority: normal
severity: normal
status: open
title: unittest.mock.MagicMock doesn't support matmul (@) operator
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar  4 11:15:48 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_Mart=C3=ADnez?=)
Date: Wed, 04 Mar 2015 10:15:48 +0000
Subject: [New-bugs-announce] [issue23582] multiprocessing.Queue.get is not
	getting all the items	in the queue
Message-ID: <1425464148.59.0.542661724106.issue23582@psf.upfronthosting.co.za>


New submission from Roberto Mart?nez:

We face yesterday a bug in a project, and after a few hours of investigation we found a bad/not documented behavior in multiprocessing.Queue.

If you put one or more items in a queue and if the items are large, there is a delay between the put is executed and the item is finally available in the queue. This is reasonable because the underlying thread and the pipe, but the problem is not this.

The problem is that Queue.qsize() is reporting the number of items put, Queue.empty() is returning True, and Queue.get() is raising Empty.

So, the only safe method to get all the items is as follows:

while q.qsize():                                                         
    try:                                                                 
        item = q.get_nowait()                                                   
    except Empty:                                                        
        pass

Which is not very nice.

I attach a sample file reproducing the behavior, a single process put 100 elements in a Queue and after that it tries to get all of them, I tested in python 2.7.9 and 3.4 with the same result (seems python3 is a little bit faster and you need to enlarge the items). Also if you wait between get's, the process is able to retrieve all the items.

----------
files: mpqueuegetwrong.py
messages: 237178
nosy: Roberto Mart?nez
priority: normal
severity: normal
status: open
title: multiprocessing.Queue.get is not getting all the items in the queue
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38327/mpqueuegetwrong.py

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

From report at bugs.python.org  Wed Mar  4 15:59:48 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 04 Mar 2015 14:59:48 +0000
Subject: [New-bugs-announce] [issue23583] IDLE: printing unicode subclasses
	broken (again)
Message-ID: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

This is a regression or recurrence of issue #19481. 

To reproduce, create a subclass of unicode and try and print an instance of that class:

class Foo(unicode): pass

print Foo()

results in a traceback:

Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    print Foo()
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 1353, in write
    s = unicode.__getslice__(s, None, None)
TypeError: an integer is required

because unicode.__getslice__ does not accept None for the start and end indices.

----------
messages: 237181
nosy: mjpieters
priority: normal
severity: normal
status: open
title: IDLE: printing unicode subclasses broken (again)
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  4 17:40:31 2015
From: report at bugs.python.org (John Beck)
Date: Wed, 04 Mar 2015 16:40:31 +0000
Subject: [New-bugs-announce] [issue23584] test_doctest lineendings fails in
	verbose mode
Message-ID: <1425487231.91.0.280595585638.issue23584@psf.upfronthosting.co.za>


New submission from John Beck:

Issue 8473 fixed a problem with lineendings in test_doctest, but it
appears not to work in verbose mode.  Adding verbose=False to the
doctest.testfile() invocations in test_lineendings() fixes this.
Attaching a patch to fix this for both 2.7 and 3.4.

----------
components: Tests
files: new.patch
keywords: patch
messages: 237191
nosy: jbeck
priority: normal
severity: normal
status: open
title: test_doctest lineendings fails in verbose mode
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38331/new.patch

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

From report at bugs.python.org  Thu Mar  5 00:35:49 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 04 Mar 2015 23:35:49 +0000
Subject: [New-bugs-announce] [issue23585] patchcheck doesn't depend on all
Message-ID: <1425512149.56.0.0578590803035.issue23585@psf.upfronthosting.co.za>


New submission from Robert Collins:

make patchcheck depends on the interpreter and modules being built to work correctly but the make target doesn't have this expressed. This simple patch will fix it and adds well under a second of latency for me.

cpython.hg$ make patchcheck
./python ./Tools/scripts/patchcheck.py
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Failed to import the site module
Traceback (most recent call last):
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 555, in <module>
    main()
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 541, in main
    known_paths = addusersitepackages(known_paths)
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 281, in addusersitepackages
    user_site = getusersitepackages()
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 257, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 247, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/home/robertc/work/cpython.hg/Lib/sysconfig.py", line 582, in get_config_var
    return get_config_vars().get(name)
  File "/home/robertc/work/cpython.hg/Lib/sysconfig.py", line 531, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/home/robertc/work/cpython.hg/Lib/sysconfig.py", line 403, in _init_posix
    from _sysconfigdata import build_time_vars
ImportError: No module named '_sysconfigdata'
Makefile:1640: recipe for target 'patchcheck' failed
make: *** [patchcheck] Error 1

----------
components: Interpreter Core
files: patchcheck.patch
keywords: patch
messages: 237221
nosy: rbcollins
priority: normal
severity: normal
status: open
title: patchcheck doesn't depend on all
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file38334/patchcheck.patch

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

From report at bugs.python.org  Thu Mar  5 02:44:14 2015
From: report at bugs.python.org (Charles-Axel Dein)
Date: Thu, 05 Mar 2015 01:44:14 +0000
Subject: [New-bugs-announce] [issue23586] Add classproperty to the builtin
	functions
Message-ID: <1425519854.76.0.695976269256.issue23586@psf.upfronthosting.co.za>


New submission from Charles-Axel Dein:

Similar to http://bugs.python.org/issue20659

Having a behavior that is similar to a property on a class seems intuitive enough. Is there any specific reason why it does not exist?

----------
messages: 237227
nosy: charlax
priority: normal
severity: normal
status: open
title: Add classproperty to the builtin functions
type: enhancement

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

From report at bugs.python.org  Thu Mar  5 03:33:28 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 02:33:28 +0000
Subject: [New-bugs-announce] [issue23587] asyncio: use the new
	traceback.TracebackException class
Message-ID: <1425522808.88.0.474702563408.issue23587@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3, an exception contains a traceback. A traceback contains frames which contain local variables. Sometimes, the newly raised exception is a local variable and so we get a reference cycle: exc -> traceback -> frame -> exc...

In asyncio, it's a real issue because exception objects are kept alive longer than an except block. They are stored in Future objects by Future.set_exception() (and so Task.set_exception()).

Python 3.5 has a new traceback.TracebackException (see issue #17911) which creates a light "view" which can be used to format a traceback and the view doesn't contain local variables.

It would be great if we can use it.

The problem is to that Future.result() raises the exception set in Future.set_exception(), and we except to get the traceback of the exception.

So it's unclear to me how long we must store the exception.

Maybe we can only store a traceback.TracebackException in release mode and store the full traceback object in debug mode? Such change means that enabling the debug mode may create reference cycles (compared to the new release mode), which can be very suprising and annoying.

----------
messages: 237234
nosy: haypo, rbcollins
priority: normal
severity: normal
status: open
title: asyncio: use the new traceback.TracebackException class
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar  5 05:10:08 2015
From: report at bugs.python.org (Ben Darnell)
Date: Thu, 05 Mar 2015 04:10:08 +0000
Subject: [New-bugs-announce] [issue23588] Errno conflicts in ssl.SSLError
Message-ID: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>


New submission from Ben Darnell:

ssl.SSLError is a subclass of OSError but uses error codes that come from a different scope than the standard errno constants and may have conflicts. For example, on my system (OSX), ssl.SSL_ERROR_WANT_X509_LOOKUP and errno.EINTR have the same value. This would cause problems for code like the following:

  def f():
    while True:
      try:
        return ssl_sock.read()
      except OSError as e:
        if e.errno == errno.EINTR:
          continue
        raise

This function would loop endlessly on ssl.SSL_ERROR_WANT_X509_LOOKUP. (Note that I have not run into any problem like this in practice so this is not a severe issue; I just stumbled across the possibility). The EINTR case is moot now that Python itself retries on EINTR, but other conflicts are possible (the problem is also mitigated by the fact that most of the interesting errnos now have dedicated exception subtypes)

To use OSError.errno correctly, it is currently necessary to check the exact type of the exception; it is not enough to do subclass matching as is usual for exceptions. To remedy this, I propose either changing the numeric constants in the SSL module (if these are not required to match constants defined in openssl), or adding an attribute to OSError like 'errno_scope' to be used when interpreting the errno field.

----------
messages: 237239
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: Errno conflicts in ssl.SSLError
type: behavior

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

From report at bugs.python.org  Thu Mar  5 09:32:38 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 05 Mar 2015 08:32:38 +0000
Subject: [New-bugs-announce] [issue23589] Redundant sentence in FAQ
Message-ID: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

In https://docs.python.org/3/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python, two sentences of essentially the same meaning exist. I try to remove this redundancy.

----------
assignee: docs at python
components: Documentation
files: faq_fix.diff
keywords: patch
messages: 237248
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Redundant sentence in FAQ
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38339/faq_fix.diff

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

From report at bugs.python.org  Thu Mar  5 16:08:15 2015
From: report at bugs.python.org (Patrick Miller)
Date: Thu, 05 Mar 2015 15:08:15 +0000
Subject: [New-bugs-announce] [issue23590] Potential leak in
	PyFloat_AsDouble. Refcount error.
Message-ID: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>


New submission from Patrick Miller:

There is a reference counting error in PyFloat_AsDouble.

When the function calls the nb_float conversion, if the method does not return an actual float object, an exception is set, but the object is not collected.

--- Objects/floatobject.c	2014-10-08 04:18:15.000000000 -0400
+++ Objects/floatobject.c.patched	2015-03-05 09:17:15.171455648 -0500
@@ -214,6 +214,7 @@
     if (fo == NULL)
         return -1;
     if (!PyFloat_Check(fo)) {
+        Py_DECREF(fo);
         PyErr_SetString(PyExc_TypeError,
                         "nb_float should return float object");
         return -1;

----------
components: Interpreter Core
files: floatobject.c-patch
messages: 237266
nosy: Patrick Miller
priority: normal
severity: normal
status: open
title: Potential leak in PyFloat_AsDouble.  Refcount error.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38342/floatobject.c-patch

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

From report at bugs.python.org  Thu Mar  5 16:31:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Mar 2015 15:31:23 +0000
Subject: [New-bugs-announce] [issue23591] Add IntFlags
Message-ID: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is preliminary implementation of IntFlags (no docs). This is an int subclass purposed to represent a set of integer flags. It supports named constants (as IntEnum), supports bitwise operations (&, |, ~) and has funny str and repr. See discussion on Python-Ideas [1].

The patch includes tests and few examples of using IntFlags in the stdlib.

[1] http://comments.gmane.org/gmane.comp.python.ideas/32267

----------
components: Library (Lib)
files: intflags.patch
keywords: patch
messages: 237269
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add IntFlags
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38344/intflags.patch

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

From report at bugs.python.org  Thu Mar  5 20:56:55 2015
From: report at bugs.python.org (A. Skrobov)
Date: Thu, 05 Mar 2015 19:56:55 +0000
Subject: [New-bugs-announce] [issue23592] SIGSEGV on interpreter shutdown,
	with daemon threads running wild
Message-ID: <1425585415.3.0.819286404467.issue23592@psf.upfronthosting.co.za>


New submission from A. Skrobov:

I'm observing that this line of code:

https://hg.python.org/cpython/file/ec9bffc35cad/Python/ceval.c#l3010

-- causes a SIGSEGV on interpreter shutdown, after running some really convoluted Python code with daemon threads running wild.

At the time of the crash, tstate->frame==NULL, and tstate->curexc_type points to an exceptions.UnboundLocalError

I can reliably reproduce the crash, but unfortunately I cannot provide a standalone reproducer.

I'm speculating that this case is due to some daemon threads carrying on running while their variables are being destroyed from underneath them.


The traceback is probably of little use, but adding it nevertheless:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4dc15940 (LWP 10317)]
0x00000000004d5c00 in PyEval_EvalFrameEx (f=0xc0da70, throwflag=0) at Python/ceval.c:3010
3010	    if (tstate->frame->f_exc_type != NULL)
(gdb) bt                                       
#0  0x00000000004d5c00 in PyEval_EvalFrameEx (f=0xc0da70, throwflag=0) at Python/ceval.c:3010
#1  0x00000000004d6db2 in PyEval_EvalCodeEx (co=0x2aaaabe1d510, globals=0x2aaaab9c62f0, locals=0x0, args=0x2aaaaf6e9bf8, argcount=2, kws=0x2aaaaf6e9c08, kwcount=0, defs=0x2aaaabe2fb78, defcount=1, closure=0x0)
    at Python/ceval.c:3267
#2  0x00000000004d9ac9 in fast_function (func=0x2aaaabe37648, pp_stack=0x4dc13c90, n=2, na=2, nk=0) at Python/ceval.c:4131
#3  0x00000000004d96d8 in call_function (pp_stack=0x4dc13c90, oparg=1) at Python/ceval.c:4056
#4  0x00000000004d4258 in PyEval_EvalFrameEx (f=0x2aaaaf6e9a60, throwflag=0) at Python/ceval.c:2681
#5  0x00000000004d6db2 in PyEval_EvalCodeEx (co=0x2aaaabe26250, globals=0x2aaaab9c62f0, locals=0x0, args=0x2aaaaac81f48, argcount=2, kws=0x2aaaaac81f58, kwcount=0, defs=0x2aaaabe2fe88, defcount=1, closure=0x0)
    at Python/ceval.c:3267
#6  0x00000000004d9ac9 in fast_function (func=0x2aaaabe39108, pp_stack=0x4dc14230, n=2, na=2, nk=0) at Python/ceval.c:4131
#7  0x00000000004d96d8 in call_function (pp_stack=0x4dc14230, oparg=1) at Python/ceval.c:4056
#8  0x00000000004d4258 in PyEval_EvalFrameEx (f=0x2aaaaac81db8, throwflag=0) at Python/ceval.c:2681
#9  0x00000000004d99af in fast_function (func=0x2aaaaee97840, pp_stack=0x4dc14620, n=1, na=1, nk=0) at Python/ceval.c:4121
#10 0x00000000004d96d8 in call_function (pp_stack=0x4dc14620, oparg=0) at Python/ceval.c:4056
#11 0x00000000004d4258 in PyEval_EvalFrameEx (f=0xc47fe0, throwflag=0) at Python/ceval.c:2681
#12 0x00000000004d99af in fast_function (func=0x2aaaabe396f0, pp_stack=0x4dc14a10, n=1, na=1, nk=0) at Python/ceval.c:4121
#13 0x00000000004d96d8 in call_function (pp_stack=0x4dc14a10, oparg=0) at Python/ceval.c:4056
#14 0x00000000004d4258 in PyEval_EvalFrameEx (f=0x2aaaaf67bdf0, throwflag=0) at Python/ceval.c:2681
#15 0x00000000004d6db2 in PyEval_EvalCodeEx (co=0x2aaaabe26880, globals=0x2aaaab9c62f0, locals=0x0, args=0x2aaaaef75fd8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3267
#16 0x000000000056346e in function_call (func=0x2aaaabe395a0, arg=0x2aaaaef75fb0, kw=0x0) at Objects/funcobject.c:526
#17 0x000000000042182c in PyObject_Call (func=0x2aaaabe395a0, arg=0x2aaaaef75fb0, kw=0x0) at Objects/abstract.c:2529
#18 0x000000000042c0d0 in instancemethod_call (func=0x2aaaabe395a0, arg=0x2aaaaef75fb0, kw=0x0) at Objects/classobject.c:2602
#19 0x000000000042182c in PyObject_Call (func=0x2aaaaeec5060, arg=0x2aaaaaacf060, kw=0x0) at Objects/abstract.c:2529
#20 0x00000000004d8ceb in PyEval_CallObjectWithKeywords (func=0x2aaaaeec5060, arg=0x2aaaaaacf060, kw=0x0) at Python/ceval.c:3904
#21 0x000000000052358b in t_bootstrap (boot_raw=0x2aaaafab9d78) at ./Modules/threadmodule.c:614
#22 0x000000342f00677d in start_thread () from /lib64/libpthread.so.0
#23 0x000000342e4d49ad in clone () from /lib64/libc.so.6

----------
components: Interpreter Core
messages: 237283
nosy: A. Skrobov
priority: normal
severity: normal
status: open
title: SIGSEGV on interpreter shutdown, with daemon threads running wild
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar  5 22:02:38 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 Mar 2015 21:02:38 +0000
Subject: [New-bugs-announce] [issue23593] Update Windows and OS X installer
	OpenSSL to 1.0.2
Message-ID: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>


New submission from Ned Deily:

Per the discussion in Issue23476, the installers should be updated to use OpenSSL 1.0.2 to solve the shortest trust path issue documented there.

----------
components: Build
messages: 237287
nosy: ned.deily, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: Update Windows and OS X installer OpenSSL to 1.0.2
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar  5 23:09:02 2015
From: report at bugs.python.org (Jeff Zemla)
Date: Thu, 05 Mar 2015 22:09:02 +0000
Subject: [New-bugs-announce] [issue23594] Wrong variable name in traceback
Message-ID: <1425593342.12.0.612342465209.issue23594@psf.upfronthosting.co.za>


New submission from Jeff Zemla:

I've found a rather simple bug in the default CPython implementation on Mac OS X 10.9.5

1) Create a new .py file containing:

def a():
    print q

x=5


2) Open Python and run using execfile() then a(). Receive error as expected:

  File "test.py", line 2, in a
    print q
NameError: global name 'q' is not defined

3) Edit file so that "print q" is not "print x", and save.

4) Run a() (Do not use execfile!)

5) Error:

  File "test.py", line 2, in a
    print x
NameError: global name 'q' is not defined

EXPECTED: Traceback should say "print q" NOT "print x". It is reading from the file. Actually, the error in the file has been corrected-- it is the copy of the program in memory that is faulty.


Python 2.7.5 (default, Mar  9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin

----------
components: Macintosh
messages: 237293
nosy: Jeff Zemla, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Wrong variable name in traceback
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar  5 23:57:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 22:57:31 +0000
Subject: [New-bugs-announce] [issue23595] Split the math module into _math
	(C) + math (py)
Message-ID: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To implement the PEP 485 (math.isclose), I proposed to split the math module into two parts: _math (C) and math (py). The current C module is renamed to _math and a new "math" module implementd in Python is added. The math module contains "from _math import *".

Attached patch implements this idea.

math.py contains the Python implementation of the following functions:

- degrees
- fsum
- factorial
- radians

I propose to add these functions to "document" the implementation of these functions, I don't want to use the Python implementation by default.

Maybe _math.degrees() and _math.radians() can be removed, the Python implementation is enough.

I'm not sure that the C implementation of factorial() is much faster, since most part of the C code calls Python functions (boxing/unboxing). But it's probably better to keep the C implementation :-)

I don't understand how _factorial_partial_product() decide to divide the computation using the number of bits. Does it make sense to compute the number of bits in Python, since the Python int type has no limit? (only memory)

The C and Python implementations are tested by test_math.

math.py cannot be used alone: it requires floor(), isfinite(), isinf() and isnan() functions of the _math module. The "try: import _math except ImportError: pass" is only useful for unit tests.

TODO: remove SIZEOF_LONG from math.py.

We may rename Module/mathmodule.c to Module/_mathmodule.c, but it's not convinient to generate a patch if a file is renamed.

----------
files: math.patch
keywords: patch
messages: 237300
nosy: haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Split the math module into _math (C) + math (py)
versions: Python 3.5
Added file: http://bugs.python.org/file38345/math.patch

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

From report at bugs.python.org  Fri Mar  6 01:54:31 2015
From: report at bugs.python.org (Antony Lee)
Date: Fri, 06 Mar 2015 00:54:31 +0000
Subject: [New-bugs-announce] [issue23596] gzip argparse interface
Message-ID: <1425603271.14.0.91808493248.issue23596@psf.upfronthosting.co.za>


New submission from Antony Lee:

The attached patch reimplements gzip's already existing command-line interface using argparse, both to provide command-line help and to avoid manual argument parsing.

----------
components: Library (Lib)
files: gzip-argparse-cli.patch
keywords: patch
messages: 237315
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: gzip argparse interface
versions: Python 3.5
Added file: http://bugs.python.org/file38353/gzip-argparse-cli.patch

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

From report at bugs.python.org  Fri Mar  6 03:12:46 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Mar 2015 02:12:46 +0000
Subject: [New-bugs-announce] [issue23597] Allow easy display of local
	variables in log messages?
Message-ID: <1425607966.26.0.932937253201.issue23597@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue #22936 added support for easily displaying local variables in tracebacks to the unittest and traceback modules.

Would it be worth also making this capability readily available in the logging APIs that display traceback messages?

The main argument against it is that automatically logging local variables in tracebacks is a *really* good way to introduce sensitive information leaks into your log messages. "Safe repr" type objects (which automatically mask sensitive details in __repr__()) can mitigate this, but we don't provide such an object in the standard library (not even for bytes, bytearray or str, which are the typical containers for potentially sensitive data like passwords).

----------
messages: 237319
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Allow easy display of local variables in log messages?
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar  6 12:56:44 2015
From: report at bugs.python.org (Robert Greener)
Date: Fri, 06 Mar 2015 11:56:44 +0000
Subject: [New-bugs-announce] [issue23598] No backspace on curses on iTerm
	(mac)
Message-ID: <1425643004.82.0.795836967438.issue23598@psf.upfronthosting.co.za>


New submission from Robert Greener:

iTerm uses ^? for backspace which is curses.ascii.DEL, patch, makes curses.ascii.DEL use same behaviour as curses.ascii.BS

----------
files: cursesbackspace.patch
keywords: patch
messages: 237345
nosy: ragreener
priority: normal
severity: normal
status: open
title: No backspace on curses on iTerm (mac)
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38355/cursesbackspace.patch

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

From report at bugs.python.org  Fri Mar  6 23:37:16 2015
From: report at bugs.python.org (Jeff Doak)
Date: Fri, 06 Mar 2015 22:37:16 +0000
Subject: [New-bugs-announce] [issue23599] single and double quotes stripped
	upon paste into	interpreter
Message-ID: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>


New submission from Jeff Doak:

On MacBook. Copy/paste the following line into 3.4.2 interpreter session:
[?Test?][?Test?]
Results in:
[Test][Test]

Same paste into 2.7.6 is as expected:
[?Test?][?Test?]

----------
components: Macintosh
messages: 237389
nosy: Jeff Doak, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: single and double quotes stripped upon paste into interpreter
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar  7 01:43:03 2015
From: report at bugs.python.org (Peter J C Law)
Date: Sat, 07 Mar 2015 00:43:03 +0000
Subject: [New-bugs-announce] [issue23600] tizinfo.fromutc changed for tzinfo
	wih StdOffset=0, DstOffset=1
Message-ID: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>


New submission from Peter J C Law:

There's a difference in behaviour between the ``fromutc`` method on a tzinfo between Python 2 and Python 3, though only under the specific case of Summer Time in regions whose usual offset is 0.

>From what I can tell, it's the Python 3 one which is wrong, based on it no longer matching the sample implementation provided in the docs and on it appearing to report the wrong times for ``datetime.now(tz)`` when on a machine configured for BST during June 2015.
Similar results can also be achieved using a manually constructed ``datetime`` for dates during summer 2014.

I've put the python script (and sample outputs) I used to investigate in a gist at https://gist.github.com/PeterJCLaw/d8bcc168d68acf066811#file-time_issues-py. The outputs there are for pythons 2.7.9 and 3.4.0.

----------
components: Library (Lib)
messages: 237407
nosy: peterjclaw
priority: normal
severity: normal
status: open
title: tizinfo.fromutc changed for tzinfo wih StdOffset=0, DstOffset=1
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar  7 12:24:41 2015
From: report at bugs.python.org (Julian Taylor)
Date: Sat, 07 Mar 2015 11:24:41 +0000
Subject: [New-bugs-announce] [issue23601] use small object allocator for
	dict key storage
Message-ID: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>


New submission from Julian Taylor:

dictionary creation spends a not insignificant amount of time in malloc allocating keys objects. Python has a nice small object allocator that avoids a lot of this overhead and falls back to malloc for larger allocations.
Is there a reason the dictionary does not use that allocator for its keys objects?
doing so e.g. via attached incomplete patch improves small dict creation performance by 15%.

import  timeit
print(timeit.repeat("dict(a=5, b=2)"))

with change:
[0.42825599999923725, 0.4272580000015296, 0.4362329999985377]
without
[0.5160610000002634, 0.5181720000000496, 0.518421999999191]


or is there something I am overlooking and the use of PyMem_Malloc instead of PyObject_Malloc is an intentional design decision?

----------
components: Interpreter Core
files: 0001-use-small-object-allocator-for-keys-object.patch
keywords: patch
messages: 237439
nosy: jtaylor
priority: normal
severity: normal
status: open
title: use small object allocator for dict key storage
versions: Python 3.5
Added file: http://bugs.python.org/file38371/0001-use-small-object-allocator-for-keys-object.patch

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

From report at bugs.python.org  Sat Mar  7 18:06:09 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sat, 07 Mar 2015 17:06:09 +0000
Subject: [New-bugs-announce] [issue23602] Implement __format__ for Fraction
Message-ID: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>


New submission from Tuomas Suutari:

Since Decimal supports __format__, it would be nice that Fraction did too.

----------
components: Library (Lib)
messages: 237460
nosy: tuomas.suutari
priority: normal
severity: normal
status: open
title: Implement __format__ for Fraction
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar  7 21:02:06 2015
From: report at bugs.python.org (Ashish Sadanandan)
Date: Sat, 07 Mar 2015 20:02:06 +0000
Subject: [New-bugs-announce] [issue23603] MinGW-64
Message-ID: <1425758526.01.0.875818979723.issue23603@psf.upfronthosting.co.za>


New submission from Ashish Sadanandan:

I'm trying to embed Python 3.4.3 (x64) in a program compiled using MinGW-W64 g++ 4.9.2 (output from "g++ -v" attached) and Boost.Python 1.57.0. A simple example kept crashing at runtime and I managed to track it down to this testcase (which is not using Boost.Python but demonstrates why a check in Boost is failing). `python34.zip` in the `Py_SetPath()` call is a zip archive containing the entire contents of the `Lib` directory in my Python3.4 installation.


		#include <Python.h>
		#include <iostream>

		int main()
		{
			Py_SetPath(L"python34.zip");
			Py_Initialize();

			PyObject *s = PyUnicode_FromString("Hello World");
			std::cout << PyUnicode_Check(s) << std::endl;
			std::cout << PyUnicode_CheckExact(s) << std::endl;
			std::cout << PyUnicode_AsUTF8(s) << std::endl;

			PyRun_SimpleString("from time import time, ctime\n"
							   "print('Today is', ctime(time())\n)");

			Py_Finalize();
		}


I compile this using

                g++ -ID:/Tools/Python/3.4/x64/include -O0 -g3 -pedantic -Wall -Wextra -std=c++14 test.cpp -LD:/Tools/Python/3.4/x64/libs -lpython34 -o test.exe

Running test.exe results in

                0
                1
                Hello World
                Today is Sat Mar  7 12:06:53 2015

The problem is the first line of output. Creating a `PyObject` using `PyUnicode_FromString()` and then calling `PyUnicode_Check()` on the earlier result is returning `0`. The cause of this is that the `tp_flags` field somewhere within `PyObject` is `0` and `PyUnicode_Check()` performs a bitand with that and returns `0`. If I understand the docs correctly, when `PyUnicode_CheckExact()` returns true, `PyUnicode_Check()` should also return true because the former is a more stringent check than the latter.

Additional details that may or may not be relevant. I followed these steps to create `libpython34.a` for linking with g++. From an MSYS prompt 

                $ gendef.exe /C/Windows/System32/python34.dll
                $ dlltool --dllname /C/Windows/System32/python34.dll --def python34.def --output-lib libpython34.a

I also tried downloading libpython34.a from Christoph Gohlke's website (http://www.lfd.uci.edu/~gohlke/pythonlibs/#libpython) but that produces the same result.

Is this a bug, or do I not understand what `PyUnicode_Check()` is supposed to do?

----------
components: Extension Modules
files: g++dashv.txt
messages: 237472
nosy: Ashish Sadanandan
priority: normal
severity: normal
status: open
title: MinGW-64
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38381/g++dashv.txt

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

From report at bugs.python.org  Sat Mar  7 21:48:33 2015
From: report at bugs.python.org (Daiyue Weng)
Date: Sat, 07 Mar 2015 20:48:33 +0000
Subject: [New-bugs-announce] [issue23604] Python 3.4 and 2.7 installation no
	Script folder and no	pip installed
Message-ID: <1425761313.01.0.208884407276.issue23604@psf.upfronthosting.co.za>


New submission from Daiyue Weng:

Hi, I was doing a fresh installation for Python 2.7.9 (32 bit) and 3.4.3 (32 bit) (downloaded from PSF) on Win7 X64 today, and I found that there is no 'Script' folder in 'Python27' and 'Python34' folder as first child level folder, but there is one in Tools. However, I couldn't find pip within that 'Script' folder, although pip should be installed with Python by default. The other I was doing the same installation for my other PC and laptop, there was 'Script' folder (as first level child folder in 'Python27' and 'Python34') containing pip. So what is going on? how to install pip and maybe other useful scripts this way? 

'C:\Pythonxy\Lib\site-packages' contains nothing but a README file. I tried 'python -m ensurepip' in 'C:\Python34'. I got the following errors: 

Ignoring indexes: https://pypi.python.org/simple 
Collecting setuptools 
 Exception: 
 Traceback (most recent call last): 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\basecommand.py", line 232, in main 
  status = self.run(options, args) 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\commands\install.py", line 339, in run 
  requirement_set.prepare_files(finder) 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\req\req_set.py", line 333, in prepare_files 
  upgrade=self.upgrade, 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\index.py", line 326, in find_requirement 
  file_locations, url_locations = self._sort_locations(locations) 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\index.py", line 158, in _sort_locations 
  sort_path(os.path.join(path, item)) 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\index.py", line 139, in sort_path 
  if mimetypes.guess_type(url, strict=False)[0] == 'text/html': 
File "C:\Python34\lib\mimetypes.py", line 287, in guess_type 
  init() 
File "C:\Python34\lib\mimetypes.py", line 348, in init 
  db.read_windows_registry() 
File "C:\Python34\lib\mimetypes.py", line 255, in read_windows_registry 
  with _winreg.OpenKey(hkcr, subkeyname) as subkey: 
TypeError: OpenKey() argument 2 must be str without null characters or None,  not str 

I also tried 'python -m ensurepip' in 'C:\Python27'. I got some errors in Users\user_name\pip log file:

------------------------------------------------------------
C:\Python27\lib\ensurepip\__main__.py run on 03/07/15 01:47:03
Ignoring indexes: https://pypi.python.org/simple/
Downloading/unpacking setuptools
Cleaning up...
  Removing temporary dir c:\users\daiyue\appdata\local\temp\pip_build_daiyue...
Exception:
Traceback (most recent call last):
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\basecommand.py", line 122, in main
    status = self.run(options, args)
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\commands\install.py", line 278, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 1177, in prepare_files
    url = finder.find_requirement(req_to_install, upgrade=self.upgrade)
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 209, in find_requirement
    file_locations, url_locations = self._sort_locations(locations)
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 128, in _sort_locations
    sort_path(os.path.join(path, item))
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 109, in sort_path
    if mimetypes.guess_type(url, strict=False)[0] == 'text/html':
  File "C:\Python27\lib\mimetypes.py", line 290, in guess_type
    init()
  File "C:\Python27\lib\mimetypes.py", line 351, in init
    db.read_windows_registry()
  File "C:\Python27\lib\mimetypes.py", line 254, in read_windows_registry
    with _winreg.OpenKey(hkcr, subkeyname) as subkey:
TypeError: must be string without null bytes or None, not str
 

I have also tried out 64bit Python installation, but got the same result. So how to fix this? I posted the same message on comp.lang.python and Python Google group with no response so I guess i may try some luck here.

cheers

----------
components: Extension Modules
messages: 237476
nosy: Daiyue Weng
priority: normal
severity: normal
status: open
title: Python 3.4 and 2.7 installation no Script folder and no pip installed
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  8 03:36:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:36:13 +0000
Subject: [New-bugs-announce] [issue23605] Use the new os.scandir() function
	in os.walk()
Message-ID: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PEP 471 announces a huge speed up of the os.walk() function, but os.walk() was not modified yet. I just merged the implementation of os.scandir() (issue #22524), it's now time to work on os.walk().

We need a patch and benchmarks on Linux and Windows.

On NFS shares (on Linux), d_type is not filled (set to DT_UNKNOWN, so a syscall is required to get the file type). Benchmarks of os.walk() on a NFS share is also required.

----------
messages: 237504
nosy: haypo
priority: normal
severity: normal
status: open
title: Use the new os.scandir() function in os.walk()
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar  8 05:41:10 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 04:41:10 +0000
Subject: [New-bugs-announce] [issue23606] ctypes.util.find_library("c") no
	longer makes sense
Message-ID: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>


New submission from Steve Dower:

With the changes to the CRT on Windows, it no longer makes any sense to call find_library("c") or ("m") as there is no single C Runtime DLL. The new structure has a grouped and layered approach that is better for versioning, so we now link to "api-ms-win-crt-*-l1-1-0.dll" where "*" is something like "filesystem", "heap", "locale", "math", "string", etc. and the "l1-1-0" part is a version.

I don't know what the intended purpose of this function is, so I can't suggest a good replacement other than very fast deprecation in 3.4 and raising an error in 3.5. Any better suggestions?

----------
components: ctypes
messages: 237510
nosy: amaury.forgeotdarc, belopolsky, meador.inge, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ctypes.util.find_library("c") no longer makes sense
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar  8 11:35:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 10:35:01 +0000
Subject: [New-bugs-announce] [issue23607] Inconsistency in
	datetime.utcfromtimestamp(Decimal)
Message-ID: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

First, datetime.utcfromtimestamp() drops fractional part of Decimal argument:

>>> import datetime
>>> from decimal import Decimal as D
>>> datetime.datetime.utcfromtimestamp(1425808327.307651)
datetime.datetime(2015, 3, 8, 9, 52, 7, 307651)
>>> datetime.datetime.utcfromtimestamp(D(1425808327.307651))
datetime.datetime(2015, 3, 8, 9, 52, 7)

Second, it works only with C implementation. With Python implementation Decimals are not supported at all.

>>> del sys.modules['datetime']
>>> sys.modules['_datetime'] = None
>>> import datetime
>>> datetime.datetime.utcfromtimestamp(D(1425808327.307651))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/datetime.py", line 1374, in utcfromtimestamp
    t, frac = divmod(t, 1.0)
TypeError: unsupported operand type(s) for divmod(): 'decimal.Decimal' and 'float'

In 2.7 Decimals are accepted and are not truncated.

>>> import datetime
>>> from decimal import Decimal as D
>>> datetime.datetime.utcfromtimestamp(D(1425808327.307651))
datetime.datetime(2015, 3, 8, 9, 52, 7, 307651)

So this can be considered as a regression.

----------
components: Library (Lib)
messages: 237527
nosy: belopolsky, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistency in datetime.utcfromtimestamp(Decimal)
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar  8 13:34:50 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 08 Mar 2015 12:34:50 +0000
Subject: [New-bugs-announce] [issue23608] ssl.VERIFY_X509_TRUSTED_FIRST:
	Incorrect value for	versionadded
Message-ID: <1425818090.41.0.129275996711.issue23608@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Commit bb6fb47e0141 added ".. versionadded:: 3.4.5" in documentation of ssl.VERIFY_X509_TRUSTED_FIRST, but next version of Python 3.4 will be 3.4.4.

----------
assignee: benjamin.peterson
components: Documentation
messages: 237531
nosy: Arfrever, alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: ssl.VERIFY_X509_TRUSTED_FIRST: Incorrect value for versionadded
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar  8 17:31:57 2015
From: report at bugs.python.org (Hristo Venev)
Date: Sun, 08 Mar 2015 16:31:57 +0000
Subject: [New-bugs-announce] [issue23609] Export PyModuleObject in
	moduleobject.h
Message-ID: <1425832317.75.0.265889084011.issue23609@psf.upfronthosting.co.za>


New submission from Hristo Venev:

Please export PyModuleObject in moduleobject.h.

It's useful for subclassing module in C.

----------
components: Interpreter Core
messages: 237543
nosy: h.venev
priority: normal
severity: normal
status: open
title: Export PyModuleObject in moduleobject.h
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  8 18:25:36 2015
From: report at bugs.python.org (Liam Marsh)
Date: Sun, 08 Mar 2015 17:25:36 +0000
Subject: [New-bugs-announce] [issue23610] -m arg behavior
Message-ID: <1425835536.72.0.145087348423.issue23610@psf.upfronthosting.co.za>


New submission from Liam Marsh:

hello!

trying the solutions proposed by the 23546'th issue, i found that the -m argument, for packages (like tkinter, or idlelib; not io or socket), trys to find the "__main__" file, not the "__init__" file, which is the main file of any package.

is that a problem?

thank you for reading this, and have a nice day/evening!

----------
components: Interpreter Core, Library (Lib)
messages: 237546
nosy: Liam.Marsh
priority: normal
severity: normal
status: open
title: -m arg behavior
type: behavior

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

From report at bugs.python.org  Sun Mar  8 18:50:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 17:50:40 +0000
Subject: [New-bugs-announce] [issue23611] Pickle nested names with protocols
	< 4
Message-ID: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch allows Python implementation of the pickle module to pickle nested names (e.g. methods) with protocols < 4. Pickled data is compatible with old releases.

If this is good I'll write C implementation.

----------
components: Library (Lib)
files: pickle_nested_names.patch
keywords: patch
messages: 237548
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pickle nested names with protocols < 4
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38390/pickle_nested_names.patch

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

From report at bugs.python.org  Sun Mar  8 20:33:14 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 19:33:14 +0000
Subject: [New-bugs-announce] [issue23612] 3.5.0a2 Windows installer does not
	remove 3.5.0a1
Message-ID: <1425843194.22.0.54226665206.issue23612@psf.upfronthosting.co.za>


New submission from Steve Dower:

Currently, 3.5.0a1 needs to be manually removed either before or after installing 3.5.0a2 (after *should* be okay, but before is preferable).

Installing a later version should detect and remove the earlier one. This is obviously an installer bug.

----------
assignee: steve.dower
components: Windows
messages: 237556
nosy: steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 3.5.0a2 Windows installer does not remove 3.5.0a1
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar  8 20:36:00 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:36:00 +0000
Subject: [New-bugs-announce] [issue23613] searchindex.js is annoying
Message-ID: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Since I get hit by this at least once a week, I thought I'd finally report a bug. The Doc/build/html/searchindex.js file is extremely annoying when grepping through the source tree (and especially when grepping in the docs), because it's very likely to match your search *and* it seems made of a huge single line of text, meaning the grep output now fills your terminal with junk.

----------
assignee: docs at python
components: Documentation
messages: 237557
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: searchindex.js is annoying
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar  8 22:36:35 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 08 Mar 2015 21:36:35 +0000
Subject: [New-bugs-announce] [issue23614] Opaque error message on UTF-8
	decoding to surrogates
Message-ID: <1425850595.48.0.491367645605.issue23614@psf.upfronthosting.co.za>


New submission from Chris Angelico:

>>> b"\xed\xb4\x80".decode("utf-8")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position
0: invalid continuation byte

The actual problem here is that this byte sequence would decode to U+DD00, which, being a surrogate, is invalid for the encoding. It's correct to raise UnicodeDecodeError, but the text of the message is a bit obscure. I'm not sure whether the "invalid continuation byte" is talking about the "0xed in position 0" or about one of the others; 0xED is not a continuation byte, it's a start byte - and a perfectly valid one:

>>> b"\xed\x9f\xbf".decode("utf-8")
'\ud7ff'

Pike is more explicit about what the problem is:

> utf8_to_string("\xed\xb4\x80");
UTF-8 sequence beginning with 0xed 0xb4 at index 0 would decode to a
UTF-16 surrogate character.

Is this something worth fixing?

Tested on 3.4.2 and a recent build of 3.5, probably applies to most 3.x versions. (2.7 actually permits this, which is a bigger bug, but one with backward-compatibility issues.)

----------
components: Interpreter Core, Unicode
messages: 237572
nosy: Rosuav, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Opaque error message on UTF-8 decoding to surrogates
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar  9 02:21:09 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 09 Mar 2015 01:21:09 +0000
Subject: [New-bugs-announce] [issue23615] Reloading tokenize breaks
	tokenize.open()
Message-ID: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

Issue #22599 changed tokenize.open() from using builtins.open() to having a module-level reference to _builtin_open, stored by doing _builtin_open = open. However, on reloading the module, _builtin_open is pointed to tokenize.open from the last execution of the code, breaking tokenize.open():

>>> import tokenize
>>> tokenize.open
<function open at 0x7f15b660fc80>
>>> tokenize._builtin_open
<built-in function open>
>>> import imp; imp.reload(tokenize)
<module 'tokenize' from '/home/takluyver/miniconda3/envs/py34/lib/python3.4/tokenize.py'>
>>> tokenize.open
<function open at 0x7f15b660fbf8>
>>> tokenize._builtin_open
<function open at 0x7f15b660fc80>
>>> tokenize.open('foo.py')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/takluyver/miniconda3/envs/py34/lib/python3.4/tokenize.py", line 438, in open
    buffer = _builtin_open(filename, 'rb')
TypeError: open() takes 1 positional argument but 2 were given

The actual case where I'm seeing this error is nose logging a failure in a test suite, so it's not clear what is reloading tokenize, but it appears that something is. This just started failing when our Windows test system updated to Python 3.4.3.

----------
components: Library (Lib)
messages: 237588
nosy: haypo, takluyver
priority: normal
severity: normal
status: open
title: Reloading tokenize breaks tokenize.open()
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar  9 07:18:26 2015
From: report at bugs.python.org (Davide Okami)
Date: Mon, 09 Mar 2015 06:18:26 +0000
Subject: [New-bugs-announce] [issue23616] Python IDLE (2.-3.)
Message-ID: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>


New submission from Davide Okami:

Keeping pressed the undo shortcut during a cycle until returning to the cycle declaration, IDLE will react deleting the declaration [1] or overlaying it on the result/s [2] ([2] intermittently and un-effectively on cycle execution).

----------
components: IDLE
files: Schermata 2015-03-09 alle 06.53.21.png
messages: 237594
nosy: Davide Okami
priority: normal
severity: normal
status: open
title: Python IDLE (2.-3.)
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38400/Schermata 2015-03-09 alle 06.53.21.png

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

From report at bugs.python.org  Mon Mar  9 07:56:35 2015
From: report at bugs.python.org (Kentrell Johnson)
Date: Mon, 09 Mar 2015 06:56:35 +0000
Subject: [New-bugs-announce] [issue23617] Incorrect plural "includes" on
	Python Standard Library	front page
Message-ID: <1425884195.77.0.695422727516.issue23617@psf.upfronthosting.co.za>


New submission from Kentrell Johnson:

"The Python installers for the Windows platform usually includes"

should be

"The Python installers for the Windows platform usually include"

----------
assignee: docs at python
components: Documentation
messages: 237598
nosy: docs at python, kentrell.johnson
priority: normal
severity: normal
status: open
title: Incorrect plural "includes" on Python Standard Library front page
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Mar  9 10:08:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:08:33 +0000
Subject: [New-bugs-announce] [issue23618] PEP 475: handle EINTR in the
	socket module
Message-ID: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PEP 475 has been accepted and is partialy implemented. The socket module is not fully patched to handle EINTR. For example, socket.socket.connect() doesn't handle EINTR yet.

Attached patch fixes socket.connect() to handle EINTR. It should fix issue #11266 and #20611 in Python 3.5 (Python 2.7 and 3.4 will need to be patched to handle explicitly InterruptedError/OSError(EINTR) in Python).

By the way, some socket functions handle EINTR but don't recompute the timeout yet. _PyTime_monotonic() should be used.

----------
components: Extension Modules
files: connect_eintr.patch
keywords: patch
messages: 237609
nosy: haypo, neologix, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PEP 475: handle EINTR in the socket module
versions: Python 3.5
Added file: http://bugs.python.org/file38402/connect_eintr.patch

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

From report at bugs.python.org  Mon Mar  9 11:23:37 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 10:23:37 +0000
Subject: [New-bugs-announce] [issue23619] Python 3.5.0a2 installer fails
Message-ID: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>


New submission from Paul Moore:

I just tried to install the 64-bit "full installer" version, for
all users with the default options. This is on a PC that hasn't had
3.5 installed before, and doesn't have Visual Studio 2015 installed.
When it got to the step "precompiling standard library" I got an error window pop up saying "python.exe - system error. The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem." All there was was an "OK" button. Pressing that told me "Setup was successful" but then "py -3.5 -V" gives me nothing (no error, no version, just returns me to the command prompt). Same result if I do "& 'C:\Program Files\Python 3.5\python.exe' -V".

Python 3.5.0a2 (64-bit) is showing in my "Add/Remove Programs".

This is Windows 7, 64-bit.

----------
assignee: steve.dower
components: Installation, Windows
messages: 237630
nosy: pmoore, steve.dower, tim.golden, zach.ware
priority: critical
severity: normal
status: open
title: Python 3.5.0a2 installer fails
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar  9 11:35:47 2015
From: report at bugs.python.org (David Vieira-Kurz)
Date: Mon, 09 Mar 2015 10:35:47 +0000
Subject: [New-bugs-announce] [issue23620] cross-type comparison is different
	in python minor	versions
Message-ID: <1425897347.3.0.6338143252.issue23620@psf.upfronthosting.co.za>


New submission from David Vieira-Kurz:

Python internal compare function does not verify if a comparison of two objects is done by using object of the same type.

In this case python does not know how to compare DECIMAL and FLOATS and returns a FALSE instead of returning an Error.

Python should have strict rules to only allow comparison between objects is aware of but depending on the version of Python we have different behaviors:

# Output:
# Python 2.6.5 32bit -- WRONG: FLOAT seems comparable with DECIMAL (WRONG)
# Python 2.7.2 32bit -- WRONG: FLOAT seems comparable with DECIMAL (WRONG)
# Python 3.1.2 32bit -- CORRECT: FLOAT is NOT comparable with DECIMAL (CORRECT)
# Python 3.4.0 ([GCC 4.8.2] on linux) 32bit -- WRONG: FLOAT seems comparable with DECIMAL (WRONG)

A proof of concept code-snippet is attached.

----------
components: Interpreter Core
files: python-float-decimal-comparison.txt
messages: 237632
nosy: secalert
priority: normal
severity: normal
status: open
title: cross-type comparison is different in python minor versions
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38405/python-float-decimal-comparison.txt

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

From report at bugs.python.org  Mon Mar  9 13:20:12 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 12:20:12 +0000
Subject: [New-bugs-announce] [issue23621] Uninstalling Python 3.5 removes a
	"py.exe" that was	installed with Python 3.4
Message-ID: <1425903612.32.0.843947786812.issue23621@psf.upfronthosting.co.za>


New submission from Paul Moore:

When I installed Python 3.4, I included the py.exe launcher. I have just installed Python 3.5a0, then uninstalled it again, and the py.exe launcher has gone.

Either the 3.5 installer should notice that py.exe is already present and remember *not* to uninstall it, or it should warn the user when installing that continuing will take ownership of the launcher from a previous installation.

(I understand why having the same file owned by 2 installers causes problems, and that there's no easy fix, but the current behaviour is not at all friendly - I now have to reinstall Python 3.4 to fix it, or at least re-download the installer and try a repair, which might work I guess).

----------
assignee: steve.dower
components: Installation, Windows
messages: 237640
nosy: pmoore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Uninstalling Python 3.5 removes a "py.exe" that was installed with Python 3.4
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar  9 14:28:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 13:28:27 +0000
Subject: [New-bugs-announce] [issue23622] Deprecate unrecognized
	backslash+letter escapes
Message-ID: <1425907707.07.0.452600036872.issue23622@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Regular expressions use the backslash character for two functions:
1) to indicate special forms;
2) to allow special characters to be used without invoking their special meaning.

If backslash + character is not recognized as special form (1), it interpreted in meaning (2).

Usually new special forms have form backslash + ASCII letter, because unlike to other characters single ASCII letters do not have special meaning in any regular expression engine or programming language. This using the backslash with inner ASCII letter dangerous. Currently it means just this letter literally, but in future it can mean special form. For example \u and \U forms were added in 3.3 and this could break regular expression patters that use \u and \U before.

To avoid possible breaking it makes sense to reject unrecognized backslash + ASCII letter sequences. Proposed patch adds deprecation warnings when unknown escape of ASCII letter is used. The idea was proposed by Matthew Barnett [1].

[1] http://permalink.gmane.org/gmane.comp.python.devel/151657

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
files: re_deprecate_escaped_letters.patch
keywords: patch
messages: 237645
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate unrecognized backslash+letter escapes
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38406/re_deprecate_escaped_letters.patch

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

From report at bugs.python.org  Mon Mar  9 15:14:27 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 14:14:27 +0000
Subject: [New-bugs-announce] [issue23623] Python 3.5 docs need to clarify
	how to set PATH, etc
Message-ID: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>


New submission from Paul Moore:

With Python 3.5 on Windows defaulting (for all users installs) to the read-only "Program Files" directory, and with "Add Python to PATH" having problems adding the per-user "user scripts" directory to PATH, the Python 3.5 documentation needs to explain the recommended practice for running Python 3.5 from the command line on Windows. Issues that should be covered include:

- System installs with need to be run from an elevated prompt, are user installs now the recommended approach? (It's worth noting in that case that user installs re *not* recommended for older versions, as the user Scripts directory wasn't versioned until Python 3.5)
- How to add the correct directories to PATH (including the user scripts directory) - for both CMD and powershell users and in an existing shell as well as a new one (i.e, no "Python command prompt" shortcuts!)
- How to add the correct directories persistently, so they are available to all programs on startup.
- While the "py" launcher solves the problem of running Python, and some modules via -m (such as pip), many packages install console scripts which do not have an equivalent -m invocation, so "use the launcher" is not a complete solution.

The documentation should clarify where (or if) 3rd party documentation needs to comment on Windows path difficulties. For example, the pip documentation has for a long time said that the way to run pip is via the "pip" command, and until Python included the "Add to PATH" option in the installer, we regularly had to deal with user queries because the "pip" command didn't work out of the box - it would be unfortunate if Python 3.5 left 3rd parties back in that situation again.

----------
assignee: docs at python
components: Documentation, Windows
messages: 237650
nosy: docs at python, pmoore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: Python 3.5 docs need to clarify how to set PATH, etc
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 10 06:53:55 2015
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 10 Mar 2015 05:53:55 +0000
Subject: [New-bugs-announce] [issue23624] str.center inconsistent with
	format "^"
Message-ID: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

Look at this:

    >>> format("ab", "^3"), "ab".center(3)
    ('ab ', ' ab')
    >>> format("abc", "^4"), "abc".center(4)
    ('abc ', 'abc ')

I'm sure you agree this is inconsistent. As far as I can see, format relies on // (flooring) behaviour when dividing remaining space by 2, while .center relies on round (ROUND_HALF_EVEN) behaviour. One of them should be changed to match the other.

As far as I can see, documentation (in neither case) says nothing about how _exactly_ strings are centered when there is an odd number of fill characters, so I would interpret this as: we can change either. (My preference is for .center to be changed, but this is not so important. Consistency is important.)

----------
messages: 237729
nosy: Vedran.?a?i?
priority: normal
severity: normal
status: open
title: str.center inconsistent with format "^"
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 10 12:14:46 2015
From: report at bugs.python.org (=?utf-8?q?Thomas_G=C3=BCttler?=)
Date: Tue, 10 Mar 2015 11:14:46 +0000
Subject: [New-bugs-announce] [issue23625] load_module() docs: zipped eggs
	are not loaded.
Message-ID: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>


New submission from Thomas G?ttler:

Please update the docs of imp.find_module()

https://docs.python.org/2/library/imp.html#imp.find_module

zipped egg files in sys.path are not found.

Please provide a link how to find modules in sys.path like the interpreter does (with support of zipped egg files).

----------
messages: 237746
nosy: Thomas G?ttler
priority: normal
severity: normal
status: open
title: load_module() docs: zipped eggs are not loaded.

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

From report at bugs.python.org  Tue Mar 10 14:38:37 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 10 Mar 2015 13:38:37 +0000
Subject: [New-bugs-announce] [issue23626] Windows per-user install of 3.5a2
	doesn't associate .py	files with the new launcher
Message-ID: <1425994717.16.0.260924440644.issue23626@psf.upfronthosting.co.za>


New submission from Paul Moore:

Installing Python 3.5a2 with the 64-bit Windows installer using a user-level install doesn't associate .py files with the new (3.5) version of the launcher.

I encountered this when there was an existing system install of Python 3.4, so .py files remained associated with that. I presume in the absence of a previous install there would have been no association at all (but I haven't tested that).

----------
assignee: steve.dower
components: Installation, Windows
messages: 237767
nosy: pmoore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows per-user install of 3.5a2 doesn't associate .py files with the new launcher
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 10 15:26:26 2015
From: report at bugs.python.org (pushpendre rastogi)
Date: Tue, 10 Mar 2015 14:26:26 +0000
Subject: [New-bugs-announce] [issue23627] Incorrect string formatting of
	float values in Python 2.7
Message-ID: <1425997586.58.0.418147847293.issue23627@psf.upfronthosting.co.za>


New submission from pushpendre rastogi:

Hi, The string formatting module in python 2.7 incorrectly formats floating point values. The following code shows the problem

>>> print "%.10s"%(-7.7176718e-05)
-7.7176718
>> print "%.10s"%(-0.0000771767)
-7.71767e-

Ideally the code should have thrown an exception (first preference)
or it should have printed  -0.0000771767 (second preference) or -7.7176718e-05 (third preference)

----------
components: Library (Lib)
messages: 237769
nosy: pushpendre rastogi
priority: normal
severity: normal
status: open
title: Incorrect string formatting of float values in Python 2.7
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 10 15:41:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Mar 2015 14:41:42 +0000
Subject: [New-bugs-announce] [issue23628] See if os.scandir() could help
	speed up importlib
Message-ID: <1425998502.08.0.152155367822.issue23628@psf.upfronthosting.co.za>


New submission from Brett Cannon:

With os.scandir() now committed and implemented in C, it would be interesting to see if os.scandir() could provide any performance benefit to importlib. If finders can pass the DirEntry to loaders then some stat calls could potentially be saved at the expense of stale file metadata.

Even if the performance is flat and the sharing of cached information is deemed not worth it, os.scandir() might still be beneficial by ditching some custom code in importlib that exists purely to replicate Python code from os.py, like _path_isfile().

----------
assignee: brett.cannon
components: Interpreter Core
messages: 237771
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: See if os.scandir() could help speed up importlib
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 10 16:44:19 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Mar 2015 15:44:19 +0000
Subject: [New-bugs-announce] [issue23629] Default __sizeof__ is wrong for
	var-sized objects
Message-ID: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

In the stdlib, this only appears with the memoryview object, but third-party types can be affected. Attaching patch.

----------
components: Interpreter Core
messages: 237776
nosy: pitrou, serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Default __sizeof__ is wrong for var-sized objects
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 10 19:18:41 2015
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Tue, 10 Mar 2015 18:18:41 +0000
Subject: [New-bugs-announce] [issue23630] support multiple hosts in
	create_server/start_server
Message-ID: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>


New submission from Sebastien Bourdeauducq:

I would like to be able to bind asyncio TCP servers to an arbitrary list of hosts, not just either one host or all interfaces.

I propose that the host parameter of create_server and start_server can be a list of strings that describes each host. Sockets are created for the set of all addresses of all specified hosts. The list may also contain None, or the empty string, in which case all interfaces are assumed.

If a string or None is passed directly, the behavior is unchanged - so this should not break compatibility.

I can submit a patch if this feature is approved.

----------
components: asyncio
messages: 237791
nosy: gvanrossum, haypo, sebastien.bourdeauducq, yselivanov
priority: normal
severity: normal
status: open
title: support multiple hosts in create_server/start_server
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 10 22:25:28 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Mar 2015 21:25:28 +0000
Subject: [New-bugs-announce] [issue23631] 3.5 (a2) traceback regression
	snarls Idle
Message-ID: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

3.5.0a2, my Win 7 and Guido's new Win laptop: error tracebacks are mangled in a way that makes Idle severely less functional, hence 'release blocker'.  First, the normal behavior.

Python 3.5.0a2 (v3.5.0a2:0337bd7ebcb6+, Mar  9 2015, 10:29:45) [MSC v.1900 64 bi
t (AMD64)] on win32
>>> 1/0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero

Idle 3.4.3 and previous give same, with the helpful addition of the code line ('1/0'), as in batch mode tracebacks, since it uses the traceback module.  But Idle 3.5.0a2 started from the installed icon gives

>>> 1/0
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 353, in runcode
    exec(code, self.locals)
  File "<pyshell#1>", line 1, in <module>
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 126, in main
    ret = method(*args, **kwargs)
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 365, in runcode
    print_exception()
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 216, in print_exception
    print_exc(typ, val, tb)
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 211, in print_exc
    traceback.print_list(tbe, file=efile)
  File "C:\Program Files\Python 3.5\lib\traceback.py", line 22, in print_list
    for item in StackSummary.from_list(extracted_list).format():
  File "C:\Program Files\Python 3.5\lib\traceback.py", line 370, in format
    frame.filename, frame.lineno, frame.name))
AttributeError: 'tuple' object has no attribute 'filename'

>>> ================================ RESTART ================================
>>> 


run.py (as should be more or less everything in idlelib) is identical in 3.4 and 3.5.  Idle started from a command line (py -3 -m idlelib) gives an even worse result.  The Idle Shell just shows

>>> 1/0
Traceback (most recent call last):
Traceback (most recent call last):

>>> ================================ RESTART ================================
>>> 


while the following appears in the command window (Command Prompt or PowerShell).

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 353, in runcode
    exec(code, self.locals)
  File "<pyshell#0>", line 1, in <module>
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 126, in main
    ret = method(*args, **kwargs)
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 365, in runcode
    print_exception()
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 216, in print_exception
    print_exc(typ, val, tb)
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 211, in print_exc
    traceback.print_list(tbe, file=efile)
  File "C:\Program Files\Python 3.5\lib\traceback.py", line 22, in print_list
    for item in StackSummary.from_list(extracted_list).format():
  File "C:\Program Files\Python 3.5\lib\traceback.py", line 370, in format
    frame.filename, frame.lineno, frame.name))
AttributeError: 'tuple' object has no attribute 'filename'
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 359, in pollpacket
    s = self.sock.recv(BUFSIZE)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the r

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 432, in pollresponse
    message = self.pollmessage(wait)
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 384, in pollmessage
    packet = self.pollpacket(wait)
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 361, in pollpacket
    raise EOFError
EOFError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\PyShell.py", line 565, in poll_subprocess
    response = clt.pollresponse(self.active_seq, wait=0.05)
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 436, in pollresponse
    self.handle_EOF()
  File "C:\Program Files\Python 3.5\lib\idlelib\PyShell.py", line 383, in handle_EOF
    raise EOFError
EOFError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
ValueError: invalid literal for int() with base 10: '??'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\tkinter\__init__.py", line 1534, in __call__
    args = self.subst(*args)
  File "C:\Program Files\Python 3.5\lib\tkinter\__init__.py", line 1252, in _substitute
    e.num = getint_event(b)
  File "C:\Program Files\Python 3.5\lib\tkinter\__init__.py", line 1231, in getint_event
    return int(s)
SystemError: result with error in PyObject_Call


This needs to be checked on another OS, but the traceback problem does not strike me as Windows-specific.

----------
keywords: 3.3regression
messages: 237810
nosy: georg.brandl, larry, ncoghlan, terry.reedy
priority: release blocker
severity: normal
stage: needs patch
status: open
title: 3.5 (a2) traceback regression snarls Idle
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 10 22:46:41 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Mar 2015 21:46:41 +0000
Subject: [New-bugs-announce] [issue23632] memoryview doesn't allow
	tuple-indexing
Message-ID: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It is a bit of pity. A least non-sliced indexing should be able to work:

>>> import numpy as np
>>> a = np.arange(10)
>>> memoryview(a)[0]
0
>>> a = np.arange(10).reshape((2,5))
>>> a[0,1]
1
>>> memoryview(a)[0,1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: memoryview: invalid slice key

----------
messages: 237814
nosy: pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview doesn't allow tuple-indexing
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 10 23:31:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Mar 2015 22:31:54 +0000
Subject: [New-bugs-announce] [issue23633] Improve py launcher help, index,
	and doc
Message-ID: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This issue is about making coordinated changes to the py launcher doc and binary.

1. The py launcher doc is https://docs.python.org/3/using/windows.html#python-launcher-for-windows.  If one does not know where to look, it is hard to find.  Add an index entry 'py launcher' pointing here.

2. py -h lists 'launcher arguments' but does not explain the default if none is given and how to change the default.  There is way too much to say in a -h response, so I suggest just adding a reference to the doc plus the directories searched for .ini files 

See https://docs.python.org/3/using/windows.html#python-launcher-for-windows for information on the default version and how to change it with a py.ini file.  This executable looks for py.ini in <user app directory> and <py.exe install directory>. 

3. 3.4.4.1. Customization via INI files starts "Two .ini files will be searched by the launcher - py.ini in the current user?s ?application data? directory (i.e. the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA) and py.ini in the same directory as the launcher."  Add "These directories are listed as part of the output of 'py -h'.  Also add "Adding or editing a file in an all-users install directory requires logging in with an administrator account."

4. In my experience, a new install of py.exe wipes out an existing py.ini along with the py(w).exe files.  'del py.*'?  If this is intended, it should be documented.  If not (and it is a nuisance having the default reverted back to py 2), it should not happen (separate issue?).


Nick, I don't know who currently maintains py.exe, but presume you do.

----------
messages: 237817
nosy: ncoghlan, steve.dower, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve py launcher help, index, and doc
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 10 23:41:49 2015
From: report at bugs.python.org (mattip)
Date: Tue, 10 Mar 2015 22:41:49 +0000
Subject: [New-bugs-announce] [issue23634] os.fdopen reopening a read-only fd
	on windows
Message-ID: <1426027309.83.0.475753794617.issue23634@psf.upfronthosting.co.za>


New submission from mattip:

If I have a read-only fd, and I try to open it as 'w' with 

os.fdopen(fd, 'w'), 

the operation raises on linux but succeeds on windows. Python relies on the underlying clib's fdopen to return an error, which glibc does, but MSVC happily closes the original fd and returns with no error.

Would a patch to fix this be welcomed? A test demonstrating the issue is attached. The fix would be to check that the mode requested matches the mode of the argument fd.

Related issues #22259 and #21191 did not consider this case

----------
components: Windows
files: test_openfd.py
messages: 237818
nosy: mattip, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.fdopen reopening a read-only fd on windows
Added file: http://bugs.python.org/file38430/test_openfd.py

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

From report at bugs.python.org  Wed Mar 11 01:15:00 2015
From: report at bugs.python.org (Alex Zhang)
Date: Wed, 11 Mar 2015 00:15:00 +0000
Subject: [New-bugs-announce] [issue23635] Python won't install correctly.
Message-ID: <1426032900.09.0.644989151138.issue23635@psf.upfronthosting.co.za>


New submission from Alex Zhang:

Currently can't install 343 on my computer. I had 342 installed, and wanted to uninstall that for 343. Afterwards, being the idiot that I was, I deleted the files in the Python34 folder. Uninstalling gives me an error.  

There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support or package vendor.

I currently have python 342 on my computer which I am unable to uninstall since it is missing the files.

----------
components: Installation, Windows
messages: 237827
nosy: Player72, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python won't install correctly.
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 11 01:49:52 2015
From: report at bugs.python.org (Anthony Ryan)
Date: Wed, 11 Mar 2015 00:49:52 +0000
Subject: [New-bugs-announce] [issue23636] Add scgi to
	urllib.parse.uses_netloc
Message-ID: <1426034992.56.0.954148874592.issue23636@psf.upfronthosting.co.za>


New submission from Anthony Ryan:

The scgi protocol is not included in urllib.parse.uses_netloc list, while other less common protocols are (such as gopher).

I would like to see scgi get added to this list.

----------
components: Library (Lib)
files: py3bug
messages: 237831
nosy: Anthony Ryan
priority: normal
severity: normal
status: open
title: Add scgi to urllib.parse.uses_netloc
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38434/py3bug

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

From report at bugs.python.org  Wed Mar 11 09:35:04 2015
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBOxJttZWM=?=)
Date: Wed, 11 Mar 2015 08:35:04 +0000
Subject: [New-bugs-announce] [issue23637] Warnings error with non-ascii
	chars.
Message-ID: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>


New submission from Luk?? N?mec:

File "/usr/lib/python2.7/warnings.py", line 29, in _show_warning
    file.write(formatwarning(message, category, filename, lineno, line))
  File "/usr/lib/python2.7/warnings.py", line 38, in formatwarning
    s =  "%s:%s: %s: %s\n" % (filename, lineno, category.__name__, message)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xed' in position 42: ordinal not in range(128)

Only thing required to make this work is add "u" in front of the message so it is unicode. This will work for all ascii characters and all non-ascii should pass unicode anyway.

----------
components: Library (Lib)
messages: 237850
nosy: Luk??.N?mec
priority: normal
severity: normal
status: open
title: Warnings error with non-ascii chars.
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 11 11:41:47 2015
From: report at bugs.python.org (yuriy_levchenko)
Date: Wed, 11 Mar 2015 10:41:47 +0000
Subject: [New-bugs-announce] [issue23638] shutil.copytree makedirs exception
Message-ID: <1426070507.27.0.472685674051.issue23638@psf.upfronthosting.co.za>


New submission from yuriy_levchenko:

We have a code:
    names = os.listdir(src)
    if ignore is not None:
        ignored_names = ignore(src, names)
    else:
        ignored_names = set()

    os.makedirs(dst)
        
    errors = []

But if I had created this folder. I have exception.

Maybe add "if"?

    if os.path.isdir(dst) is False:
        os.makedirs(dst)
        pass

----------
components: Library (Lib)
messages: 237858
nosy: yuriy_levchenko
priority: normal
severity: normal
status: open
title: shutil.copytree makedirs exception
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar 11 12:15:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 11:15:01 +0000
Subject: [New-bugs-announce] [issue23639] Not documented special names
Message-ID: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here are lists of special names used in Python core and the stdlib, but absent in documentation index.

Module level names used in pydoc:
    __author__
    __credits__
    __date__
    __version__

Module level name used in doctest:
    __test__

Other module level names:
    __about__               (heapq only)
    __copyright__           (many modules)
    __cvsid__               (tarfile only)
    __docformat__           (doctest only)
    __email__               (test_with and test_keywordonlyarg only)
    __libmpdec_version__    (decimal only)
    __status__              (logging only)


type attributes (mostly used in tests):
    __abstractmethods__     (used in abc, functools)
    __base__
    __basicsize__
    __dictoffset__
    __flags__               (used in inspect, copyreg)
    __itemsize__
    __weakrefoffset__

super() attributes:
    __self_class__
    __thisclass__

Used in sqlite:
    __adapt__
    __conform__

Used in ctypes:
    __ctype_be__
    __ctype_le__
    __ctypes_from_outparam__

Used in unittest:
    __unittest_expecting_failure__
    __unittest_skip__
    __unittest_skip_why__

float methods, for testing:
    __getformat__
    __setformat__

Used in IDLE RPC:
    __attributes__
    __methods__

Others:
    __alloc__               (bytearray method)
    __args__                (used in bdb)
    __build_class__         (builtins function, used in eval loop)
    __builtins__            (module attribute)
    __decimal_context__     (used in decimal)
    __exception__           (used in pdb)
    __getinitargs__         (used in pickle, datetime)
    __initializing__        (used in importlib)
    __isabstractmethod__    (function/method/descriptor attribute, used in abc, functools, types)
    __ltrace__              (used in eval loop, never set)
    __members__             (Enum attribute, used in many modules)
    __mp_main__             (used in multiprocessing)
    __new_member__          (Enum attribute, used in enum internally)
    __newobj__              (copyreg function, used in pickle, object.__reduce_ex__)
    __newobj_ex__           (copyreg function, used in pickle, object.__reduce_ex__)
    __objclass__            (descriptor/enum attribute, used in inspect, pydoc, doctest, multiprocessing)
    __prepare__             (metaclass method, used in builtins.__build_class__, types)
    __pycache__             (cache directory name)
    __return__              (used in pdb)
    __signature__           (used in inspect, never set)
    __sizeof__              (standard method, used in sys.getsizeof)
    __slotnames__           (used in object.__getstate__ for caching)
    __text_signature__      (function/method/descriptor attribute, used in inspect)
    __trunc__               (used in math.trunc, int, etc)
    __warningregistry__     (used in warnings)
    __weakref__             (used in weakref)
    __wrapped__             (used in inspect, functools, contextlib, asyncio)

Needed a patch or a set of patches that will add theses names to the index and document them if they are not documented.

----------
assignee: docs at python
components: Documentation
messages: 237859
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Not documented special names
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 11 14:34:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 13:34:36 +0000
Subject: [New-bugs-announce] [issue23640] Enum.from_bytes() is broken
Message-ID: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Example:

>>> import socket
>>> x = socket.AddressFamily.from_bytes(b'\1', 'big')
>>> type(x)
<enum 'AddressFamily'>
>>> int(x)
1
>>> str(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/enum.py", line 464, in __str__
    return "%s.%s" % (self.__class__.__name__, self._name_)
AttributeError: 'AddressFamily' object has no attribute '_name_'
>>> repr(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/enum.py", line 461, in __repr__
    self.__class__.__name__, self._name_, self._value_)
AttributeError: 'AddressFamily' object has no attribute '_name_'

----------
components: Library (Lib)
messages: 237864
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Enum.from_bytes() is broken
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 11 15:42:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 14:42:14 +0000
Subject: [New-bugs-announce] [issue23641] Got rid of bad dunder names
Message-ID: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch gets rid of uses and mentions of bad dunder names. I.e. names inherited from Python 2: __cmp__, __nonzero__, __getslice__, __unicode__, __div__, etc. They are replaced by correct names (__truediv__, __floordiv__, __eq__, __bool__, etc) or removed. Also fixed typos and other minor bugs. Also added support for __matmul__ and __getnewargs_ex__ in unittest.mock and added tests for __matmul__.

----------
components: Library (Lib), Tests
files: bad_dunder_names.patch
keywords: patch
messages: 237868
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Got rid of bad dunder names
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38443/bad_dunder_names.patch

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

From report at bugs.python.org  Wed Mar 11 16:08:51 2015
From: report at bugs.python.org (David Beazley)
Date: Wed, 11 Mar 2015 15:08:51 +0000
Subject: [New-bugs-announce] [issue23642] Interaction of ModuleSpec and C
	Extension Modules
Message-ID: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>


New submission from David Beazley:

I have been investigating some of the new importlib machinery and the addition of ModuleSpec objects.  I am a little curious about the intended handling of C Extension modules going forward. 

Backing up for a moment, consider a pure Python module.  It seems that I can do things like this to bring a module into existence (some steps involving sys.modules omitted).

>>> from importlib.util import find_spec, module_from_spec
>>> spec = find_spec('socket')
>>> socket = module_from_spec(spec)
>>> spec.loader.exec_module(socket)
>>>

However, it all gets "weird" with C extension modules.  For example, you can perform the first few steps:

>>> spec = find_spec('math')
>>> spec
ModuleSpec(name='math', loader=<_frozen_importlib.ExtensionFileLoader object at 0x1012122b0>, origin='/usr/local/lib/python3.5/lib-dynload/math.so')
>>> math = module_from_spec(spec)
>>> math
<module 'math' from '/usr/local/lib/python3.5/lib-dynload/math.so'>
>>> dir(math)
['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__']

As you can see, you get a fresh "unloaded" module here.  However, if you try to bring in the module contents, things get screwy.

>>> spec.loader.exec_module(math)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'ExtensionFileLoader' object has no attribute 'exec_module'
>>>

Yes, this is the old legacy interface in action--there is no exec_module() method.   You can always fall back to load_module() like this:

>>> spec.loader.load_module(spec.name)
<module 'math' from '/usr/local/lib/python3.5/lib-dynload/math.so'>
>>>

The problem here is that it creates a brand new module and ignores the one that was previously created by module_from_spec().  That module is still empty:

>>> dir(math)
['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__']
>>> 

I realize that I'm treading into a swamp of legacy interfaces and some pretty complex machinery here.  However, here's my question:  are C extension modules always going to be a special case that need to be considered code that interacts with the import system.  Specifically, will it need to be special-cased to use load_module() instead of the module_from_spec()/exec_module() combination?

I suppose the question might also apply to built-in and frozen modules as well (although I haven't investigated that so much). 

Mainly, I'm just trying to gain some insight from the devs as to the overall direction where the import implementation is going with this.

P.S.  ModuleSpecs are cool. +1

----------
components: Interpreter Core
messages: 237872
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Interaction of ModuleSpec and C Extension Modules
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 11 18:14:04 2015
From: report at bugs.python.org (Michael Klein)
Date: Wed, 11 Mar 2015 17:14:04 +0000
Subject: [New-bugs-announce] [issue23643] Segmentation Fault with Large
	Simple Function
Message-ID: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>


New submission from Michael Klein:

I have gotten "Segmentation Fault: 11" with the newest version of Python 2.7 and nothing but standard functions. The program is of the following form (attached to this email):

def loopcountaux(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14, a15, a16, a17, a18, a19, a20, a21, a22, a23, a24, a25, a26, a27, a28, a29, a30, a31, a32, a33, a34, a35, a36, a37, a38, a39, a40, a41, a42, a43):

    loopcount = ((1-a36)*(a37)*(1-a41)) + ((a22)*(a33)*(1-a23)) + ((a27)*(a34)*(1-a28)) + ((a38)*(a43)*(1-a39)) + ((a40)*(a42)*(1-a41))+((1-a22)*(1-a33)*(a23)) + ((1-a27)*(1-a34)*(a28)) + ((1-a38)*(1-a43)*(a39)) + ((1-a40)*(1-a42)*(a41)) + ((a36)*(1-a37)*(a41))
    return loopcount

print loopcountaux(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)

The only difference between this and the file which causes the fault is the number of formulas added to the line where "loopcount" is defined (74858 more of a similar kind). Note that this program finds the number of boolean formulas from a given set which are true for given variables a1, a2,... For example, "((1-a36)*(a37)*(1-a41))" is effectively the same as "(not a36) and (a37) and (not a41)".

If this example makes debugging particularly difficult, I can try to find a less complex example, though this example is just long enough to cause a segfault (with one less statement it runs well).

Thank you for your time.

The OSX error report is as follows:

Process:               Python [8151]
Path:                  /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               2.7.9 (2.7.9)
Code Type:             X86-64 (Native)
Parent Process:        bash [3554]
Responsible:           Terminal [599]
User ID:               501

Date/Time:             2015-03-11 12:21:52.952 -0400
OS Version:            Mac OS X 10.10.2 (14C109)
Report Version:        11
Anonymous UUID:        49801587-229C-BA4D-0630-D2490825F5C7

Sleep/Wake UUID:       44D3FBEF-DC64-44CA-A10A-70E9E16AE5C2

Time Awake Since Boot: 160000 seconds
Time Since Wake:       17000 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x00007fff5f3ffff8

VM Regions Near 0x7fff5f3ffff8:
    MALLOC_SMALL           000000014e800000-0000000151000000 [ 40.0M] rw-/rwx SM=PRV  
--> STACK GUARD            00007fff5bc00000-00007fff5f400000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
    Stack                  00007fff5f400000-00007fff5fc00000 [ 8192K] rw-/rwx SM=COW  thread 0

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.python.python             	0x000000010005d734 PyObject_RichCompareBool + 4
1   org.python.python             	0x0000000100070f38 tuplerichcompare + 152
2   org.python.python             	0x000000010005cbf9 PyObject_RichCompare + 201
3   org.python.python             	0x000000010005d760 PyObject_RichCompareBool + 48
4   org.python.python             	0x0000000100052ebd lookdict + 397
5   org.python.python             	0x0000000100054900 PyDict_GetItem + 112
6   org.python.python             	0x00000001000c63a5 compiler_add_o + 277
7   org.python.python             	0x00000001000c9348 compiler_visit_expr + 840
8   org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
9   org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
10  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
11  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
12  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
13  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
14  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
15  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
16  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
17  org.python.python             	0x00000001000c9bc0 compiler_visit_expr + 3008
18  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
19  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
20  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
21  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
22  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
23  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
24  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
25  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
26  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
27  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
28  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
29  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
30  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
31  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
32  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
33  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
34  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
35  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
36  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
37  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
38  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
39  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
40  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
41  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
42  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
43  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
44  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
45  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
46  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
47  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
48  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
49  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
50  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
51  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
52  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
53  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
54  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
55  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
56  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
57  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
58  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
59  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
60  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
61  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
62  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
63  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
64  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
65  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
66  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
67  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
68  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
69  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
70  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
71  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
72  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
73  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
74  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
75  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
76  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
77  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
78  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
79  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
80  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
81  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
82  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
83  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
84  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
85  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
86  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
87  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
88  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
89  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
90  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
91  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
92  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
93  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
94  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
95  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
96  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
97  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
98  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
99  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
100 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
101 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
102 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
103 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
104 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
105 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
106 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
107 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
108 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
109 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
110 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
111 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
112 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
113 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
114 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
115 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
116 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
117 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
118 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
119 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
120 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
121 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
122 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
123 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
124 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
125 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
126 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
127 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
128 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
129 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
130 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
131 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
132 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
133 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
134 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
135 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
136 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
137 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
138 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
139 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
140 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
141 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
142 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
143 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
144 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
145 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
146 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
147 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
148 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
149 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
150 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
151 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
152 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
153 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
154 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
155 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
156 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
157 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
158 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
159 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
160 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
161 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
162 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
163 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
164 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
165 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
166 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
167 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
168 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
169 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
170 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
171 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
172 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
173 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
174 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
175 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
176 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
177 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
178 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
179 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
180 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
181 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
182 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
183 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
184 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
185 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
186 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
187 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
188 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
189 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
190 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
191 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
192 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
193 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
194 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
195 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
196 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
197 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
198 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
199 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
200 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
201 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
202 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
203 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
204 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
205 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
206 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
207 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
208 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
209 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
210 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
211 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
212 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
213 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
214 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
215 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
216 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
217 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
218 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
219 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
220 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
221 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
222 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
223 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
224 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
225 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
226 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
227 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
228 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
229 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
230 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
231 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
232 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
233 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
234 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
235 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
236 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
237 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
238 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
239 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
240 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
241 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
242 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
243 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
244 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
245 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
246 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
247 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
248 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
249 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
250 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
251 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
252 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
253 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
254 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
255 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
256 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
257 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
258 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
259 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
260 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
261 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
262 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
263 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
264 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
265 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
266 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
267 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
268 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
269 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
270 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
271 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
272 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
273 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
274 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
275 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
276 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
277 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
278 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
279 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
280 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
281 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
282 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
283 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
284 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
285 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
286 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
287 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
288 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
289 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
290 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
291 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
292 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
293 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
294 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
295 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
296 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
297 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
298 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
299 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
300 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
301 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
302 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
303 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
304 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
305 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
306 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
307 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
308 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
309 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
310 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
311 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
312 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
313 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
314 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
315 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
316 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
317 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
318 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
319 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
320 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
321 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
322 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
323 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
324 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
325 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
326 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
327 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
328 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
329 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
330 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
331 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
332 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
333 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
334 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
335 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
336 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
337 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
338 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
339 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
340 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
341 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
342 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
343 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
344 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
345 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
346 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
347 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
348 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
349 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
350 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
351 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
352 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
353 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
354 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
355 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
356 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
357 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
358 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
359 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
360 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
361 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
362 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
363 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
364 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
365 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
366 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
367 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
368 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
369 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
370 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
371 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
372 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
373 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
374 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
375 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
376 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
377 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
378 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
379 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
380 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
381 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
382 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
383 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
384 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
385 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
386 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
387 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
388 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
389 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
390 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
391 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
392 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
393 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
394 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
395 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
396 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
397 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
398 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
399 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
400 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
401 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
402 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
403 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
404 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
405 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
406 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
407 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
408 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
409 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
410 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
411 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
412 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
413 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
414 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
415 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
416 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
417 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
418 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
419 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
420 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
421 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
422 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
423 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
424 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
425 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
426 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
427 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
428 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
429 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
430 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
431 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
432 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
433 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
434 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
435 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
436 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
437 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
438 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
439 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
440 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
441 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
442 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
443 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
444 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
445 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
446 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
447 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
448 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
449 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
450 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
451 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
452 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
453 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
454 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
455 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
456 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
457 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
458 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
459 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
460 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
461 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
462 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
463 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
464 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
465 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
466 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
467 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
468 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
469 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
470 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
471 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
472 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
473 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
474 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
475 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
476 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
477 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
478 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
479 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
480 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
481 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
482 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
483 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
484 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
485 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
486 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
487 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
488 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
489 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
490 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
491 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
492 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
493 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
494 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
495 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
496 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
497 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
498 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
499 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
500 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
501 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
502 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
503 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
504 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
505 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
506 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
507 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
508 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
509 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
510 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
511 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000100182c80  rbx: 0x0000000000000000  rcx: 0x0000000100070ea0  rdx: 0x0000000000000002
  rdi: 0x000000010030e2a8  rsi: 0x000000010030e2a8  rbp: 0x00007fff5f400000  rsp: 0x00007fff5f400000
   r8: 0x0000000000000002   r9: 0x0000000000000006  r10: 0x0000000000000000  r11: 0x000000010005a130
  r12: 0x00000001004c03f8  r13: 0x0000000000000002  r14: 0x00000001004c0440  r15: 0x0000000000000002
  rip: 0x000000010005d734  rfl: 0x0000000000010202  cr2: 0x00007fff5f3ffff8
  
Logical CPU:     2
Error Code:      0x00000006
Trap Number:     14


Binary Images:
       0x100000000 -        0x100000fff +org.python.python (2.7.9 - 2.7.9) <8B6E6BCC-310B-E381-4F96-CD43435AE589> /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x100170ff7 +org.python.python (2.7.9, [c] 2004-2014 Python Software Foundation. - 2.7.9) <51C9254B-00A0-0B7D-4DC6-BE7C9295ECD6> /Library/Frameworks/Python.framework/Versions/2.7/Python
       0x1002f2000 -        0x1002f4ff7 +_locale.so (???) <4294AC62-5881-66AE-E045-59F50FDFBCA1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
    0x7fff6099c000 -     0x7fff609d2837  dyld (353.2.1) <65DCCB06-339C-3E25-9702-600A28291D0E> /usr/lib/dyld
    0x7fff87e68000 -     0x7fff87e6cfff  libcache.dylib (69) <45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1> /usr/lib/system/libcache.dylib
    0x7fff8804b000 -     0x7fff88050ff7  libunwind.dylib (35.3) <BE7E51A0-B6EA-3A54-9CCA-9D88F683A6D6> /usr/lib/system/libunwind.dylib
    0x7fff88a8e000 -     0x7fff88ab6fff  libsystem_info.dylib (459) <B85A85D5-8530-3A93-B0C3-4DEC41F79478> /usr/lib/system/libsystem_info.dylib
    0x7fff88b8f000 -     0x7fff88b91fff  libsystem_configuration.dylib (699.1.5) <5E14864E-089A-3D84-85A4-980B776427A8> /usr/lib/system/libsystem_configuration.dylib
    0x7fff88d3c000 -     0x7fff88d3dfff  libDiagnosticMessagesClient.dylib (100) <2EE8E436-5CDC-34C5-9959-5BA218D507FB> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff88de7000 -     0x7fff88df8ff7  libsystem_coretls.dylib (35.1.2) <BC691CD1-17B6-39A5-BD02-AF973695FD1D> /usr/lib/system/libsystem_coretls.dylib
    0x7fff88f07000 -     0x7fff88f10fff  libsystem_pthread.dylib (105.10.1) <3103AA7F-3BAE-3673-9649-47FFD7E15C97> /usr/lib/system/libsystem_pthread.dylib
    0x7fff8942e000 -     0x7fff89430ff7  libsystem_coreservices.dylib (9) <41B7C578-5A53-31C8-A96F-C73E030B0938> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff894e7000 -     0x7fff89512fff  libc++abi.dylib (125) <88A22A0F-87C6-3002-BFBA-AC0F2808B8B9> /usr/lib/libc++abi.dylib
    0x7fff8986c000 -     0x7fff89871ff7  libsystem_stats.dylib (163.10.18) <9B8CCF24-DDDB-399A-9237-4BEC225D2E8C> /usr/lib/system/libsystem_stats.dylib
    0x7fff898a5000 -     0x7fff898abfff  libsystem_trace.dylib (72.1.3) <A9E6B7D8-C327-3742-AC54-86C94218B1DF> /usr/lib/system/libsystem_trace.dylib
    0x7fff89a9d000 -     0x7fff89aa8fff  libcommonCrypto.dylib (60061) <D381EBC6-69D8-31D3-8084-5A80A32CB748> /usr/lib/system/libcommonCrypto.dylib
    0x7fff89aa9000 -     0x7fff89afdfff  libc++.1.dylib (120) <1B9530FD-989B-3174-BB1C-BDC159501710> /usr/lib/libc++.1.dylib
    0x7fff89afe000 -     0x7fff89b0fff7  libz.1.dylib (55) <88C7C7DE-04B8-316F-8B74-ACD9F3DE1AA1> /usr/lib/libz.1.dylib
    0x7fff89b10000 -     0x7fff89b13ff7  libdyld.dylib (353.2.1) <4E33E416-F1D8-3598-B8CC-6863E2ECD0E6> /usr/lib/system/libdyld.dylib
    0x7fff8a1f0000 -     0x7fff8a1f1fff  libSystem.B.dylib (1213) <90B107BC-FF74-32CC-B1CF-4E02F544D957> /usr/lib/libSystem.B.dylib
    0x7fff8a35f000 -     0x7fff8a367fff  libsystem_platform.dylib (63) <64E34079-D712-3D66-9CE2-418624A5C040> /usr/lib/system/libsystem_platform.dylib
    0x7fff8a512000 -     0x7fff8a588fe7  libcorecrypto.dylib (233.1.2) <E1789801-3985-3949-B736-6B3378873301> /usr/lib/system/libcorecrypto.dylib
    0x7fff8bd61000 -     0x7fff8bd68ff7  libcompiler_rt.dylib (35) <BF8FC133-EE10-3DA6-9B90-92039E28678F> /usr/lib/system/libcompiler_rt.dylib
    0x7fff8c3c4000 -     0x7fff8c3caff7  libsystem_networkextension.dylib (167.1.10) <29AB225B-D7FB-30ED-9600-65D44B9A9442> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff8d0f2000 -     0x7fff8d0f2ff7  libunc.dylib (29) <5676F7EA-C1DF-329F-B006-D2C3022B7D70> /usr/lib/system/libunc.dylib
    0x7fff8e4ba000 -     0x7fff8e500ff7  libauto.dylib (186) <A260789B-D4D8-316A-9490-254767B8A5F1> /usr/lib/libauto.dylib
    0x7fff8e8ee000 -     0x7fff8e8f6fff  libsystem_dnssd.dylib (561.1.1) <62B70ECA-E40D-3C63-896E-7F00EC386DDB> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff8efcd000 -     0x7fff8efeafff  libsystem_kernel.dylib (2782.10.72) <97CD7ACD-EA0C-3434-BEFC-FCD013D6BB73> /usr/lib/system/libsystem_kernel.dylib
    0x7fff8ff7b000 -     0x7fff8ff7bff7  libkeymgr.dylib (28) <77845842-DE70-3CC5-BD01-C3D14227CED5> /usr/lib/system/libkeymgr.dylib
    0x7fff90a05000 -     0x7fff90a91ff7  libsystem_c.dylib (1044.10.1) <199ED5EB-77A1-3D43-AA51-81779CE0A742> /usr/lib/system/libsystem_c.dylib
    0x7fff90a92000 -     0x7fff90e28fff  com.apple.CoreFoundation (6.9 - 1152) <CBD1591C-405E-376E-87E9-B264610EBF49> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff919c4000 -     0x7fff919fcffb  libsystem_network.dylib (411.1) <2EC3A005-473F-3C36-A665-F88B5BACC7F0> /usr/lib/system/libsystem_network.dylib
    0x7fff9208f000 -     0x7fff92091ff7  libsystem_sandbox.dylib (358.1.1) <95312E09-DA28-324A-A084-F3E574D0210E> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff9233a000 -     0x7fff9236afff  libsystem_m.dylib (3086.1) <1E12AB45-6D96-36D0-A226-F24D9FB0D9D6> /usr/lib/system/libsystem_m.dylib
    0x7fff9236b000 -     0x7fff92393fff  libxpc.dylib (559.10.3) <876216DC-D5D3-381E-8AF9-49AE464E5107> /usr/lib/system/libxpc.dylib
    0x7fff92680000 -     0x7fff92681fff  libsystem_secinit.dylib (18) <581DAD0F-6B63-3A48-B63B-917AF799ABAA> /usr/lib/system/libsystem_secinit.dylib
    0x7fff92f9a000 -     0x7fff92f9aff7  liblaunch.dylib (559.10.3) <DFCDEBDF-8247-3DC7-9879-E7E497DDA4B4> /usr/lib/system/liblaunch.dylib
    0x7fff92f9b000 -     0x7fff92fb1ff7  libsystem_asl.dylib (267) <F153AC5B-0542-356E-88C8-20A62CA704E2> /usr/lib/system/libsystem_asl.dylib
    0x7fff93ed9000 -     0x7fff93ef5ff7  libsystem_malloc.dylib (53.1.1) <19BCC257-5717-3502-A71F-95D65AFA861B> /usr/lib/system/libsystem_malloc.dylib
    0x7fff93fd8000 -     0x7fff93fddff7  libmacho.dylib (862) <126CA2ED-DE91-308F-8881-B9DAEC3C63B6> /usr/lib/system/libmacho.dylib
    0x7fff94003000 -     0x7fff9400bffb  libcopyfile.dylib (118.1.2) <0C68D3A6-ACDD-3EF3-991A-CC82C32AB836> /usr/lib/system/libcopyfile.dylib
    0x7fff94241000 -     0x7fff9443b46f  libobjc.A.dylib (647) <759E155D-BC42-3D4E-869B-6F57D477177C> /usr/lib/libobjc.A.dylib
    0x7fff944ba000 -     0x7fff944c3ff7  libsystem_notify.dylib (133.1.1) <61147800-F320-3DAA-850C-BADF33855F29> /usr/lib/system/libsystem_notify.dylib
    0x7fff944c4000 -     0x7fff944eeff7  libdispatch.dylib (442.1.4) <502CF32B-669B-3709-8862-08188225E4F0> /usr/lib/system/libdispatch.dylib
    0x7fff95c6e000 -     0x7fff95c6fffb  libremovefile.dylib (35) <3485B5F4-6CE8-3C62-8DFD-8736ED6E8531> /usr/lib/system/libremovefile.dylib
    0x7fff95e69000 -     0x7fff95e6bff7  libquarantine.dylib (76) <DC041627-2D92-361C-BABF-A869A5C72293> /usr/lib/system/libquarantine.dylib
    0x7fff96290000 -     0x7fff96475ff3  libicucore.A.dylib (531.31) <B08E00D5-13C6-3391-AB3A-8DE693D3B42E> /usr/lib/libicucore.A.dylib
    0x7fff97443000 -     0x7fff97444ff7  libsystem_blocks.dylib (65) <9615D10A-FCA7-3BE4-AA1A-1B195DACE1A1> /usr/lib/system/libsystem_blocks.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 1
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 7502283
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=83.7M resident=73.1M(87%) swapped_out_or_unallocated=10.5M(13%)
Writable regions: Total=323.1M written=239.8M(74%) resident=255.3M(79%) swapped_out=0K(0%) unallocated=67.8M(21%)
 
REGION TYPE                      VIRTUAL
===========                      =======
Kernel Alloc Once                     4K
MALLOC                            314.8M
MALLOC (admin)                       16K
STACK GUARD                        56.0M
Stack                              8192K
VM_ALLOCATE                           8K
__DATA                             1440K
__LINKEDIT                         70.8M
__TEXT                             12.8M
__UNICODE                           544K
shared memory                         4K
===========                      =======
TOTAL                             464.4M

Model: MacBookPro8,2, BootROM MBP81.0047.B27, 4 processors, Intel Core i7, 2.5 GHz, 8 GB, SMC 1.69f4
Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB
Graphics: AMD Radeon HD 6770M, AMD Radeon HD 6770M, PCIe, 1024 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.106.98.100.24)
Bluetooth: Version 4.3.2f6 15235, 3 services, 19 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: Hitachi HTS727575A9E362, 750.16 GB
Serial ATA Device: HL-DT-ST DVDRW  GS31N
USB Device: Hub
USB Device: IR Receiver
USB Device: FaceTime HD Camera (Built-in)
USB Device: Hub
USB Device: BRCM2070 Hub
USB Device: Bluetooth USB Host Controller
USB Device: Apple Internal Keyboard / Trackpad
Thunderbolt Bus: MacBook Pro, Apple Inc., 22.1

----------
components: Macintosh
files: test.py
messages: 237889
nosy: Michael Klein, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Segmentation Fault with Large Simple Function
versions: Python 2.7
Added file: http://bugs.python.org/file38446/test.py

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

From report at bugs.python.org  Thu Mar 12 15:59:00 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Thu, 12 Mar 2015 14:59:00 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue23644=5D_swig_compile_fails?=
 =?utf-8?q?_with_=E2=80=98=5FAtomic=E2=80=99_does_not_name_a_type?=
Message-ID: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>


New submission from Joshua J Cogliati:

The attached example works fine with Python 3.4.2, but fails with Python 3.5.0a1 and 3.5.0a2

I am using:
$ g++ --version
g++ (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
$ swig -version

SWIG Version 3.0.5

Compiled with g++ [x86_64-redhat-linux-gnu]

Configured options: +pcre
$ python3 --version
Python 3.5.0a2



The output of trying the makefile with Python 3.5.0a2 is:

$ make
swig -c++ -python -py3 example.i
g++ -g -fPIC -c example.cxx example_wrap.cxx -I/local/python350a2/include/python3.5m -I/local/python350a2/include/python3.5m
In file included from /local/python350a2/include/python3.5m/pyatomic.h:10:0,
                 from /local/python350a2/include/python3.5m/Python.h:53,
                 from example_wrap.cxx:154:
/usr/include/c++/4.9.2/exception:161:34: error: missing binary operator before token "("
 #if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1)
                                  ^
In file included from /local/python350a2/include/python3.5m/pyatomic.h:10:0,
                 from /local/python350a2/include/python3.5m/Python.h:53,
                 from example_wrap.cxx:154:
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:40:9: error: ?_Atomic? does not name a type
 typedef _Atomic _Bool atomic_bool;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:41:9: error: ?_Atomic? does not name a type
 typedef _Atomic char atomic_char;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:42:9: error: ?_Atomic? does not name a type
 typedef _Atomic signed char atomic_schar;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:43:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned char atomic_uchar;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:44:9: error: ?_Atomic? does not name a type
 typedef _Atomic short atomic_short;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:45:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned short atomic_ushort;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:46:9: error: ?_Atomic? does not name a type
 typedef _Atomic int atomic_int;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:47:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned int atomic_uint;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:48:9: error: ?_Atomic? does not name a type
 typedef _Atomic long atomic_long;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:49:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned long atomic_ulong;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:50:9: error: ?_Atomic? does not name a type
 typedef _Atomic long long atomic_llong;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:51:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned long long atomic_ullong;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:52:9: error: ?_Atomic? does not name a type
 typedef _Atomic __CHAR16_TYPE__ atomic_char16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:53:9: error: ?_Atomic? does not name a type
 typedef _Atomic __CHAR32_TYPE__ atomic_char32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:54:9: error: ?_Atomic? does not name a type
 typedef _Atomic __WCHAR_TYPE__ atomic_wchar_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:55:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_LEAST8_TYPE__ atomic_int_least8_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:56:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_LEAST8_TYPE__ atomic_uint_least8_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:57:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_LEAST16_TYPE__ atomic_int_least16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:58:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_LEAST16_TYPE__ atomic_uint_least16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:59:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_LEAST32_TYPE__ atomic_int_least32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:60:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_LEAST32_TYPE__ atomic_uint_least32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:61:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_LEAST64_TYPE__ atomic_int_least64_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:62:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_LEAST64_TYPE__ atomic_uint_least64_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:63:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_FAST8_TYPE__ atomic_int_fast8_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:64:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_FAST8_TYPE__ atomic_uint_fast8_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:65:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_FAST16_TYPE__ atomic_int_fast16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:66:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_FAST16_TYPE__ atomic_uint_fast16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:67:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_FAST32_TYPE__ atomic_int_fast32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:68:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_FAST32_TYPE__ atomic_uint_fast32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:69:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_FAST64_TYPE__ atomic_int_fast64_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:70:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_FAST64_TYPE__ atomic_uint_fast64_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:71:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INTPTR_TYPE__ atomic_intptr_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:72:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINTPTR_TYPE__ atomic_uintptr_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:73:9: error: ?_Atomic? does not name a type
 typedef _Atomic __SIZE_TYPE__ atomic_size_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:74:9: error: ?_Atomic? does not name a type
 typedef _Atomic __PTRDIFF_TYPE__ atomic_ptrdiff_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:75:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INTMAX_TYPE__ atomic_intmax_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:76:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINTMAX_TYPE__ atomic_uintmax_t;        
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:232:9: error: ?_Atomic? does not name a type
 typedef _Atomic struct
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:239:3: error: ?atomic_flag? does not name a type
 } atomic_flag;
   ^
In file included from /local/python350a2/include/python3.5m/Python.h:53:0,
                 from example_wrap.cxx:154:
/local/python350a2/include/python3.5m/pyatomic.h:37:5: error: ?_Atomic? does not name a type
     _Atomic void *_value;
     ^
/local/python350a2/include/python3.5m/pyatomic.h:41:5: error: ?atomic_int? does not name a type
     atomic_int _value;
     ^
Makefile:4: recipe for target 'example.so' failed
make: *** [example.so] Error 1


The output with Python 3.4.2:
$ make
swig -c++ -python -py3 example.i
g++ -g -fPIC -c example.cxx example_wrap.cxx -I/local/python342m/include/python3.4m -I/local/python342m/include/python3.4m
g++ -g -shared *.o -o _example.so
$ python3.4 a_test.py 
3

----------
files: min_example.tar.gz
messages: 237942
nosy: Joshua.J.Cogliati, jrincayc
priority: normal
severity: normal
status: open
title: swig compile fails with ?_Atomic? does not name a type
versions: Python 3.5
Added file: http://bugs.python.org/file38453/min_example.tar.gz

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

From report at bugs.python.org  Thu Mar 12 16:24:36 2015
From: report at bugs.python.org (=?utf-8?q?Ga=C3=ABtan_de_Menten?=)
Date: Thu, 12 Mar 2015 15:24:36 +0000
Subject: [New-bugs-announce] [issue23645] Incorrect doc for __getslice__
Message-ID: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>


New submission from Ga?tan de Menten:

The documentation for __getslice__ at https://docs.python.org/2/reference/datamodel.html#object.__getslice__ states: "Note that missing i or j in the slice expression are replaced by zero or sys.maxint, respectively."

However, in practice, it seems like it is replaced by sys.maxsize instead. This is obviously only a problem for 64bit versions of Python 2 since sys.maxint and sys.maxsize are the same on 32bit Python.

In [1]: class A(object):
   ...:     def __getslice__(self, i, j):
   ...:         print i, j
   ...:

In [2]: a = A()

In [3]: a[:]
0 9223372036854775807

In [4]: import sys

In [5]: sys.maxint
Out[5]: 2147483647

In [6]: sys.maxsize
Out[6]: 9223372036854775807L

In [7]: sys.version
Out[7]: '2.7.9 |Continuum Analytics, Inc.| (default, Dec 18 2014, 16:57:52) [MSC v.1500 64 bit (AMD64)]'

----------
assignee: docs at python
components: Documentation
messages: 237947
nosy: docs at python, gdementen
priority: normal
severity: normal
status: open
title: Incorrect doc for __getslice__
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 12 16:37:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:37:42 +0000
Subject: [New-bugs-announce] [issue23646] PEP 475: handle EINTR in the time
	module, retry sleep()
Message-ID: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch changes time.sleep() to retry select() when select() is interrupted by a signal or retry WaitForSingleObjectEx() when the signal SIGINT is received on Windows.

The patch drops support for EMX, sorry! I didn't know EMX, I had to Google it: "EMX is a free 32-bit DOS extender which adds some properties of Unix to MS-compatible DOS and IBM's OS/2 operating systems." (OS/2 support was dropped in Python 3.4  by the PEP 11.)

The patch also drops support for Watcom C compiler. I guess that it's also something specific to MS-DOS or very old (and unsupported) Windows versions.

select.select() is available on all platforms according to the doc, so I don't understand why we would not use it on all platforms for time.sleep() in 2015!
https://docs.python.org/dev/library/select.html#select.select

----------
files: sleep_eintr.patch
keywords: patch
messages: 237948
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: PEP 475: handle EINTR in the time module, retry sleep()
versions: Python 3.5
Added file: http://bugs.python.org/file38454/sleep_eintr.patch

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

From report at bugs.python.org  Thu Mar 12 16:39:25 2015
From: report at bugs.python.org (Arnt Gulbrandsen)
Date: Thu, 12 Mar 2015 15:39:25 +0000
Subject: [New-bugs-announce] [issue23647] imaplib.py MAXLINE value is too
	low for 2015 (patch	attached)
Message-ID: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>


New submission from Arnt Gulbrandsen:

http://stackoverflow.com/q/28923997 and various other SO questions point out that imaplib's _MAXLINE value is a bit behind the times. Fine for 1997, when people had 10MB mailbox quotas, not so fine for the age of gmail.

I'm tired of seeing those questions, so the attached patch increases the limit without abolishing it completely.

There are also other issues in imaplib, but I fix just this one now, to test the waters so to speak.

FWIW, I've signed the contributor form, just in case.

----------
components: Library (Lib)
files: 0001-Increase-IMAP-line-length-limit.patch
keywords: patch
messages: 237950
nosy: arnt
priority: normal
severity: normal
status: open
title: imaplib.py MAXLINE value is too low for 2015 (patch attached)
type: enhancement
Added file: http://bugs.python.org/file38456/0001-Increase-IMAP-line-length-limit.patch

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

From report at bugs.python.org  Thu Mar 12 16:51:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:51:26 +0000
Subject: [New-bugs-announce] [issue23648] PEP 475 meta issue
Message-ID: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I created this issue to group all issues related to the implementation of the PEP 475 "Retry system calls failing with EINTR".
https://www.python.org/dev/peps/pep-0475/

- Issue #23646: the time module, retry sleep()
- Issue #23618: the socket module
- Issue #23285: the io and the os modules, and open()
- Issue #23485: the select and selectors module

----------
messages: 237954
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475 meta issue
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 12 17:40:01 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 16:40:01 +0000
Subject: [New-bugs-announce] [issue23649] tarfile not re-entrant for
	multi-threading
Message-ID: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>


New submission from Srdjan Grubor:

When running tarfile.extract through multiple threads, the archive reading pointer is not protected from simultaneous seeks and causes various convoluted bugs:

  <some code>
    self.archive_object.extract(member, extraction_path)
  File "/usr/lib/python3.4/tarfile.py", line 2019, in extract
    set_attrs=set_attrs)
  File "/usr/lib/python3.4/tarfile.py", line 2088, in _extract_member
    self.makefile(tarinfo, targetpath)
  File "/usr/lib/python3.4/tarfile.py", line 2127, in makefile
    source.seek(tarinfo.offset_data)
  File "/usr/lib/python3.4/gzip.py", line 573, in seek
    self.read(1024)
  File "/usr/lib/python3.4/gzip.py", line 365, in read
    if not self._read(readsize):
  File "/usr/lib/python3.4/gzip.py", line 449, in _read
    self._read_eof()
  File "/usr/lib/python3.4/gzip.py", line 485, in _read_eof
    hex(self.crc)))
OSError: CRC check failed 0x1036a2e1 != 0x0

----------
messages: 237960
nosy: sgnn7
priority: normal
severity: normal
status: open
title: tarfile not re-entrant for multi-threading
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 12 18:32:05 2015
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Michel_L=27Heureux?=)
Date: Thu, 12 Mar 2015 17:32:05 +0000
Subject: [New-bugs-announce] [issue23650] xml.etree.ElementTreee.write can't
	parse its own output
Message-ID: <1426181525.16.0.169351519158.issue23650@psf.upfronthosting.co.za>


New submission from Fran?ois-Michel L'Heureux:

Using TreeBuilder to put data into XML tree.
Convert that tree to a string.
Parse that string.
XML parser error.

I expect XML library to be able to parse its own output.

Reference example: https://github.com/FinchPowers/python_xml_builder_bug/blob/d98b2422d9ecadbee37e2896a5098abf82b1d7a4/python_xml_builder_bug.py

----------
components: XML
files: python_xml_builder_bug.py
messages: 237965
nosy: Fran?ois-Michel L'Heureux
priority: normal
severity: normal
status: open
title: xml.etree.ElementTreee.write can't parse its own output
versions: Python 2.7
Added file: http://bugs.python.org/file38459/python_xml_builder_bug.py

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

From report at bugs.python.org  Thu Mar 12 19:37:11 2015
From: report at bugs.python.org (Nathan West)
Date: Thu, 12 Mar 2015 18:37:11 +0000
Subject: [New-bugs-announce] [issue23651] Typo in argparse allow_abrev
Message-ID: <1426185431.21.0.35714831717.issue23651@psf.upfronthosting.co.za>


New submission from Nathan West:

The documentation for the new argparse feature allow_abrev contains a typo:

>>> parser.add_argument('--foobar', action='store_true')
>>> parser.add_argument('--foonley', action='store_false')
>>> parser.parse_args([--foon])
usage: PROG [-h] [--foobar] [--foonley]
PROG: error: unrecognized arguments: --foon

The --foon should be quoted:

>>> parser.parse_args(['--foon'])

----------
assignee: docs at python
components: Documentation
messages: 237971
nosy: Lucretiel, docs at python
priority: normal
severity: normal
status: open
title: Typo in argparse allow_abrev
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 12 21:41:46 2015
From: report at bugs.python.org (Matt Frank)
Date: Thu, 12 Mar 2015 20:41:46 +0000
Subject: [New-bugs-announce] [issue23652] ifdef uses of EPOLLxxx macros so
	we can compile on	systems that don't have them
Message-ID: <1426192906.82.0.724323476801.issue23652@psf.upfronthosting.co.za>


New submission from Matt Frank:

With the LSB (Linux Standard Base) headers for libc Modules/selectmodule.c fails to compile because we have code that uses EPOLLRDNORM, EPOLLRDBAND, EPOLLWRNORM and EPOLLMSG without first checking that they are defined.

The patch wraps the five uses of PyModule_AddIntMacro in #ifdefs, following exactly the same pattern that is used for the POLLRDNORM, POLLRDBAND, POLLWRNORM, POLLMSG macros 30 lines earlier in selectmodule.c.

The only documentation I can find for these five macros from Linux is (a) in the Python documentation for the select module!  (https://docs.python.org/3.4/library/select.html#edge-and-level-trigger-polling-epoll-objects) and (b) on this StackOverflow answer: http://stackoverflow.com/a/27143672/2209313.

They are not described on http://man7.org/linux/man-pages/man2/epoll_ctl.2.html (where the rest of the EPOLL macros are defined), nor at http://linux.die.net/man/4/epoll.  As explained by the StackOverflow answer they actually are described (indirectly) by http://man7.org/linux/man-pages/man2/poll.2.html.

Nor are these macros in the Linux Foundation's LSB database: http://www.linuxbase.org/navigator/browse/headgroup.php?cmd=list-byheadgroup&HGid=1398.

Obviously almost all modern Linuxes have these macros, so we should keep them, but we should also compile with the LSB headers (since compiling and linking against the LSB SDK (http://www.linuxfoundation.org/collaborate/workgroups/lsb/group) is one of the easiest ways to produce a Python binary that will actually run on most important supported Linux distros (e.g., RHEL 5).

http://man7.org/linux/man-pages/man7/epoll.7.html,

----------
components: Build
files: epoll-macros-patch.diff
keywords: patch
messages: 237984
nosy: WanderingLogic
priority: normal
severity: normal
status: open
title: ifdef uses of EPOLLxxx macros so we can compile on systems that don't have them
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38461/epoll-macros-patch.diff

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

From report at bugs.python.org  Thu Mar 12 22:31:49 2015
From: report at bugs.python.org (Nathan West)
Date: Thu, 12 Mar 2015 21:31:49 +0000
Subject: [New-bugs-announce] [issue23653] Make inspect._empty test to False
Message-ID: <1426195909.5.0.733462239813.issue23653@psf.upfronthosting.co.za>


New submission from Nathan West:

A common Python idiom is to test objects by value in an if. This includes container emptiness and regular expression matches, or using 'or' to specify a default value:

    if my_list:
        # list isn't empty
    if regex.match(string):
        # string matched the regex
    my_list = arg or [1,2,3]

It'd be nice if we could use this idiom with inspect.Signature._empty or inspect.Parameter.empty:

    sig = signature(func)
    for param in sig.parameters.values():
        if param.annotation:
            ...

or, to use a the example that motivated this idea:

    def arg_type(param):
        return param.annotation or str

The only issue I can think of is that, if an annotation or default value is some False value, like None, than the test will fail even if the value isn't _empty. However, this issue already exists for other uses of this idiom, and I think this is a perfect extension of the form.

----------
components: Library (Lib)
messages: 237987
nosy: Lucretiel
priority: normal
severity: normal
status: open
title: Make inspect._empty test to False
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 12 23:51:27 2015
From: report at bugs.python.org (Matt Frank)
Date: Thu, 12 Mar 2015 22:51:27 +0000
Subject: [New-bugs-announce] [issue23654] infinite loop in
	faulthandler._stack_overflow
Message-ID: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>


New submission from Matt Frank:

When the faulthandler module is compiled at -O3 (the default for non-debug builds) with a compiler that does tailcall optimization the Modules/faulthandler.c:stack_overflow() function may become an infinite loop that does not expand the stack.  This puts the interpreter into an infinite loop with 100% CPU utilization that won't respond to SIGINT.  (But sending SIGTERM will get it to exit.)

The Intel compiler (15.0.1 on Linux) seems to be able to prove this optimization "safe".  (And thus cause the function to turn into an infinite loop.)  While gcc 4.8.2 and clang 3.4.2 do not currently optimize this call (because their pointer analysis isn't quite strong enough to deal with the pointer to the depth argument), there's no guarantee that they won't be able to optimize it in their next versions.

This patch adds a test between the recursive call and the return statement which makes it not a tail call.

----------
components: Extension Modules
files: faulthandler-infloop.patch
keywords: patch
messages: 237993
nosy: WanderingLogic
priority: normal
severity: normal
status: open
title: infinite loop in faulthandler._stack_overflow
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38463/faulthandler-infloop.patch

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

From report at bugs.python.org  Fri Mar 13 07:47:15 2015
From: report at bugs.python.org (John Nagle)
Date: Fri, 13 Mar 2015 06:47:15 +0000
Subject: [New-bugs-announce] [issue23655] Memory corruption using pickle
	over pipe to subprocess
Message-ID: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>


New submission from John Nagle:

I'm porting a large, working system from Python 2 to Python 3, using "six", so the same code works with both. One part of the system works a lot like the multiprocessing module, but predates it. It launches child processes with "Popen" and talks to them using "pickle" over stdin/stdout as pipes.  Works fine under Python 2, and has been working in production for years.

Under Python 3, I'm getting errors that indicate memory corruption:

Fatal Python error: GC object already tracked

Current thread 0x00001a14 (most recent call first):
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 411
in description
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 1248
in _get_descriptions
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 1182
in _read_result_packet
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 1132
in read
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 929
in _read_query_result
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 768
in query
  File "C:\python34\lib\site-packages\pymysql\cursors.py", line 282 in
_query
  File "C:\python34\lib\site-packages\pymysql\cursors.py", line 134 in
execute
  File "C:\projects\sitetruth\domaincacheitem.py", line 128 in select
  File "C:\projects\sitetruth\domaincache.py", line 30 in search
  File "C:\projects\sitetruth\ratesite.py", line 31 in ratedomain
  File "C:\projects\sitetruth\RatingProcess.py", line 68 in call
  File "C:\projects\sitetruth\subprocesscall.py", line 140 in docall
  File "C:\projects\sitetruth\subprocesscall.py", line 158 in run
  File "C:\projects\sitetruth\RatingProcess.py", line 89 in main
  File "C:\projects\sitetruth\RatingProcess.py", line 95 in <module>

That's clear memory corruption.

Also,

  File "C:\projects\sitetruth\InfoSiteRating.py", line 200, in scansite
    if len(self.badbusinessinfo) > 0 :                  # if bad stuff
NameError: name 'len' is not defined

There are others, but those two should be impossible to cause from Python source. 

I've done the obvious stuff - deleted all .pyc files and Python cache directories.  All my code is in Python. Every library module came in via "pip", into a clean Python 3.4.3 (32 bit) installation on Win7/x86-64.

Currently installed packages (via "pip list")

beautifulsoup4 (4.3.2)
dnspython3 (1.12.0)
html5lib (0.999)
pip (6.0.8)
PyMySQL (0.6.6)
pyparsing (2.0.3)
setuptools (12.0.5)
six (1.9.0)

Nothing exotic there.  The project has zero local C code; any C code came 
from the Python installation or the above packages, most of which are pure Python.

It all works fine with Python 2.7.9.  Everything else in the program seems
to be working fine under both 2.7.9 and 3.4.3, until subprocesses are involved.

What's being pickled is very simple; no custom objects, although Exception types are sometimes pickled if the subprocess raises an exception.  

Pickler and Unpickler instances are being reused here.  A message is pickled, piped to the subprocess, unpickled, work is done, and a response comes back later via the return pipe.  A send looks like:

    self.writer.dump(args)      # send data
    self.dataout.flush()        # finish output
    self.writer.clear_memo()    # no memory from cycle to cycle

and a receive looks like:

    result = self.reader.load() # read and return from child
    self.reader.memo = {}       # no memory from cycle to cycle

Those were the recommended way to reset "pickle" for new traffic years ago.
(You have to clear the receive side as well as the send side, or the dictionary
of saved objects grows forever.) My guess is that there's something about reusing "pickle" instances that botches memory uses in CPython 3's C code 
for "cpickle".  That should work, though; the "multiprocessing" module works
by sending pickled data over pipes.

The only code difference between Python 2 and 3 is that under Python 3 I have to use "sys.stdin.buffer" and "sys.stdout.buffer" as arguments to Pickler and Unpickler. Otherwise they complain that they're getting type "str".

Unfortunately, I don't have an easy way to reproduce this bug yet. 

Is there some way to force the use of the pure Python pickle module under Python 3? That would help isolate the problem.

				John Nagle

----------
components: Library (Lib)
messages: 238009
nosy: nagle
priority: normal
severity: normal
status: open
title: Memory corruption using pickle over pipe to subprocess
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 13 09:13:02 2015
From: report at bugs.python.org (Hiroaki Miyajima)
Date: Fri, 13 Mar 2015 08:13:02 +0000
Subject: [New-bugs-announce] [issue23656] shutil.copyfile (or built-in open)
	releases sqlite3's	transaction lock
Message-ID: <1426234382.55.0.94867097951.issue23656@psf.upfronthosting.co.za>


New submission from Hiroaki Miyajima:

When copying sqlite3's database file by shutil.copyfile while holding its transaction lock, its lock is released unexpectedly.

Attached is a sample program showing this. Inside,
process-1 and process-2 just do following steps respectively:
   (1) open a sqlite dbfile
   (2) execute('begin EXCLUSIVE transaction') to acquire lock
   (3) copy the dbfile
   (4) sleep some seconds for demonstration
   (4) rollback() to release lock

if shutil.copyfile() is used as (3), process-2 gets a lock
while process-1 must hold a lock.
It seems that this happens if database file is opened with built-in open(), which is used in shutil.copyfile.

In addition,
- With os.open(), there seems no problem.
- With linux cp command, it works correct.
- Using multi-thread instead of multi-process, it works expectedly.

I think this is a bug, but does someone explain this behaviour?
Thank you.

Below is the execute example of the attached on python 2.7.9.
----------
# python Test_sqlite3_lock.py
Use <function shutil_copyfile at 0x7fe810b22500>
process-1 : Transaction lock acquired
process-2 : Transaction lock acquired
process-1 : Transaction lock released
process-2 : Transaction lock released

Use <function low_copyfile at 0x7fe810b22578>
process-1 : Transaction lock acquired
process-1 : Transaction lock released
process-2 : Transaction lock acquired
process-2 : Transaction lock released

Use <function command_copyfile at 0x7fe810b225f0>
process-1 : Transaction lock acquired
process-1 : Transaction lock released
process-2 : Transaction lock acquired
process-2 : Transaction lock released

----------

----------
files: Test_sqlite3_lock.py
messages: 238013
nosy: h-miyajima
priority: normal
severity: normal
status: open
title: shutil.copyfile (or built-in open) releases sqlite3's transaction lock
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file38467/Test_sqlite3_lock.py

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

From report at bugs.python.org  Fri Mar 13 15:50:10 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Mar 2015 14:50:10 +0000
Subject: [New-bugs-announce] [issue23657] Don't do isinstance checks in
	zipapp
Message-ID: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As it stand, zipapp's code checks for str and then otherwise assumes an object is a file-like object. It might work out better to do some duck typing and simply check if an object has 'read' and 'readline' attributes then it's a file-like object and otherwise that it's a path.

Doing this would then potentially make it easier to use pathlib.Path through the module rather than the os module.

----------
assignee: pmoore
components: Library (Lib)
messages: 238030
nosy: brett.cannon, pmoore
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't do isinstance checks in zipapp
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 13 16:22:22 2015
From: report at bugs.python.org (Dan Nawrocki)
Date: Fri, 13 Mar 2015 15:22:22 +0000
Subject: [New-bugs-announce] [issue23658] multiprocessing: string arg to
	SystemExit
Message-ID: <1426260142.17.0.720553845147.issue23658@psf.upfronthosting.co.za>


New submission from Dan Nawrocki:

It seems that the fix for 13854 (http://bugs.python.org/issue13854) actually tried to solve 2 issues:

1. handle non-integer, non-string arg to SystemExit
2. use exit code of 0 when the arg was a string

The change involved for #2 seems to go against the documentation for sys.exit:

"...In particular, sys.exit("some error message") is a quick way to exit a program when an error occurs."

Indeed, python 2.7.5 appears to follow this behavior:

[me at localhost ~]$ python -c 'raise SystemExit("bye")'; echo $?
bye
1

Shouldn't the return code from a subprocess when using multiprocessing match the return code when called w/o the multiprocessing module?

----------
components: Library (Lib)
messages: 238034
nosy: Dan Nawrocki
priority: normal
severity: normal
status: open
title: multiprocessing: string arg to SystemExit
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 13 16:31:24 2015
From: report at bugs.python.org (Vladimir Ulupov)
Date: Fri, 13 Mar 2015 15:31:24 +0000
Subject: [New-bugs-announce] [issue23659] csv.register_dialect  doc string
Message-ID: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>


New submission from Vladimir Ulupov:

I use PyCharm. This IDE checks the signature functions.
When I used the extra arguments to the function register_dialect - IDE reported error.

This is what has generated IDE for this function.
http://dumpz.org/1347592/

Apparently error here
https://hg.python.org/cpython/file/44c1c0cbdc06/Modules/_csv.c#l1547
https://hg.python.org/cpython/file/c1abcbcfefab/Modules/_csv.c#l1590


https://docs.python.org/2/library/csv.html?highlight=csv#csv.register_dialect
https://docs.python.org/3/library/csv.html?highlight=csv#csv.register_dialect

----------
assignee: docs at python
components: Documentation
messages: 238035
nosy: Vladimir Ulupov, docs at python
priority: normal
severity: normal
status: open
title: csv.register_dialect  doc string
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Mar 13 16:42:52 2015
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 13 Mar 2015 15:42:52 +0000
Subject: [New-bugs-announce] [issue23660] Turtle left/right inverted when
	using different	coordinates orientation
Message-ID: <1426261372.66.0.413514291582.issue23660@psf.upfronthosting.co.za>


New submission from Andre Roberge:

The turtle module using screen coordinates such that the vertical coordinate increases vertically on the screen. This orientation is different from the traditional orientation for graphics programs.

It is possible to set coordinates with the "normal" orientation using the setworldcoordinates function, e.g.

    >>> from turtle import *
    >>> setworldcoordinates(0, 400, 400, 0)

With the above choice, the y coordinate increases as the turtle moves down on the screen.  However, doing so inverts the role of left() and right().

I have attached a "diff" file which introduces a change needed so that left() and right() behave correctly with this different orientation.

----------
files: turtle_diff.txt
messages: 238037
nosy: aroberge
priority: normal
severity: normal
status: open
title: Turtle left/right inverted when using different coordinates orientation
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38473/turtle_diff.txt

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

From report at bugs.python.org  Sat Mar 14 01:45:40 2015
From: report at bugs.python.org (Ignacio Rossi)
Date: Sat, 14 Mar 2015 00:45:40 +0000
Subject: [New-bugs-announce] [issue23661] Setting a exception side_effect on
	a mock from	create_autospec does not work
Message-ID: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za>


New submission from Ignacio Rossi:

The following fails on python 3.4.2, 3.4.3 and 3.5.0a2 (downloaded from python.org and compiled on Ubuntu 14.04). 
The same happens when using mock.patch with autospec=True.

>>> from unittest.mock import create_autospec
>>> def function():
...     pass
... 
>>> mock = create_autospec(function)
>>> mock.side_effect = ValueError('MyError')
>>> mock()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in function
  File "/usr/local/lib/python3.5/unittest/mock.py", line 910, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/usr/local/lib/python3.5/unittest/mock.py", line 963, in _mock_call
    effect = self.side_effect
  File "/usr/local/lib/python3.5/unittest/mock.py", line 510, in __get_side_effect
    sf = _MockIter(sf)
  File "/usr/local/lib/python3.5/unittest/mock.py", line 351, in __init__
    self.obj = iter(obj)
TypeError: 'ValueError' object is not iterable

But, on Python 3.3.5, 3.4.0, or when the mock is created via Mock(), for  instance, the exception is raised as expected:

[...]
>>> mock()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in function
  File "/usr/lib/python3.4/unittest/mock.py", line 885, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/usr/lib/python3.4/unittest/mock.py", line 941, in _mock_call
    raise effect
ValueError: MyError

----------
components: Library (Lib)
messages: 238064
nosy: Ignacio Rossi
priority: normal
severity: normal
status: open
title: Setting a exception side_effect on a mock from create_autospec does not work
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 14 16:01:20 2015
From: report at bugs.python.org (Malcolm Smith)
Date: Sat, 14 Mar 2015 15:01:20 +0000
Subject: [New-bugs-announce] [issue23662] Cookie.domain is undocumented
Message-ID: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>


New submission from Malcolm Smith:

This is a fundamental attribute of a cookie, which will be set even if the server doesn't specify it, yet it doesn't appear in the documentation either of 2.x cookielib or 3.x http.cookiejar.

----------
assignee: docs at python
components: Documentation
messages: 238087
nosy: Malcolm Smith, docs at python
priority: normal
severity: normal
status: open
title: Cookie.domain is undocumented
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 14 23:04:28 2015
From: report at bugs.python.org (David Macek)
Date: Sat, 14 Mar 2015 22:04:28 +0000
Subject: [New-bugs-announce] [issue23663] Crash on failure in ctypes on
	Cygwin
Message-ID: <1426370668.97.0.493459472376.issue23663@psf.upfronthosting.co.za>


New submission from David Macek:

Two Cygwin-specific sections in `Modules/_ctypes/_ctypes.c` cause a crash due to bad call to `PyErr_Format`. I'm not sure if there's one extra format specifier, or one argument is missing. Patches assuming the former case for v2.7 and v3.3:

https://github.com/Alexpux/MSYS2-packages/blob/master/python3/3.3-wrong-parameters.patch

https://github.com/Alexpux/MSYS2-packages/blob/master/python2/0260-wrong-parameters.patch

----------
components: ctypes
files: 3.3-wrong-parameters.patch
keywords: patch
messages: 238101
nosy: elieux
priority: normal
severity: normal
status: open
title: Crash on failure in ctypes on Cygwin
type: crash
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file38486/3.3-wrong-parameters.patch

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

From report at bugs.python.org  Sun Mar 15 00:22:54 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 Mar 2015 23:22:54 +0000
Subject: [New-bugs-announce] [issue23664] Modernize HTML output of
	difflib.HtmlDiff.make_file()
Message-ID: <1426375374.93.0.948523072227.issue23664@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This is a split off from issue 2052. issue2052_html5_v2.diff (from issue 2052) needs to be updated.

----------
assignee: berker.peksag
components: Library (Lib)
messages: 238106
nosy: berker.peksag
priority: normal
severity: normal
stage: needs patch
status: open
title: Modernize HTML output of difflib.HtmlDiff.make_file()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 15 00:33:44 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Mar 2015 23:33:44 +0000
Subject: [New-bugs-announce] [issue23665] Provide IDLE menu option to set
	command-line arguments
Message-ID: <1426376024.32.0.301061562538.issue23665@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

A number of IDEs support menu options to set the execution environment for programs under development and testing.  In particular, it would be nice if IDLE let the user set command line arguments to be passed into sys.argv when running a script by pressing F5.

Here are some existing implementations for reference:
* Wing-IDE: https://wingware.com/doc/intro/tutorial-debugging-launch
* Visual Studio: https://www.youtube.com/watch?v=IgbQCRHKV-Y
* PyCharm: https://www.jetbrains.com/pycharm/help/run-debug-configuration-python.html

This feature will help users interactively develop and test command-line tools while retaining all the nice features of the IDE.   I would personally find it useful when teaching students about how sys.argv works.

I suggest adding an option under the Run menu for Set Command Line arguments.  It would trigger a dialog box that lets a user set a string such as "somefile.txt -r 10".  The user string would be run through shlex to break it into separate fields.  When F5 is pressed, the sys.argv list would be repopulated to include the script name and the lexed arguments.

A little more elaborate option is to add a Run menu entry for Set Execution Enviroment that let's the user 1) set the command-line  2) specify the start-up directory (using os.chdir), 3) and edit the environment variables (from os.environ) or at least be able to set PYTHONPATH.

----------
components: IDLE
messages: 238108
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide IDLE menu option to set command-line arguments
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 15 00:38:05 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Mar 2015 23:38:05 +0000
Subject: [New-bugs-announce] [issue23666] Add shell session logging option
	to IDLE
Message-ID: <1426376285.32.0.372835851361.issue23666@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

IDLE's interactive shell supports File / Save to save an interactive session.  However, if a user restarts a session or accidentally exits without saving, all is lost.

In Python courses I've taught, there has been a recurring request for an auto-logging feature (save the session at some regular interval).  This would help user's record everything they type during a Python class.

I suggest an addition to the File menu (for the interactive shell only): Session Logging Enable/Disable.

----------
components: IDLE
messages: 238109
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add shell session logging option to IDLE
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 15 00:43:04 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Mar 2015 23:43:04 +0000
Subject: [New-bugs-announce] [issue23667] IDLE to provide option for making
	trailing whitespace	visible
Message-ID: <1426376584.28.0.267295855034.issue23667@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

We have an option to clear trailing whitespace (Format / Strip trailing whitespace) but it isn't always clear when to use it (because the trailing whitespace is invisible).

One thing the can be done is to colorize trailing white space to make it more visible (this idea is inspired by a similar feature in mercurial's colorized diffs).

Another option is put a hook on File / Save to scan for trailing whitespace and offer to remove it (this idea is inspired by the whitespace commit hook used in Python's own source code management).

----------
components: IDLE
messages: 238110
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE to provide option for making trailing whitespace visible
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 15 02:41:38 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 01:41:38 +0000
Subject: [New-bugs-announce] [issue23668] Support os.[f]truncate on Windows
Message-ID: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>


New submission from Steve Dower:

With _chsize_s (which supports 64-bit sizes, unlike _chsize), this seems fairly trivial to do, but I'll put a patch up for it in case there's something I've missed.

----------
assignee: steve.dower
components: Windows
messages: 238113
nosy: steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Support os.[f]truncate on Windows
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 15 05:23:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 04:23:48 +0000
Subject: [New-bugs-announce] [issue23669] test_socket.NonBlockingTCPTests
	failing due to race	condition
Message-ID: <1426393428.29.0.286141594262.issue23669@psf.upfronthosting.co.za>


New submission from Steve Dower:

The test at Lib/test/test_socket.py:3883 is failing intermittently (but more often than not) due to a race condition between the two threads involved in the test.

======================================================================
FAIL: testRecv (test.test_socket.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\build\cpython\lib\test\test_socket.py", line 3883, in testRecv
    self.fail("Error trying to do non-blocking recv.")
AssertionError: Error trying to do non-blocking recv.

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

The message in this case means the recv succeeded when it should have failed due to lack of data. But the second thread just delays briefly before sending data, and apparently the main thread can stall long enough for the data to be available in the first part of the test.

A quick check using an Event rather than the sleep shows that the race condition can be fixed, but it seems like this may affect more tests as a lot seem to involve sleep-based timing.

(I've only seen this on Windows, but I see no reason why it shouldn't affect other platforms as well.)

----------
components: Tests
messages: 238121
nosy: pitrou, steve.dower
priority: normal
severity: normal
status: open
title: test_socket.NonBlockingTCPTests failing due to race condition
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 15 07:25:47 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Sun, 15 Mar 2015 06:25:47 +0000
Subject: [New-bugs-announce] [issue23670] Modifications to support iOS as a
	development platform
Message-ID: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>


New submission from Russell Keith-Magee:

Proposal: iOS should be a supported platform for Python development.

The attached patch is a first pass at a patch to achieve this. It is a single patch against Python 3.4.2 sources, and requires no pre- or post-configure modifications. 

Supporting iOS requires multiple builds - one for each of the hardware platforms that iOS supports (x86_64 simulator, ARMv7 and ARM64). These separate builds must then be merged into a single "fat" framework. The patch contains an iOS directory with a "meta" Makefile that manages this build-and-merge process. See the README in the iOS directory for details on usage.

The patch also introduces a new 'ios' platform type.

A sample XCode project for an iOS app is also provided as part of the patch.

iOS/README contains a couple of other notes about the build and the approach taken.

There are some known problems/limitations with this patch:

 * It's a patch against 3.4.2, not hg trunk

 * The code doesn't currently compile for ARMv7. In order to support ARM64, it has been necessary to use an unreleased trunk version of libffi; however, this version is currently broken for ARMv7. Older versions of libffi (including the formal 3.2.1 release) *do* work.

 * The patch doesn't currently provide any way to run the test suite on the target platform. Testing is currently based on a simple smoke test of some basic features.

So - the patch isn't ready for commit to trunk. I'm presenting it for the purposes of getting feedback on the broad approach while I continue to resolve the known issues.

----------
components: Build, Cross-Build
files: 20150314.diff
keywords: patch
messages: 238125
nosy: freakboy3742
priority: normal
severity: normal
status: open
title: Modifications to support iOS as a development platform
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file38493/20150314.diff

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

From report at bugs.python.org  Sun Mar 15 09:21:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Mar 2015 08:21:34 +0000
Subject: [New-bugs-announce] [issue23671] string.Template doesn't work with
	the self keyword	argument
Message-ID: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

string.Template doesn't allow to specify the self substitute parameter as keyword argument.

>>> import string
>>> string.Template('the self is $self').substitute(self='bozo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: substitute() got multiple values for argument 'self'
>>> string.Template('the self is $self').safe_substitute(self='bozo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: safe_substitute() got multiple values for argument 'self'

The same issue is with string.Formatter.format:

>>> string.Formatter().format('the self is {self}', self='bozo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: format() got multiple values for argument 'self'

Proposed patch fixes these issues.

----------
components: Library (Lib)
files: string_formatting_self.patch
keywords: patch
messages: 238132
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: string.Template doesn't work with the self keyword argument
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38497/string_formatting_self.patch

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

From report at bugs.python.org  Sun Mar 15 09:51:42 2015
From: report at bugs.python.org (Kamisky)
Date: Sun, 15 Mar 2015 08:51:42 +0000
Subject: [New-bugs-announce] [issue23672] IDLE for osx 10.8.5 won't run
Message-ID: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>


New submission from Kamisky:

I could run the IDLE in the past time.But today,when I try and launch IDLE, the icon appears on the dock for a second and then disappears and the application doesn't run.Moreover,When I run IDLE3 in Terminal,it says:
bogon:~ Kamisky$ idle3
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/bin/idle3", line 5, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py", line 1560, in main
    shell = flist.open_shell()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py", line 315, in open_shell
    self.pyshell = PyShell(self)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py", line 866, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/EditorWindow.py", line 301, in __init__
    self.update_recent_files_list()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/EditorWindow.py", line 927, in update_recent_files_list
    underline=0)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/__init__.py", line 2719, in add_command
    self.add('command', cnf or kw)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/__init__.py", line 2710, in add
    self._options(cnf, kw))
_tkinter.TclError: character U+1f393 is above the range (U+0000-U+FFFF) allowed by Tcl

Thanks.

----------
components: IDLE
messages: 238136
nosy: kamisky
priority: normal
severity: normal
status: open
title: IDLE for osx 10.8.5 won't run
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar 15 16:10:45 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Mar 2015 15:10:45 +0000
Subject: [New-bugs-announce] [issue23673] IntEnum is unpicklable by previous
	Python versions
Message-ID: <1426432245.83.0.265780672947.issue23673@psf.upfronthosting.co.za>


New submission from Ethan Furman:

IntEnum is advertised as being a drop-in replacement for integer contants; however this fails in the case of unpickling on previous Python versions.

This occurs because when a pickle is created the module, class, and value are stored -- but those don't exist prior to Python 3.4.

One solution is to modify IntEnum to pickle just like a plain int would, but this has the serious disadvantage of losing the benefits of IntEnum on Python versions that support it.

Another solution is to use Serhiy's idea of pickling by name; this would store the module and name to look up in that madule, and this works on all Python versions that have that constant: on Python 3.3 socket.AF_INET returns an integerer (2, I think), and on Python 3.4+ it returns the AF_INET AddressFamily member.

----------
assignee: ethan.furman
keywords: 3.4regression
messages: 238148
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: test needed
status: open
title: IntEnum is unpicklable by previous Python versions
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar 15 20:40:51 2015
From: report at bugs.python.org (Tapani Kiiskinen)
Date: Sun, 15 Mar 2015 19:40:51 +0000
Subject: [New-bugs-announce] [issue23674] super() documentation isn't very
	clear
Message-ID: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>


New submission from Tapani Kiiskinen:

https://docs.python.org/3/library/functions.html#super

There's no mention in the document which __mro__ is used in the case of a super(Type, obj) call. There's this mention 'The __mro__ attribute of the *type* lists the method resolution search order used by both getattr() and super().' but my understanding is that this only applies in the case of a super(type) call plus it doesn't state that it only applies in that case. (I'm fairly certain I'm not wrong; if only the __mro__ of the type was used then cooperative multiple inheritance (which is referenced three paragraphs down) could not work because the __mro__ of the type never has sibling types.)

Isn't this misleading due to a super(Type, obj) call (or just super() inside a class in 3k) being the more normal way to use the function? Even now I can't find a single resource to confirm which exact mro is used in the case of a super(Type, obj) call, I've only been able to deduce that it probably uses the type(obj).__mro__ then finds the Type and then tries the entries after Type.

Finally 'If the second argument is omitted, the super object returned is unbound. If the second argument is an object, isinstance(obj, type) must be true. If the second argument is a type, issubclass(type2, type) must be true (this is useful for classmethods).'

I'm interpreting this is essentially saying that if the second argument is given that the returned object will be bound, given an object the super call would return a bound instance method and given a type a bound class method? I feel like stating this explicitly would be more clear than implicitly.

----------
assignee: docs at python
components: Documentation
messages: 238157
nosy: Tapani Kiiskinen, docs at python
priority: normal
severity: normal
status: open
title: super() documentation isn't very clear
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Mar 15 22:50:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Mar 2015 21:50:34 +0000
Subject: [New-bugs-announce] [issue23675] glossary entry for 'method
	resolution order' links to	something with python 2.3 in the title
Message-ID: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za>


New submission from R. David Murray:

The link is correct; that document describes the new-style class method resolution order, which is what Python3 uses.  However, the title is a bit problematic, and either the title should be changed or the link from the Python3 docs should have a gloss explaining why the document is in fact the correct link.

----------
messages: 238161
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: glossary entry for 'method resolution order' links to something with python 2.3 in the title

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

From report at bugs.python.org  Sun Mar 15 22:59:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Mar 2015 21:59:08 +0000
Subject: [New-bugs-announce] [issue23676] Add support of
	UnicodeTranslateError in standard error	handlers
Message-ID: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds support of UnicodeTranslateError in standard error handlers "xmlcharrefreplace", "namereplace" and "surrogatepass". Support in "backslashreplace" was added in issue22286, support in "strict", "ignore" and "replace" was always, support in "surrogateescape" is unlikely possible.

This can be used with issue18814.

----------
components: Interpreter Core
files: translate_error_handlers.patch
keywords: patch
messages: 238163
nosy: doerwalter, lemburg, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add support of UnicodeTranslateError in standard error handlers
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38502/translate_error_handlers.patch

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

From report at bugs.python.org  Mon Mar 16 09:50:55 2015
From: report at bugs.python.org (Frank Millman)
Date: Mon, 16 Mar 2015 08:50:55 +0000
Subject: [New-bugs-announce] [issue23677] Mention dict and set comps in
	library reference
Message-ID: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>


New submission from Frank Millman:

This is from the documentation at Section 4.6.4. Lists

"""
Lists may be constructed in several ways:

Using a pair of square brackets to denote the empty list: []
Using square brackets, separating items with commas: [a], [a, b, c]
Using a list comprehension: [x for x in iterable]
Using the type constructor: list() or list(iterable)
"""

Comprehensions are mentioned as a constructor.

This is from the documentation at Section 4.10. Mapping Types

"""
Dictionaries can be created by placing a comma-separated list of key: value pairs within braces, for example: {'jack': 4098, 'sjoerd': 4127} or {4098: 'jack', 4127: 'sjoerd'}, or by the dict constructor.

class dict(**kwarg) 
class dict(mapping, **kwarg) 
class dict(iterable, **kwarg) 
Return a new dictionary initialized from an optional positional argument and a possibly empty set of keyword arguments.
"""

There is no mention of dictionary comprehensions.

For consistency, I believe that the documentation for Dicts and Sets should mention comprehensions.

----------
assignee: docs at python
components: Documentation
messages: 238186
nosy: FrankMillman, docs at python
priority: normal
severity: normal
status: open
title: Mention dict and set comps in library reference
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 16 10:31:53 2015
From: report at bugs.python.org (bjshan)
Date: Mon, 16 Mar 2015 09:31:53 +0000
Subject: [New-bugs-announce] [issue23678] imaplib status command cannot
	handle folder name	containing whitespaces
Message-ID: <1426498313.59.0.493788060886.issue23678@psf.upfronthosting.co.za>


New submission from bjshan:

imaplib status failed if the folder name contains whitespace.
For example, 
c = IMAP4_SSL('hostname')
c = login(username, password)
c.status('Drafts', '(MESSAGES)')    # would succeed
c.status('Apple Mail To Do', '(MESSAGES)') # would fail, error message is:
imaplib.error: STATUS command error: BAD [b"parse error: wrong character; expected '(' but got 'M'"]

It seems the status method could not properly parse the folder name "Apple Mail To Do", it recognizes only the first word "Apple", then failed when meeting the following word "Mail". 

I checked imaplib.py, _command 's definition looks like the cause, but I am not sure:

    def _command(self, name, *args):
         
        ...    
        
        name = bytes(name, 'ASCII')
        data = tag + b' ' + name
        for arg in args:
            if arg is None: continue
            if isinstance(arg, str):
                arg = bytes(arg, "ASCII")
            data = data + b' ' + arg

Work around for this:
Manually add double quote around the folder name, like:   
   '"' + mailbox_name + '"'

BUT, 
while c.status('"Apple Mail To Do"', '(MESSAGES)') worked, 
c.status("'Apple Mail To Do'", '(MESSAGES)') failed. Suggesting single and double quote weighs not the same?

----------
components: Library (Lib)
messages: 238188
nosy: bjshan
priority: normal
severity: normal
status: open
title: imaplib status command cannot handle folder name containing whitespaces
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 16 12:31:05 2015
From: report at bugs.python.org (mogli)
Date: Mon, 16 Mar 2015 11:31:05 +0000
Subject: [New-bugs-announce] [issue23679] SSL Ciphers RC4
Message-ID: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>


New submission from mogli:

The documentation (https://docs.python.org/2/library/ssl.html) says:
The settings in Python 2.7.9 are: PROTOCOL_SSLv23, OP_NO_SSLv2, and OP_NO_SSLv3 with high encryption cipher suites without RC4

But it still seems to use RC4: https://www.howsmyssl.com/a/check

Also the test at https://www.ssllabs.com/ssltest/viewMyClient.html says it still supports SSLv3 (not so sure about this one).

----------
messages: 238194
nosy: mogli
priority: normal
severity: normal
status: open
title: SSL Ciphers RC4
type: security
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 16 16:53:27 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Mar 2015 15:53:27 +0000
Subject: [New-bugs-announce] [issue23680] Sporadic freeze in
	test_interrupted_write_retry_text
Message-ID: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Sometimes the test suite freezes in test_interrupted_write_retry_text (test.test_io.CSignalsTest). Corresponding strace is:


write(1, "test_interrupted_write_retry_tex"..., 66) = 66
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {SIG_DFL, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
pipe2([4, 5], O_CLOEXEC)                = 0
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd0944d40) = -1 EINVAL (Invalid argument)
lseek(5, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
lseek(5, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
alarm(1)                                = 0
brk(0x3360000)                          = 0x3360000
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2640030)                 = 53870592
write(5, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4194305


A successful run looks like this:

write(1, "test_interrupted_write_retry_tex"..., 66) = 66
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {SIG_DFL, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
pipe2([4, 5], O_CLOEXEC)                = 0
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd0944d40) = -1 EINVAL (Invalid argument)
lseek(5, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
lseek(5, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
alarm(1)                                = 0
brk(0x2f60000)                          = 0x2f60000
brk(0x3360000)                          = 0x3360000
write(5, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4194305) = 65536
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2640030)                 = 65536
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
alarm(1)                                = 0
write(5, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4128769) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2640030)                 = -1 EINTR (Interrupted system call)
clone(child_stack=0x7fd1a8852ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SE
TTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fd1a88539d0, tls=0x7fd1a8853700, child_tidptr=0x7fd1a88539d0) = 3611
futex(0x24b5140, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x9a1904, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1563, {1426520501, 20155000}, ffffffff) = 0
futex(0x9a1940, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x9a1940, FUTEX_WAKE_PRIVATE, 1)  = 0
write(5, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4128769) = 4128769
futex(0x9a1904, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x9a1900, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x9a1940, FUTEX_WAKE_PRIVATE, 1)  = 1
futex(0x2631c50, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
close(5)                                = 0
close(4)                                = 0
rt_sigaction(SIGALRM, {SIG_DFL, [], SA_RESTORER, 0x7fd1ada2d0a0}, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
write(1, "ok\n", 3)                     = 3

----------
messages: 238215
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Sporadic freeze in test_interrupted_write_retry_text
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 16 18:05:30 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Mar 2015 17:05:30 +0000
Subject: [New-bugs-announce] [issue23681] Have -b warn when directly
	comparing ints and bytes
Message-ID: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>


New submission from Brett Cannon:

To help writing Python 2/3 code the -b flag should switch on a warning when comparing an int to a bytes object in Python 2. This will help when someone writes something like `b'abcd'[2] == b'c'` and it always returns False thanks to the indexing returning 99 in Python 3.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 238228
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Have -b warn when directly comparing ints and bytes
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 16 22:32:46 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 16 Mar 2015 21:32:46 +0000
Subject: [New-bugs-announce] [issue23682] distutils docs still talk about
	compatibility with	Python 2.2
Message-ID: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

I'm pretty sure the distutils docs for Python 3.4 don't need to describe how to make packages compatible with Python < 2.2.3.

I know that these docs are deprecated in favour of the Python packaging guide, but I still look at them at times, and this is embarrassing.

----------
assignee: docs at python
components: Documentation
files: dont-mention-py22.patch
keywords: patch
messages: 238241
nosy: docs at python, takluyver
priority: normal
severity: normal
status: open
title: distutils docs still talk about compatibility with Python 2.2
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38512/dont-mention-py22.patch

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

From report at bugs.python.org  Tue Mar 17 01:47:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 00:47:44 +0000
Subject: [New-bugs-announce] [issue23683] allow timeit to run expensive
	reset code per repeats
Message-ID: <1426553264.53.0.0690817239564.issue23683@psf.upfronthosting.co.za>


New submission from Robert Collins:

I was timing some cold-cache operations today and had to not use timeit because I wanted to run some code between statement (flushing caches) that shouldn't be timed as part of statement. It would be nice, similarly to -s, to be able to say -i 'something run between statement repetitions'. That is - we run statement in a tight loop some N times, and then repeat that loop some R times, I'd like to run the -i code between the R repetitions, not inside the inner timing loop (since we run that to get timer resolution).

----------
messages: 238252
nosy: rbcollins
priority: normal
severity: normal
status: open
title: allow timeit to run expensive reset code per repeats
type: enhancement

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

From report at bugs.python.org  Tue Mar 17 02:39:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 01:39:42 +0000
Subject: [New-bugs-announce] [issue23684] urlparse() documentation does not
	account for default	scheme
Message-ID: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation for urlsplit() says:

'''
urlparse(urlstring, scheme='', allow_fragments=True)

. . .

If the scheme argument is specified, it gives the default addressing scheme, to be used only if the URL does not specify one. The default value for this argument is the empty string.
'''

However this contradicts the table of attributes, which gives:

Attribute: scheme, . . . Value if not present: empty string

Similarly for urlsplit(). Of course, the description of the ?scheme? parameter is correct, and the table is only correct when no ?scheme? parameter is given:

>>> urlparse("//example.net").scheme
''
>>> urlparse(b"//example.net").scheme
b''
>>> urlparse("//example.net", "http").scheme
'http'

This issue is split off another where I tried to sneak in a quick fix, but the wording probably needs more thought. Original change: <https://bugs.python.org/review/22852/patch/14176/52720#old-line-92>.

Maybe change it to this?

Value if not present: empty string or default scheme

----------
assignee: docs at python
components: Documentation
messages: 238253
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: urlparse() documentation does not account for default scheme

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

From report at bugs.python.org  Tue Mar 17 11:13:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 10:13:53 +0000
Subject: [New-bugs-announce] [issue23685] Fix usage of PyMODINIT_FUNC
Message-ID: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch fixes the usage of the PyMODINIT_FUNC macro.

My patch is based on Thomas Wouters's patch of the issue #11410.

I don't understand why Modules/pyexpat.c redefined PyMODINIT_FUNC if not defined. In which case PyMODINIT_FUNC was not defined?

I'm not sure that PC/config.c should use PyMODINIT_FUNC instead of use "PyObject*".

@Steve.Dower: Does my change to PC/config.c look correct or not?

----------
components: Build, Windows
files: PyMODINIT_FUNC.patch
keywords: patch
messages: 238272
nosy: haypo, loewis, pitrou, steve.dower, tim.golden, twouters, zach.ware
priority: normal
severity: normal
status: open
title: Fix usage of PyMODINIT_FUNC
versions: Python 3.5
Added file: http://bugs.python.org/file38517/PyMODINIT_FUNC.patch

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

From report at bugs.python.org  Tue Mar 17 12:29:42 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 17 Mar 2015 11:29:42 +0000
Subject: [New-bugs-announce] [issue23686] Upgrade copy of OpenSSL bundled
	with Python
Message-ID: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

On Thursday OpenSSL will disclose some security issues and issue new releases: https://mta.openssl.org/pipermail/openssl-announce/2015-March/000020.html

When that happens, Python's that bundle an OpenSSL should be upgraded.

----------
keywords: security_issue
messages: 238280
nosy: alex
priority: normal
severity: normal
status: open
title: Upgrade copy of OpenSSL bundled with Python

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

From report at bugs.python.org  Tue Mar 17 14:44:45 2015
From: report at bugs.python.org (Edward)
Date: Tue, 17 Mar 2015 13:44:45 +0000
Subject: [New-bugs-announce] [issue23687] Stacktrace identifies wrong line
	in multiline list	comprehension
Message-ID: <1426599885.89.0.0578302709073.issue23687@psf.upfronthosting.co.za>


New submission from Edward:

This code:

z = [
        ["Y" for y in None
        ] for x in range(4)
    ]

produces this stacktrace in both Python 2.7 and 3.4:

Traceback (most recent call last):
  File "/Users/edwsmith/dev/untitled4/test.py", line 7, in <module>
    ] for x in range(4)
  File "/Users/edwsmith/dev/untitled4/test.py", line 7, in <listcomp>
    ] for x in range(4)
TypeError: 'NoneType' object is not iterable

Of course my code was slightly more complex, but I lost a fair amount of time troubleshooting how the 'for x in range(4)' was evaluating to None, when really, it was the inner comprehension that was failing.

Ideally the stack trace would say:

Traceback (most recent call last):
  File "/Users/edwsmith/dev/untitled4/test.py", line 6, in <module>
    ["Y" for y in None
  File "/Users/edwsmith/dev/untitled4/test.py", line 6, in <listcomp>
    ["Y" for y in None
TypeError: 'NoneType' object is not iterable

----------
components: Interpreter Core
messages: 238290
nosy: ers81239
priority: normal
severity: normal
status: open
title: Stacktrace identifies wrong line in multiline list comprehension
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Mar 17 15:26:04 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 17 Mar 2015 14:26:04 +0000
Subject: [New-bugs-announce] [issue23688] unnecessary copying of memoryview
	in gzip.GzipFile.write	?
Message-ID: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

I thought I'd go back to work on a test patch for issue21560 today, but now I'm puzzled by the explicit handling of memoryviews in gzip.GzipFile.write.
The method is defined as:

    def write(self,data):
        self._check_closed()
        if self.mode != WRITE:
            import errno
            raise OSError(errno.EBADF, "write() on read-only GzipFile object")

        if self.fileobj is None:
            raise ValueError("write() on closed GzipFile object")

        # Convert data type if called by io.BufferedWriter.
        if isinstance(data, memoryview):
            data = data.tobytes()

        if len(data) > 0:
            self.size = self.size + len(data)
            self.crc = zlib.crc32(data, self.crc) & 0xffffffff
            self.fileobj.write( self.compress.compress(data) )
            self.offset += len(data)

        return len(data)

So for some reason, when it gets passed data as a meoryview it will first copy its content to a bytes object and I do not understand why.
zlib.crc32 and zlib.compress seem to be able to deal with memoryviews so the only sepcial casing that seems required here is in determining the byte length of the data, which I guess needs to use memoryview.nbytes. I've prepared a patch (overlapping the one for issue21560) that avoids copying the data and seems to work fine.

Did I miss something about the importance of the tobytes conversion ?

----------
components: Library (Lib)
messages: 238294
nosy: wolma
priority: normal
severity: normal
status: open
title: unnecessary copying of memoryview in gzip.GzipFile.write ?
type: resource usage
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 17 17:56:20 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 16:56:20 +0000
Subject: [New-bugs-announce] [issue23689] Memory leak in Modules/sre_lib.h
Message-ID: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

In Modules/sre_lib.h on line 882 [1], a block of memory is allocated. If SRE(match) function later terminates abruptly, either because of a signal or because subsequent memory allocation fails, this block is never released.

[1] https://hg.python.org/cpython/file/c89f7c34e356/Modules/sre_lib.h#l882

----------
components: Regular Expressions
messages: 238313
nosy: abacabadabacaba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Memory leak in Modules/sre_lib.h
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 17 18:04:35 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 17:04:35 +0000
Subject: [New-bugs-announce] [issue23690] re functions never release GIL
Message-ID: <1426611875.32.0.330312694867.issue23690@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Looks like function in re module (match, fullmatch and so on) don't release GIL, even though these operations can take much time. As a result, other threads can't run while a pattern is being matched, and thread switching doesn't happen as well.

----------
components: Regular Expressions
messages: 238316
nosy: abacabadabacaba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re functions never release GIL
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 17 18:17:06 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 17:17:06 +0000
Subject: [New-bugs-announce] [issue23691] re.finditer iterator is not
	reentrant, but doesn't protect against nested calls to __next__
Message-ID: <1426612626.66.0.267835433945.issue23691@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Iterator returned by re.finditer includes a SRE_STATE value, which is not designed to be used concurrently. However, it is possible to call __next__ on such iterator while another such call is in progress, e.g. from a signal handler. This may result in corruption of SRE_STATE structure.

----------
components: Regular Expressions
messages: 238323
nosy: abacabadabacaba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.finditer iterator is not reentrant, but doesn't protect against nested calls to __next__
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 17 19:49:44 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 18:49:44 +0000
Subject: [New-bugs-announce] [issue23692] Undocumented feature prevents re
	module from finding	certain matches
Message-ID: <1426618184.57.0.811463464384.issue23692@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

This pattern matches:

    re.match('(?:()|(?(1)()|z)){2}(?(2)a|z)', 'a')

But this doesn't:

    re.match('(?:()|(?(1)()|z)){0,2}(?(2)a|z)', 'a')

The difference is that {2} is replaced by {0,2}. This shouldn't prevent the pattern from matching anywhere where it matched before.

The reason for this misbehavior is a feature which is designed to protect re engine from infinite loops, but in fact it sometimes prevents patterns from matching where they should. I think that this feature should be at least properly documented, by properly I mean that it should be possible to reconstruct the exact behavior from documentation, as the implementation is not particularly easy to understand.

----------
components: Regular Expressions
messages: 238330
nosy: abacabadabacaba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Undocumented feature prevents re module from finding certain matches
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 17 23:34:37 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 22:34:37 +0000
Subject: [New-bugs-announce] [issue23693] timeit accuracy could be better
Message-ID: <1426631677.96.0.782828300886.issue23693@psf.upfronthosting.co.za>


New submission from Robert Collins:

In #6422 Haypo suggested making the timeit reports much better. This is a new ticket just for that. See https://bitbucket.org/haypo/misc/src/tip/python/benchmark.py and http://bugs.python.org/issue6422?@ok_message=issue%206422%20nosy%2C%20nosy_count%2C%20stage%20edited%20ok&@template=item#msg164216

----------
components: Library (Lib)
messages: 238353
nosy: haypo, rbcollins
priority: normal
severity: normal
stage: needs patch
status: open
title: timeit accuracy could be better
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar 18 00:19:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 23:19:38 +0000
Subject: [New-bugs-announce] [issue23694] PEP 475: handle EINTR in
	fileutils.c
Message-ID: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>


New submission from STINNER Victor:

fileutils.c must be modified to retry when a function fails with EINTR: see the PEP 475.

I'm working on a patch.

----------
messages: 238358
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: handle EINTR in fileutils.c
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 18 01:18:02 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Wed, 18 Mar 2015 00:18:02 +0000
Subject: [New-bugs-announce] [issue23695] idiom for clustering a data series
	into n-length groups
Message-ID: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>


New submission from Paddy McCarthy:

In the zip section of the documentation, e.g. https://docs.python.org/3/library/functions.html#zip There is mention of an idiom for clustering a data series into n-length groups that I seem to only come across when people are explaining how it works on blog entries such as the three mentioned here: http://www.reddit.com/r/programming/comments/2z4rv4/a_function_for_partitioning_python_arrays/cpfvwun?context=3

It is not a straight-forward bit of code and so I think it should either be explained in more detail in the documentation or removed as an idiom, or I guess it could be encapsulated in a function and added to the stdlib.

----------
assignee: docs at python
components: Documentation
messages: 238365
nosy: Paddy McCarthy, docs at python
priority: normal
severity: normal
status: open
title: idiom for clustering a data series into n-length groups
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar 18 01:58:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 00:58:16 +0000
Subject: [New-bugs-announce] [issue23696] zipimport: chain ImportError to
	OSError
Message-ID: <1426640296.98.0.079062899559.issue23696@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To work on the issue #23694, I refactored the C function _Py_fopen_obj() to raise an exception on error. I noticed the that zipimport replaces the current exception with ZipImportError.

Attached patch chains the ZipImportError to the OSError to provide more context on error. For example, you can see in the unit test that ZipImportError was caused by a permission error.

Is it ok to require ZipImport.__context__ to be an OSError in the unit test? Can it be added to "zipimport spec"? If not, the test may be splitted to only check __context__ in a test decorated with @cpython_only.

----------
files: zipimporterror_oserror.patch
keywords: patch
messages: 238368
nosy: brett.cannon, haypo, ncoghlan
priority: normal
severity: normal
status: open
title: zipimport: chain ImportError to OSError
versions: Python 3.5
Added file: http://bugs.python.org/file38536/zipimporterror_oserror.patch

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

From report at bugs.python.org  Wed Mar 18 04:20:20 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Mar 2015 03:20:20 +0000
Subject: [New-bugs-announce] [issue23697] Module level map & submit for
	concurrent.futures
Message-ID: <1426648820.66.0.638337601517.issue23697@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Currently, concurrent.futures requires you to explicitly create and manage the lifecycle of a dedicated executor to handle multithreaded and multiprocess dispatch of concurrent activities.

It may be beneficial to provide module level tmap(), pmap(), tsubmit() and psubmit() APIs that use a default ThreadExecutor and/or ProcessExecutor instance to provide concurrent execution, with reasonable default settings for the underlying thread & process pools.

(Longer names like map_thread, and map_process would also be possible, but tmap & pmap are much easier to type and seem sufficient for mnemonic purposes)

This would allow usage like:

  done, not_done = wait(tmap(func, data))

and:

  for f in as_completed(tmap(func, data)):
    result = f.result()

Ways to explicitly set and get the default thread and process pools would also need to be provided, perhaps based on the design of the event loop management interface in the asyncio module.

----------
messages: 238373
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Module level map & submit for concurrent.futures

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

From report at bugs.python.org  Wed Mar 18 07:33:05 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Wed, 18 Mar 2015 06:33:05 +0000
Subject: [New-bugs-announce] [issue23698] Fix documentation for
	multiprocessing.Manager
Message-ID: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

multiprocessing.Manager seems to have an inconsistency in behaviour/documentation or both.

The behaviour inconsistency is documented in the attached test script which should run for both Python2 and Python3. 

Briefly, multiprocessing.managers.BaseManager class starts a Python subprocess only after a call to its "start" method. Whereas its subclass, multiprocessing.managers.SyncManager does at the time of object creation. This is undocumented and against the base classe's documented behaviour.

Also, the SyncManager is more commonly advertised via the facade multiprocessing.Manager() which is again at odds with the BaseManager's interface in that,

1. It takes no arguments (Python2) and different arguments (Python 3).
2. You can't call "start" on it but you can call "start" if you initialize it via multiprocessing.managers.SyncManager directly (!)
3. Even if you can't call a start on it, apparently you can shut it down via a call to "shutdown"
4. When you try to start such a manager you get a strange AssertionError complaining the state is not INITIAL. A better error is required here.

Please find the attached file for all the sequence of tests done.

Suggested changes are,

1. Fix the inconsistency in documented behaviour between SyncManager and its base class. Either don't start the child process upon object creation or document it.
2. Fix the inconsistency in SyncManager object creation interface and behaviour via "mulitprocessing.Manager()" and directly via "multiprocessing.managers.SyncManager(...)" . One should be able to start both objects cleanly. And the former should also take the address argument. If not document it properly.
3. The AssertionError when trying to start the SyncManager object obtained via a call to "multiprocessing.Manager()" looks like a bug. It should be fixed - otherwise a bette error should be raised and documentation updated.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: mp_test.py
messages: 238379
nosy: docs at python, pythonhacker
priority: normal
severity: normal
status: open
title: Fix documentation for multiprocessing.Manager
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38537/mp_test.py

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

From report at bugs.python.org  Wed Mar 18 14:43:22 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 18 Mar 2015 13:43:22 +0000
Subject: [New-bugs-announce] [issue23699] Add a macro to ease writing rich
	comparisons
Message-ID: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

Rich comparison functions of many builtin types include a block of boilerplate which can be consolidated in a macro. The macro can be useful for third-party extensions as well as CPython itself.

See this e-mail for a longer write-up: https://mail.python.org/pipermail/python-ideas/2015-March/032564.html

----------
files: 0001-Define-Py_RICHCOMPARE-to-ease-writing-rich-compariso.patch
keywords: patch
messages: 238441
nosy: encukou
priority: normal
severity: normal
status: open
title: Add a macro to ease writing rich comparisons
type: enhancement
Added file: http://bugs.python.org/file38541/0001-Define-Py_RICHCOMPARE-to-ease-writing-rich-compariso.patch

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

From report at bugs.python.org  Wed Mar 18 16:17:06 2015
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 18 Mar 2015 15:17:06 +0000
Subject: [New-bugs-announce] [issue23700] tempfile.NamedTemporaryFile can
	close too early if used	as iterator
Message-ID: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

This bug is very similar to #18879, the only difference is that _TemporaryFileWrapper.__iter__ is the problem (in #18879, __getattr__ was fixed, but __iter__ was not). The real world use case that helped me find this bug is at the bottom of this report, this is a simple reproducer:


>>> import tempfile
>>> for l in tempfile.NamedTemporaryFile(mode='a+b'):
...     print(l)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: readline of closed file


I'm attaching a patch that fixes this (+ testcase).

Note: I actually discovered this while using


>>> from urllib.request import urlopen
>>> for l in urlopen('ftp://<some_ftp>'):
...     print(l)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: readline of closed file


Opening FTP uses urllib.response, which in turn uses tempfile._TemporaryFileWrapper, which makes this example fail.

----------
components: Library (Lib)
files: python-3.4-tempfile-iter.patch
keywords: patch
messages: 238451
nosy: bkabrda
priority: normal
severity: normal
status: open
title: tempfile.NamedTemporaryFile can close too early if used as iterator
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38543/python-3.4-tempfile-iter.patch

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

From report at bugs.python.org  Wed Mar 18 17:51:10 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Wed, 18 Mar 2015 16:51:10 +0000
Subject: [New-bugs-announce] [issue23701] Drop extraneous comment from
	winreg.QueryValue's	docstring
Message-ID: <1426697470.53.0.824194712699.issue23701@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

winreg.QueryValue's docstring has an "interesting" comment at the end:

"But the underlying API call doesn't return the type, Lame Lame Lame, DONT USE THIS!!!"

The documentation (https://docs.python.org/3.4/library/winreg.html#winreg.QueryValue) already mentions the shortcomings of QueryValue. This comment should be removed or at least rewritten in a more serious note.

----------
components: Library (Lib)
files: drop_winreg_string.patch
keywords: patch
messages: 238459
nosy: Claudiu.Popa, loewis, steve.dower
priority: low
severity: normal
status: open
title: Drop extraneous comment from winreg.QueryValue's docstring
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38545/drop_winreg_string.patch

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

From report at bugs.python.org  Wed Mar 18 20:48:34 2015
From: report at bugs.python.org (Paul Sokolovsky)
Date: Wed, 18 Mar 2015 19:48:34 +0000
Subject: [New-bugs-announce] [issue23702]
	docs.python.org/3/howto/descriptor.html still refers
	to	"unbound methods"
Message-ID: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

Under https://docs.python.org/3/howto/descriptor.html#functions-and-methods , there're several references to unbound methods (including in expected output from the interpreter).

As known, unbound methods are gone in Python3, so seeing those are confusing. (I didn't sharply know that unbound methods are gone from Py3, so was pretty confused by the examples there, comparing them with actual output of Cpython 3.4).

----------
assignee: docs at python
components: Documentation
messages: 238468
nosy: docs at python, pfalcon
priority: normal
severity: normal
status: open
title: docs.python.org/3/howto/descriptor.html still refers to "unbound methods"
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 19 08:09:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Mar 2015 07:09:16 +0000
Subject: [New-bugs-announce] [issue23703] urljoin() with no directory
	segments duplicates filename
Message-ID: <1426748956.21.0.814756519005.issue23703@psf.upfronthosting.co.za>


New submission from Martin Panter:

This is a regression caused by revision 901e4e52b20a. Before (e.g. Python 3.4):

>>> urljoin('a', 'b')
'b'

After:

>>> urljoin('a', 'b')
'b/b'

This was identified in <https://bugs.python.org/issue18828#msg238363> but is actually caused by the revision committed for Issue 22278.

----------
components: Library (Lib)
messages: 238493
nosy: demian.brecht, vadmium
priority: normal
severity: normal
status: open
title: urljoin() with no directory segments duplicates filename
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 19 08:11:27 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 07:11:27 +0000
Subject: [New-bugs-announce] [issue23704] Make deques a full MutableSequence
	by adding index(), insert(), and copy()
Message-ID: <1426749087.45.0.288673142528.issue23704@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: Library (Lib)
files: deque_insert_index_copy3.diff
keywords: patch
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Make deques a full MutableSequence by adding index(), insert(), and copy()
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38552/deque_insert_index_copy3.diff

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

From report at bugs.python.org  Thu Mar 19 08:25:15 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 07:25:15 +0000
Subject: [New-bugs-announce] [issue23705] Speed-up deque.__contains__
Message-ID: <1426749915.16.0.735258813195.issue23705@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Help deques match the performance of lists for a __contains__ check.  Comparative timings are attached.

----------
assignee: rhettinger
components: Library (Lib)
files: deque_contains0.diff
keywords: patch
messages: 238496
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Speed-up deque.__contains__
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file38553/deque_contains0.diff

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

From report at bugs.python.org  Thu Mar 19 10:32:41 2015
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Thu, 19 Mar 2015 09:32:41 +0000
Subject: [New-bugs-announce] [issue23706] pathlib.Path.write_text should
	include a newline argument
Message-ID: <1426757561.17.0.481870343329.issue23706@psf.upfronthosting.co.za>


New submission from Ugra D?niel:

The new pathlib.Path [read|write]_[binary|text] methods will be very useful, one thing I miss badly is the newline argument for write_text.

In some cases text files need a specific line ending (independent from the platform the code is being executed on.) In my mind this is analogous to passing an explicit encoding argument.

Of course, one can always use built-in open for this scenario. It would be a nice addition anyway :)

----------
components: Library (Lib)
messages: 238498
nosy: daniel.ugra
priority: normal
severity: normal
status: open
title: pathlib.Path.write_text should include a newline argument
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 19 13:19:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 12:19:55 +0000
Subject: [New-bugs-announce] [issue23707] PEP 475: os.urandom() doesn't
	handle EINTR correctly
Message-ID: <1426767595.67.0.731351330983.issue23707@psf.upfronthosting.co.za>


New submission from STINNER Victor:

dev_urandom_python() retries read() if it fails with EINTR, but Python signal handlers are not called: PyErr_CheckSignals() is not called. It's important be able to interrupt a function by a signal, especially if it's blocking.

We need maybe a new _Py_read() function which would retry on EINTR. The code can be based on posix_read(). For open(), there is already _Py_open() which retries on EINTR (since the changeset ed25e945cdc2, issue #23694). It can be useful for FileIO.read().

dev_urandom_noraise() retries on EINTR without calling PyErr_CheckSignals(). It may be acceptable since this function is only called by _PyRandom_Init() at an early stage of Python initialization. Or maybe EINTR should call Py_FatalError()?

On Linux 3.18 (Fedora 21 with kernel 3.18.7-200.fc21.x86_64), reading 1 GB from /dev/urandom or getrandom() returns 0x1ffffff bytes (32 MB). It's not an issue, os.urandom() continues to read until it gets enough data.

I tried to interrupt os.urandom() on Python 3.4 (read) and Python 3.5 (getrandom): reading from /dev/urandom using a file descriptor or getrandom() have the same behaviour, none fail with EINTR. I checked syscalls using strace.

It looks like getrandom() only fails with EINTR when flags=GRND_RANDOM. So this issue is maybe more theoric.

----------
messages: 238503
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: os.urandom() doesn't handle EINTR correctly
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 19 14:33:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:33:30 +0000
Subject: [New-bugs-announce] [issue23708] PEP 475: Add _Py_read() and
	_Py_write() functions
Message-ID: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To factorize code handling EINTR, I propose add 2 new functions to fileutils.h: _Py_read() and _Py_write().

Attached patch adds these functions and use them in the os and _io modules.

The code of the functions is based on the code from the os and _io modules. The main change is that the functions now truncate code if greater than PY_SSIZE_T_MAX. Other changes are just refactoring.

----------
files: py_read_write.patch
keywords: patch
messages: 238514
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: Add _Py_read() and _Py_write() functions
versions: Python 3.5
Added file: http://bugs.python.org/file38557/py_read_write.patch

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

From report at bugs.python.org  Thu Mar 19 14:36:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:36:49 +0000
Subject: [New-bugs-announce] [issue23709] Refactor ossaudiodev: use _Py_read
	and _Py_write with	the Py_buffer
Message-ID: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch enhances ossaudiodev to support buffer larger than 2 GB (replace the C int type with C Py_ssize_t). It uses the new _Py_read() and _Py_write() functions added in the issue #23708 with the Py_buffer API.

By the way, I don't understand the purpose of the input and output counters (icount and ocount fields of the oss_audio_t structure), they don't look to be used?!

----------
files: ossaudiodev.patch
keywords: patch
messages: 238516
nosy: haypo
priority: normal
severity: normal
status: open
title: Refactor ossaudiodev: use _Py_read and _Py_write with the Py_buffer
versions: Python 3.5
Added file: http://bugs.python.org/file38559/ossaudiodev.patch

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

From report at bugs.python.org  Thu Mar 19 15:41:39 2015
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Thu, 19 Mar 2015 14:41:39 +0000
Subject: [New-bugs-announce] [issue23710] C API doc for PyObject_HEAD is
	outdated
Message-ID: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen:

https://docs.python.org/3/c-api/structures.html#c.PyObject_HEAD says that the macro should be used for creating new types and that it has ob_type. Unfortunately at some point (@61466 perhaps) that definition in object.h was changed. This affects other pages too (at least https://docs.python.org/3/extending/newtypes.html).

I encountered this while checking if a C extension (imposm.parser) could be trivially ported for Python 3. Unfortunately not. I suppose

  self->ob_type

should be replaced with

  Py_TYPE(self)

but that isn't really clear from the docs.

----------
assignee: docs at python
components: Documentation
messages: 238530
nosy: docs at python, tpievila
priority: normal
severity: normal
status: open
title: C API doc for PyObject_HEAD is outdated

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

From report at bugs.python.org  Thu Mar 19 16:40:37 2015
From: report at bugs.python.org (Maxim Kot)
Date: Thu, 19 Mar 2015 15:40:37 +0000
Subject: [New-bugs-announce] [issue23711] ConfigParser module blames on
	section less ini file
Message-ID: <1426779637.66.0.616231455892.issue23711@psf.upfronthosting.co.za>


New submission from Maxim Kot:

Wikipedia (http://en.wikipedia.org/wiki/INI_file#Sections) says:
>Keys may (but need not) be grouped into arbitrarily named sections

But when it's trying to parse file without section header - "MissingSectionHeaderError: File contains no section headers" raised.

Can such check be made optional and switched on for default for example?

----------
components: Library (Lib)
messages: 238537
nosy: Maxim Kot, lukasz.langa
priority: normal
severity: normal
status: open
title: ConfigParser module blames on section less ini file
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 19 20:57:42 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 19:57:42 +0000
Subject: [New-bugs-announce] [issue23712] Experiment: Assume that exact
	unicode hashes are perfect	discriminators
Message-ID: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

This tracker item is for a thought experiment I'm running where I can collect the thoughts and discussions in one place.  It is not an active proposal for inclusion in Python.

The idea is to greatly speed-up the language for set/dict lookups of unicode value by skipping the exact comparison when the unicode type is exact and the 64-bit hash values are known to match.

Given the siphash and hash randomization, we get a 1 in 2**64 chance of a false positive (which is better than the error rate for non-ECC DRAM itself).  

However, since the siphash isn't cryptographically secure, presumably a malicious chooser of keys could generate a false positive on-purpose.

This technique is currently used by git and mercurial which use hash values for file and version graphs without checking for an exact match (because the chance of a false positive is vanishingly rare).

The Python test suite passes as does the test suites for a number of packages I have installed.

----------
assignee: rhettinger
components: Interpreter Core
files: assume_perf_uni_hash.diff
keywords: patch
messages: 238552
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Experiment:  Assume that exact unicode hashes are perfect discriminators
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file38565/assume_perf_uni_hash.diff

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

From report at bugs.python.org  Thu Mar 19 21:05:03 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 20:05:03 +0000
Subject: [New-bugs-announce] [issue23713] intermittent failure of
	multiprocessing unit
	test	test_imap_unordered_handle_iterable_exception
Message-ID: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za>


New submission from Davin Potts:

test_imap_unordered_handle_iterable_exception fails intermittently on some platforms due to the test being too rigid (fragile) about the order of the items being iterated over which, as the name would imply, is not guaranteed.

Of the multiprocessing module's test modules, test_multiprocessing_fork, test_multiprocessing_forkserver, and test_multiprocessing_spawn all leverage the unit test test_imap_unordered_handle_iterable_exception in multiple different contexts.  There are thus multiple opportunities for test_imap_unordered_handle_iterable_exception to fail due to this fragility -- it's maybe a little bit surprising the test doesn't fail more often than it does.

A patch is forthcoming.

----------
assignee: davin
components: Tests
messages: 238553
nosy: davin, jnoller, sbt
priority: normal
severity: normal
status: open
title: intermittent failure of multiprocessing unit test test_imap_unordered_handle_iterable_exception
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 19 22:31:47 2015
From: report at bugs.python.org (Ariel Bruner)
Date: Thu, 19 Mar 2015 21:31:47 +0000
Subject: [New-bugs-announce] [issue23714] Comprehension + eval doesn't work
	inside function	definition
Message-ID: <1426800707.67.0.859108792069.issue23714@psf.upfronthosting.co.za>


New submission from Ariel Bruner:

The following code gives a NameError:

>>> def foo(bar):
	print {eval(x) for x in ['bar']}


>>> foo(2)

Traceback (most recent call last):
  File "<pyshell#52>", line 1, in <module>
    foo(2)
  File "<pyshell#51>", line 2, in foo
    print {eval(x) for x in ['bar']}
  File "<pyshell#51>", line 2, in <setcomp>
    print {eval(x) for x in ['bar']}
  File "<string>", line 1, in <module>
NameError: name 'bar' is not defined

I've seen this kind of bug reported for Python 3.X (e.g. Issue5242), and the behavior seems to be identical (e.g. can be fixed with {eval(x) for x in ['bar'] if True or bar}), but the previously reported bug reports mention comprehension is implemented differently on 2.X and that it should not happen there, so I thought that might be of interest.

----------
components: Windows
messages: 238561
nosy: Ariel Bruner, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Comprehension + eval doesn't work inside function definition
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 20 02:13:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 01:13:29 +0000
Subject: [New-bugs-announce] [issue23715] PEP 475: signal.sigtimedwait()
	must retry if	sigtimedwait() failed with EINTR
Message-ID: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch changes signal.sigtimedwait() to retry if sigtimedwait() failed with EINTR and the signal handler didn't raise an exception.

----------
files: sigtimedwait_eintr.patch
keywords: patch
messages: 238595
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: signal.sigtimedwait() must retry if sigtimedwait() failed with EINTR
versions: Python 3.5
Added file: http://bugs.python.org/file38583/sigtimedwait_eintr.patch

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

From report at bugs.python.org  Fri Mar 20 03:14:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 02:14:57 +0000
Subject: [New-bugs-announce] [issue23716] test_multiprocessing_spawn hangs
	on x86 Ubuntu Shared 3.x
Message-ID: <1426817697.21.0.499031040791.issue23716@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like the changeset 0b99d7043a99 (issue #23694) introduced a regression:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11358/

[340/393] test_multiprocessing_spawn
Timeout (1:00:00)!
Thread 0x55aacdc0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 943 in acquire
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 911 in test_notify_all
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 577 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 625 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 176 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1772 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1806 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1283 in test_runner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 967 in runtest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 763 in main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/__main__.py", line 3 in <module>
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 170 in _run_module_as_main
make: *** [buildbottest] Error 1

----------
messages: 238600
nosy: haypo, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn hangs on x86 Ubuntu Shared 3.x
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 20 12:19:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 11:19:31 +0000
Subject: [New-bugs-announce] [issue23717] strptime() with year-weekday pair
	can produce invalid	data
Message-ID: <1426850371.96.0.168304833853.issue23717@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

strptime() with year-weekday pair can produce invalid data.

>>> time.strptime('2015 0', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 1', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 2', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=1, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 3', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 4', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 5', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=4, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 6', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=1, tm_isdst=-1)

You get Jan 1 with any weekday.

----------
components: Library (Lib)
messages: 238645
nosy: belopolsky, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: strptime() with year-weekday pair can produce invalid data
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar 20 12:30:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 11:30:32 +0000
Subject: [New-bugs-announce] [issue23718] strptime() can produce invalid
	date with negative year	day
Message-ID: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

strptime() can produce invalid time with negative year day when parse year-week-weekday set. Such time is rejected by strftime(), so strptime/strftime roundtrip doesn't work.

>>> t = time.strptime('2015 0 0', '%Y %U %w')
>>> t
time.struct_time(tm_year=2014, tm_mon=12, tm_mday=28, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=-3, tm_isdst=-1)
>>> time.strftime('%Y %U %w', t)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: day of year out of range

----------
components: Library (Lib)
messages: 238648
nosy: belopolsky, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: strptime() can produce invalid date with negative year day
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar 20 13:09:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 12:09:51 +0000
Subject: [New-bugs-announce] [issue23719] PEP 475: port test_eintr to Windows
Message-ID: <1426853391.45.0.421512531157.issue23719@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, test_eintr is complelty skipped on Windows. time.sleep() was also patched on Windows to retry when interrupted by a signal (issue #23646) and I was able to see a different when testing manually.

test_eintr is currently implemented with signal.setitimer() and os.fork(). Windows doesn't have signal.setitimer(), signal.alarm(), nor os.fork(), but it's possible to send a signal to another process using os.kill() (by the way, see the issue #14484 "missing return in win32_kill?").

At least, time.sleep() should be tested on Windows.

----------
messages: 238652
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: port test_eintr to Windows
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 20 13:56:26 2015
From: report at bugs.python.org (Alexey Kazantsev)
Date: Fri, 20 Mar 2015 12:56:26 +0000
Subject: [New-bugs-announce] [issue23720] __del__() order is broken since
	3.4.0
Message-ID: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>


New submission from Alexey Kazantsev:

Pythons prior to 3.4.0 print

Vector!
Device!

while >=3.4.0 print

Device!
Vector!

If we replace Main with Vector on line 21, the behavior becomes random: in 50% of all cases it prints the wrong sequence, in other 50% the right. Our team treats this as a bug for several reasons:

1) Objects should be destroyed in breadth first reference tree traversal order, starting from the root. There are no cycles. It is nonsense to have freed children in parent's destructor.

2) Our applications suffer very much from this bug. Real "Vector" holds GPGPU memory and real "Device" holds the context, and CUDA/OpenCL require the context to be freed the last. With CUDA, the invalid destructor call order leads to segmentation faults.

This may have something to deal with the implementation of PEP 442 (though in our case there no reference cycles at all).

----------
files: bug.py
messages: 238661
nosy: Alexey Kazantsev
priority: normal
severity: normal
status: open
title: __del__() order is broken since 3.4.0
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38599/bug.py

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

From report at bugs.python.org  Fri Mar 20 14:28:50 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Mar 2015 13:28:50 +0000
Subject: [New-bugs-announce] [issue23721] Set up a daily test coverage run
Message-ID: <1426858130.98.0.810512379451.issue23721@psf.upfronthosting.co.za>


New submission from Brett Cannon:

devinabox has instructions on how to get the best test coverage for Python possible: https://hg.python.org/devinabox/file/1eeb96fe98f1/README#l124 . It would probably be good to get a test report at least daily to help keep an eye on general test coverage and to help new contributors to know where they can help by contributing more tests.

Otherwise we should try to get something like https://coveralls.io/ set up on https://github.com/python/cpython

----------
messages: 238668
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Set up a daily test coverage run

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

From report at bugs.python.org  Fri Mar 20 14:44:21 2015
From: report at bugs.python.org (Martin Teichmann)
Date: Fri, 20 Mar 2015 13:44:21 +0000
Subject: [New-bugs-announce] [issue23722] During metaclass.__init__,
	super() of the constructed class does not work
Message-ID: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>


New submission from Martin Teichmann:

When a new class is initialized with __init__ in a metaclass,
the __class__ cell of the class about to be initialized is not
set yet, meaning that super() does not work.

This is a known but fixable problem. The attached patch moves
the initialization of __class__ from the end of __build_class__
into type.__new__. This avoids the proliferation of methods
which don't have the __class__ cell set.

----------
components: Interpreter Core
files: patch
messages: 238672
nosy: Martin.Teichmann
priority: normal
severity: normal
status: open
title: During metaclass.__init__, super() of the constructed class does not work
versions: Python 3.5
Added file: http://bugs.python.org/file38604/patch

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

From report at bugs.python.org  Fri Mar 20 19:14:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Mar 2015 18:14:42 +0000
Subject: [New-bugs-announce] [issue23723] Provide a way to disable bytecode
	staleness checks
Message-ID: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>


New submission from Brett Cannon:

In environments where bytecode generation is thoroughly controlled, it would be nice if there was a way to specify that the bytecode file is externally guaranteed to be up-to-date, and thus skip any stat call involving bytecode verification. Could be represented with a timestamp of either all zeroes or ones in the bytecode file header.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 238704
nosy: brett.cannon, gregory.p.smith, twouters
priority: low
severity: normal
status: open
title: Provide a way to disable bytecode staleness checks
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 20 19:50:08 2015
From: report at bugs.python.org (Umank Behera)
Date: Fri, 20 Mar 2015 18:50:08 +0000
Subject: [New-bugs-announce] [issue23724] Stack Trace should show argument
	value passed into a	function, not just the keyword
Message-ID: <1426877408.78.0.379022955074.issue23724@psf.upfronthosting.co.za>


New submission from Umank Behera:

Code:
def main(foo):
    raise Exception("Some Exception")

bar = 1
main(bar)
----

On execution:
Traceback (most recent call last):
  File "st.py", line 5, in <module>
    main(bar)
  File "st.py", line 2, in main
    raise Exception("Some Exception")
Exception: Some Exception
----

It should show the value of bar is 1 on the first frame printed.

----------
files: st.py
messages: 238711
nosy: Umank Behera
priority: normal
severity: normal
status: open
title: Stack Trace should show argument value passed into a function, not just the keyword
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38607/st.py

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

From report at bugs.python.org  Fri Mar 20 20:14:52 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Fri, 20 Mar 2015 19:14:52 +0000
Subject: [New-bugs-announce] [issue23725] [PATCH] update tempfile docs to
	say that TemporaryFile	is secure
Message-ID: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>


New submission from Zbyszek J?drzejewski-Szmek:

tempfile docs can use some refreshing.

----------
components: Library (Lib)
files: 0001-docs-update-description-of-TemporaryFile-and-tempfil.patch
keywords: patch
messages: 238713
nosy: zbysz
priority: normal
severity: normal
status: open
title: [PATCH] update tempfile docs to say that TemporaryFile is secure
versions: Python 3.5
Added file: http://bugs.python.org/file38608/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch

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

From report at bugs.python.org  Fri Mar 20 21:25:57 2015
From: report at bugs.python.org (Eugene Toder)
Date: Fri, 20 Mar 2015 20:25:57 +0000
Subject: [New-bugs-announce] [issue23726] Don't enable GC for classes that
	don't add new fields
Message-ID: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>


New submission from Eugene Toder:

As far as I can tell, if a new class does not add any new fields, and its base class doesn't use GC, there's no reason to enable GC for the new class.
This is useful for creating lightweight wrappers around classes implemented in C.

----------
files: class_gc.diff
keywords: patch
messages: 238718
nosy: eltoder, pitrou
priority: normal
severity: normal
status: open
title: Don't enable GC for classes that don't add new fields
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file38610/class_gc.diff

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

From report at bugs.python.org  Fri Mar 20 22:38:06 2015
From: report at bugs.python.org (Brian Peterson)
Date: Fri, 20 Mar 2015 21:38:06 +0000
Subject: [New-bugs-announce] [issue23727] rfc2231 line continuations result
	in an additional	newline
Message-ID: <1426887486.58.0.0728817977831.issue23727@psf.upfronthosting.co.za>


New submission from Brian Peterson:

Hey, 

So here we go:

When an email header goes over a line break, rfc2231 (https://tools.ietf.org/html/rfc2231) specifies that it get formatted in such a way that the line break is stripped out. This formatting looks like, for example:

> filename*0="my long attachment"
> filename*1="name.txt"

... which should then get interpreted so that is "semantically identical" to:

> filename="my long attachment name.txt"

Here's a link to an example github repo where I see this not occurring: https://github.com/bepetersn/special-repo

More specifically, the behavior I AM seeing is that the formatting is handled just fine, but that a newline character gets added in.

(I originally thought this had to do with the requests library, so that's why my example repo has some stuff related to that in there too, which you can safely ignore.)

Also, if I am off-base, possibly if my input email's formatting is to blame, sorry for the trouble. :-)

Thanks for reading!

----------
components: Windows
messages: 238725
nosy: Brian Peterson, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: rfc2231 line continuations result in an additional newline
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 20 22:52:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 21:52:50 +0000
Subject: [New-bugs-announce] [issue23728] binascii.crc_hqx() can return
	negative integer
Message-ID: <1426888370.18.0.244841446134.issue23728@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

zlib.adler32(), zlib.crc32(), and binascii.crc32() always return 32-bit unsigned integer in Python 3. binascii.crc_hqx() almost always returns 16-bit unsigned integer. But there is an exception. The result can negative only when arguments of binascii.crc_hqx() are empty bytes and negative integer. This looks as a bug and should be fixed. But may be no need to apply changes to maintained releases.

----------
components: Extension Modules
keywords: easy
messages: 238726
nosy: gregory.p.smith, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: binascii.crc_hqx() can return negative integer
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 21 09:29:32 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 08:29:32 +0000
Subject: [New-bugs-announce] [issue23729] Import ElementTree documentation
	for namespaces and XPath
Message-ID: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Show examples of how to search XML that contains namespaces.

Also indicate the ElementTree subset of XPath supports filters in the form [tag=text].

----------
assignee: rhettinger
components: Documentation
files: elementtree_doc.diff
keywords: patch
messages: 238774
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Import ElementTree documentation for namespaces and XPath
versions: Python 3.5
Added file: http://bugs.python.org/file38620/elementtree_doc.diff

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

From report at bugs.python.org  Sat Mar 21 10:11:29 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 21 Mar 2015 09:11:29 +0000
Subject: [New-bugs-announce] [issue23730] Document return value for
	ZipFile.extract()
Message-ID: <1426929089.45.0.62065226759.issue23730@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

The documentation for zipfile.ZipFile.extract() doesn't mention at all that it returns the local path created, either for the directory that the member represents, or the new file created from the zipped data.

*Returns the full local path created (a directory or new file)* or similar.

----------
assignee: docs at python
components: Documentation
messages: 238778
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: Document return value for ZipFile.extract()
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Mar 21 14:33:51 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 21 Mar 2015 13:33:51 +0000
Subject: [New-bugs-announce] [issue23731] Implement PEP 488
Message-ID: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za>


New submission from Brett Cannon:

https://www.python.org/dev/peps/pep-0488/

----------
assignee: brett.cannon
components: Interpreter Core
messages: 238799
nosy: brett.cannon
priority: release blocker
severity: normal
stage: test needed
status: open
title: Implement PEP 488
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 21 15:02:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 21 Mar 2015 14:02:55 +0000
Subject: [New-bugs-announce] [issue23732] Update porting HOWTO about new -b
	semantics
Message-ID: <1426946575.09.0.666027898536.issue23732@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Thanks to http://bugs.python.org/issue23681 we now have a better story about helping people find int/bytes comparison issues. The docs for Python 3.5 -- but not Python 3.4! -- should get updated to point out this change.

----------
assignee: brett.cannon
components: Documentation
messages: 238803
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update porting HOWTO about new -b semantics
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 21 15:03:47 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 21 Mar 2015 14:03:47 +0000
Subject: [New-bugs-announce] [issue23733] Update porting HOWTO for bytes
	interpolation
Message-ID: <1426946627.25.0.962328562695.issue23733@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The porting HOWTO for Python 3.5 doesn't mention that bytes interpolation will exist.

----------
assignee: brett.cannon
components: Documentation
messages: 238804
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update porting HOWTO for bytes interpolation
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 21 19:59:07 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 21 Mar 2015 18:59:07 +0000
Subject: [New-bugs-announce] [issue23734] zipimport should not check pyc
	timestamps against zipped	py files
Message-ID: <1426964347.09.0.21067648462.issue23734@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The zipimport module checks the timestamp of a pyc file loaded from the zip file against the timestamp of a corresponding py file in the zip if any.  This seems pointless.  By the time someone has created a zip file for zipimport they should have guaranteed that the pyc's are fresh or not have put them into the zip file at all (wasteful).

https://hg.python.org/cpython/file/e8878579eb68/Modules/zipimport.c#l1187

There is a comment in the code alluding to this, but the mtime check is still done right above.

----------
components: Extension Modules
messages: 238824
nosy: gregory.p.smith
priority: low
severity: normal
status: open
title: zipimport should not check pyc timestamps against zipped py files
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 22 01:42:54 2015
From: report at bugs.python.org (Carlos Pita)
Date: Sun, 22 Mar 2015 00:42:54 +0000
Subject: [New-bugs-announce] [issue23735] Readline not adjusting width after
	resize with 6.3
Message-ID: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>


New submission from Carlos Pita:

See here:

https://github.com/ipython/ipython/issues/6974

Chet Ramey confirmed the bug is downstream:

As I recall from looking briefly at the ipython/python source code, it has
to do with python not handling the SIGWINCH and expecting readline to do
it even when readline is not active. In readline-6.3, readline only
installs its signal handlers when rl_callback_read_char is called, which
python does only when it receives a character and its select(2) call
returns. The way readline-6.2 and earlier did things, it could `steal'
signals from an application without being active. I think python doesn't
handle SIGWINCH at all, which means that it expects readline's signal
handler to be active all the time, instead of just when python calls back
into readline to have it read a character.

A possible fix would be to have python's readline module install a signal
handler for SIGWINCH and have it set readline's idea of the screen size.

----------
messages: 238857
nosy: Carlos Pita
priority: normal
severity: normal
status: open
title: Readline not adjusting width after resize with 6.3

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

From report at bugs.python.org  Sun Mar 22 05:53:51 2015
From: report at bugs.python.org (John Nagle)
Date: Sun, 22 Mar 2015 04:53:51 +0000
Subject: [New-bugs-announce] [issue23736] "make test" on clean py3 install
	on CentOS 6.2 - 2 tests	fail
Message-ID: <1427000031.58.0.0063675703932.issue23736@psf.upfronthosting.co.za>


New submission from John Nagle:

Installing Python 3.4.2 on CentOS 6.  Clean install.  Using procedure in README file:

./configure
make
make test

2 tests fail in "make test" The first one is because the FTP client
test is trying to test against a site that is long gone, the Digital Equipment Corporation Systems Research Center in Palo Alto:

ERROR: test_ftp (test.test_urllib2net.OtherNetworkTests) (url='ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/00README-Legal-Rules-Regs')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/staging/local/python/Python-3.4.3/Lib/urllib/request.py", line 1399, in ftp_open
    fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
  File "/home/staging/local/python/Python-3.4.3/Lib/urllib/request.py", line 1445, in connect_ftp
    dirs, timeout)
  File "/home/staging/local/python/Python-3.4.3/Lib/urllib/request.py", line 2243, in __init__
    self.init()
  File "/home/staging/local/python/Python-3.4.3/Lib/urllib/request.py", line 2249, in init
    self.ftp.connect(self.host, self.port, self.timeout)
  File "/home/staging/local/python/Python-3.4.3/Lib/ftplib.py", line 153, in connect
    source_address=self.source_address)
  File "/home/staging/local/python/Python-3.4.3/Lib/socket.py", line 512, in create_connection
    raise err
  File "/home/staging/local/python/Python-3.4.3/Lib/socket.py", line 503, in create_connection
    sock.connect(sa)
TimeoutError: [Errno 110] Connection timed out


The second one is failing because "readline" (probably GNU readline) didn't behave as expected. The installed GCC is
"gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)", which came with
"CentOS release 6.2 (Final)".  This is a long-running production server.
Is that too old?


FAIL: test_init (test.test_readline.TestReadline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/staging/local/python/Python-3.4.3/Lib/test/test_readline.py", line 57, in test_init
    self.assertEqual(stdout, b'')
AssertionError: b'\x1b[?1034h' != b''

----------
components: Installation
messages: 238869
nosy: nagle
priority: normal
severity: normal
status: open
title: "make test" on clean py3 install on CentOS 6.2 - 2 tests fail
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar 22 07:06:40 2015
From: report at bugs.python.org (bintang raksaguna)
Date: Sun, 22 Mar 2015 06:06:40 +0000
Subject: [New-bugs-announce] [issue23737] web course
Message-ID: <1427004400.99.0.712280768019.issue23737@psf.upfronthosting.co.za>


New submission from bintang raksaguna:

href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat Kursus website, SEO, Desain Grafis Favorit</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat Kursus website, SEO, Desain Grafis Favorit 2015 di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus website</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus SEO</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus Desain Grafis</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">kursus SEO di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">kursus website di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Kursus Desain Grafis di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus SEO di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus website di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat Kursus Desain Grafis di jakarta</a>

----------
hgrepos: 302
messages: 238875
nosy: bintangrksgn
priority: normal
severity: normal
status: open
title: web course

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

From report at bugs.python.org  Sun Mar 22 11:31:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 10:31:01 +0000
Subject: [New-bugs-announce] [issue23738] Clarify documentation of
	positional-only default values
Message-ID: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>


New submission from Martin Panter:

This patch adds the PEP 457 positional-only slash ?/? indicator to some function signatures in the documentation. I only looked at the the os, builtin, binascii, zlib and fcntl modules, and their functions where the documentation incorrectly suggests that they accept keyword arguments. For example, I changed

eval(expression, globals=None, locals=None)

to

eval(expression, globals=None, locals=None, /)

References:

* Issue 22832: ?fcntl? module changed to look like accepting keyword arguments
* Ongoing discussion: <https://mail.python.org/pipermail/python-dev/2015-March/138847.html>

There are many more instances where square brackets are used, or the arguments are mandatory. See the PEP for examples, but I do not think it is so important to ?fix? them.

I also fixed parameter name mismatches that I discovered for a quite a few functions that do take keyword arguments.

One more thing I noticed, that I do not know how to fix, is the Argument Clinic signatures list invalid default values for zlib.compressobj(zdict=None) and os.utime(ns=None):

>>> zlib.compressobj(zdict=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' does not support the buffer interface
>>> os.utime("dummy", ns=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: utime: 'ns' must be a tuple of two ints

----------
assignee: docs at python
components: Documentation
files: pos-defaults.patch
keywords: patch
messages: 238890
nosy: docs at python, serhiy.storchaka, vadmium
priority: normal
severity: normal
status: open
title: Clarify documentation of positional-only default values
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38632/pos-defaults.patch

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

From report at bugs.python.org  Sun Mar 22 16:36:40 2015
From: report at bugs.python.org (=?utf-8?q?Saulius_=C5=BDemaitaitis?=)
Date: Sun, 22 Mar 2015 15:36:40 +0000
Subject: [New-bugs-announce] [issue23739] locale.setlocale checks locale
	name for string	incorrectly
Message-ID: <1427038600.94.0.309195930192.issue23739@psf.upfronthosting.co.za>


New submission from Saulius ?emaitaitis:

Steps to reproduce:

python2.7 -c "import locale; locale.setlocale(locale.LC_ALL, u'en_US')"

Raises: ValueError: too many values to unpack

Problem lies in locale.py file from the standard library. It checks if locale is string incorrectly:

    if locale and type(locale) is not type(""):
        # convert to string
        locale = normalize(_build_localename(locale))

I think it should instead check if locale is basestring:

    locale and not isinstance(locale, basestring):
        # <..>

If above fix looks correct I'll submit it as a patch.

----------
components: Library (Lib)
messages: 238914
nosy: Saulius ?emaitaitis
priority: normal
severity: normal
status: open
title: locale.setlocale checks locale name for string incorrectly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar 22 20:28:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 19:28:44 +0000
Subject: [New-bugs-announce] [issue23740] http.client request and send
	method have some datatype	issues
Message-ID: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>


New submission from R. David Murray:

While committing the patch for issue 23539 I decided to rewrite the 'request' docs for clarity.  I doing so I found that http.client isn't as consistent as it could be about how it handles bytes and strings.  Two points specifically:  it will only take the length of a bytes-like object (to supply a default Content-Length header) if isinstance(x, bytes) is true (that is, it doesn't take the length of eg array or memoryview objects), and (2) if an iterable is passed in, it must be an iterable of bytes-like objects.  Since it already automatically encodes string objects and text files, for consistency it should probably also encode strings if they are passed in via an iterator.

----------
keywords: easy
messages: 238928
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: http.client request and send method have some datatype issues
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 22 22:26:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 21:26:16 +0000
Subject: [New-bugs-announce] [issue23741] Small pprint refactoring
Message-ID: <1427059576.13.0.118751604266.issue23741@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This issue is not so ambitious as issue7434. Proposed match only slightly refactor current implementation, so it becomes easier extensible for standard types. No public interface provided, this task left for issue7434. No behavior changed.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: pprint_refactoring.diff
keywords: patch
messages: 238943
nosy: fdrake, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Small pprint refactoring
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38636/pprint_refactoring.diff

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

From report at bugs.python.org  Mon Mar 23 02:35:37 2015
From: report at bugs.python.org (=?utf-8?q?Manuel_V=C3=B6gele?=)
Date: Mon, 23 Mar 2015 01:35:37 +0000
Subject: [New-bugs-announce] [issue23742] expandvars removes single quotes (
	' )
Message-ID: <1427074537.6.0.869076773491.issue23742@psf.upfronthosting.co.za>


New submission from Manuel V?gele:

When executing

os.path.expandvars("%SystemDrive%\\Foo'Bar")

the function erases the ' returning

'C:\\FooBar'

using Python 3.4.3 on Windows 7

----------
components: Library (Lib)
messages: 238968
nosy: manuel_v, serhiy.storchaka
priority: normal
severity: normal
status: open
title: expandvars removes single quotes ( ' )
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 23 06:10:34 2015
From: report at bugs.python.org (matham)
Date: Mon, 23 Mar 2015 05:10:34 +0000
Subject: [New-bugs-announce] [issue23743] Python crashes upon exit if
	importing g++ compiled mod	after importing gcc compiled mod
Message-ID: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>


New submission from matham:

I have encountered a situation where python crashes when python exits if one imports a c compiled extension followed by a cpp compiled extension (but not if imported in the reverse order). This is on windows with mingw (current using mingw-get install gcc g++ msys-make) and py2.7.9.

This is basically the issue reported at https://mail.python.org/pipermail/python-win32/2013-April/012798.html a while back by someone else, but I'm filing it in bug form so it can't be ignored :D

Here's how to replicate it:

cplayground.c:

#include <Python.h>

static PyObject*
say_hello(PyObject* self, PyObject* args)
{
    Py_RETURN_NONE;
}

static PyMethodDef HelloMethods[] =
{
     {"say_hello", say_hello, METH_VARARGS, "Greet somebody."},
     {NULL, NULL, 0, NULL}
};

PyMODINIT_FUNC
initcplayground(void)
{
     (void) Py_InitModule("cplayground", HelloMethods);
}


cplayground.cpp:

#include <Python.h>

static PyObject*
say_hello(PyObject* self, PyObject* args)
{
    Py_RETURN_NONE;
}

static PyMethodDef HelloMethods[] =
{
     {"say_hello", say_hello, METH_VARARGS, "Greet somebody."},
     {NULL, NULL, 0, NULL}
};

PyMODINIT_FUNC
initcppplayground(void)
{
     (void) Py_InitModule("cppplayground", HelloMethods);
}


setup.py:

from distutils.core import setup
from distutils.extension import Extension
import Cython.Compiler.Options
from Cython.Distutils import build_ext
from os.path import join, sep, dirname, abspath

def get_extensions_from_sources():
    ext_modules = []
    ext_modules.append(Extension('src.cplayground', sources=['src/cplayground.c']))
    ext_modules.append(Extension('src.cppplayground', sources=['src/cplayground.cpp']))
    return ext_modules

setup(
    name='Playground',
    version='.1',
    author='Matthew Einhorn',
    ext_modules=get_extensions_from_sources(),
    cmdclass={'build_ext': build_ext},
    packages=['src']
      )


Here's a demonstration of the issue:

G:\Python\libs\Playground\src>python
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cplayground
>>> import cppplayground
>>> exit()

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

G:\Python\libs\Playground\src>python
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppplayground
>>> import cplayground
>>> exit()

Here's my config:

G:\Python\libs\Playground\src>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=g:/python/env/test/py279_x86/mingw/bin/../libexec/gcc/mingw3
2/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

G:\Python\libs\Playground\src>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=g:/python/env/test/py279_x86/mingw/bin/../libexec/gcc/mingw3
2/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

----------
components: Extension Modules, Windows
messages: 238981
nosy: matham, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 23 07:05:12 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 23 Mar 2015 06:05:12 +0000
Subject: [New-bugs-announce] [issue23744] Speed-up deque.__bool__
Message-ID: <1427090712.12.0.119881784491.issue23744@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The __bool__ method is a little faster than __len__.
Timings attached.

----------
assignee: rhettinger
components: Library (Lib)
files: deque_bool1.diff
keywords: patch
messages: 238983
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Speed-up deque.__bool__
versions: Python 3.5
Added file: http://bugs.python.org/file38644/deque_bool1.diff

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

From report at bugs.python.org  Mon Mar 23 08:43:43 2015
From: report at bugs.python.org (Elmer)
Date: Mon, 23 Mar 2015 07:43:43 +0000
Subject: [New-bugs-announce] [issue23745] Exception when parsing an email
	using	email.parser.BytesParser
Message-ID: <1427096623.21.0.20064628085.issue23745@psf.upfronthosting.co.za>


New submission from Elmer:

I am working with a large dataset of emails and loading one of them resulted in an exception: "TypeError: unorderable types: ValueTerminal() < CFWSList()"

I have attached the (anonymised and minimised) email source of the email that triggered the exception.

$ python
Python 3.4.2 (default, Nov 12 2014, 18:23:59) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> from email import parser, policy
>>> 
>>> f = open("testmail.eml",'rb')
>>> src = f.read()
>>> f.close()
>>> 
>>> msg = email.parser.BytesParser(_class=email.message.EmailMessage, policy=email.policy.default).parsebytes(src)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/parser.py", line 124, in parsebytes
    return self.parser.parsestr(text, headersonly)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/parser.py", line 68, in parsestr
    return self.parse(StringIO(text), headersonly=headersonly)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/parser.py", line 57, in parse
    feedparser.feed(data)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/feedparser.py", line 178, in feed
    self._call_parse()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/feedparser.py", line 182, in _call_parse
    self._parse()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/feedparser.py", line 384, in _parsegen
    for retval in self._parsegen():
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/feedparser.py", line 255, in _parsegen
    if self._cur.get_content_type() == 'message/delivery-status':
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/message.py", line 579, in get_content_type
    value = self.get('content-type', missing)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/message.py", line 472, in get
    return self.policy.header_fetch_parse(k, v)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/policy.py", line 145, in header_fetch_parse
    return self.header_factory(name, ''.join(value.splitlines()))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/headerregistry.py", line 583, in __call__
    return self[name](name, value)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/headerregistry.py", line 194, in __new__
    cls.parse(value, kwds)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/headerregistry.py", line 441, in parse
    kwds['decoded'] = str(parse_tree)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/_header_value_parser.py", line 195, in __str__
    return ''.join(str(x) for x in self)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/_header_value_parser.py", line 195, in <genexpr>
    return ''.join(str(x) for x in self)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/_header_value_parser.py", line 1136, in __str__
    for name, value in self.params:
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/_header_value_parser.py", line 1101, in params
    parts = sorted(parts)
TypeError: unorderable types: ValueTerminal() < CFWSList()

----------
components: email
files: testmail.eml
messages: 238987
nosy: Elmer, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Exception when parsing an email using email.parser.BytesParser
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38647/testmail.eml

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

From report at bugs.python.org  Mon Mar 23 10:13:02 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:13:02 +0000
Subject: [New-bugs-announce] [issue23746] sysconfg.is_python_build() is buggy
Message-ID: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

On Python 3.5.0a1+ built from source,

>>> import sysconfig
>>> sysconfig.is_python_build()
False
>>> sysconfig.is_python_build(True)
False
>>> sysconfig._PROJECT_BASE
'/opt/bin'
>>> import sys
>>> sys._home
>>>

The problem is, when sys._home is None, this function uses _is_python_source_dir(_PROJECT_BASE) . In this case the _PROJECT_BASE is clearly passed wrongly as '/opt/bin'. That is the INSTALL_PREFIX, not _PROJECT_BASE .

Let us do a small hack and set _PROJECT_BASE to the folder where I build this Python version.

# Of course this can't be reproduced but you get the idea.

>>> sysconfig._PROJECT_BASE='/home/anand/code/cpython/'
>>> sysconfig.is_python_build()
True

The documentation says,

"

sysconfig.is_python_build()

    Return True if the current Python installation was built from source.

"

which is clearly in conflict with what it is doing. 

>From a quick look at sysconfig.py it looks like it is calculating _PROJECT_BASE wrongly. 

I can give a patch for this, but first I am more interested in finding out what this function is supposed to do - why have this function if you are not able to get the details of the build environment from the built interpreter ? Clearly it is not doing that here.



The conclusions are part of the attached file in comments.

----------
components: Library (Lib)
messages: 238993
nosy: pythonhacker
priority: normal
severity: normal
status: open
title: sysconfg.is_python_build() is buggy
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 23 10:30:16 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:30:16 +0000
Subject: [New-bugs-announce] [issue23747] platform module exposes win32_ver
	function on posix	systems
Message-ID: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

>>> import platform
>>> platform.system()
'Linux'
>>> platform.win32_ver()
('', '', '', '')

Why is this function even exposed on Linux ? It should be conditionally exposed only on win32 platforms. 

Funny that this is coming from the module named "platform" itself :)

----------
components: Library (Lib)
messages: 238995
nosy: pythonhacker
priority: normal
severity: normal
status: open
title: platform module exposes win32_ver function on posix systems

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

From report at bugs.python.org  Mon Mar 23 11:37:50 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 10:37:50 +0000
Subject: [New-bugs-announce] [issue23748] platform._uname_cache is writeable
Message-ID: <1427107070.63.0.510567117775.issue23748@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

>> import platform
>>> print 'Actual =>',platform.uname()
Actual => ('Linux', 'toshiba-laptop', '3.13.0-24-generic', '#47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014', 'x86_64', 'x86_64')
>>> import hack_uname
# Someone imports my module unaware of the hack (see attached file)
>>> platform.uname()
('Limux', 'hacker-laptop', '11.15.0-28000-absurd', '#10000 - FunkyDistro SMMP Fry Feb 30 2015 23:59:00 UTC 2015', 'x866_64', 'x866_64')

Fix - Make the global _uname_cache inaccessible via the module and hence unwriteable. I can provide a patch - it is kind of easy fix.

I think this might also be a security issue since if someone is writing a significant piece of code based on the platform it can screw up the system - or his web application if a piece of code like this is introduced in a module via his chain of imports by a malicious hacker.

----------
components: Library (Lib)
files: hack_uname.py
messages: 239005
nosy: pythonhacker
priority: normal
severity: normal
status: open
title: platform._uname_cache is writeable
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38652/hack_uname.py

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

From report at bugs.python.org  Mon Mar 23 14:59:59 2015
From: report at bugs.python.org (Giovanni Cannata)
Date: Mon, 23 Mar 2015 13:59:59 +0000
Subject: [New-bugs-announce] [issue23749] asyncio missing wrap_socket
Message-ID: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>


New submission from Giovanni Cannata:

It's not possible to wrap a socket in tls. The StreamWriter object should have an option to start a tls negotiation using the SSLContext of the server.

This is needed for protocols the have a "start_tls" feature, for example the ldap protocol.

In a non async program it's very easy: 
   wrapped_socket = ssl_context.wrap_socket(connection.socket, server_side=True, do_handshake_on_connect=True)

there should be something similar in the StreamWriter interface:
   yield from writer.wrap_socket()

Bye,
Giovanni

----------
components: asyncio
messages: 239021
nosy: gc, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio missing wrap_socket
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 23 15:28:11 2015
From: report at bugs.python.org (Andreas Sommer)
Date: Mon, 23 Mar 2015 14:28:11 +0000
Subject: [New-bugs-announce] [issue23750] Clarify difference between
	os.system/subprocess.call in	section "Replacing os.system()"
Message-ID: <1427120891.65.0.0570880238086.issue23750@psf.upfronthosting.co.za>


New submission from Andreas Sommer:

Reading over the section "Replacing os.system()" (https://docs.python.org/2/library/subprocess.html#replacing-os-system), one might assume that the return value of os.system and subprocess.call are equivalent.

    status = os.system("mycmd" + " myarg")
    # becomes
    status = subprocess.call("mycmd" + " myarg", shell=True)

However, they are not. Example:

    import sys
    import os
    import subprocess

    print subprocess.call("false")
    print os.system("false")

gives 1 and 256, respectively. Maybe this could be rephrased for clarity, or a hint added.

----------
assignee: docs at python
components: Documentation
messages: 239028
nosy: Andreas Sommer, docs at python
priority: normal
severity: normal
status: open
title: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"
type: enhancement

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

From report at bugs.python.org  Mon Mar 23 16:04:15 2015
From: report at bugs.python.org (Mohith)
Date: Mon, 23 Mar 2015 15:04:15 +0000
Subject: [New-bugs-announce] [issue23751] Allow reverse lookup
	(value-to-member) for Enum	sublcasses decorated with @enum.unique
Message-ID: <1427123055.25.0.902352877052.issue23751@psf.upfronthosting.co.za>


New submission from Mohith:

Addendum to issue 18042.

I've had a use case where I wanted to allow reverse lookups (i.e. value-to-member lookup) for my enum.Enum that was decorated via @enum.unique. In such a case, I would add my own class method that performs the logic. E.g. an unoptimized copy-and-paste-able example for use via python3 interactive shell:


import datetime
import enum

@enum.unique
class DayOfWeek(enum.Enum):
  SUNDAY = 0  # Sunday is '0' according to strftime('%w')
  MONDAY = 1
  TUESDAY = 2
  WEDNESDAY = 3
  THURSDAY = 4
  FRIDAY = 5
  SATURDAY = 6  # Saturday is '6' according to strftime('%w')
  @classmethod
  def reverse_lookup(cls, value):
    for _, member in cls.__members__.items():
      if member.value == value:
        return member
    raise LookupError

today_value = int(datetime.date.today().strftime('%w'))
today = DayOfWeek.reverse_lookup(today_value)
print('Today is', today.name.title())


---

(Aside: it seems like an optimized version that uses a cached lookup dictionary is inconvenient to implement in that it involves storing the cache in a global variable or a closure or a descriptor attribute or etc. [unless there's a simple recommended approach of which I am just unaware].)

I think use cases for reverse lookup would not be uncommon. For example, an IntEnum subclass decorated via @enum.unique is a great candidate (as is any simple hashable/equatable value type). I am unsure of the proper interface, but I am thinking that passing a boolean argument to enum.unique should enable the usage of a special __lookup__ metaclass property for optimized reverse lookups. I am thinking a possible (untested) enhancement to enum.unique along the lines of:


class EnumMeta(type):

  ...

  _reverse_lookup_ = None

  @property
  def __lookup__(cls):
    if cls._reverse_lookup_ is None:
      raise AttributeError('Reverse lookup unsupported.')
    return MappingProxyType(cls._reverse_lookup_)


def unique(enumeration, reverse_lookup=False):
    ...
    reverse_lookup = {} if reverse_lookup else None
    for name, member in enumeration.__members__.items():
      ...
      if reverse_lookup is not None:
        reverse_lookup[member.value] = member
    ...
    if reverse_lookup is not None:
      enumeration._reverse_lookup_ = reverse_lookup
    return enumeration

----------
components: Library (Lib)
messages: 239038
nosy: barry, eli.bendersky, ethan.furman, mmuddasani
priority: normal
severity: normal
status: open
title: Allow reverse lookup (value-to-member) for Enum sublcasses decorated with @enum.unique
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Mar 23 17:51:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 16:51:05 +0000
Subject: [New-bugs-announce] [issue23752] Cleanup io.FileIO
Message-ID: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While reviewing a Python implementation of io.FileIO (_pyio.FileIO) in the issue #21859, many issues were found in the C implementation. I open an issue to fix them.

We may fix them before or after the Python implementation is merged.

----------
components: Library (Lib)
messages: 239045
nosy: haypo
priority: normal
severity: normal
status: open
title: Cleanup io.FileIO
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 23 18:16:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 17:16:39 +0000
Subject: [New-bugs-announce] [issue23753] Drop HAVE_FSTAT: require fstat()
	to compile/use Python
Message-ID: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Topic previously discussed at:
https://mail.python.org/pipermail/python-dev/2013-May/126285.html

Related issue:
http://bugs.python.org/issue12082

Antoine Pitrou wrote in the issue:
"I would personally like to remove HAVE_FSTAT and make Python unconditionally use fstat(). It will make the code quite simpler in some places."

I agree. I'm quite sure that Python doesn't work on such platform, and it would require much more changes than just making fstat optional.

So I'm in favor of dropping the check on fstat() and expect it to be always available.

Examples of Python modules of the standard library using os.fstat:

- fileinput
- genericpath
- netrc
- os which contains "set.add(stat) # fstat always works"
- _pyio (the call is optional, it catchs AttributeError)
- shutil
- socket
- tarfile
- asyncio
- http.client (optional, catch AttributeError)
- http.server
- logging
- io
- etc.

----------
messages: 239047
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Drop HAVE_FSTAT: require fstat() to compile/use Python
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 23 22:16:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:16:11 +0000
Subject: [New-bugs-announce] [issue23754] Add a new os.read_into() function
	to avoid memory copies
Message-ID: <1427145371.9.0.485193711036.issue23754@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Sockets have a recv_into() method, io.IOBase has a readinto() method, but there is no os.read_into() function. It would avoid memory copies. It would benefit to the Python implementation FileIO (readall() and readinto() methods), see the issue #21859.

----------
components: Library (Lib)
messages: 239069
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a new os.read_into() function to avoid memory copies
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 24 01:55:06 2015
From: report at bugs.python.org (Stephen Gallagher)
Date: Tue, 24 Mar 2015 00:55:06 +0000
Subject: [New-bugs-announce] [issue23755] tempfile.NamedTemporaryFile should
	be able to toggle	"delete"
Message-ID: <1427158506.1.0.856842662258.issue23755@psf.upfronthosting.co.za>


New submission from Stephen Gallagher:

Currently, NamedTemporaryFile takes an attribute at initialization that allows it to remove the temporary file on going out of scope or else leave it around. However, it's not possible to change this after the fact.

It would be a much more sensible pattern to be able to operate with auto-deletion enabled while constructing the file and then to be able to toggle this option off once the file is completed.

For example, the use-case I have in mind is that I am creating a file that, once complete, will go into a well-known location. Because of known attacks, the only secure way to create this file is to generate it in a temporary location and then atomically move (os.rename()) it into its final location. This avoids time-of-check-time-of-use risks as well as avoiding overwriting the old file if something goes wrong.

It would be handy if tempfile could be extended to support this operation.

Additionally, I attempted to solve this by monkey-patching tempfile and overriding the __del__ function on the _TemporaryFileWrapper object to be a no-op. This works in python 2.7.9, but seems to be ignored on python 3.4.2.

Example code:

{{{
import tempfile
import os

f = tempfile.NamedTemporaryFile()
os.unlink(f.name)
f.unlink = lambda x: None
}}}

If you run that under python2, it will succeed. On Python 3, it will noisily report:
Exception ignored in: <bound method _TemporaryFileCloser.__del__ of <tempfile._TemporaryFileCloser object at 0x7f7a24548c88>>
Traceback (most recent call last):
  File "/usr/lib64/python3.4/tempfile.py", line 366, in __del__
  File "/usr/lib64/python3.4/tempfile.py", line 362, in close
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmpqs5k6w7q'

----------
components: Library (Lib)
messages: 239082
nosy: Stephen Gallagher
priority: normal
severity: normal
status: open
title: tempfile.NamedTemporaryFile should be able to toggle "delete"
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Mar 24 09:25:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 08:25:17 +0000
Subject: [New-bugs-announce] [issue23756] Tighten definition of bytes-like
	objects
Message-ID: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>


New submission from Martin Panter:

There are moves at documenting and implementing support for ?bytes-like? objects in more APIs, such as the ?io? module (Issue 20699), http.client (Issue 23740). The glossary definition is currently ?An object that supports the Buffer Protocol, like bytes, bytearray or memoryview.? This was originally added for Issue 16518. However after reading Issue 23688, I realized that it should probably not mean absolutely _any_ object supporting the buffer protocol. For instance:

>>> reverse_view = memoryview(b"123")[::-1]
>>> stdout.buffer.write(reverse_view)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: memoryview: underlying buffer is not C-contiguous

I think the definition should at least be tightened to only objects with a contiguous buffer, and ?contiguous? should be defined (probably in the linked C API page or the memoryview.contiguous flag definition, not the glossary). So far, my understanding is these are contiguous:

* A zero-dimensional object, such as a ctypes object
* An multi-dimensional array with items stored contiguously in order of increasing indexes. I.e. a_2,2 is stored somewhere after both a_1,2 and a_2,1, and all the strides are positive.

and these are not contiguous:

* memoryview(contiguous)[::2], because there are memory gaps between the items
* memoryview(contiguous)[::-1], despite there being no gaps nor overlapping items
* Views that set the ?suboffsets? field (i.e. include pointers to further memory)
* Views where different array items overlap each other (e.g. 0 in view.strides)

Perhaps the bytes-like definition should tightened further, to match the above error message, to only ?C-contiguous? buffers. I understand that C-contiguous means the strides tuple has to be in non-strict decreasing order, e.g. for 2 ? 1 ? 3 arrays, strides == (3, 3, 1) is C-contiguous, but strides == (1, 3, 3) is not. This also needs documenting.

I?m not so sure about these, but the definition could be tightened even further:

* Require memoryview(x).cast("B") to be supported. Otherwise, native Python code would have to use workarounds like struct.pack_into() to write to the ?bytes-like? object. See Issue 15944.
* Require len(view) == view.nbytes. This would help in some cases avoid the bug that I have seen of code naively calling len(data), but the downside is ctypes objects would no longer be considered bytes-like objects.

----------
assignee: docs at python
components: Documentation
messages: 239097
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Tighten definition of bytes-like objects

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

From report at bugs.python.org  Tue Mar 24 09:42:29 2015
From: report at bugs.python.org (David MacIver)
Date: Tue, 24 Mar 2015 08:42:29 +0000
Subject: [New-bugs-announce] [issue23757] tuple function gives wrong answer
	when called on list	subclass with custom __iter__
Message-ID: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za>


New submission from David MacIver:

Converting a list to a tuple appears to have an optimisation that is wrong in the presence of subclassing to override __iter__. It ignores the user defined iter and uses the normal list one. I've attached a file with a test case to demonstrate this.

I've verified this on both python 2.7 and python 3.4. It's presumably also the case on everything in between.

This was found because it caused a bug with a type that pytz uses, which lazily populates the list on iteration: https://bugs.launchpad.net/pytz/+bug/1435617

----------
components: Library (Lib)
files: listwithiter.py
messages: 239098
nosy: David MacIver
priority: normal
severity: normal
status: open
title: tuple function gives wrong answer when called on list subclass with custom __iter__
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38663/listwithiter.py

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

From report at bugs.python.org  Tue Mar 24 10:44:55 2015
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Tue, 24 Mar 2015 09:44:55 +0000
Subject: [New-bugs-announce] [issue23758] Improve documenation about
	num_params in sqlite3	create_function and create_aggregate
Message-ID: <1427190295.06.0.0583773654336.issue23758@psf.upfronthosting.co.za>


New submission from C?dric Krier:

num_params must have the value -1 for any number of arguments see https://www.sqlite.org/c3ref/create_function.html

----------
assignee: docs at python
components: Documentation
files: sqlite3_doc.patch
keywords: patch
messages: 239104
nosy: ced, docs at python
priority: normal
severity: normal
status: open
title: Improve documenation about num_params in sqlite3 create_function and create_aggregate
type: enhancement
Added file: http://bugs.python.org/file38664/sqlite3_doc.patch

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

From report at bugs.python.org  Tue Mar 24 11:45:14 2015
From: report at bugs.python.org (chrysn)
Date: Tue, 24 Mar 2015 10:45:14 +0000
Subject: [New-bugs-announce] [issue23759] urllib.parse: make coap:// known
Message-ID: <1427193914.26.0.435634285689.issue23759@psf.upfronthosting.co.za>


New submission from chrysn:

The CoAP protocol (RFC 7252) registers the new URI schemes coap and coaps. They adhere to the generic RFC3986 rules, and use netloc and relative URIs.

Therefore, please add the 'coap' and 'coaps' schemes to the uses_relative and uses_netloc lists in urllib.parse.

I'm not sure about uses_params; the CoAP protocol in itself does not do anything special with the ';' character in URIs, so probably it should not be included there. (But then again, neither does RFC2616 mention ";" in the context of addresses, and it is included in uses_params).

----------
components: Library (Lib)
messages: 239106
nosy: chrysn
priority: normal
severity: normal
status: open
title: urllib.parse: make coap:// known
type: enhancement

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

From report at bugs.python.org  Tue Mar 24 11:47:56 2015
From: report at bugs.python.org (Victor Korolkevich)
Date: Tue, 24 Mar 2015 10:47:56 +0000
Subject: [New-bugs-announce] [issue23760] Tkinter in Python 3.4 on Windows
	don't post internal	clipboard data to the Windows clipboard on exit
Message-ID: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za>


New submission from Victor Korolkevich:

>From http://stackoverflow.com/questions/26321333/tkinter-in-python-3-4-on-windows-dont-post-internal-clipboard-data-to-the-windo

I use the following code to place result in clipboard.

from tkinter import Tk
r = Tk()
r.withdraw()
r.clipboard_clear()
r.clipboard_append("Result")

It works fine on Python version 3.3.5 and earlier. But in Python 3.4 it was receive empty clipboard. If I prevent the script from the immediate exit, adding input() after clipboard_append(), I see that clipboard contains the correct "Result".

If I run script, switch to any other window and press Ctrl+V, I receive "Result" and "Result" remains in clipboard after script exits.

I think in tcl/tk 8.6 clipboard_clear() affect system clipboard, but clipboard_append affect only internal tcl/tk clipboard that transfered to system clipboard only by OS request. Looks like it was done in Linux, that don't have system clipboard.

----------
components: Tkinter
messages: 239107
nosy: Victor Korolkevich
priority: normal
severity: normal
status: open
title: Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 24 14:21:41 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 24 Mar 2015 13:21:41 +0000
Subject: [New-bugs-announce] [issue23761] test_socket fails on Mac OSX 10.9.5
Message-ID: <1427203301.62.0.862934673257.issue23761@psf.upfronthosting.co.za>


New submission from Carol Willing:

On Mac OSX 10.9.5, test_socket fails when regression tests are run.


Specifically, the following fails:

FAIL: test_host_resolution (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/carol/Development/cpython/Lib/test/test_socket.py", line 788, in test_host_resolution
    self.assertRaises(OSError, socket.gethostbyname, addr)
AssertionError: OSError not raised by gethostbyname


The output from

    ./python.exe -m test -v test_socket > output-test-socket.txt

is attached.

----------
components: Tests
files: output-test-socket.txt
messages: 239120
nosy: willingc
priority: normal
severity: normal
status: open
title: test_socket fails on Mac OSX 10.9.5
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file38665/output-test-socket.txt

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

From report at bugs.python.org  Tue Mar 24 15:28:05 2015
From: report at bugs.python.org (=?utf-8?q?Jo=C3=ABl_Schaerer?=)
Date: Tue, 24 Mar 2015 14:28:05 +0000
Subject: [New-bugs-announce] [issue23762] python.org page on new-style
	classes should be updated
Message-ID: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>


New submission from Jo?l Schaerer:

This page (found it via a search engine):

https://www.python.org/doc/newstyle/

is supposed to give the status of "New-style classes". However this information is no longer relevant for Python 3, and my needlessly scare newcomers. I believe it should be either deleted or updated to mention that python3 users don't need to care about this anymore.

----------
assignee: docs at python
components: Documentation
messages: 239127
nosy: docs at python, joelthelion
priority: normal
severity: normal
status: open
title: python.org page on new-style classes should be updated
type: enhancement

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

From report at bugs.python.org  Tue Mar 24 15:41:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 14:41:37 +0000
Subject: [New-bugs-announce] [issue23763] Chain exceptions in C
Message-ID: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3, it becomes possible to chain two exceptions. It's one of the killer feature of Python 3, it helps debugging.


In Python, exceptions are chained by default. Example:

    try:
        raise TypeError("old message")
    except TypeError:
        raise ValueError("new message")

Output:

    Traceback (most recent call last):
      File "x.py", line 2, in <module>
        raise TypeError("old message")
    TypeError: old message

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "x.py", line 4, in <module>
        raise ValueError("new message")
    ValueError: new message

In C, using the public PyErr_SetNone(), PyErr_Format(), PyErr_SetString(), ... functions, exceptions are *not* chained by default.

You have to call explicitly the new private _PyErr_ChainExceptions() function introduced in Python 3.4. It is not trivial to use it: you have to call PyErr_Fetch() and check if an exception was already raised.


In Python, the following examples are bad practice because they may hide important exceptions like MemoryError or KeyboardInterrupt:

    try:
        ....
    except:
        pass

or

    try:
        ....
    except:
        raise ValueError(...)

In C extensions, it's common to write such code, few functions check which exception was raised.


Last months, I enhanced Python to detect exceptions ignored by mistake: I added assert(!PyErr_Occurred()) in many functions which can clear the current exception (ex: call PyErr_Clear()) or raise a new exception (ex: call PyErr_SetString(...)). The last step is the issue #23571 which now implements in release mode.


For the next step, I propose to explicitly clear the current exception before raising a new exception.


I don't know yet if it would be a good idea to modify PyErr_*() functions to automatically chain exceptions.

----------
messages: 239130
nosy: haypo
priority: normal
severity: normal
status: open
title: Chain exceptions in C

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

From report at bugs.python.org  Tue Mar 24 19:14:33 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Tue, 24 Mar 2015 18:14:33 +0000
Subject: [New-bugs-announce] [issue23764] functools.wraps should be able to
	change function	argspec as well
Message-ID: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>


New submission from productivememberofsociety666:

functools.wraps currently only changes the wrapped function's "superficial" attributes such as docstring or annotations.

But it would be useful to be able to change the function's actual argspec as well so it matches up with the changed annotations (e.g. to get proper error messages when the wrapped and wrapper functions' argspecs don't match up).

To avoid breaking existing code, this could be achieved by adding another argument change_argspec (defaulting to False) to functools.wraps. Of course, the way functools.wraps is implemented now as well as its current documentation would have to be thrown out of the window in order for this to work (at least for the case of change_argspec==True).


There is an existing 3rd party package ( https://pypi.python.org/pypi/decorator ) which has a decorator called "decorator" that does kind of what I'd want functools.wraps to do, but the details of how it is called are different and either way it's embarassing that you have to fall back on a 3rd party library to get functionality that is present but incomplete in Python's standard library.

----------
components: Library (Lib)
messages: 239165
nosy: productivememberofsociety666
priority: normal
severity: normal
status: open
title: functools.wraps should be able to change function argspec as well
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Mar 24 19:39:05 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 24 Mar 2015 18:39:05 +0000
Subject: [New-bugs-announce] [issue23765] Remove IsBadStringPtr calls in
	ctypes
Message-ID: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>


New submission from Steve Dower:

Modules/_ctypes/cfield.c has this horror in it (twice):

    /* XXX What about invalid pointers ??? */
    if (*(void **)ptr) {
#if defined(MS_WIN32) && !defined(_WIN32_WCE)
        if (IsBadStringPtrA(*(char **)ptr, -1)) {
            PyErr_Format(PyExc_ValueError,
                         "invalid string pointer %p",
                         *(char **)ptr);
            return NULL;
        }
#endif
        return PyBytes_FromStringAndSize(*(char **)ptr,
                                         strlen(*(char **)ptr));

IsBadStringPtr should generally not be used, and the -1 parameter makes it even worse. See http://blogs.msdn.com/b/oldnewthing/archive/2006/09/27/773741.aspx for details, but the main reason is that if it is actually a bad pointer, we've just deferred the crash from the obvious location to somewhere that should "never" crash.

The strlen() call has exactly the same behaviour as IsBadStringPtrA except the crash will occur here.

A better alternative would be to use the safe strlen function to limit the maximum length of strings, but since we likely can't agree on a suitable maximum we should just stop trying to handle this case at all.

----------
assignee: steve.dower
components: Windows, ctypes
messages: 239167
nosy: steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove IsBadStringPtr calls in ctypes
type: enhancement

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

From report at bugs.python.org  Tue Mar 24 20:43:43 2015
From: report at bugs.python.org (Pavel Strashkin)
Date: Tue, 24 Mar 2015 19:43:43 +0000
Subject: [New-bugs-announce] [issue23766] json.dumps: solidus ("/") should
	be escaped
Message-ID: <1427226223.82.0.96478521351.issue23766@psf.upfronthosting.co.za>


New submission from Pavel Strashkin:

According to http://www.json.org/ and https://tools.ietf.org/html/rfc7159#section-7, the solidus ("/") should be escaped ("\/") and currently it's not.

----------
messages: 239170
nosy: xaka
priority: normal
severity: normal
status: open
title: json.dumps: solidus ("/") should be escaped
type: behavior

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

From report at bugs.python.org  Tue Mar 24 21:04:00 2015
From: report at bugs.python.org (Samuel Cabrero)
Date: Tue, 24 Mar 2015 20:04:00 +0000
Subject: [New-bugs-announce] [issue23767] Library and include paths not
	added when cross compiling	on localized sytem
Message-ID: <1427227440.25.0.884604694697.issue23767@psf.upfronthosting.co.za>


New submission from Samuel Cabrero:

When cross compiling on a localized system (eg. LANG=es_ES.utf8) the add_gcc_paths is called. This function parses the output of "gcc -v -E" and fails because the output is localized which
results in no paths added and detect_modules not able to find
any system library (eg. libz, libssl, etc.)

The attached patch forces the use of the default locale in the function
add_gcc_paths.

----------
components: Cross-Build
files: 0001-Override-system-locale-and-set-to-default-when-addin.patch
keywords: patch
messages: 239173
nosy: kernevil
priority: normal
severity: normal
status: open
title: Library and include paths not added when cross compiling on localized sytem
versions: Python 3.4
Added file: http://bugs.python.org/file38671/0001-Override-system-locale-and-set-to-default-when-addin.patch

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

From report at bugs.python.org  Tue Mar 24 21:20:09 2015
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 24 Mar 2015 20:20:09 +0000
Subject: [New-bugs-announce] [issue23768] assert on getting the
	representation of a thread in	atexit function
Message-ID: <1427228409.82.0.424611775358.issue23768@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The following 'thread_repr.py' script:
--------------------------------------

import threading, atexit

def foo():
    print(threading.currentThread())

atexit.register(foo)



gives the following output:
---------------------------

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "thread_repr.py", line 4, in foo
    print(threading.currentThread())
  File "/usr/local/lib/python3.5/threading.py", line 826, in __repr__
    self.is_alive() # easy way to get ._is_stopped set when appropriate
  File "/usr/local/lib/python3.5/threading.py", line 1122, in is_alive
    self._wait_for_tstate_lock(False)
  File "/usr/local/lib/python3.5/threading.py", line 1078, in _wait_for_tstate_lock
    assert self._is_stopped
AssertionError

----------
components: Library (Lib)
messages: 239175
nosy: xdegaye
priority: normal
severity: normal
status: open
title: assert on getting the representation of a thread in atexit function
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 24 23:32:14 2015
From: report at bugs.python.org (Robert Kuska)
Date: Tue, 24 Mar 2015 22:32:14 +0000
Subject: [New-bugs-announce] [issue23769] valgrind reports leaks for
	test_zipimport
Message-ID: <1427236334.27.0.200472101868.issue23769@psf.upfronthosting.co.za>


New submission from Robert Kuska:

Leaks happen only when both testDoctestFile and testDoctestSuite are run.
Run with Python 3.4.2 and 3.4.1 with same result.

I have extracted those two tests into `leak.py` (attached).

> $ valgrind --suppressions=/../cpython/Misc/valgrind-python.supp python3 leak.py                                                                                            
==17896== Memcheck, a memory error detector
==17896== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17896== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==17896== Command: python3 leak.py
==17896== 
==17896== 
==17896== HEAP SUMMARY:
==17896==     in use at exit: 1,599,328 bytes in 11,595 blocks
==17896==   total heap usage: 283,757 allocs, 272,162 frees, 37,891,147 bytes allocated
==17896== 
==17896== LEAK SUMMARY:
==17896==    definitely lost: 30 bytes in 1 blocks
==17896==    indirectly lost: 0 bytes in 0 blocks
==17896==      possibly lost: 597,418 bytes in 2,319 blocks
==17896==    still reachable: 1,001,880 bytes in 9,275 blocks
==17896==         suppressed: 0 bytes in 0 blocks
==17896== Rerun with --leak-check=full to see details of leaked memory
==17896== 
==17896== For counts of detected and suppressed errors, rerun with: -v
==17896== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Note that when I remove support.modules_cleanup(*modules_before) from leak.py valgrind reports no leaks (in original test_zipimport those are run in setUp and tearDown).

Output of  
valgrind --suppressions=/home/rkuska/upstream/cpython/Misc/valgrind-python.supp --leak-check=yes -v python3 leak.py
attached as `report`.

----------
components: Tests
files: leak.py
messages: 239193
nosy: rkuska
priority: normal
severity: normal
status: open
title: valgrind reports leaks for test_zipimport
versions: Python 3.4
Added file: http://bugs.python.org/file38672/leak.py

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

From report at bugs.python.org  Wed Mar 25 01:29:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:29:20 +0000
Subject: [New-bugs-announce] [issue23770] Rework of exceptions are handled
	in the parser module	(in validate_repeating_list())
Message-ID: <1427243360.96.0.274103044553.issue23770@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch avoids calling validate_numnodes() with an exception set in the parser module.

I found this issue while working on the issue #23763 "Chain exceptions in C".

----------
files: validate_repeating_list.patch
keywords: patch
messages: 239199
nosy: haypo
priority: normal
severity: normal
status: open
title: Rework of exceptions are handled in the parser module (in validate_repeating_list())
versions: Python 3.5
Added file: http://bugs.python.org/file38676/validate_repeating_list.patch

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

From report at bugs.python.org  Wed Mar 25 03:42:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 02:42:02 +0000
Subject: [New-bugs-announce] [issue23771] Timeouts on "x86 Ubuntu Shared
	3.x" buildbot
Message-ID: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>


New submission from STINNER Victor:

First timeout:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11358

This build was only triggered by one changeset 0b99d7043a99: "Issue #23694: Enhance _Py_open(), it now raises exceptions".

 * _Py_open() now raises exceptions on error. If open() fails, it raises an OSError with the filename.
 * _Py_open() now releases the GIL while calling open()
 * Add _Py_open_noraise() when _Py_open() cannot be used because the GIL is not held

Example of subprocess timeout:
---
Timeout (1:00:00)!
Thread 0x55aaedc0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1502 in _try_wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1552 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_subprocess.py", line 58 in tearDown
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 580 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 625 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 176 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1773 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1807 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_subprocess.py", line 2532 in test_main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 967 in runtest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 763 in main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/__main__.py", line 3 in <module>
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 170 in _run_module_as_main
make: *** [buildbottest] Error 1
---

Example of multiprocessing timeout:
---
[240/393] test_multiprocessing_spawn
Timeout (1:00:00)!
Thread 0x68fddb40 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 955 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 834 in f
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 871 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x58a5ab40 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 955 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 834 in f
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 871 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 891 in _bootstrap

(...)

Thread 0x55aaedc0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 943 in acquire
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 933 in test_notify_all
  ...
---

----------
messages: 239214
nosy: haypo
priority: normal
severity: normal
status: open
title: Timeouts on "x86 Ubuntu Shared 3.x" buildbot
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 25 03:51:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 02:51:22 +0000
Subject: [New-bugs-announce] [issue23772] pymonotonic() gone backward on
	"AMD64 Debian root 3.x"	buildbot
Message-ID: <1427251882.59.0.116696625299.issue23772@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I would be interested to know the Linux version of this buildbot slave.

Maybe the slave is running in a VM and it's a virtualization issue? If it's the case, should Python fix the bug? Or should we just remove the assertion?

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/1943/steps/test/logs/stdio
---
python: Python/pytime.c:221: pymonotonic: Assertion `last.tv_usec == -1 || tp->tv_sec > last.tv_sec || (tp->tv_sec == last.tv_sec && tp->tv_usec >= last.tv_usec)' failed.
Fatal Python error: Aborted

Thread 0x00002b9135bc4700 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 364 in sleeper_gen
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 390 in make_nested
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 395 in run_thread
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 871 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 891 in _bootstrap

Current thread 0x00002b91355c1700 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 364 in sleeper_gen
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 390 in make_nested
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 395 in run_thread
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 871 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x00002b9127825b20 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 407 in test_trashcan_threads
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 577 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 625 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/runner.py", line 176 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1772 in _run_suite
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1806 in run_unittest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 1000 in test_main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 967 in runtest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 763 in main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/__main__.py", line 3 in <module>
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 85 in _run_code
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 170 in _run_module_as_main
---

----------
messages: 239216
nosy: haypo
priority: normal
severity: normal
status: open
title: pymonotonic() gone backward on "AMD64 Debian root 3.x" buildbot
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 25 04:28:58 2015
From: report at bugs.python.org (Shiz)
Date: Wed, 25 Mar 2015 03:28:58 +0000
Subject: [New-bugs-announce] [issue23773] importlib does not properly remove
	frames when invoking	external import hooks
Message-ID: <1427254138.42.0.76544892287.issue23773@psf.upfronthosting.co.za>


New submission from Shiz:

When adding a custom module loader to sys.meta_path, importlib does not properly remove its frames before invoking it. This results in a weird traceback with importlib._bootstrap frames in if an error occurs during load_module(), like such:

Traceback (most recent call last):
  File "/Users/mark/Development/Projects/rave/rave/bootstrap/__init__.py", line 102, in bootstrap_game
    __import__(MODULE_PACKAGE + '.' + mod.replace('.py', ''))
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/__init__.py", line 1, in <module>
    from . import common, core3
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/core3/__init__.py", line 11, in <module>
    from .texture import Texture, Image
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/core3/texture.py", line 8, in <module>
    raise ValueError

Attached is a patch against the current hg head that makes sure module loaders are invoked through _call_with_frames_removed, so that the output becomes a lot more readable:

Traceback (most recent call last):
  File "/Users/mark/Development/Projects/rave/rave/bootstrap/__init__.py", line 102, in bootstrap_game
    __import__(MODULE_PACKAGE + '.' + mod.replace('.py', ''))
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/__init__.py", line 1, in <module>
    from . import common, core3
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/core3/__init__.py", line 11, in <module>
    from .texture import Texture, Image
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/core3/texture.py", line 8, in <module>
    raise ValueError
ValueError

Ideally it would remove the calls /within/ the module loader itself too, but I do not see an easy way to do this without changing the entire _call_with_frames_removed semantics. This fixes most of the issues, though.

----------
components: Library (Lib)
files: cpython-3ac58de829ef-fix-external-module-loader-call-traceback.patch
keywords: patch
messages: 239219
nosy: shiz
priority: normal
severity: normal
status: open
title: importlib does not properly remove frames when invoking external import hooks
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38681/cpython-3ac58de829ef-fix-external-module-loader-call-traceback.patch

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

From report at bugs.python.org  Wed Mar 25 07:41:36 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:41:36 +0000
Subject: [New-bugs-announce] [issue23774] Test failures when unable to write
	to install location
Message-ID: <1427265696.1.0.371099529167.issue23774@psf.upfronthosting.co.za>


New submission from Steve Dower:

The following tests fail when run in an all-users installation because they cannot write to the install directory:

test_compileall test_tcl test_tools test_zipfile

See the attached file for traces.

>From Ned Deily:
Regarding tests trying to write into the install directory tree, I'm pretty sure that there have been fixes added for those but I can't recall off the top of my head specific examples.  I think the best approach is to use a temporary, writable directory instead; if that's not practical, then the test case should be skipped.  I support fixing any tests that still currently fail due to this.

(New issue cloned from discussion on #23619)

----------
components: Tests, Windows
files: 35a2-failures.txt
messages: 239225
nosy: ned.deily, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Test failures when unable to write to install location
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38682/35a2-failures.txt

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

From report at bugs.python.org  Wed Mar 25 08:54:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 07:54:56 +0000
Subject: [New-bugs-announce] [issue23775] Fix pprint of OrderedDict
Message-ID: <1427270096.56.0.104555413271.issue23775@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently pprint prints the repr of OrderedDict if it fits in one line, and prints the repr of dict if it is wrapped.

>>> import collections, pprint
>>> pprint.pprint(collections.OrderedDict([(4, 3), (2, 1)]))
OrderedDict([(4, 3), (2, 1)])
>>> pprint.pprint(collections.OrderedDict([(4, 3), (2, 1)]), width=25)
{4: 3,
 2: 1}

Proposed patch makes pprint always produce an output compatible with OrderedDict's repr.

>>> pprint.pprint(collections.OrderedDict([(4, 3), (2, 1)]), width=25)
OrderedDict([(4, 3),
             (2, 1)])

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: pprint_ordered_dict.patch
keywords: patch
messages: 239234
nosy: fdrake, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix pprint of OrderedDict
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38683/pprint_ordered_dict.patch

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

From report at bugs.python.org  Wed Mar 25 10:37:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 09:37:42 +0000
Subject: [New-bugs-announce] [issue23776] Don't use assert for checking
	arguments in pprint
Message-ID: <1427276262.37.0.171943179164.issue23776@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The assert statement should be used only for checking internal logic, and not for checking user data. These assertions should be either removed or converted into explicit raising ValueError.

----------
components: Library (Lib)
messages: 239241
nosy: fdrake, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Don't use assert for checking arguments in pprint
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 25 11:37:25 2015
From: report at bugs.python.org (SpaceOne)
Date: Wed, 25 Mar 2015 10:37:25 +0000
Subject: [New-bugs-announce] [issue23777] argparse subcommand action can't
	be specified
Message-ID: <1427279845.4.0.291157397861.issue23777@psf.upfronthosting.co.za>


New submission from SpaceOne:

parser.add_subparsers(dest='arguments', action='append')
will raise the following exception:

  File "/usr/lib/python2.7/argparse.py", line 1675, in add_subparsers
    action = parsers_class(option_strings=[], **kwargs)
TypeError: __init__() got an unexpected keyword argument 'prog'

Instead of 'argparse._SubParsersAction' the class 'argparse._AppendAction' is used.
Could maybe fixed by passing the 'action' parameter to the _SubParsersAction class which then instanciates a _AppendAction and somehow uses this internally for further things.

----------
components: Library (Lib)
messages: 239246
nosy: spaceone
priority: normal
severity: normal
status: open
title: argparse subcommand action can't be specified
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 25 16:22:15 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 15:22:15 +0000
Subject: [New-bugs-announce] [issue23778] Add a visual distinction to
	multiline versionchanged	blocks
Message-ID: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>


New submission from Demian Brecht:

This came up during #2211, where a multiline versionchanged entry was suggested. Currently, there is no visual distinction between any but the first line of the description and the rest of the body of the docs. The attached patch adds a consistent level of indentation (30px) to all but the first child. This change makes it much more obvious where the versionchanged block ends and the rest of the docs continue.

----------
assignee: docs at python
components: Documentation
files: versionchanged_indent.patch
keywords: patch
messages: 239261
nosy: demian.brecht, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Add a visual distinction to multiline versionchanged blocks
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38689/versionchanged_indent.patch

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

From report at bugs.python.org  Wed Mar 25 23:21:23 2015
From: report at bugs.python.org (Craig Holmquist)
Date: Wed, 25 Mar 2015 22:21:23 +0000
Subject: [New-bugs-announce] [issue23779] imaplib authenticate raises
	TypeError if authenticator	tries to abort
Message-ID: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za>


New submission from Craig Holmquist:

If the authenticator object passed to the IMAP authenticate method tries to abort the handshake by returning None, TypeError is raised instead of sending the * line to the server.

>>> import imaplib
>>> imap = imaplib.IMAP4_SSL('imap.gmail.com')
>>> imap.authenticate(b'PLAIN', lambda x: None)
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    imap.authenticate(b'PLAIN', lambda x: None)
  File "C:\Python34\lib\imaplib.py", line 380, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mech)
  File "C:\Python34\lib\imaplib.py", line 1133, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "C:\Python34\lib\imaplib.py", line 940, in _command
    self.send(literal)
  File "C:\Python34\lib\imaplib.py", line 276, in send
    self.sock.sendall(data)
  File "C:\Python34\lib\ssl.py", line 723, in sendall
    v = self.send(data[count:])
  File "C:\Python34\lib\ssl.py", line 684, in send
    v = self._sslobj.write(data)
TypeError: 'str' does not support the buffer interface

The problem is that _Authenticator.process returns a string instead of bytes in this case.

----------
components: Library (Lib)
files: imap_auth.patch
keywords: patch
messages: 239283
nosy: craigh
priority: normal
severity: normal
status: open
title: imaplib authenticate raises TypeError if authenticator tries to abort
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38694/imap_auth.patch

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

From report at bugs.python.org  Thu Mar 26 09:02:03 2015
From: report at bugs.python.org (Florian Bruhin)
Date: Thu, 26 Mar 2015 08:02:03 +0000
Subject: [New-bugs-announce] [issue23780] Surprising behaviour when passing
	list to os.path.join.
Message-ID: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

I just accidentally passed a list (instead of unpacking it) to os.path.join. I was surprised when it just returned the list unmodified:

>>> os.path.join([1, 2, 3])
[1, 2, 3]

Looking at the source, it simply returns the first argument (path = a; ...; return path) when the '*p' part is empty.

I think a "genericpath._check_arg_types('join', a)" or similiar should be added at the top, or it should ensure the "*p" part is not empty (as the docstring says "two or more pathname components").

----------
components: Library (Lib)
messages: 239314
nosy: The Compiler, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Surprising behaviour when passing list to os.path.join.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 26 10:49:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 09:49:48 +0000
Subject: [New-bugs-announce] [issue23781] Add private
	_PyErr_ReplaceException() in 2.7
Message-ID: <1427363388.22.0.986381006689.issue23781@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds internal private function _PyErr_ReplaceException() in 2.7. This functions is like _PyErr_ChainExceptions() in 3.x, but doesn't set the context. It makes the code of 2.x simpler and more similar to 3.x and makes the backporting from 3.x easier.

----------
components: Interpreter Core
files: capi_PyErr_ReplaceException.patch
keywords: patch
messages: 239317
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add private _PyErr_ReplaceException() in 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file38697/capi_PyErr_ReplaceException.patch

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

From report at bugs.python.org  Thu Mar 26 11:25:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 10:25:02 +0000
Subject: [New-bugs-announce] [issue23782] Leak in _PyTraceback_Add
Message-ID: <1427365502.47.0.105321888995.issue23782@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a leak of fetched exception in _PyTraceback_Add() (Python/traceback.c:146).

----------
messages: 239319
nosy: georg.brandl, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Leak in _PyTraceback_Add
type: resource usage

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

From report at bugs.python.org  Thu Mar 26 11:36:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 10:36:56 +0000
Subject: [New-bugs-announce] [issue23783] Leak in PyObject_ClearWeakRefs
Message-ID: <1427366216.42.0.852268629074.issue23783@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

If restore_error == 1 in PyObject_ClearWeakRefs() (Objects/weakrefobject.c:883) and PyTuple_New() fails in Objects/weakrefobject.c:923, PyErr_Fetch is called twice and both exceptions leak.

----------
components: Extension Modules
messages: 239320
nosy: fdrake, haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Leak in PyObject_ClearWeakRefs
type: resource usage

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

From report at bugs.python.org  Thu Mar 26 12:17:57 2015
From: report at bugs.python.org (David Marks)
Date: Thu, 26 Mar 2015 11:17:57 +0000
Subject: [New-bugs-announce] [issue23784] Reloading tokenize module leads to
	error
Message-ID: <1427368677.31.0.668766566103.issue23784@psf.upfronthosting.co.za>


New submission from David Marks:

On 432 in tokenize.py there is an assignment

_builtin_open = open

Followed in 434 with a redefinition of open

def open(filename):

If the module is reloaded, _builtin_open gets reassigned to the new function and subsequent calls to _builtin_open fail.

----------
components: Library (Lib)
messages: 239322
nosy: dmarks
priority: normal
severity: normal
status: open
title: Reloading tokenize module leads to error
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 26 14:04:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 13:04:41 +0000
Subject: [New-bugs-announce] [issue23785] Leak in TextIOWrapper.tell()
Message-ID: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

If an exception was raised in TextIOWrapper.tell() and then restoring state is failed, original exception is lost and leaked.

----------
components: Extension Modules
messages: 239327
nosy: benjamin.peterson, haypo, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Leak in TextIOWrapper.tell()
type: resource usage
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar 26 14:47:27 2015
From: report at bugs.python.org (Peter)
Date: Thu, 26 Mar 2015 13:47:27 +0000
Subject: [New-bugs-announce] [issue23786]
	test_unaligned_buffers	(test.test_hash.HashEqualityTestCase)
	... Fatal Python error:	Bus error
Message-ID: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>


New submission from Peter:

I compiled Python 3.4.3 on Solaris 11, and when I ran the regression test, I get a core dump when the hash() function was being used. I went through the bug database looking for something similar but couldn't find anything.

Tests like:
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

Current thread 0x00000001 (most recent call first):
  File "/usr/local/lib/python3.4/test/test_hash.py", line 89 in test_unaligned_buffers
  File "/usr/local/lib/python3.4/unittest/case.py", line 577 in run
  File "/usr/local/lib/python3.4/unittest/case.py", line 625 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/runner.py", line 168 in run
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1769 in _run_suite
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1803 in run_unittest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1279 in test_runner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1280 in runtest_inner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 978 in runtest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 763 in main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1564 in main_in_temp_cwd
  File "/usr/local/lib/python3.4/test/__main__.py", line 3 in <module>
  File "/usr/local/lib/python3.4/runpy.py", line 85 in _run_code
  File "/usr/local/lib/python3.4/runpy.py", line 170 in _run_module_as_main
Bus Error (core dumped)


and


test_hash_equality (test.datetimetester.TestTime_Fast) ... Fatal Python error: Bus error

Current thread 0x00000001 (most recent call first):
  File "/usr/local/lib/python3.4/test/datetimetester.py", line 2155 in test_hash_equality
  File "/usr/local/lib/python3.4/unittest/case.py", line 577 in run
  File "/usr/local/lib/python3.4/unittest/case.py", line 625 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/runner.py", line 168 in run
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1769 in _run_suite
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1803 in run_unittest
  File "/usr/local/lib/python3.4/test/test_datetime.py", line 45 in test_main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1280 in runtest_inner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 978 in runtest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 763 in main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1564 in main_in_temp_cwd
  File "/usr/local/lib/python3.4/test/__main__.py", line 3 in <module>
  File "/usr/local/lib/python3.4/runpy.py", line 85 in _run_code
  File "/usr/local/lib/python3.4/runpy.py", line 170 in _run_module_as_main
Bus Error (core dumped)



I then ran the same test through gdb:
$ gdb /usr/local/bin/python3.4
GNU gdb (GDB) 7.8.1
<snip>
(gdb) run -m test -v test_hash
Starting program: /usr/local/bin/python3.4 -m test -v test_hash
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
== CPython 3.4.3 (default, Mar 25 2015, 17:35:25) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   hash algorithm: fnv 32bit
==   /tmp/test_python_12329
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_
site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_hash
test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... FAIL
test_randomized_hash (test.test_hash.DatetimeTimeTests) ... FAIL
test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok
test_hash_distribution (test.test_hash.HashDistributionTestCase) ... ok
test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok
test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok
test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xff25d14c in fnv (src=0x1d2289, len=127) at Python/pyhash.c:267
267             x = (_PyHASH_MULTIPLIER * x) ^ block.value;
(gdb) bt
#0  0xff25d14c in fnv (src=0x1d2289, len=127) at Python/pyhash.c:267
#1  0xff25d3f8 in _Py_HashBytes (src=0x1d2289, len=127) at Python/pyhash.c:186
#2  0xff1a7ce4 in memory_hash (self=0xfdff5570) at Objects/memoryobject.c:2793
#3  0xff1afa40 in PyObject_Hash (v=0xfdff5570) at Objects/object.c:757
#4  0xff22b6fc in builtin_hash (self=0xfee23600, v=0xfdff5570) at Python/bltinmodule.c:1269
#5  0xff236a70 in call_function (oparg=<optimized out>, pp_stack=0xffbfcc94) at Python/ceval.c:4224
#6  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2838
#7  0xff237790 in fast_function (nk=<optimized out>, na=<optimized out>, n=1, pp_stack=0xffbfcd8c,
    func=<optimized out>) at Python/ceval.c:4334
<snip>


(gdb) list
262
263         x = (Py_uhash_t) _Py_HashSecret.fnv.prefix;
264         x ^= (Py_uhash_t) *p << 7;
265         while (blocks--) {
266             PY_UHASH_CPY(block.bytes, p);
267             x = (_PyHASH_MULTIPLIER * x) ^ block.value;
268             p += SIZEOF_PY_UHASH_T;
269         }
270         /* add remainder */
271         for (; remainder > 0; remainder--)



Further info:
$ uname -a
SunOS vstrlily1d 5.11 11.1 sun4v sparc sun4v Solaris

$ gcc --verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sparc-sun-solaris2.11/4.6.2/lto-wrapper
Target: sparc-sun-solaris2.11
Configured with: ../gcc-4.6.2/configure --prefix=/usr/local --enable-languages=c,c++ --disable-nls --with-gnu-as --with-gnu-ld --target=sparc-sun-solaris2.11
Thread model: posix
gcc version 4.6.2 (GCC)

----------
components: Interpreter Core, Tests
messages: 239330
nosy: petriborg
priority: normal
severity: normal
status: open
title: test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 27 12:24:06 2015
From: report at bugs.python.org (Valentine Sinitsyn)
Date: Fri, 27 Mar 2015 11:24:06 +0000
Subject: [New-bugs-announce] [issue23787] sum() function docstring lists
	arguments incorrectly
Message-ID: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>


New submission from Valentine Sinitsyn:

sum() function doctstring describes expected arguments as follows (Python 2.7.6):

sum(...)
    sum(sequence[, start]) -> value
...

This implies sum() should accept str, unicode, list, tuple, bytearray, buffer, and xrange. However, you clearly can't use this function to sum strings (which is also mentioned in the docstring):

>>> sum('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

I'd suggest to describe first argument as iterable, which is actually what sum() expects there.

----------
assignee: docs at python
components: Documentation
messages: 239388
nosy: docs at python, vsinitsyn
priority: normal
severity: normal
status: open
title: sum() function docstring lists arguments incorrectly
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 27 13:18:21 2015
From: report at bugs.python.org (Raniere Silva)
Date: Fri, 27 Mar 2015 12:18:21 +0000
Subject: [New-bugs-announce] [issue23788] test_bad_address fails
Message-ID: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za>


New submission from Raniere Silva:

Starting from Git commit 1996f3038458df2b6443c23e4705478ff5db43f8

$ ./configure
$ make
$ make test
======================================================================
FAIL: test_bad_address (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/raniere/src/cpython/Lib/test/test_urllib2_localnet.py", line 656, in test_bad_address
    "http://sadflkjsasf.i.nvali.d./")
AssertionError: OSError not raised by urlopen

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

----------
components: Tests
messages: 239390
nosy: raniere
priority: normal
severity: normal
status: open
title: test_bad_address fails
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 27 14:01:13 2015
From: report at bugs.python.org (Paul Eckhardt)
Date: Fri, 27 Mar 2015 13:01:13 +0000
Subject: [New-bugs-announce] [issue23789] decimal.Decimal: __format__
	behaviour
Message-ID: <1427461273.99.0.604875598845.issue23789@psf.upfronthosting.co.za>


New submission from Paul Eckhardt:

The bahaviour of __format__ for decimal.Decimal type differs in one detail from float:
The minimum number of digits used for the exponent is 1 for Decimal, and 2 for float.
e.g.: "{:8.2E}".format(1.0) --> "1.00E+00"
      "{:8.2E}".format(Decimal(1.0)) --> " 1.00E+0"

Is there any reason for this?
If not, the following patch should do:

--- /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/decimal.py	2015-03-27 12:55:22.000000000 +0100
+++ ./decimal.py	2015-03-27 14:00:09.000000000 +0100
@@ -6116,7 +6116,7 @@
 
     if exp != 0 or spec['type'] in 'eE':
         echar = {'E': 'E', 'e': 'e', 'G': 'E', 'g': 'e'}[spec['type']]
-        fracpart += "{0}{1:+}".format(echar, exp)
+        fracpart += "{0}{1:+03d}".format(echar, exp)
     if spec['type'] == '%':
         fracpart += '%'

----------
components: Library (Lib)
messages: 239394
nosy: MonsieurPaul
priority: normal
severity: normal
status: open
title: decimal.Decimal: __format__ behaviour
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 27 14:05:10 2015
From: report at bugs.python.org (Oskar Hahn)
Date: Fri, 27 Mar 2015 13:05:10 +0000
Subject: [New-bugs-announce] [issue23790] When xdrlib.Packer().pack_string()
	fails, the Packer is corrupted
Message-ID: <1427461510.09.0.808726067558.issue23790@psf.upfronthosting.co.za>


New submission from Oskar Hahn:

When xdrlib.Packer().pack_string() is called with an unsupported value, it raises a TypeError. But it calles self.pack_uint(n) before it raises the exception so the buffer is changed.

There are two possible solutions to solve this behaviour. The argument s can be tested to be supported, or undo the call of self.pack_uint(n).

I added two alternative patches for this two solutions.

This is my first patch for cpython, I hope it is ok.

----------
components: Library (Lib)
files: test_value.patch
keywords: patch
messages: 239396
nosy: ostcar
priority: normal
severity: normal
status: open
title: When xdrlib.Packer().pack_string() fails, the Packer is corrupted
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38710/test_value.patch

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

From report at bugs.python.org  Fri Mar 27 17:25:20 2015
From: report at bugs.python.org (Brian)
Date: Fri, 27 Mar 2015 16:25:20 +0000
Subject: [New-bugs-announce] [issue23791] Identify Moved Lines with difflib
Message-ID: <1427473520.44.0.514545586028.issue23791@psf.upfronthosting.co.za>


New submission from Brian:

It would be a helpful feature to incorporate logic into the difflib module to optionally identify and ignore identical, but relocated lines when doing a diff. This would be used when the order of lines in a document is not critical, but rather just the overall content. The Notepad++ Compare plug-in has this feature for reference. 

I would be willing to help submit a patch for this change. The only drawbacks I see using this function is it will either have to increase processing time or increase memory usage.

----------
components: Library (Lib)
messages: 239416
nosy: bkiefer
priority: normal
severity: normal
status: open
title: Identify Moved Lines with difflib
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar 27 18:09:23 2015
From: report at bugs.python.org (Rusi)
Date: Fri, 27 Mar 2015 17:09:23 +0000
Subject: [New-bugs-announce] [issue23792] help crash leaves terminal in raw
	mode
Message-ID: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>


New submission from Rusi:

Start python3.4
Do help(something) which invokes the pager
Ctrl-C
A backtrace results and after that the terminal is in raw mode even after exiting python

[python 3.4 under debian testing with xfce4]

----------
components: IDLE
messages: 239417
nosy: RusiMody
priority: normal
severity: normal
status: open
title: help crash leaves terminal in raw mode
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 27 18:33:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Mar 2015 17:33:58 +0000
Subject: [New-bugs-announce] [issue23793] Support __add__ for deques.
Message-ID: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

One more step towards making the deque API a little closer to that for lists:
  
    >>> deque('abc') + deque('def')
    deque(['a', 'b', 'c', 'd', 'e', 'f'])

----------
assignee: rhettinger
components: Extension Modules
files: deque_add4.diff
keywords: patch
messages: 239419
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Support __add__ for deques.
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38712/deque_add4.diff

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

From report at bugs.python.org  Fri Mar 27 18:58:30 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 27 Mar 2015 17:58:30 +0000
Subject: [New-bugs-announce] [issue23794] http package should support HTTP/2
Message-ID: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

The spec is available at https://http2.github.io/

----------
components: Library (Lib)
messages: 239424
nosy: alex
priority: normal
severity: normal
status: open
title: http package should support HTTP/2

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

From report at bugs.python.org  Fri Mar 27 19:02:33 2015
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Ferreira?=)
Date: Fri, 27 Mar 2015 18:02:33 +0000
Subject: [New-bugs-announce] [issue23795] argparse -- incorrect usage for
	mutually exclusive
Message-ID: <1427479353.63.0.760069319945.issue23795@psf.upfronthosting.co.za>


New submission from Jo?o Ferreira:

The usage that is printed by argparse with the "--help" argument is slightly incorrect when using mutually exclusive groups. This happens in version 3.4.3 but did not happen in version 3.4.0.

I have this minimal example:

import argparse

p = argparse.ArgumentParser()

g1 = p.add_mutually_exclusive_group(required=False)
g1.add_argument("-a")
g1.add_argument("-b")

g2 = p.add_mutually_exclusive_group(required=False)
g2.add_argument("-c")
g2.add_argument("-d")

p.parse_args()

In python 3.4.0, "python test.py --help" produces the usage:

usage: test.py [-h] [-a A | -b B] [-c C | -d D]

In python 3.4.3, the usage is:

usage: test.py [-h] [-a A | -b B [-c C | -d D]

Note the absence of the closing square bracket after B.

----------
components: Library (Lib)
messages: 239425
nosy: jotomicron
priority: normal
severity: normal
status: open
title: argparse -- incorrect usage for mutually exclusive
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 28 01:29:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Mar 2015 00:29:50 +0000
Subject: [New-bugs-announce] [issue23796] BufferedReader.peek() crashes if
	closed
Message-ID: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>


New submission from Martin Panter:

If the BufferedReader object has already been closed, calling peek() can cause a strange error message or a crash:

$ python3 -bWall
Python 3.4.2 (default, Oct  8 2014, 14:33:30) 
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from io import *
>>> b = BufferedReader(BytesIO())
>>> b.close()
>>> b.peek()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: PyMemoryView_FromBuffer(): info->buf must not be NULL
>>> b = BufferedReader(BytesIO(b"12"))
>>> b.read(1)
b'1'
>>> b.close()
>>> b.peek()
Segmentation fault (core dumped)
[Exit 139]

I?m not able to check with 3.5 at the moment, but looking at the code, I suspect this also applies to 3.5 and there needs to be a CHECK_CLOSED() call added somewhere around Modules/_io/bufferedio.c:884.

----------
components: IO
messages: 239445
nosy: vadmium
priority: normal
severity: normal
status: open
title: BufferedReader.peek() crashes if closed
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 28 11:47:55 2015
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 28 Mar 2015 10:47:55 +0000
Subject: [New-bugs-announce] [issue23797] Mac OS X locale setup in thread
	happens sometime after	run() is called
Message-ID: <1427539675.57.0.610869974475.issue23797@psf.upfronthosting.co.za>


New submission from Barry Alan Scott:

I'm seeing a random traceback when starting a new thread on Mac OS X 10.10.2 with python 3.4.3 final.

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py", line 920, in _bootstrap_inner
    self.run()
  File "/Users/barry/wc/svn/pysvn-phoenix/WorkBench/Source/wb_background_thread.py", line 40, in run
    self.app.log.info( 'BackgroundThread locale %r' % (locale.getlocale(),) )
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/locale.py", line 575, in getlocale
    return _parse_localename(localename)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/locale.py", line 484, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: UTF-8

Adding a time.sleep( 5 ) prevents the traceback.

Using _locale.setlocale( locale.LC_ALL, None ) to see the state with locale.py interfering it looks like the locale is being initialised in the thread after run() is called. (Make no sense to me, but I can reproduce).

I have failed to create a small script to show this bug.

----------
messages: 239458
nosy: barry-scott
priority: normal
severity: normal
status: open
title: Mac OS X locale setup in thread happens sometime after run() is called
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar 28 19:00:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Mar 2015 18:00:54 +0000
Subject: [New-bugs-announce] [issue23798] NameError in the encode fixer
Message-ID: <1427565654.6.0.111247541.issue23798@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

======================================================================
ERROR: test_all_project_files (lib2to3.tests.test_all_fixers.Test_all)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/lib2to3/tests/test_all_fixers.py", line 25, in test_all_project_files
    self.refactor.refactor_file(filepath)
  File "/home/serhiy/py/cpython/Lib/lib2to3/refactor.py", line 354, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home/serhiy/py/cpython/Lib/lib2to3/refactor.py", line 386, in refactor_string
    self.refactor_tree(tree, name)
  File "/home/serhiy/py/cpython/Lib/lib2to3/refactor.py", line 460, in refactor_tree
    new = fixer.transform(node, results)
  File "/home/serhiy/py/cpython/Lib/lib2to3/fixes/fix_encode.py", line 50, in transform
    if negation:
NameError: name 'negation' is not defined

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

Variable 'negation' is never set.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 239462
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: NameError in the encode fixer
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 28 21:10:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Mar 2015 20:10:30 +0000
Subject: [New-bugs-announce] [issue23799] Join started threads in tests
Message-ID: <1427573430.36.0.605750682641.issue23799@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When a test starts many threads in a loop, there is a chance that the starting thread will fail due to lack of memory. In this case all started threads left dangling and make MemotyError even more probably. They also can provoke dim error messages in this and in following tests. Proposed patch adds new helper function test.support.start_threads() that starts threads and then join started threads.

Some tests even hang without this patch.

----------
components: Tests
files: test_support_start_threads.patch
keywords: patch
messages: 239465
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Join started threads in tests
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38720/test_support_start_threads.patch

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

From report at bugs.python.org  Sat Mar 28 21:50:31 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Mar 2015 20:50:31 +0000
Subject: [New-bugs-announce] [issue23800] Support POSIX uselocale interface
	for thread-specific	locale settings
Message-ID: <1427575831.26.0.23077822818.issue23800@psf.upfronthosting.co.za>


New submission from Ned Deily:

POSIX 2008 provides a system interface, uselocale, to set locales individually on a thread basis rather than just process global, as currently supported with locale.setlocale().  uselocale is supported in most current GNU libc, BSD, and OS X releases.  While there is currently a third-party package available in PyPI, it currently doesn't claim to support Python 3 and it would be good to have uselocale as part of the standard library where available.

http://pubs.opengroup.org/stage7tc1/functions/uselocale.html

https://github.com/wichert/xlocale

----------
components: Library (Lib)
messages: 239467
nosy: lemburg, loewis, ned.deily
priority: normal
severity: normal
status: open
title: Support POSIX uselocale interface for thread-specific locale settings
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 29 04:22:21 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 29 Mar 2015 02:22:21 +0000
Subject: [New-bugs-announce] [issue23801] cgi.FieldStorage has different
	(wrong?) behavior on	Python3 than Python2
Message-ID: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>


New submission from Donald Stufft:

While working on PyPI 2.0 (which is currently running Python 3) I discovered that ``setup.py upload`` was causing an exception. After tracing things I determined that the reason for this is that Python 3 fails to handle leading whitespace in a multipart body.

I've attached a minimum reproducer that runs without error on Python 2.6 and Python 2.7 which fails on Python 3.2, 3.3, and 3.4.

If I go into the cgi.py module and add a print() statement that will print the header of each part, I get output that looks like:

b'----------------GHSKFJDLGDS7543FJKLFHRE75642756743254\r\nContent-Disposition: form-data; name="protcol_version"\r\n\r\n'
b'Content-Disposition: form-data; name="summary"\r\n\r\n'
b'Content-Disposition: form-data; name="home_page"\r\n\r\n'
b'Content-Disposition: form-data; name="filetype"\r\n\r\n'
b'Content-Disposition: form-data; name="content"; filename="jasmin-13.13.13.tar.gz"\r\n\r\n'

The first line of that is obviously suspicious since it includes the inner boundary marker. Looking at the Python 3.x code it throws away the first line off the fp and then proceeds to process the rest of the fp. However in this case the first line is just a blank b'\r\n'. Looking at the Python 2.7 code it throws away an entire first part, not just the first line.

I'm guessing that the "read first line and throw it away code" needs to continue reading lines until it's read enough lines to get to the boundary marker.

----------
files: reproduce.py
messages: 239471
nosy: dstufft
priority: normal
severity: normal
status: open
title: cgi.FieldStorage has different (wrong?) behavior on Python3 than Python2
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38721/reproduce.py

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

From report at bugs.python.org  Sun Mar 29 08:01:41 2015
From: report at bugs.python.org (Daniel Shahaf)
Date: Sun, 29 Mar 2015 06:01:41 +0000
Subject: [New-bugs-announce] [issue23802] patch: __deepcopy__ memo dict
	argument usage
Message-ID: <1427608901.41.0.0640545279461.issue23802@psf.upfronthosting.co.za>


New submission from Daniel Shahaf:

In the 'copy' module documentation, it wasn't fully clear to me how __deepcopy__ implementations should treat the memo dict argument.  The attached patch clarifies that __deepcopy__ implementations should treat the memo dict argument as an opaque type.

----------
assignee: docs at python
components: Documentation
files: opaque.diff
keywords: patch
messages: 239473
nosy: danielsh, docs at python
priority: normal
severity: normal
status: open
title: patch: __deepcopy__ memo dict argument usage
type: enhancement
Added file: http://bugs.python.org/file38723/opaque.diff

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

From report at bugs.python.org  Sun Mar 29 09:02:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 07:02:47 +0000
Subject: [New-bugs-announce] [issue23803] str.partition() is broken in 3.4
Message-ID: <1427612567.08.0.637724736927.issue23803@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tests added in b923eeaf8162 exposed a bug in str.partition() and str.rpartition() in 3.4 on big-endian platforms. It should exist in 3.3 too. It likely was fixed in 3.5 in issue23573.

http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.4/builds/913/steps/test/logs/stdio
======================================================================
FAIL: test_partition (test.test_unicode.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_unicode.py", line 383, in test_partition
    left + right, 'partition', delim)
  File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/string_tests.py", line 63, in checkequal
    realresult
AssertionError: Tuples differ: ('bbbbbbbbbaaaaaaaaa', '', '') != ('', '?', '\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00')

First differing element 0:
bbbbbbbbbaaaaaaaaa


- ('bbbbbbbbbaaaaaaaaa', '', '')
+ ('', '?', '\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00')

======================================================================
FAIL: test_rpartition (test.test_unicode.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_unicode.py", line 399, in test_rpartition
    left + right, 'rpartition', delim)
  File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/string_tests.py", line 63, in checkequal
    realresult
AssertionError: Tuples differ: ('', '', 'bbbbbbbbbaaaaaaaaa') != ('\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00', '?', '')

First differing element 0:

bbbb

- ('', '', 'bbbbbbbbbaaaaaaaaa')
+ ('\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00', '?', '')

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

'bbbbbbbbbaaaaaaaaa'.partition('\U00010302') returns ('', '?', '\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00')
'bbbbbbbbbaaaaaaaaa'.rpartition('\U00010302') returns ('\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00', '?', '')

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 239475
nosy: benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: str.partition() is broken in 3.4
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Mar 29 12:30:23 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Mar 2015 10:30:23 +0000
Subject: [New-bugs-announce] [issue23804] SSLSocket.recv(0) receives up to
	1024 bytes
Message-ID: <1427625023.61.0.148010223441.issue23804@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation claims that SSL socket objects provide some of the same methods as plain socket objects, including recv(), and that the ?bufsize? parameter specifies the maximum amount of data to be received. With ordinary sockets, socket.recv(0) always seems to return zero bytes (b""), as expected. But not so with SSL sockets:

>>> import socket, ssl
>>> s = ssl.wrap_socket(socket.create_connection(("localhost", 631)))
>>> s.sendall(b"GET / HTTP/1.1\r\nHost: localhost\r\n\r\n")
35
>>> len(s.recv(0))
263
>>> len(s.recv(0))
1024

The call will hang or raise SSLWantReadError when no data is actually available. Looking at the code, the value of zero seems to be used as a placeholder for a default of 1024 in SSLObject.read(). Either the SSL module should be fixed to return no bytes (my preference), or the documentation needs to warn that the recv(0) is not supported, or does not work the same as for plain sockets. SSLSocket.read() might also be affected.

----------
components: Library (Lib)
messages: 239483
nosy: vadmium
priority: normal
severity: normal
status: open
title: SSLSocket.recv(0) receives up to 1024 bytes
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar 29 14:23:21 2015
From: report at bugs.python.org (Freddy)
Date: Sun, 29 Mar 2015 12:23:21 +0000
Subject: [New-bugs-announce] [issue23805] _hashlib compile error?
Message-ID: <1427631801.6.0.245894260937.issue23805@psf.upfronthosting.co.za>


New submission from Freddy:

I just installed Python 3.5.0a2 from Source.
Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux

[264/392] test_hashlib
/root/Downloads/Python-3.5.0a2/Lib/test/test_hashlib.py:52: UserWarning: Did a C extension fail to compile? No module named '_hashlib'
  warnings.warn('Did a C extension fail to compile? %s' % error)

Sorry, I'm not sure if it is an issue.

----------
components: Installation
messages: 239487
nosy: SinusAlpha
priority: normal
severity: normal
status: open
title: _hashlib compile error?
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 29 16:56:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 14:56:26 +0000
Subject: [New-bugs-announce] [issue23806] documentation for no_proxy is
	missing from the python3	urllib documentation
Message-ID: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>


New submission from R. David Murray:

no_proxy (and what notation it supports) is mentioned in the python2 urllib docs, but not in the python3 docs.

----------
assignee: docs at python
components: Documentation
messages: 239493
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: documentation for no_proxy is missing from the python3 urllib documentation
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar 29 17:42:19 2015
From: report at bugs.python.org (Thana Annis)
Date: Sun, 29 Mar 2015 15:42:19 +0000
Subject: [New-bugs-announce] [issue23807] Improved test coverage for
	calendar.py command line
Message-ID: <1427643739.5.0.155189832451.issue23807@psf.upfronthosting.co.za>


New submission from Thana Annis:

Added a test to ensure that --locale cannot be called without --encoding. This is targeting lines 654-656 of calendar.py.

----------
components: Tests
files: test_calendar.patch
keywords: patch
messages: 239494
nosy: Bwaffles
priority: normal
severity: normal
status: open
title: Improved test coverage for calendar.py command line
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38727/test_calendar.patch

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

From report at bugs.python.org  Sun Mar 29 20:45:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 18:45:10 +0000
Subject: [New-bugs-announce] [issue23808] Symlink to directory on Windows 8
Message-ID: <1427654710.52.0.171827508348.issue23808@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Looks as a symlink on Windows 8 can has the FILE_ATTRIBUTE_DIRECTORY flag.

http://buildbot.python.org/all/builders/AMD64%20Windows8%203.4/builds/348/steps/test/logs/stdio
======================================================================
FAIL: test_walk_bottom_up (test.test_os.WalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File &#34;D:\buildarea\3.4.bolen-windows8\build\lib\test\test_os.py&#34;, line 802, in test_walk_bottom_up
    self.sub2_tree)
AssertionError: Tuples differ: (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;]) != (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])

First differing element 1:
[&#39;broken_link&#39;, &#39;link&#39;]
[&#39;link&#39;]

- (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;])
?                                                 ----------

+ (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])
?                                 ++++++++++


======================================================================
FAIL: test_walk_prune (test.test_os.WalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File &#34;D:\buildarea\3.4.bolen-windows8\build\lib\test\test_os.py&#34;, line 782, in test_walk_prune
    self.assertEqual(all[1], self.sub2_tree)
AssertionError: Tuples differ: (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;]) != (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])

First differing element 1:
[&#39;broken_link&#39;, &#39;link&#39;]
[&#39;link&#39;]

- (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;])
?                                                 ----------

+ (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])
?                                 ++++++++++


======================================================================
FAIL: test_walk_topdown (test.test_os.WalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File &#34;D:\buildarea\3.4.bolen-windows8\build\lib\test\test_os.py&#34;, line 765, in test_walk_topdown
    self.assertEqual(all[3 - 2 * flipped], self.sub2_tree)
AssertionError: Tuples differ: (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;]) != (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])

First differing element 1:
[&#39;broken_link&#39;, &#39;link&#39;]
[&#39;link&#39;]

- (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;])
?                                                 ----------

+ (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])
?                                 ++++++++++


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

Create broken link:

    os.symlink('non_existing_patch', 'broken_link', target_is_directory=True)

What return os.path.isdir('broken_link')?

----------
components: Tests, Windows
messages: 239506
nosy: paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Symlink to directory on Windows 8
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 30 03:00:31 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Mar 2015 01:00:31 +0000
Subject: [New-bugs-announce] [issue23809] RFE: emit a warning when a module
	in a traceback shadows	a stdlib module
Message-ID: <1427677231.57.0.397201302545.issue23809@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

A colleague just ran into the issue where they created a "json.py" module in their local directory and broke a previously working program. I picked up on the mistake when I saw the following traceback snippet:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python2.7/site-packages/praw/__init__.py", line 27, in <module>
        import json
      File "json.py", line 1, in <module>
        r = requests.get("http://www.reddit.com/user/spilcm/about/.json")

However, actually making the connection required thinking "Wait, why is the stdlib JSON module calling out to Reddit?" followed immediately by "Oh, that's not the stdlib json module".

That connection would potentially be easier for new Python users to make if there was an inline notification printed after the traceback warning of the stdlib module shadowing. If nothing else, it would give them something specific to search for to lead them to a discussion of name shadowing and the problems that can arise when you name one of your local modules the same as a standard library module.

Offering such a feature would necessarily rely on having a standard way of getting a programmatic list of the standard library modules available to the running interpreter version without actually loading them all, a question which is discussed further in https://stackoverflow.com/questions/6463918/how-can-i-get-a-list-of-all-the-python-standard-library-modules and https://github.com/jackmaney/python-stdlib-list

Since the contents of the standard library for a given release is immutable, and we'd like to keep any such mechanism (if we decide to provide it) very simple so we can easily access it from the low level interpreter traceback machinery, my suggestion would be along the lines of:

1. Update the interpreter build process to emit a flat text file containing a complete list of fully qualified stdlib module names (including submodules), one name per line (this will be generated at build time, so it *won't* contain filenames, just the module names - however, it could theoretically be combined with importlib.util.find_spec to generate a PEP 376 style RECORD file for the non-builtin parts of the standard library at installation time)
2. Rather than exposing the underlying machinery to end users directly, instead expose a function in sysconfig to read that list of modules into memory via a read-only line based iterator. (There may be an internal API to allow access to the content without going through sysconfig)
3. Updating the two main traceback display mechanisms (the builtin traceback display and the traceback module) to check that list for potential conflicts after displaying a traceback

(This idea could benefit from discussion on python-ideas and potentially even escalate into a full PEP, but I don't currently have the personal bandwidth available to pursue that course. Accordingly, I'm just filing the idea here in case someone else finds it intriguing and has more time available to pursue it)

----------
messages: 239543
nosy: georg.brandl, larry, ncoghlan, rbcollins
priority: normal
severity: normal
status: open
title: RFE: emit a warning when a module in a traceback shadows a stdlib module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 30 03:54:14 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Mar 2015 01:54:14 +0000
Subject: [New-bugs-announce] [issue23810] Suboptimal stacklevel of
	deprecation warnings for	formatter and imp modules
Message-ID: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

https://hg.python.org/cpython/rev/2a336cc29282 changed stacklevel of some deprecation warnings.
However new value is still not useful, because either _frozen_importlib or importlib/_bootstrap.py is now mentioned in deprecation warnings:

$ cat test.py
import formatter
import imp
$ python3.4 -Wd test.py
/usr/lib64/python3.4/formatter.py:24: PendingDeprecationWarning: the formatter module is deprecated and will be removed in Python 3.6
  'Python 3.6', PendingDeprecationWarning)
/usr/lib64/python3.4/imp.py:32: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  PendingDeprecationWarning)
$ python3.5 -Wd test.py
_frozen_importlib:321: DeprecationWarning: the formatter module is deprecated and will be removed in Python 3.6
/usr/lib64/python3.5/importlib/_bootstrap.py:321: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  return f(*args, **kwds)

----------
assignee: brett.cannon
components: Library (Lib)
messages: 239554
nosy: Arfrever, brett.cannon
priority: normal
severity: normal
status: open
title: Suboptimal stacklevel of deprecation warnings for formatter and imp modules
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 30 13:58:58 2015
From: report at bugs.python.org (Akshet Pandey)
Date: Mon, 30 Mar 2015 11:58:58 +0000
Subject: [New-bugs-announce] [issue23811] Python py_compile error message
	inconsistent and missing	newline
Message-ID: <1427716738.06.0.245811504272.issue23811@psf.upfronthosting.co.za>


New submission from Akshet Pandey:

On the following test file (test.py):

```python
class Solution:
  def repeatedNumber(self, A):
    test = 1
      return []
```

Running python -m py_compile test.py return the following error message:
Sorry: IndentationError: unexpected indent (test.py, line 6)

But without a newline on stderr at the end of the message. This causes some problems with scripts that expect a newline and new my particular case with reading stderr on docker where docker just ignore the line if it doesn't end in a newline.

Also, this message differs from the runtime error message:

```
  File "test.py", line 6
    return []
    ^
IndentationError: unexpected indent
```

Would it be possible to at least add in a newline and at best, change the message to be consistent with the runtime error message?

I will trying to look at the code and see if I can write a patch but it will take me some time.

----------
components: Interpreter Core
messages: 239598
nosy: akshetp
priority: normal
severity: normal
status: open
title: Python py_compile error message inconsistent and missing newline
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Mar 30 15:59:52 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 30 Mar 2015 13:59:52 +0000
Subject: [New-bugs-announce] [issue23812] asyncio.Queue.put_nowait(),
	followed get() task cancellation leads to item being lost
Message-ID: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>


New submission from Gustavo J. A. M. Carneiro:

I have a pattern where I read from a queue with a timeout, generally like this:

while True:
  reader = asyncio.async(wait_for(queue.get(), 0.1))
  try:
    item = (yield from reader)
  except asyncio.TimeoutError:
    reader.cancel()
    continue

This is to have a loop where we try to get items from the queue with a timeout.  Prior to Python 3.5, wait_for() doesn't automatically cancel the reading task, so I have to do it explicitly above.

The code has a strange race condition where, if a taks calls put_nowait on a reader task that is just about to be cancelled due to timeout, then the item that wast put onto the queue gets lost.

In the tests framework, the minimal test case I can come up with is mainly this code:


  q = asyncio.Queue(loop=loop)
  reader = loop.create_task(q.get())
  loop.run_until_complete(asyncio.sleep(0.01, loop=loop))

  q.put_nowait(1)
  q.put_nowait(2)
  reader.cancel()

When the reader gets cancelled, the item `1` is lost into the ether, and when you create another reader for the same queue, it only gets the second item `2`.  I would expect that, if a reader task is cancelled, the item at the head of the queue doesn't get lost.  Either the reader succeeds and the item is removed, or it doesn't succeed and the item is left alone.

I attach a patch to the tulip tests that reproduces the problem in both Python 3.4.2 and tulip hg.

----------
components: asyncio
files: bug-test.diff
keywords: patch
messages: 239611
nosy: gustavo, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38740/bug-test.diff

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

From report at bugs.python.org  Mon Mar 30 20:35:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 18:35:51 +0000
Subject: [New-bugs-announce] [issue23813] RSS and Atom feeds of buildbot
	results are broken
Message-ID: <1427740551.98.0.543585412367.issue23813@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are links to Atom and RSS feeds on https://www.python.org/dev/buildbot/:

http://buildbot.python.org/all/rss
http://buildbot.python.org/all/atom

Both referred pages are broken.

web.Server Traceback (most recent call last):
exceptions.UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 39: invalid start byte
/usr/lib/python2.7/dist-packages/twisted/web/server.py:189 in process
188                    self._encoder = encoder
189            self.render(resrc)
190        except:
/usr/lib/python2.7/dist-packages/twisted/web/server.py:238 in render
237        try:
238            body = resrc.render(self)
239        except UnsupportedMethod as e:
/data/buildbot/lib/python/buildbot/status/web/feeds.py:55 in render
54    def render(self, request):
55        data = self.content(request)
56        request.setHeader("content-type", self.contentType)
/data/buildbot/lib/python/buildbot/status/web/feeds.py:224 in content
223                        for line in logdata.split('\n')[-30:]:
224                            unilist.append(unicode(line,'utf-8'))
225                        log_lines.extend(unilist)
exceptions.UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 39: invalid start byte

----------
messages: 239631
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: RSS and Atom feeds of buildbot results are broken
type: behavior

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

From report at bugs.python.org  Mon Mar 30 20:40:47 2015
From: report at bugs.python.org (Karl O. Pinc)
Date: Mon, 30 Mar 2015 18:40:47 +0000
Subject: [New-bugs-announce] [issue23814] argparse: Parser level defaults do
	not always override	argument level defaults
Message-ID: <1427740847.33.0.866518706982.issue23814@psf.upfronthosting.co.za>


New submission from Karl O. Pinc:

In the argparse library parser library, contrary to the documentation,
parser-level defaults do not always override argument-level defaults.

https://docs.python.org/3.5/library/argparse.html#argparse.ArgumentParser.set_defaults

says "Note that parser-level defaults always override argument-level defaults:"

(And so does the python 3.3 docs.)

The docs then provide this example:

  >>> parser = argparse.ArgumentParser()
  >>> parser.add_argument('--foo', default='bar')
  >>> parser.set_defaults(foo='spam')
  >>> parser.parse_args([])
  Namespace(foo='spam')

But it is only true that parser-level defaults override argument-level
defaults when they are established after the argument is added.

The output below shows an argument level default overrideing
a parser level default.

$ python3
Python 3.3.2 (default, Jun  4 2014, 11:36:37) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.set_defaults(foo='spam')
>>> parser.add_argument('--foo', default='bar')
_StoreAction(option_strings=['--foo'], dest='foo', nargs=None, const=None, default='bar', type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args([])
Namespace(foo='bar')

It seems that whichever default is set last is the one which is used.
Or perhaps there are not argument level defaults and parser level
defaults, there are just defaults, period.  (It might, possibly,
be nice if there _were_ both argument and parser level defaults
and parser level defaults had priority.  Then this would not be
a documentation bug.)

----------
assignee: docs at python
components: Documentation
messages: 239632
nosy: docs at python, kop
priority: normal
severity: normal
status: open
title: argparse: Parser level defaults do not always override argument level defaults
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 30 21:56:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 19:56:55 +0000
Subject: [New-bugs-announce] [issue23815] Segmentation fault when create
	_tkinter objects
Message-ID: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In 2.7 and 3.3:

>>> import _tkinter
>>> _tkinter.Tcl_Obj()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create '_tkinter.Tcl_Obj' instances
>>> _tkinter.TkttType()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'tktimertoken' instances

In 3.4+:

>>> import _tkinter
>>> _tkinter.Tcl_Obj()
Segmentation fault (core dumped)

And the same for _tkinter.TkttType.

Looks as this is a result of issue15721.

----------
components: Extension Modules, Tkinter
messages: 239636
nosy: Robin.Schreiber, amaury.forgeotdarc, asvetlov, loewis, ned.deily, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Segmentation fault when create _tkinter objects
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 30 23:27:03 2015
From: report at bugs.python.org (Jon Heiner)
Date: Mon, 30 Mar 2015 21:27:03 +0000
Subject: [New-bugs-announce] [issue23816] struct.unpack returns null pascal
	strings - [first] bug	report
Message-ID: <1427750823.57.0.914162685824.issue23816@psf.upfronthosting.co.za>


New submission from Jon Heiner:

I believe there is an issue with the _struct.c handling of Pascal style strings.

In the _struct.c:s_unpack_internal() function (reading 2.7.6 and 2.7.9 source from tgz ball), the size parameter 'n' is clamped to code->size-1.

As far as I can tell, 'n' is set to the correct deserialized value, but the code->size value is not set to 255. I could be incorrect, as I'm not running in a debugger.

I've attached a short repro case. Note the use of unpack_from() as otherwise unpac() will thrown an error. Additionally, I may be using it wrong, but this feels correct.

----------
components: Library (Lib)
files: unpack_pascal.py
messages: 239644
nosy: jonheiner, mark.dickinson, meador.inge
priority: normal
severity: normal
status: open
title: struct.unpack returns null pascal strings - [first] bug report
versions: Python 2.7
Added file: http://bugs.python.org/file38745/unpack_pascal.py

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

From report at bugs.python.org  Tue Mar 31 14:46:47 2015
From: report at bugs.python.org (bapt)
Date: Tue, 31 Mar 2015 12:46:47 +0000
Subject: [New-bugs-announce] [issue23817] Consider FreeBSD like any other OS
	in SOVERSION
Message-ID: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za>


New submission from bapt:

In the configuration script:
https://hg.python.org/cpython/file/47b2d1ff9743/configure.ac#l963

There is a special treatment done for FreeBSD, which is not needed, FreeBSD is perfectly fine with multiple digit in soversion.

----------
components: Build
messages: 239695
nosy: bapt
priority: normal
severity: normal
status: open
title: Consider FreeBSD like any other OS in SOVERSION

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

From report at bugs.python.org  Tue Mar 31 15:08:36 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:08:36 +0000
Subject: [New-bugs-announce] [issue23818] test_enum
	failing	test_class_nested_enum_and_pickle_protocol_four
Message-ID: <1427807316.71.0.103044792684.issue23818@psf.upfronthosting.co.za>


New submission from Brett Cannon:

test test_enum failed -- Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_enum.py", line 580, in test_class_nested_enum_and_pickle_protocol_four
    protocol=(0, 3))
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_enum.py", line 82, in test_pickle_exception
    dumps(obj, protocol=protocol)
AssertionError: PicklingError not raised

----------
components: Library (Lib)
messages: 239700
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_enum failing test_class_nested_enum_and_pickle_protocol_four
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 15:31:35 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:31:35 +0000
Subject: [New-bugs-announce] [issue23819] test_asyncio fails when run under
	-O
Message-ID: <1427808695.9.0.385563565443.issue23819@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Ton of failures along the lines of:

======================================================================
ERROR: test_ctor (test.test_asyncio.test_unix_events.UnixReadPipeTransportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_asyncio/test_unix_events.py", line 329, in setUp
    self.loop = self.new_test_loop()
  File "/Users/bcannon/Repositories/cpython/default/Lib/asyncio/test_utils.py", line 413, in new_test_loop
    self.set_event_loop(loop)
  File "/Users/bcannon/Repositories/cpython/default/Lib/asyncio/test_utils.py", line 407, in set_event_loop
    events.set_event_loop(None)
  File "/Users/bcannon/Repositories/cpython/default/Lib/asyncio/events.py", line 581, in set_event_loop
    get_event_loop_policy().set_event_loop(loop)
AttributeError: 'object' object has no attribute 'set_event_loop'

----------
components: asyncio
messages: 239704
nosy: brett.cannon, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: test_asyncio fails when run under -O
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 15:35:35 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:35:35 +0000
Subject: [New-bugs-announce] [issue23820] test_importlib fails under -O
Message-ID: <1427808935.25.0.609166440001.issue23820@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
FAIL: test_cached_sourceless (test.test_importlib.test_spec.Frozen_ModuleSpecTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_importlib/test_spec.py", line 224, in test_cached_sourceless
    self.assertEqual(self.loc_spec.cached, 'spam.pyc')
AssertionError: None != 'spam.pyc'

----------
assignee: brett.cannon
components: Tests
messages: 239705
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importlib fails under -O
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 15:38:14 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:38:14 +0000
Subject: [New-bugs-announce] [issue23821] test_pdb fails under -O
Message-ID: <1427809094.04.0.0519767176067.issue23821@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Tests
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pdb fails under -O
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 15:39:13 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:39:13 +0000
Subject: [New-bugs-announce] [issue23822] test_py_compile fails under -O
Message-ID: <1427809153.77.0.260576385757.issue23822@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
FAIL: test_double_dot_no_clobber (__main__.PyCompileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_py_compile.py", line 115, in test_double_dot_no_clobber
    'foo.bar.{}.pyc'.format(sys.implementation.cache_tag)))
AssertionError: '__pycache__/foo.bar.cpython-35.pyo' != '__pycache__/foo.bar.cpython-35.pyc'
- __pycache__/foo.bar.cpython-35.pyo
?                                  ^
+ __pycache__/foo.bar.cpython-35.pyc
?

----------
assignee: brett.cannon
components: Tests
messages: 239707
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_py_compile fails under -O
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 15:56:02 2015
From: report at bugs.python.org (rschwieb)
Date: Tue, 31 Mar 2015 13:56:02 +0000
Subject: [New-bugs-announce] [issue23823] "Generalization" misused in deque
	docs
Message-ID: <1427810162.43.0.413466648837.issue23823@psf.upfronthosting.co.za>


New submission from rschwieb:

This sentence in the deque docs (https://docs.python.org/2/library/collections.html#collections.deque) is not accurate: 

"Deques are a generalization of stacks and queues ..."

Deques are a _specialization_ of stacks and queues. Every deque is-a stack and is-a queue, but saying that "deques generalize stacks and queues" reverses this relationship.

On the surface it might seem minor, but I think it's worth correcting in this case since the "is-a" relationship is so fundamental in computer science. Besides, I'd like to think Python's awesome documentation is above using words to mean the opposite of what they mean :)

----------
assignee: docs at python
components: Documentation
messages: 239710
nosy: docs at python, rschwieb
priority: normal
severity: normal
status: open
title: "Generalization" misused in deque docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Mar 31 16:01:23 2015
From: report at bugs.python.org (Jethro)
Date: Tue, 31 Mar 2015 14:01:23 +0000
Subject: [New-bugs-announce] [issue23824] in-place addition of a shadowed
	class field
Message-ID: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za>


New submission from Jethro:

Look at this simple code:

    class A:
	tot = 0
	def __init__(self, a):
		self.tot += a

    x = A(3)
    print(x.tot, A.tot)

Result from print: 

    3 0

What the interpreter did was that it first resolved self.tot to be the class field tot, which resolves to 0, then it created an instance field tot to hold the result 3.

This is not correct, as one single self.tot meant two different things. Two ways to fix this: 

1. report a name undefined error (interpret self.tot as instance field)

2. increase A.tot (interpret self.tot as class field)

Clearly 1 seems more naturally to Python, even though I wished python could disallow a class field to be shadowed by instance field, which seems quite a reasonable thing to do.

----------
components: Interpreter Core
messages: 239714
nosy: jethro
priority: normal
severity: normal
status: open
title: in-place addition of a shadowed class field
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 31 16:29:03 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 14:29:03 +0000
Subject: [New-bugs-announce] [issue23825] test_idle fails under -OO
Message-ID: <1427812143.77.0.00519422003594.issue23825@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: IDLE
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_idle fails under -OO
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 18:10:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 16:10:38 +0000
Subject: [New-bugs-announce] [issue23826] test_enum fails under -OO
Message-ID: <1427818238.81.0.788495836451.issue23826@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
FAIL: test_pydoc (__main__.TestStdLib)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_enum.py", line 1609, in test_pydoc
    self.assertEqual(result, expected_text)
AssertionError: 'Help[450 chars]n |  \n |  value\n |  \n |  ------------------[123 chars]rs__' != 'Help[450 chars]n |      The name of the Enum member.\n |  \n [394 chars]ing.'
Diff is 969 characters long. Set self.maxDiff to None to see it.

----------
components: Tests
messages: 239728
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_enum fails under -OO
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 18:52:44 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 16:52:44 +0000
Subject: [New-bugs-announce] [issue23827] test.test_multiprocessing_spawn
	fails under -Werror
Message-ID: <1427820764.77.0.00384265932855.issue23827@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
FAIL: test_sys_exit (__main__.WithProcessesTestSubclassingProcess)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/_test_multiprocessing.py", line 483, in test_sys_exit
    self.assertEqual(f.read().rstrip(), str(reason))
AssertionError: "[1, 2, 3]\nException ignored in: <_io.Fi[136 chars]-8'>" != '[1, 2, 3]'
- [1, 2, 3]
?          -
+ [1, 2, 3]- Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True>
- ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>

----------
components: Tests
messages: 239731
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test.test_multiprocessing_spawn fails under -Werror
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 18:55:36 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 16:55:36 +0000
Subject: [New-bugs-announce] [issue23828] test_socket fails under -Werror
Message-ID: <1427820936.86.0.258398348531.issue23828@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
ERROR: testCmsgTruncLen0 (__main__.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 2956, in testCmsgTruncLen0
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 2937, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 1921, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
RuntimeWarning: received malformed or improperly-truncated ancillary data

----------
components: Tests
messages: 239732
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_socket fails under -Werror
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 18:56:21 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 16:56:21 +0000
Subject: [New-bugs-announce] [issue23829] test_warnings fails under -Werror
Message-ID: <1427820981.19.0.491329560672.issue23829@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
ERROR: test_warning_classes (__main__.CWarnTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_warnings.py", line 460, in test_warning_classes
    self.module.warn('good warning category', MyWarningClass)
WarnTests.test_warning_classes.<locals>.MyWarningClass: good warning category

----------
components: Tests
messages: 239734
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_warnings fails under -Werror
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 31 21:01:24 2015
From: report at bugs.python.org (Neale Ferguson)
Date: Tue, 31 Mar 2015 19:01:24 +0000
Subject: [New-bugs-announce] [issue23830] Add AF_IUCV support to sockets
Message-ID: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za>


New submission from Neale Ferguson:

IUCV is a hypervisor mediated communications method for z/VM guest virtual machines. Linux on z Systems (aka s390x) has supported this via the use of AF_IUCV sockets for many years (added to kernel Feb 2007). This suggested patch adds support to Python 2.7.9 for this socket type. I have built Python on both s390x and x86_64: both build cleanly and the test added to test_socket.py runs cleanly on s390x and is skipped on other platforms.

----------
components: Library (Lib)
files: af_iucv.patch
keywords: patch
messages: 239743
nosy: neale
priority: normal
severity: normal
status: open
title: Add AF_IUCV support to sockets
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file38765/af_iucv.patch

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

From report at bugs.python.org  Tue Mar 31 22:15:32 2015
From: report at bugs.python.org (mps)
Date: Tue, 31 Mar 2015 20:15:32 +0000
Subject: [New-bugs-announce] [issue23831] tkinter canvas lacks of moveto
	method.
Message-ID: <1427832932.11.0.38662420535.issue23831@psf.upfronthosting.co.za>


New submission from mps:

I apologize if it has already been reported but I was unable to find similar issue reported using "search".

Maybe just add:
    def moveto(self, tagOrId, xPos, yPos):
        """Move the items given by tagOrId in the canvas coordinate  
        space so that the first coordinate pair of the bottommost 
        item with tag tagOrId is located at position (xPos,yPos). 
        xPos and yPos may be the empty string, in which case the        
        corresponding coordinate will be unchanged. All items matching
        tagOrId remain in the same positions relative to each other.    
        This command returns an empty string. 
        """
        return self.tk.call(self._w, 'moveto', tagOrId, xPos, yPos)

----------
components: Tkinter
messages: 239745
nosy: mps
priority: normal
severity: normal
status: open
title: tkinter canvas lacks of moveto method.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 31 22:35:12 2015
From: report at bugs.python.org (Gerrit Holl)
Date: Tue, 31 Mar 2015 20:35:12 +0000
Subject: [New-bugs-announce] [issue23832] pdb's `longlist` shows only
	decorator if that one	contains a lambda
Message-ID: <1427834112.73.0.627625379595.issue23832@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

When a decorater contains a `lambda` declaration, using the pdb command `longlist` will show only the definition of the decorator.  The definition of the function itself is not shown:


cat mini.py

#!/usr/bin/python3.4

def foo(x, y=None):
    return x

@foo(foo, lambda a:a)
def spam():
    0+0
    1+1
    1/0

spam()
$ python3.4 -mpdb mini.py                                                                                                                                               
> /tmp/mini.py(3)<module>()
-> def foo(x, y=None):
(Pdb) cont
Traceback (most recent call last):
  File "/usr/lib64/python3.4/pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib64/python3.4/pdb.py", line 1542, in _runscript
    self.run(statement)
  File "/usr/lib64/python3.4/bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/tmp/mini.py", line 3, in <module>
    def foo(x, y=None):
  File "/tmp/mini.py", line 10, in spam
    1/0
ZeroDivisionError: division by zero
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /tmp/mini.py(10)spam()
-> 1/0
(Pdb) longlist
  6     @foo(foo, lambda a:a)
(Pdb) 


The last line illustrates the problem.  `longlist` should show the definition of `spam`, not just the decorator.

----------
messages: 239749
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: pdb's `longlist` shows only decorator if that one contains a lambda
type: behavior
versions: Python 3.4

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