From report at bugs.python.org  Tue Apr  1 01:09:06 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 31 Mar 2014 23:09:06 +0000
Subject: [New-bugs-announce] [issue21118] str.translate is absurdly slow in
	majority of use cases	(takes 3x to 10x longer than similar
	functions)
Message-ID: <1396307346.31.0.221715925478.issue21118@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

String translation functions, at least in other languages, are typically a performance optimization when you *really* need the speed. In exchange for paying the memory cost and one-time work to create a translation table, you get much faster 1 to 1 and deletion of characters.

In Python 3, str.translate is usually a performance pessimization, not optimization. While it does a few things similar functions (e.g. str.replace) can't do, like perform a translation where the inputs and outputs overlap ('abc' -> 'bca' wouldn't work with str.replace), and it handles the full Unicode range ('\u0f01\u0f02' -> '\u0f03\u0f04' can't be done by encoding, using bytes.translate, then decoding again), when another approach is available, str.translate is almost always the slowest.

While it may not be practical to make the general case for str.translate match the performance of bytes.translate, it should at least be possible to improve upon it in many common cases.

My timing data (see attached file for how it was produced):

    $ python.exe translate_timing.py

    Testing 1-1 translation
    bytes.translate 0.05638575777521804
    str.translate 2.9639258423152874
    str.translate from bytes trans 1.6307581351818357
    str.encode->bytes.translate->bytes.decode 0.09472254504689914
    str.replace 0.2507745649580393

    Testing deletion
    bytes.translate 0.05367317344084199
    str.translate 2.360142494240577
    str.encode->bytes.translate->bytes.decode 0.0629345277274993
    str.replace 0.31173443413690904

    Testing enlarging translations
    str.translate 2.33631417640283
    str.replace 0.41248187325160757

Obviously, this is somewhat contrived, but it illustrates my point that the common case (ASCII or latin-1 strings) are far too slow. In every case, str.translate loses to every competitor, including itself when you pass it a translation table produced by bytes.translate, and including the case where a pure Python function calls str.replace over and over.

A large part of the problem is clearly the use of a dict to perform lookups; as seen in the 1-1 test case, str.translate using the result of str.maketrans takes nearly twice as long as when it uses the result of a similar bytes.maketrans. While I have not profiled the code, I suspect the remainder is a combination of the overhead involving conversion of Py_UCS4 to PyLong for general purpose lookup, handling the multiple ways the translation target can be expressed (a Unicode ordinal or a str object), and the code that checks for and resizes the output buffer each time.

I have ideas for a solution involving a special purpose translation object to be produced by str.maketrans for cases where the translation table will produce an equal or smaller string (all to values are None or length 1 or lower strings), and the from values all fall in a small enough range (say, 1024) to avoid excessive memory usage from large translation table objects. But I'd like to know whether such a change (including modifying the behavior of str.maketrans to produce an unspecified mapping object, instead of the current dict) is desired, acceptable, what have you.

----------
components: Unicode
files: translate_timing.py
messages: 215283
nosy: ezio.melotti, haypo, josh.rosenberg
priority: normal
severity: normal
status: open
title: str.translate is absurdly slow in majority of use cases (takes 3x to 10x longer than similar functions)
type: performance
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34688/translate_timing.py

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

From report at bugs.python.org  Tue Apr  1 05:04:44 2014
From: report at bugs.python.org (Lars Andersson)
Date: Tue, 01 Apr 2014 03:04:44 +0000
Subject: [New-bugs-announce] [issue21119] asyncio create_connection resource
	warning
Message-ID: <1396321484.68.0.174945090803.issue21119@psf.upfronthosting.co.za>


New submission from Lars Andersson:

The attached code generates an unclosed socket ResourceWarning when timing out trying to connect to an unreachable address.

Probably not terribly serious, but in my case, it generates distracting warnings during unit testing.

I have looked briefly at the asyncio code but it's not immediately obvious to me how to fix it.

----------
components: Library (Lib)
files: timeout.py
messages: 215291
nosy: landersson
priority: normal
severity: normal
status: open
title: asyncio create_connection resource warning
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file34689/timeout.py

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

From report at bugs.python.org  Tue Apr  1 10:10:21 2014
From: report at bugs.python.org (Andrey)
Date: Tue, 01 Apr 2014 08:10:21 +0000
Subject: [New-bugs-announce] [issue21120] PyArena type is used in headers
	from the limited API
Message-ID: <1396339821.73.0.473299529971.issue21120@psf.upfronthosting.co.za>


New submission from Andrey:

Hi all,

The PyArena data type is defined in the pyarena.h under the #ifndef Py_LIMITED_API statement, so it's not included in the limited api. But this type is used in Python-ast.h, ast.h and asdl.h headers that included in the limited api, because they don't contain any checks for Py_LIMITED_API.

May be all these header files (Python-ast.h, ast.h, asdl.h) should begin with "#ifndef Py_LIMITED_API" (excluded from the limited api)?

Thanks.

----------
components: Library (Lib)
messages: 215300
nosy: aponomarenko
priority: normal
severity: normal
status: open
title: PyArena type is used in headers from the limited API
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Tue Apr  1 12:42:13 2014
From: report at bugs.python.org (nils)
Date: Tue, 01 Apr 2014 10:42:13 +0000
Subject: [New-bugs-announce] [issue21121]
	-Werror=declaration-after-statement is added even
	for	extension modules through setup.py
Message-ID: <1396348933.92.0.0275278232722.issue21121@psf.upfronthosting.co.za>


New submission from nils:

I got an error while rebuilding a module for 3.4. This was a ISO C90 error but setup.py explicitely adds "-std=c99" to the gcc parameters, and indeed it is used. 

fifo.h:114:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
uint32_t ofs = fifo->write_count - fifo->write_offset; 

However, Py 3.4 seems to add -Werror=declaration-after-statement also for extension modules. This should not happe (said also Yhg1s in #python).

Attached is a file that shows the setup.py and also the error log.

----------
components: Build, Distutils, Extension Modules
files: pybug.txt
messages: 215305
nosy: dstufft, eric.araujo, nilsge
priority: normal
severity: normal
status: open
title: -Werror=declaration-after-statement is added even for extension modules through setup.py
versions: Python 3.4
Added file: http://bugs.python.org/file34692/pybug.txt

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

From report at bugs.python.org  Tue Apr  1 14:11:00 2014
From: report at bugs.python.org (Jonas Wagner)
Date: Tue, 01 Apr 2014 12:11:00 +0000
Subject: [New-bugs-announce] [issue21122] CPython fails to build modules
	with LLVM LTO on Mac OS
Message-ID: <1396354260.96.0.514432416417.issue21122@psf.upfronthosting.co.za>


New submission from Jonas Wagner:

CPython fails to build with LLVM's link-time optimization (LTO) in Mac OS. Very similar commands work on Linux.

I'm currently configuring CPython as follows:

on Linux:
RANLIB="ar -s --plugin=/path/to/llvm/lib/LLVMgold.so" CC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto" ./configure

on Mac OS:
CC=/path/to/llvm/bin/clang CXX=/path/to/llvm/bin/clang++ CFLAGS="-g -flto" LDFLAGS="-flto" ./configure

The RANLIB variable should not be needed on Mac, because its toolchain does not need a GOLD plugin.

On Linux, the above builds correctly and passes most of the test suite. On Mac, I receive the following error (similar for other extensions):

building '_scproxy' extension
/usr/bin/clang -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -flto -I../cpython/Include -I. -I/usr/local/include -I../cpython/Include -I../cpython-lto-build -c ../cpython/Modules/_scproxy.c -o build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o
/usr/bin/clang -bundle -undefined dynamic_lookup -flto build/temp.macosx-10.9-x86_64-3.5/path/to/cpython/Modules/_scproxy.o -L/usr/local/lib -o build/lib.macosx-10.9-x86_64-3.5/_scproxy.so -framework SystemConfiguration -framework CoreFoundation
*** WARNING: renaming "_scproxy" since importing it failed: dlopen(build/lib.macosx-10.9-x86_64-3.5/_scproxy.so, 2): Symbol not found: __Py_NoneStruct
  Referenced from: build/lib.macosx-10.9-x86_64-3.5/_scproxy.so
  Expected in: flat namespace
 in build/lib.macosx-10.9-x86_64-3.5/_scproxy.so

----------
components: Extension Modules
messages: 215307
nosy: Sjlver
priority: normal
severity: normal
status: open
title: CPython fails to build modules with LLVM LTO on Mac OS
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Tue Apr  1 16:52:27 2014
From: report at bugs.python.org (dellair jie)
Date: Tue, 01 Apr 2014 14:52:27 +0000
Subject: [New-bugs-announce] [issue21123] Compilation error on _struct
	module on Python 3.4
Message-ID: <1396363947.51.0.530971318271.issue21123@psf.upfronthosting.co.za>


New submission from dellair jie:

Dear all,

I am compiling Python 3.4 on Cygwin 1.7.17.

The following has been done in order to reach the point where _struct module failed.
> A clean Python 3.4
> Applied patches:
  cygwin_si_band.patch in Issue21085
  0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch in issue13756
  0019-MINGW-export-_PyNode_SizeOf-as-PyAPI-for-parser-modu.patch in issue186373
> configure + make

The issue happened during make:
building '_struct' extension
gcc -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/cygdrive/c/temp/Python-3.4.0/Include -I/cygdrive/c/temp/Python-3.4.0 -c /cygdrive/c/temp/Python-3.4.0/Modules/_struct.c -o build/temp.cygwin-1.7.17-i686-3.4/cygdrive/c/temp/Python-3.4.0/Modules/_struct.o
/cygdrive/c/temp/Python-3.4.0/Modules/_struct.c:1630:5: error: initializer element is not constant
/cygdrive/c/temp/Python-3.4.0/Modules/_struct.c:1630:5: error: (near initialization for ?unpackiter_type.ob_base.ob_base.ob_type?)

Please feel free to find the build.log and the output of _struct.c.txt (gcc with -dD -E -DPy_BUILD_core) for more information.

Thanks in advance,
Br,
Dellair

----------
files: _struct.c.txt
messages: 215320
nosy: dellair.jie
priority: normal
severity: normal
status: open
title: Compilation error on _struct module on Python 3.4
versions: Python 3.4
Added file: http://bugs.python.org/file34694/_struct.c.txt

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

From report at bugs.python.org  Tue Apr  1 16:52:31 2014
From: report at bugs.python.org (dellair jie)
Date: Tue, 01 Apr 2014 14:52:31 +0000
Subject: [New-bugs-announce] [issue21124] Compilation error on _struct
	module on Python 3.4
Message-ID: <1396363951.96.0.324613047949.issue21124@psf.upfronthosting.co.za>


New submission from dellair jie:

Dear all,

I am compiling Python 3.4 on Cygwin 1.7.17.

The following has been done in order to reach the point where _struct module failed.
> A clean Python 3.4
> Applied patches:
  cygwin_si_band.patch in Issue21085
  0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch in issue13756
  0019-MINGW-export-_PyNode_SizeOf-as-PyAPI-for-parser-modu.patch in issue186373
> configure + make

The issue happened during make:
building '_struct' extension
gcc -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/cygdrive/c/temp/Python-3.4.0/Include -I/cygdrive/c/temp/Python-3.4.0 -c /cygdrive/c/temp/Python-3.4.0/Modules/_struct.c -o build/temp.cygwin-1.7.17-i686-3.4/cygdrive/c/temp/Python-3.4.0/Modules/_struct.o
/cygdrive/c/temp/Python-3.4.0/Modules/_struct.c:1630:5: error: initializer element is not constant
/cygdrive/c/temp/Python-3.4.0/Modules/_struct.c:1630:5: error: (near initialization for ?unpackiter_type.ob_base.ob_base.ob_type?)

Please feel free to find the build.log and the output of _struct.c.txt (gcc with -dD -E -DPy_BUILD_core) for more information.

Thanks in advance,
Br,
Dellair

----------
files: _struct.c.txt
messages: 215321
nosy: dellair.jie
priority: normal
severity: normal
status: open
title: Compilation error on _struct module on Python 3.4
versions: Python 3.4
Added file: http://bugs.python.org/file34695/_struct.c.txt

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

From report at bugs.python.org  Tue Apr  1 17:36:16 2014
From: report at bugs.python.org (Glenn Maynard)
Date: Tue, 01 Apr 2014 15:36:16 +0000
Subject: [New-bugs-announce] [issue21125] traceback.extract_tb says
	"quadruple" when it means	"tuple"
Message-ID: <1396366576.76.0.132198557562.issue21125@psf.upfronthosting.co.za>


New submission from Glenn Maynard:

https://docs.python.org/2/library/traceback.html

"A ?pre-processed? stack trace entry is a quadruple (filename, line number, function name, text) representing the information that is usually printed for a stack trace."

There's no such thing as a "quadruple".  This should be "tuple".

----------
assignee: docs at python
components: Documentation
messages: 215326
nosy: Glenn.Maynard, docs at python
priority: normal
severity: normal
status: open
title: traceback.extract_tb says "quadruple" when it means "tuple"

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

From report at bugs.python.org  Tue Apr  1 20:12:24 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 01 Apr 2014 18:12:24 +0000
Subject: [New-bugs-announce] [issue21126] Integrate
	doctest.run_docstring_examples() with unittest
Message-ID: <1396375944.72.0.495252715824.issue21126@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In order to run a certain function via doctest run_docstring_examples() can be used:
http://stackoverflow.com/a/10081450/376587
The function returns None though.
I am in a situation where I want to run a single function's doctest from a unittest and want to "fail" in case the doctest fails.
Patch in attachment makes run_docstring_examples() return a list of TestResults instances so that you can do:

class TestFoo(unittest.TestCase):

    def test_foo(self):
        ret = doctest.run_docstring_examples(somefun, globals())
        self.assertFalse(ret[0].failed)

Patch lacks tests because run_docstring_examples() is currently not tested. I will open a separate ticket for that.

----------
files: doctest.patch
keywords: patch
messages: 215335
nosy: giampaolo.rodola, tim.peters
priority: normal
severity: normal
status: open
title: Integrate doctest.run_docstring_examples() with unittest
versions: Python 3.5
Added file: http://bugs.python.org/file34697/doctest.patch

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

From report at bugs.python.org  Wed Apr  2 00:08:28 2014
From: report at bugs.python.org (Antony Lee)
Date: Tue, 01 Apr 2014 22:08:28 +0000
Subject: [New-bugs-announce] [issue21127] Path objects cannot be constructed
	from str subclasses
Message-ID: <1396390108.81.0.285327356985.issue21127@psf.upfronthosting.co.za>


New submission from Antony Lee:

Trying to construct a Path object from a str subclass, e.g.

class S(str): pass
Path(S("foo"))

fails because the subclass cannot be interned.  I think that the interning should simply be removed for non-exactly-str arguments (it is only here for performance reasons, right?), or at least the error should be more explicit (note, in particular, that there is no error if one tries 'Path(S("foo/bar"))' instead, which only confuses the matter more).

In practice, I found out this via numpy, which provides its own str subclass, numpy.str_.

----------
components: Library (Lib)
messages: 215342
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Path objects cannot be constructed from str subclasses
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr  2 00:22:57 2014
From: report at bugs.python.org (mattip)
Date: Tue, 01 Apr 2014 22:22:57 +0000
Subject: [New-bugs-announce] [issue21128] testing stdlib and compatibility
	with pypy
Message-ID: <1396390977.66.0.122853817502.issue21128@psf.upfronthosting.co.za>


New submission from mattip:

In continuation of issue 20887, this patch closes and removes all temp files created while running regression tests for stdlib 2.7.6 on win32 and pypy. Note that a gc.collect was required to release the closed files in test_argparse, as well as making them all rw.

----------
components: Tests
files: patch
messages: 215343
nosy: mattip
priority: normal
severity: normal
status: open
title: testing stdlib and compatibility with pypy
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34698/patch

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

From report at bugs.python.org  Wed Apr  2 05:07:21 2014
From: report at bugs.python.org (Mayank Gupta)
Date: Wed, 02 Apr 2014 03:07:21 +0000
Subject: [New-bugs-announce] [issue21129] Segfault in python interpreter
Message-ID: <1396408041.53.0.971896348675.issue21129@psf.upfronthosting.co.za>


New submission from Mayank Gupta:

If I open the python interpreter:
$ python
Then type
def to_hex(i):
  result = hex(i)[2:]

My interpreter segfaults (EXC_BAD_ACCESS).
Here's a backtrace from lldb:
(lldb) bt
* thread #1: tid = 0x152e7f, 0x00000001002eff97 readline.so`call_readline + 647, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001002eff97 readline.so`call_readline + 647
    frame #1: 0x0000000100008852 Python`PyOS_Readline + 274
    frame #2: 0x000000010000a0a8 Python`tok_nextc + 104
    frame #3: 0x000000010000a853 Python`PyTokenizer_Get + 147
    frame #4: 0x000000010000544a Python`parsetok + 218
    frame #5: 0x00000001000e7722 Python`PyParser_ASTFromFile + 146
    frame #6: 0x00000001000e8983 Python`PyRun_InteractiveOneFlags + 243
    frame #7: 0x00000001000e8c6e Python`PyRun_InteractiveLoopFlags + 78
    frame #8: 0x00000001000e9451 Python`PyRun_AnyFileExFlags + 161
    frame #9: 0x00000001000ffc9f Python`Py_Main + 2111
    frame #10: 0x0000000100000f14 Python

I am using cpython 2.7.3.

----------
components: Interpreter Core
messages: 215351
nosy: mayank
priority: normal
severity: normal
status: open
title: Segfault in python interpreter
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  2 09:57:52 2014
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 02 Apr 2014 07:57:52 +0000
Subject: [New-bugs-announce] [issue21130] equivalent functools.partial
	instances should compare	equal
Message-ID: <1396425472.15.0.80240218298.issue21130@psf.upfronthosting.co.za>


New submission from Thomas Heller:

I think that 'equivalent' functools.partial objects should compare equal, so the following snippet SHOULD print True:

>>> import functools
>>> f = lambda x: x
>>> a = functools.partial(f, 42)
>>> b = functools.partial(f, 42)
>>> a == b
False
>>>

----------
components: Library (Lib)
messages: 215363
nosy: theller
priority: normal
severity: normal
status: open
title: equivalent functools.partial instances should compare equal
type: behavior

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

From report at bugs.python.org  Wed Apr  2 11:17:18 2014
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 02 Apr 2014 09:17:18 +0000
Subject: [New-bugs-announce] [issue21131]
	test_faulthandler.test_register_chain fails on 64bit	ppc/arm
	with kernel >= 3.10
Message-ID: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

test_faulthandler.test_register_chain fails on some 64bit architectures (arm8, ppc64) with kernel >= 3.10:

======================================================================
FAIL: test_register_chain (__main__.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.3.2/Lib/test/test_faulthandler.py", line 588, in test_register_chain
    self.check_register(chain=True)
  File "/builddir/build/BUILD/Python-3.3.2/Lib/test/test_faulthandler.py", line 572, in check_register
    self.assertEqual(exitcode, 0)
AssertionError: -11 != 0

I created a minimal reproducer (reproduces the issue on 3.3, 3.4 and dev) of this segfault (attached). When run with GC assertions turned on, Python fails with:

python: /builddir/build/BUILD/Python-3.3.2/Modules/gcmodule.c:332: update_refs: Assertion `gc->gc.gc_refs == (-3)\' failed.

We experienced this issue when building Python 3.3 on Fedora's arm8 builder [1], it seems that opensuse have experienced the same failure on ppc64 [2] and ubuntu has a similar issue in their 64bit arm builds [3].

It seems that this may be caused by a change in kernel, since it's only reproducible on kernel >= 3.10. A nice explanation of what goes on and how the problem can be narrowed down is at the opensuse bug report [4], this is basically where I got stuck with this problem, too.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1045193
[2] https://bugzilla.novell.com/show_bug.cgi?id=831629
[3] https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1264354
[4] https://bugzilla.novell.com/show_bug.cgi?id=831629#c15

----------
components: Tests
files: test_register_chain_segfault_reproducer.py
messages: 215365
nosy: bkabrda
priority: normal
severity: normal
status: open
title: test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34699/test_register_chain_segfault_reproducer.py

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

From report at bugs.python.org  Wed Apr  2 14:14:13 2014
From: report at bugs.python.org (David Woakes)
Date: Wed, 02 Apr 2014 12:14:13 +0000
Subject: [New-bugs-announce] [issue21132] Failure to import win32api
Message-ID: <1396440853.53.0.482865580463.issue21132@psf.upfronthosting.co.za>


New submission from David Woakes:

I've seen issue 21050 and tried a complete uninstall, delete c:\python34 and install of python 3.4.

I can't get win32api to load unless I copy pythoncom34.dll and psywintypes34.dll to C:\Python34\Lib\site-packages\win32 from C:\Python34\Lib\site-packages\pywin32_system32.

Here's output from a python -v session:

>>> import win32api
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 2214, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2203, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1191, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1161, in _load_backward_compatible
  File "<frozen importlib._bootstrap>", line 539, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1692, in load_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
ImportError: DLL load failed: The specified module could not be found.
>>> import pdb; pdb.pm()
# C:\Python34\lib\__pycache__\pdb.cpython-34.pyc matches C:\Python34\lib\pdb.py
# code object from 'C:\\Python34\\lib\\__pycache__\\pdb.cpython-34.pyc'
# C:\Python34\lib\__pycache__\re.cpython-34.pyc matches C:\Python34\lib\re.py
# code object from 'C:\\Python34\\lib\\__pycache__\\re.cpython-34.pyc'
# C:\Python34\lib\__pycache__\sre_compile.cpython-34.pyc matches C:\Python34\lib\sre_compile.py
# code object from 'C:\\Python34\\lib\\__pycache__\\sre_compile.cpython-34.pyc'
# C:\Python34\lib\__pycache__\sre_parse.cpython-34.pyc matches C:\Python34\lib\sre_parse.py
# code object from 'C:\\Python34\\lib\\__pycache__\\sre_parse.cpython-34.pyc'
# C:\Python34\lib\__pycache__\sre_constants.cpython-34.pyc matches C:\Python34\lib\sre_constants.py
# code object from 'C:\\Python34\\lib\\__pycache__\\sre_constants.cpython-34.pyc'
import 'sre_constants' # <_frozen_importlib.SourceFileLoader object at 0x02EB21B0>
import 'sre_parse' # <_frozen_importlib.SourceFileLoader object at 0x02EAE4B0>
import 'sre_compile' # <_frozen_importlib.SourceFileLoader object at 0x027D4BF0>
# C:\Python34\lib\__pycache__\copyreg.cpython-34.pyc matches C:\Python34\lib\copyreg.py
# code object from 'C:\\Python34\\lib\\__pycache__\\copyreg.cpython-34.pyc'
import 'copyreg' # <_frozen_importlib.SourceFileLoader object at 0x02EB23B0>
import 're' # <_frozen_importlib.SourceFileLoader object at 0x027D44D0>
# C:\Python34\lib\__pycache__\cmd.cpython-34.pyc matches C:\Python34\lib\cmd.py
# code object from 'C:\\Python34\\lib\\__pycache__\\cmd.cpython-34.pyc'
# C:\Python34\lib\__pycache__\string.cpython-34.pyc matches C:\Python34\lib\string.py
# code object from 'C:\\Python34\\lib\\__pycache__\\string.cpython-34.pyc'
import 'string' # <_frozen_importlib.SourceFileLoader object at 0x02EB2CB0>
import 'cmd' # <_frozen_importlib.SourceFileLoader object at 0x02EAEDF0>
# C:\Python34\lib\__pycache__\bdb.cpython-34.pyc matches C:\Python34\lib\bdb.py
# code object from 'C:\\Python34\\lib\\__pycache__\\bdb.cpython-34.pyc'
# C:\Python34\lib\__pycache__\fnmatch.cpython-34.pyc matches C:\Python34\lib\fnmatch.py
# code object from 'C:\\Python34\\lib\\__pycache__\\fnmatch.cpython-34.pyc'
# C:\Python34\lib\__pycache__\posixpath.cpython-34.pyc matches C:\Python34\lib\posixpath.py
# code object from 'C:\\Python34\\lib\\__pycache__\\posixpath.cpython-34.pyc'
import 'posixpath' # <_frozen_importlib.SourceFileLoader object at 0x02EBBFD0>
import 'fnmatch' # <_frozen_importlib.SourceFileLoader object at 0x02EBBD30>
# C:\Python34\lib\__pycache__\inspect.cpython-34.pyc matches C:\Python34\lib\inspect.py
# code object from 'C:\\Python34\\lib\\__pycache__\\inspect.cpython-34.pyc'
# C:\Python34\lib\__pycache__\ast.cpython-34.pyc matches C:\Python34\lib\ast.py
# code object from 'C:\\Python34\\lib\\__pycache__\\ast.cpython-34.pyc'
import 'ast' # <_frozen_importlib.SourceFileLoader object at 0x02ED7D30>
# C:\Python34\lib\importlib\__pycache__\__init__.cpython-34.pyc matches C:\Python34\lib\importlib\__init__.py
# code object from 'C:\\Python34\\lib\\importlib\\__pycache__\\__init__.cpython-34.pyc'
# C:\Python34\lib\__pycache__\warnings.cpython-34.pyc matches C:\Python34\lib\warnings.py
# code object from 'C:\\Python34\\lib\\__pycache__\\warnings.cpython-34.pyc'
import 'warnings' # <_frozen_importlib.SourceFileLoader object at 0x02EF94B0>
import 'importlib' # <_frozen_importlib.SourceFileLoader object at 0x02EF92D0>
# C:\Python34\lib\importlib\__pycache__\machinery.cpython-34.pyc matches C:\Python34\lib\importlib\machinery.py
# code object from 'C:\\Python34\\lib\\importlib\\__pycache__\\machinery.cpython-34.pyc'
import 'importlib.machinery' # <_frozen_importlib.SourceFileLoader object at 0x02EF9410>
# C:\Python34\lib\__pycache__\linecache.cpython-34.pyc matches C:\Python34\lib\linecache.py
# code object from 'C:\\Python34\\lib\\__pycache__\\linecache.cpython-34.pyc'
# C:\Python34\lib\__pycache__\tokenize.cpython-34.pyc matches C:\Python34\lib\tokenize.py
# code object from 'C:\\Python34\\lib\\__pycache__\\tokenize.cpython-34.pyc'
# C:\Python34\lib\__pycache__\token.cpython-34.pyc matches C:\Python34\lib\token.py
# code object from 'C:\\Python34\\lib\\__pycache__\\token.cpython-34.pyc'
import 'token' # <_frozen_importlib.SourceFileLoader object at 0x02F066D0>
import 'tokenize' # <_frozen_importlib.SourceFileLoader object at 0x02EF9C90>
import 'linecache' # <_frozen_importlib.SourceFileLoader object at 0x02EF9B70>
# C:\Python34\lib\__pycache__\dis.cpython-34.pyc matches C:\Python34\lib\dis.py
# code object from 'C:\\Python34\\lib\\__pycache__\\dis.cpython-34.pyc'
# C:\Python34\lib\__pycache__\opcode.cpython-34.pyc matches C:\Python34\lib\opcode.py
# code object from 'C:\\Python34\\lib\\__pycache__\\opcode.cpython-34.pyc'
import 'opcode' # <_frozen_importlib.SourceFileLoader object at 0x02F142B0>
import 'dis' # <_frozen_importlib.SourceFileLoader object at 0x02F01090>
import 'inspect' # <_frozen_importlib.SourceFileLoader object at 0x02EC8550>
import 'bdb' # <_frozen_importlib.SourceFileLoader object at 0x02EB2C10>
# C:\Python34\lib\__pycache__\code.cpython-34.pyc matches C:\Python34\lib\code.py
# code object from 'C:\\Python34\\lib\\__pycache__\\code.cpython-34.pyc'
# C:\Python34\lib\__pycache__\traceback.cpython-34.pyc matches C:\Python34\lib\traceback.py
# code object from 'C:\\Python34\\lib\\__pycache__\\traceback.cpython-34.pyc'
import 'traceback' # <_frozen_importlib.SourceFileLoader object at 0x02F2FF70>
# C:\Python34\lib\__pycache__\codeop.cpython-34.pyc matches C:\Python34\lib\codeop.py
# code object from 'C:\\Python34\\lib\\__pycache__\\codeop.cpython-34.pyc'
# C:\Python34\lib\__pycache__\__future__.cpython-34.pyc matches C:\Python34\lib\__future__.py
# code object from 'C:\\Python34\\lib\\__pycache__\\__future__.cpython-34.pyc'
import '__future__' # <_frozen_importlib.SourceFileLoader object at 0x02F24770>
import 'codeop' # <_frozen_importlib.SourceFileLoader object at 0x02F24450>
import 'code' # <_frozen_importlib.SourceFileLoader object at 0x02F2FB70>
# C:\Python34\lib\__pycache__\glob.cpython-34.pyc matches C:\Python34\lib\glob.py
# code object from 'C:\\Python34\\lib\\__pycache__\\glob.cpython-34.pyc'
import 'glob' # <_frozen_importlib.SourceFileLoader object at 0x02F24690>
# C:\Python34\lib\__pycache__\pprint.cpython-34.pyc matches C:\Python34\lib\pprint.py
# code object from 'C:\\Python34\\lib\\__pycache__\\pprint.cpython-34.pyc'
import 'pprint' # <_frozen_importlib.SourceFileLoader object at 0x02F24B90>
import 'pdb' # <_frozen_importlib.SourceFileLoader object at 0x027C44D0>
> <frozen importlib._bootstrap>(321)_call_with_frames_removed()
(Pdb) locals()
{'args': ('win32api', 'C:\\Python34\\lib\\site-packages\\win32\\win32api.pyd'), 'kwds': {}, 'f': <built-in function load_dynamic>}
(Pdb) q

----------
components: Interpreter Core
messages: 215378
nosy: woakesd
priority: normal
severity: normal
status: open
title: Failure to import win32api
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr  2 14:21:40 2014
From: report at bugs.python.org (the mulhern)
Date: Wed, 02 Apr 2014 12:21:40 +0000
Subject: [New-bugs-announce] [issue21133] unittest discover should allow
	option to run each	package separately
Message-ID: <1396441300.71.0.677176151152.issue21133@psf.upfronthosting.co.za>


New submission from the mulhern:

You can run "python -m unittest discover <some args>" and the unittests discovered by discover will be run. This is nice.

However, it is actually desirable to run each unittest package individually, rather than in the same interpreter instance. When run via discover, imports from previous unittests corrupt the namespace of subsequent unittests and lead to failures (usually if there are mock objects in previously imported unit tests) and successes (usually if some other test module has imported something that the current test module ought to import but does not) which are both erroneous.

discover should have some option to start the interpreter afresh for each unittest package or perhaps just clear all its imports.

----------
components: Library (Lib)
messages: 215380
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: unittest discover should allow option to run each package separately
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr  2 16:10:37 2014
From: report at bugs.python.org (Marek Kowalski)
Date: Wed, 02 Apr 2014 14:10:37 +0000
Subject: [New-bugs-announce] [issue21134] Segfault when stringifying
	UnicodeEncodeError (or	UnicodeDecodeError) created with __new__()
Message-ID: <1396447837.72.0.201261233456.issue21134@psf.upfronthosting.co.za>


New submission from Marek Kowalski:

I'm attaching a minimal script to reproduce. I tested only with 3.2 and 2.7 versions. Its possible that it has been fixed since 3.2.

----------
components: Unicode
files: segv.py
messages: 215384
nosy: Marek.Kowalski, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__()
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file34702/segv.py

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

From report at bugs.python.org  Wed Apr  2 22:03:45 2014
From: report at bugs.python.org (Eijebong)
Date: Wed, 02 Apr 2014 20:03:45 +0000
Subject: [New-bugs-announce] [issue21135] Remove useless _vb_pattern
	parameter in	cgi.valid_boundary
Message-ID: <1396469025.05.0.161523900352.issue21135@psf.upfronthosting.co.za>


New submission from Eijebong:

The parameter _vb_pattern parameter in cgi.valid_boundary has no reason to exist since it's forced to a value later.

----------
components: Library (Lib)
files: valid_boundary.patch
keywords: patch
messages: 215396
nosy: Eijebong
priority: normal
severity: normal
status: open
title: Remove useless _vb_pattern parameter in cgi.valid_boundary
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file34703/valid_boundary.patch

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

From report at bugs.python.org  Thu Apr  3 01:52:30 2014
From: report at bugs.python.org (William Ehlhardt)
Date: Wed, 02 Apr 2014 23:52:30 +0000
Subject: [New-bugs-announce] [issue21136] fractions.Fraction.__pow__ does
	unneeded renormalization
Message-ID: <1396482750.35.0.873465877702.issue21136@psf.upfronthosting.co.za>


New submission from William Ehlhardt:

The following Python runs unnecessarily slowly:

import fractions
fractions.Fraction(6249919, 6250000) ** 89993


The problem here is that Fraction.__pow__ constructs a new Fraction() to return, and Fraction.__new__ tries to gcd to normalize the numerator/denominator. The gcd is very, very slow, and more to the point, unnecessary; raising a normalized fraction to an integer power will always yield another normalized fraction.


fractions.Fraction.__pow__ should use this trick to make the code snippet above fast.

----------
components: Library (Lib)
messages: 215409
nosy: Orborde
priority: normal
severity: normal
status: open
title: fractions.Fraction.__pow__ does unneeded renormalization
type: performance
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Apr  3 03:19:02 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Apr 2014 01:19:02 +0000
Subject: [New-bugs-announce] [issue21137] Better repr for threading.Lock()
Message-ID: <1396487942.81.0.581020836184.issue21137@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

It is really nice to have the open/closed status in the __repr__ of file objects: 

  <open file 'data.txt', mode 'r' at 0x102c8ec90>
  <closed file 'data.txt', mode 'r' at 0x102c8ec90>

I would like to have the same for locks:

  <unlocked thread.lock object at 0x1002b1330>
  <locked thread.lock object at 0x1002b1330>

This would be nice in logs and tracebacks for example.

----------
components: Library (Lib)
keywords: easy
messages: 215413
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Better repr for threading.Lock()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Apr  3 03:39:20 2014
From: report at bugs.python.org (tanbro)
Date: Thu, 03 Apr 2014 01:39:20 +0000
Subject: [New-bugs-announce] [issue21138] mimetypes.MimeType
	UnicodeDecodeError
Message-ID: <1396489160.22.0.410580562036.issue21138@psf.upfronthosting.co.za>


New submission from tanbro:

when new a mimetypes.MimeType instance in a my Windows, whose default coding is mbcs, UnicdeDecodeError occurred.

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> from mimetypes import MimeTypes
>>> mt = MimeTypes()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Python27\lib\mimetypes.py", line 66, in __init__
    init()
  File "D:\Python27\lib\mimetypes.py", line 358, in init
    db.read_windows_registry()
  File "D:\Python27\lib\mimetypes.py", line 258, in read_windows_registry
    for subkeyname in enum_types(hkcr):
  File "D:\Python27\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc7 in position 8: ordinal
not in range(128)

i think this error was caused by the code in mimetypes.py's line 256

default_encoding = sys.getdefaultencoding() 

if change this line to:

default_encoding = sys.getfilesystemencoding()

such error will be resolved

----------
components: Library (Lib)
messages: 215414
nosy: tanbro
priority: normal
severity: normal
status: open
title: mimetypes.MimeType UnicodeDecodeError
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr  3 04:29:23 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Apr 2014 02:29:23 +0000
Subject: [New-bugs-announce] [issue21139] Idle: change default reformat
	width from 70 to 72
Message-ID: <1396492163.57.0.51526901235.issue21139@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

PEP 8 specifies a limit of 72 chars for flowing text (comments, multiline strings). The current default limit for Idle's Format / Reformat Paragraph is 70. Increase it to PEP 8's 72.

----------
messages: 215417
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: change default reformat width from 70 to 72
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr  3 04:47:39 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Apr 2014 02:47:39 +0000
Subject: [New-bugs-announce] [issue21140] Idle: saving an OutputWindow
	should default to .txt
Message-ID: <1396493259.83.0.13428125931.issue21140@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

If possible, when saving an instance of an OutputWindow, the file type should default to .txt (or possibly even nothing) instead of .py. At present, OutputWindows are only used for Find in Files (grep) output, which is very much not Python code. The same should be true of any other OutputWindow uses, which I except there will be, making OutputWindow saves more common.

A patch should be tested and verified on Mac, Linux, and Windows.

----------
components: IDLE
messages: 215419
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: saving an OutputWindow should default to .txt
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr  3 05:39:49 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 03 Apr 2014 03:39:49 +0000
Subject: [New-bugs-announce] [issue21141] Don't mention Perl in Windows
	build output
Message-ID: <1396496389.49.0.887037786203.issue21141@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Attached is a patch that prevents mentioning Perl in the Windows build output, thereby avoiding giving the indication that Perl is necessary to build Python.

To make this work, the patch converts PCbuild/build_ssl.py into PCbuild/prepare_ssl.py and removes the actual building of OpenSSL from that script.  Instead, prepare_ssl.py takes a directory name as an argument (which is assumed to be a directory containing OpenSSL sources) and does what it has always done to prepare the way for building, except now it does it for both platforms.  PCbuild/build_ssl.bat is also updated to match.

Meanwhile, the actual building is moved entirely within ssl.vcxproj, which now runs a short script that copies buildinf*.h and opensslconf*.h into place and calls nmake with the appropriate makefile (x64 builds also run the appropriate nasm command first).  Since this is all done inside ssl.vcxproj, the dependency on python.vcxproj is dropped, allowing SSL to be built in parallel with pythoncore, tcl, tk, and tix when using the '/m' msbuild command line switch.

As a part of converting build_ssl.py into prepare_ssl.py, the comments at the top of the file have been updated.  Also, some dead code has been trimmed: the "-a" flag has been completely unused for a long time, and debug builds have been disabled as well; all code relating to either feature has been removed.

I've tested this by successfully preparing (once) and building openssl-1.0.1f in both 32 and 64 bit builds.

----------
components: Build, Windows
files: no_perl.diff
keywords: patch
messages: 215421
nosy: loewis, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Don't mention Perl in Windows build output
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file34711/no_perl.diff

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

From report at bugs.python.org  Thu Apr  3 10:50:16 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 03 Apr 2014 08:50:16 +0000
Subject: [New-bugs-announce] [issue21142] Daily/weekly ABI scan?
Message-ID: <1396515016.38.0.140196375249.issue21142@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

At Anatoly's prompting, Andrey Ponomarenko set up ABI/API compatibility checks for CPython on the Linux upstream tracker (http://upstream-tracker.org/)

Everything: http://upstream-tracker.org/versions/python.html
Public API/ABI (no leading underscores): http://upstream-tracker.org/versions/python_public_api.html
3.2 limited API/stable ABI (no leading underscores): http://upstream-tracker.org/versions/python_stable_api.html

Andrey's analysis in the python-ideas thread [1] indicates we've likely made some mistakes in exposing struct internals, as well as exposing new APIs unintentionally under older Py_LIMITED_API definitions.

There's probably not too much (if anything) we can do to rectify the past mistakes, but we could set up a daily or weekly check (akin to the existing refleak scan) that monitored for such mistakes to prevent the introduction of any new errors along these lines.

[1] https://mail.python.org/pipermail/python-dev/2014-April/133754.html

----------
messages: 215432
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Daily/weekly ABI scan?
type: enhancement

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

From report at bugs.python.org  Thu Apr  3 11:54:45 2014
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Thu, 03 Apr 2014 09:54:45 +0000
Subject: [New-bugs-announce] [issue21143] Copy-paste error in documentation
	of __builtin__.max
Message-ID: <1396518885.59.0.164691798901.issue21143@psf.upfronthosting.co.za>


New submission from Jyrki Pulliainen:

Looks like the documentation of the __builtin__.max() got copied over from the __builtin__.min.

Instead of "the smallest of the positional arguments" it should say "the largest of the positional arguments".

This was introduced in 3.4. Patch attached.

Thanks to chiman@#python.fi for spotting this!

----------
assignee: docs at python
components: Documentation
files: fix-typo-in-max.patch
keywords: patch
messages: 215434
nosy: docs at python, nailor
priority: normal
severity: normal
status: open
title: Copy-paste error in documentation of __builtin__.max
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34712/fix-typo-in-max.patch

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

From report at bugs.python.org  Thu Apr  3 12:23:47 2014
From: report at bugs.python.org (Nikolaus Demmel)
Date: Thu, 03 Apr 2014 10:23:47 +0000
Subject: [New-bugs-announce] [issue21144] ensurepip "AssertionError:
	Multiple .dist-info	directories"
Message-ID: <1396520627.59.0.769231802002.issue21144@psf.upfronthosting.co.za>


New submission from Nikolaus Demmel:

I am installing python 3.4 on OS X 10.9 Mavericks via Homebrew.

The Homebrew formula is: https://github.com/Homebrew/homebrew/blob/4bd9b7538297c2ecbcaba281a6db86e8d8f660c8/Library/Formula/python3.rb

During the installation, `ensurepip` is called, but failes with "AssertionError: Multiple .dist-info directories".

I have reported this downstream with Homebrew, but it is suggested that this is an upstream issue: https://github.com/Homebrew/homebrew/issues/28035

The ensurepip output can be seen here: https://gist.github.com/NikolausDemmel/9952010#file-python3-4-installation-with-homebrew-L685-L709

And the mentioned log file here: https://gist.github.com/NikolausDemmel/9952010#file-python3-4-installation-with-homebrew-L751-L784

----------
messages: 215438
nosy: demmeln
priority: normal
severity: normal
status: open
title: ensurepip "AssertionError: Multiple .dist-info directories"
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr  3 12:28:52 2014
From: report at bugs.python.org (Omer Katz)
Date: Thu, 03 Apr 2014 10:28:52 +0000
Subject: [New-bugs-announce] [issue21145] Add the @cached_property decorator
Message-ID: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>


New submission from Omer Katz:

cached properties are widely used in various prominent Python projects such as Django and pip (and many more).
They are not very complicated and there are proven implementation out there. Unfortunately there are way too many of them. This situation leads me to suggest adding it to the builtins.

Possible benefits:
* Implementation in C can improve caching performance
* Standardized implementation that can be used anywhere

----------
messages: 215439
nosy: Omer.Katz
priority: normal
severity: normal
status: open
title: Add the @cached_property decorator
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Apr  3 12:40:06 2014
From: report at bugs.python.org (Wolfgang Maier)
Date: Thu, 03 Apr 2014 10:40:06 +0000
Subject: [New-bugs-announce] [issue21146] update gzip usage examples in docs
Message-ID: <1396521606.53.0.161098821761.issue21146@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

The current documentation of the gzip module should have its section "12.2.1. Examples of usage" updated to reflect the changes made to the module in Python3.2 (https://docs.python.org/3.2/whatsnew/3.2.html#gzip-and-zipfile).

Currently, the recipe given for gz-compressing a file is:

import gzip
with open('/home/joe/file.txt', 'rb') as f_in:
    with gzip.open('/home/joe/file.txt.gz', 'wb') as f_out:
        f_out.writelines(f_in)

which is clearly sub-optimal because it is line-based.

An equally simple, but more efficient recipe would be:

chunk_size = 1024
with open('/home/joe/file.txt', 'rb') as f_in:
    with gzip.open('/home/joe/file.txt.gz', 'wb') as f_out:
        while True:
            c = f_in.read(chunk_size)
            if not c: break
            d = f_out.write(c)

Comparing the two examples I find a >= 2x performance gain (both in terms of CPU time and wall time).

In the inverse scenario of file *de*-compression (which is not part of the docs though), the performance increase of substituting:

with gzip.open('/home/joe/file.txt.gz', 'rb') as f_in:
    with open('/home/joe/file.txt', 'wb') as f_out:
        f_out.writelines(f_in)

with:

with gzip.open('/home/joe/file.txt.gz', 'rb') as f_in:
    with open('/home/joe/file.txt', 'wb') as f_out:
        while True:
            c = f_in.read(chunk_size)
            if not c: break
            d = f_out.write(c)

is even higher (4-5x speed-ups).

In the de-compression case, another >= 2x speed-up can be achieved by avoiding the gzip module completely and going through a zlib.decompressobj instead, but of course this is a bit more complicated and should be documented in the zlib docs rather than the gzip docs (if you're interested, I could provide my code for it though).
Using the zlib library compression/decompression speed gets comparable to linux gzip/gunzip.

----------
assignee: docs at python
components: Documentation
messages: 215440
nosy: docs at python, wolma
priority: normal
severity: normal
status: open
title: update gzip usage examples in docs
type: performance
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Apr  3 19:07:25 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Apr 2014 17:07:25 +0000
Subject: [New-bugs-announce] [issue21147] sqlite3 doesn't complain if the
	request contains a null	character
Message-ID: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za>


New submission from STINNER Victor:

>>> import sqlite3
>>> c=sqlite3.connect(":memory:")
>>> c.execute("select 1")
<sqlite3.Cursor object at 0x7fd11e6a9110>
>>> c.execute("select 1").fetchall()
[(1,)]
>>> c.execute("\0select 1").fetchall()
[]

----------
messages: 215459
nosy: haypo
priority: normal
severity: normal
status: open
title: sqlite3 doesn't complain if the request contains a null character
versions: Python 3.5

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

From report at bugs.python.org  Thu Apr  3 20:39:32 2014
From: report at bugs.python.org (Julian Taylor)
Date: Thu, 03 Apr 2014 18:39:32 +0000
Subject: [New-bugs-announce] [issue21148] avoid memset in small tuple
	creation
Message-ID: <1396550372.7.0.587989241442.issue21148@psf.upfronthosting.co.za>


New submission from Julian Taylor:

attached a prototype patch that avoids the memset of ob_item in PyTuple_New which is not necessary for the BUILD_TUPLE bytecode and PyTuple_Pack as these overwrite every entry in ob_item anyway.
This improves small tuple creation by about 5%.

It does this by adding a new internal function that does not use the memset loop and wrapping that in PyTuple_New that does it. _Pack and ceval call the internal function.
The patch still needs cleanup I don't know where the signature for ceval.c would best go. Does the internal function need to be hidden from the DSO?

microbenchmark, compiled with gcc-4.8.2 on ubuntu 14.04 amd64, default configure options:

import timeit
print(min(timeit.repeat("(a,)", setup="a = 1; b = 1", repeat=5, number=10**7)))
print(min(timeit.repeat("(a, b)", setup="a = 1; b = 1", repeat=5, number=10**7)))

before:
0.45767
0.52926

after:
0.42652
0.50122

larger tuples do not profit much as the loading is more expensive in comparison.

----------
components: Interpreter Core
files: avoid-memset.patch
keywords: patch
messages: 215461
nosy: jtaylor
priority: normal
severity: normal
status: open
title: avoid memset in small tuple creation
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file34715/avoid-memset.patch

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

From report at bugs.python.org  Thu Apr  3 22:20:57 2014
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 03 Apr 2014 20:20:57 +0000
Subject: [New-bugs-announce] [issue21149] logging._removeHandlerRef is not
	threadsafe during	interpreter shutdown
Message-ID: <1396556457.93.0.286132850658.issue21149@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre:

If another thread is active during interpreter shutdown, it can hold the last reference to a handler; when it drops that reference, the weakref callback -- _removeHandlerRef -- will be executed in this other thread. So while this callback is running, the main thread is replacing module globals with None. This creates a data race for the globals in logging -- for example, _releaseLock can be replaced with None after the "_releaseLock is not None" check, but before it is used.

In principle I suspect this could cause a deadlock, in practice all I've seen are exception messages mentioning how None is not callable.

I have attached a patch that I think resolves this issue. The patch is written against 2.7, although I expect this issue affects all versions of Python prior to 3.4

BTW, the copyright for this patch belongs to my employer, Google; please let me know if there are any contributor agreements or such that my employer needs to look at.

----------
components: Library (Lib)
files: patch.diff
keywords: patch
messages: 215466
nosy: Devin Jeanpierre, gregory.p.smith
priority: normal
severity: normal
status: open
title: logging._removeHandlerRef is not threadsafe during interpreter shutdown
versions: Python 2.7
Added file: http://bugs.python.org/file34718/patch.diff

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

From report at bugs.python.org  Thu Apr  3 22:47:15 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Apr 2014 20:47:15 +0000
Subject: [New-bugs-announce] [issue21150] Add quick links table to argparse
	docs
Message-ID: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The argparse module has many functions and options.

It would benefit from a summary and quick links table at the top of the page just like we have for the itertools module docs and the builtins module docs.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 215468
nosy: docs at python, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add quick links table to argparse docs
versions: Python 3.5

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

From report at bugs.python.org  Fri Apr  4 05:17:01 2014
From: report at bugs.python.org (Dave Odell)
Date: Fri, 04 Apr 2014 03:17:01 +0000
Subject: [New-bugs-announce] [issue21151] winreg.SetValueEx causes crash if
	value = None
Message-ID: <1396581421.46.0.554143633373.issue21151@psf.upfronthosting.co.za>


New submission from Dave Odell:

Here's a small program that crashes Python 3.

import winreg
winreg.SetValueEx(winreg.HKEY_CURRENT_USER, 'Value', 0, 3, None)

I get a 0xC0000374 exception (STATUS_HEAP_CORRUPTION) when trying to run this. Here's a stack dump:

(snip)
ntdll.dll!RtlpLogHeapFailure+0xa4
ntdll.dll! ?? ::FNODOBFM::`string'+0x10c7c
kernel32.dll!HeapFree+0xa
MSVCR100.dll!free+0x1c
python34.dll!PySetValueEx+0xf8
python34.dll!PyCFunction_Call+0x12d
python34.dll!call_function+0x2ab
python34.dll!PyEval_EvalFrameEx+0x2259
python34.dll!PyEval_EvalCodeEx+0x65c
python34.dll!PyEval_EvalCode+0x2e
python34.dll!builtin_exec+0x1b5
python34.dll!PyCFunction_Call+0x12d
python34.dll!call_function+0x2ab
python34.dll!PyEval_EvalFrameEx+0x2259
python34.dll!PyEval_EvalCodeEx+0x65c
python34.dll!function_call+0x15d
python34.dll!PyObject_Call+0x61
python34.dll!ext_do_call+0x2ab
python34.dll!PyEval_EvalFrameEx+0x22fe
python34.dll!PyEval_EvalCodeEx+0x65c
python34.dll!fast_function+0x14d
python34.dll!call_function+0x311
python34.dll!PyEval_EvalFrameEx+0x2259
python34.dll!PyEval_EvalCodeEx+0x65c
python34.dll!PyEval_EvalCode+0x2e
python34.dll!run_mod+0x53
python34.dll!PyRun_StringFlags+0x9c
python34.dll!PyRun_SimpleStringFlags+0x41
python34.dll!run_command+0x55
python34.dll!Py_Main+0x683
pythonw.exe!__tmainCRTStartup+0x166
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x1d

System is Windows 7 64-bit, with stock x86-64 Python 3.4.0 binaries.

Incidentally, I was feeding the 'None' to winreg.SetValueEx because that is the value that winreg.EnumValue returns for zero-length binary values. This is somewhat unexpected; I'd personally prefer to get b'' in that instance.

----------
components: Library (Lib), Windows
messages: 215486
nosy: dmo2118, stutzbach
priority: normal
severity: normal
status: open
title: winreg.SetValueEx causes crash if value = None
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Fri Apr  4 10:13:06 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Apr 2014 08:13:06 +0000
Subject: [New-bugs-announce] [issue21152] Idle: timed autosave for shell
	(and maybe editor) window
Message-ID: <1396599186.38.0.494576293163.issue21152@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

>From #21140, msg215485, Raymond Hettinger: "Students commonly save shell sessions as a record of everything they tried in call. It would nice if there were a way to trigger a periodic autosave (perhaps every five minutes or so)."

----------
components: IDLE
messages: 215499
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: timed autosave for shell (and maybe editor) window
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Apr  4 12:33:36 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 04 Apr 2014 10:33:36 +0000
Subject: [New-bugs-announce] [issue21153] bdist_rpm fails if project
	contains files with spaces in	the names
Message-ID: <1396607616.44.0.695495728794.issue21153@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

In https://bitbucket.org/pypa/setuptools/issue/178, Eduard reported an issue that setuptools fails to install due to files in its structure with spaces in the filenames. These files have been around for some time (over two years in Distribute), but are now revealing a limitation in bdist_rpm.

The aforementioned ticket demonstrates the issue, and I will be providing a script to replicate the failure shortly.

----------
components: Distutils
messages: 215508
nosy: dstufft, eric.araujo, jason.coombs
priority: normal
severity: normal
status: open
title: bdist_rpm fails if project contains files with spaces in the names
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Apr  4 15:00:03 2014
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 04 Apr 2014 13:00:03 +0000
Subject: [New-bugs-announce] [issue21154] Small fix in 2.7.6 lang ref
Message-ID: <1396616403.97.0.334401802689.issue21154@psf.upfronthosting.co.za>


New submission from Armin Rigo:

The docs still say that the default __hash__() is equal to id(), but that's not the case since Python 2.7.

----------
assignee: docs at python
components: Documentation
files: lang-ref-fix.diff
keywords: patch
messages: 215517
nosy: arigo, docs at python
priority: normal
severity: normal
status: open
title: Small fix in 2.7.6 lang ref
versions: Python 2.7
Added file: http://bugs.python.org/file34723/lang-ref-fix.diff

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

From report at bugs.python.org  Fri Apr  4 18:57:31 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Apr 2014 16:57:31 +0000
Subject: [New-bugs-announce] [issue21155] asyncio:
	calling	_UnixSelectorEventLoop.create_unix_server(sock=...,
	path=...) must fail
Message-ID: <1396630651.69.0.156271009949.issue21155@psf.upfronthosting.co.za>


New submission from STINNER Victor:

_UnixSelectorEventLoop.create_unix_server() can be called with path *and* sock. In this case, the sock parameter is ignored.

Attached patch changes the method to raise a ValueError, to have the same behaviour than create_connection().

----------
files: unix.patch
keywords: patch
messages: 215536
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: calling _UnixSelectorEventLoop.create_unix_server(sock=..., path=...) must fail
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34726/unix.patch

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

From report at bugs.python.org  Fri Apr  4 19:59:20 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Apr 2014 17:59:20 +0000
Subject: [New-bugs-announce] [issue21156] Consider
	moving	importlib.abc.InspectLoader.source_to_code() to
	importlib.abc.Loader
Message-ID: <1396634360.22.0.98257221553.issue21156@psf.upfronthosting.co.za>


New submission from Brett Cannon:

importlib.abc.InspectLoader.source_to_code exists on InspectLoader because InspectLoader.get_code() uses it. But there is technically no reason to leave it there and not simply move it up to importlib.abc.Loader(). There is also no reason to not make it a staticmethod so that one can use it without worrying about abstractmethod overrides.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 215544
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Apr  4 20:38:32 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Apr 2014 18:38:32 +0000
Subject: [New-bugs-announce] [issue21157] Update imp docs for a PEP 451 world
Message-ID: <1396636712.05.0.464506869774.issue21157@psf.upfronthosting.co.za>


New submission from Brett Cannon:

imp.find_module() should point to importlib.find_spec() instead of find_loader(). As for imp.load_module() I've started a discussion on import-sig on how to best handle that.

----------
assignee: brett.cannon
components: Documentation
messages: 215547
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Update imp docs for a PEP 451 world
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Apr  4 21:18:42 2014
From: report at bugs.python.org (Payden Comer)
Date: Fri, 04 Apr 2014 19:18:42 +0000
Subject: [New-bugs-announce] [issue21158] Windows installer service could
	not be accessed
Message-ID: <1396639122.72.0.136527705506.issue21158@psf.upfronthosting.co.za>


New submission from Payden Comer:

I am VERY tech saavy, so don't give me an auto reply like I'm stupid (it's happened before). Sorry for the rude start! Anyhoo, This is the only program on my pc that does this, tried registry fixes, ms fixit, cmd, services, you named it I've (most likely) done it!

----------
components: Installation
files: python bug.PNG
messages: 215555
nosy: thecheater887
priority: normal
severity: normal
status: open
title: Windows installer service could not be accessed
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34729/python bug.PNG

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

From report at bugs.python.org  Sat Apr  5 12:35:12 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 05 Apr 2014 10:35:12 +0000
Subject: [New-bugs-announce] [issue21159]
	configparser.InterpolationMissingOptionError is not very	intuitive
Message-ID: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

The error message from the title is not very intuitive from a user point of view. For instance, in the following traceback, only the first one gives a meaning to this error, through the leaked KeyError, thus the user knows that home_dir1 is invalid and missing. But the second message with "Bad value substitution" doesn't emphasize the actual problem and you have to stare at it for a couple of moments to figure out what's happening and why. Maybe changing the "Bad value substitution" with a "Missing value" would suffice. This came up in issue19546. 

Traceback (most recent call last):
  File "C:\Python34\lib\configparser.py", line 410, in _interpolate_some
    v = map[var]
  File "C:\Python34\lib\collections\__init__.py", line 789, in __getitem__
    return self.__missing__(key)            # support subclasses that define __missing__
  File "C:\Python34\lib\collections\__init__.py", line 781, in __missing__
    raise KeyError(key)
KeyError: 'home_dir1'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\configparser.py", line 1204, in __getitem__
    return self._parser.get(self._name, key)
  File "C:\Python34\lib\configparser.py", line 773, in get
    d)
  File "C:\Python34\lib\configparser.py", line 374, in before_get
    self._interpolate_some(parser, option, L, value, section, defaults, 1)
  File "C:\Python34\lib\configparser.py", line 413, in _interpolate_some
    option, section, rest, var)
configparser.InterpolationMissingOptionError: Bad value substitution:
        section: [Paths]
        option : my_dir
        key    : home_dir1
        rawval : /lumberjack

----------
components: Library (Lib)
messages: 215589
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: configparser.InterpolationMissingOptionError is not very intuitive
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Apr  5 12:45:36 2014
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sat, 05 Apr 2014 10:45:36 +0000
Subject: [New-bugs-announce] [issue21160] incorrect comments in nturl2path.py
Message-ID: <1396694736.78.0.949476383561.issue21160@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

nturl2path.py module contains comments implying that it converts local paths to URLs with ':' characters replaced with '|'. This has not been true since Python 2.6.

Commit at:

  http://bitbucket.org/jurko/cpython/commits/8fe56380b09e238f104ba4a4d7a67df73182bc21

updates those comments - prepared against the CPython development repo.

----------
components: Library (Lib), Windows
hgrepos: 230
messages: 215592
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: incorrect comments in nturl2path.py
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Apr  5 13:55:43 2014
From: report at bugs.python.org (Kay)
Date: Sat, 05 Apr 2014 11:55:43 +0000
Subject: [New-bugs-announce] [issue21161] list comprehensions don't see
	local variables in pdb in	python3
Message-ID: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za>


New submission from Kay:

Using generators in pdb are very handy but since Python3 they don't work properly. For example:

import pdb
def foo():
  items = [1, 2, 3]
  limit = 5
  pdb.set_trace()

foo()

in pdb prompt the following fails:

(pdf) all(x < limit for x in items)
*** NameError: global name 'items' is not defined

I can express that in a lambda expression (i.e. pass items as an argument) but this seems unnecessary and very inelegant.

----------
components: Interpreter Core
messages: 215595
nosy: kay
priority: normal
severity: normal
status: open
title: list comprehensions don't see local variables in pdb in python3
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr  5 18:41:00 2014
From: report at bugs.python.org (Ivan K)
Date: Sat, 05 Apr 2014 16:41:00 +0000
Subject: [New-bugs-announce] [issue21162] code in multiprocessing.pool
	freeze if inside some code	from scikit-learn (and probably
	liblinear) executed on ubuntu	12.04 64 Bit
Message-ID: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za>


New submission from Ivan K:

Here is a code. https://gist.github.com/anonymous/9994217 When I run it in freeze and never end. If I run it without pool with loop or joblib - it works fine.

Also there is a question on stackoverflow: http://stackoverflow.com/q/22881850/1888017

Python 2.7.6/2.7.3, cpu core i7 if it's important

----------
components: Library (Lib)
messages: 215620
nosy: Ivan.K
priority: normal
severity: normal
status: open
title: code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  5 23:10:31 2014
From: report at bugs.python.org (Richard Kiss)
Date: Sat, 05 Apr 2014 21:10:31 +0000
Subject: [New-bugs-announce] [issue21163] asyncio Task Possibly Incorrectly
	Garbage Collected
Message-ID: <1396732231.93.0.182409018223.issue21163@psf.upfronthosting.co.za>


New submission from Richard Kiss:

Some tasks created via asyncio are vanishing because there is no reference to their resultant futures.

This behaviour does not occur in Python 3.3.3 with asyncio-0.4.1.

Also, doing a gc.collect() immediately after creating the tasks seems to fix the problem.

Attachment also available at https://gist.github.com/richardkiss/9988156

----------
components: Library (Lib)
files: asyncio-gc-issue.py
hgrepos: 231
messages: 215633
nosy: richard.kiss
priority: normal
severity: normal
status: open
title: asyncio Task Possibly Incorrectly Garbage Collected
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34741/asyncio-gc-issue.py

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

From report at bugs.python.org  Mon Apr  7 04:57:52 2014
From: report at bugs.python.org (Leslie Klein)
Date: Mon, 07 Apr 2014 02:57:52 +0000
Subject: [New-bugs-announce] [issue21164] print unicode in Windows console
Message-ID: <1396839472.79.0.493888101601.issue21164@psf.upfronthosting.co.za>


New submission from Leslie Klein:

The console behaves by encoding a str (using the sys.getdefaultencoding()) and then decodes the bytes to a glyph for rendering. The decoder used is 'cp437'. Apparently, there is no way to override that!

See ipython notebook for summary and example of the issue.

nbviewer.ipython.org/gist/LeslieK/10013426

----------
components: Windows
messages: 215675
nosy: LeslieK
priority: normal
severity: normal
status: open
title: print unicode in Windows console
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  7 11:10:44 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Apr 2014 09:10:44 +0000
Subject: [New-bugs-announce] [issue21165] Optimize str.translate() for
	replacement with substrings	and non-ASCII strings
Message-ID: <1396861844.88.0.0543379452839.issue21165@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In issue #21118, I optimized str.translate() in Python 3.5 for ASCII 1:1 mapping and ASCII deletion. My optimization is not used if a character is replaced with a string (ex: "abc".translate({ord('a'): "xxx"})) and for non-ASCII strings.

translate_script.py is a simple benchmark for 1:1 mapping. It should be enhanced to benchmark also replacement strings.

----------
files: translate_script.py
messages: 215677
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize str.translate() for replacement with substrings and non-ASCII strings
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file34745/translate_script.py

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

From report at bugs.python.org  Mon Apr  7 11:32:57 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Apr 2014 09:32:57 +0000
Subject: [New-bugs-announce] [issue21166] Bus error on "AMD64 FreeBSD 9.x
	3.4" buildbot
Message-ID: <1396863177.29.0.753462829204.issue21166@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/44/steps/compile/logs/stdio

./python -E -S -m sysconfig --generate-posix-vars
Bus error (core dumped)

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4

----------
messages: 215683
nosy: haypo
priority: normal
severity: normal
status: open
title: Bus error on "AMD64 FreeBSD 9.x 3.4" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr  7 12:02:32 2014
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 07 Apr 2014 10:02:32 +0000
Subject: [New-bugs-announce] [issue21167] float('nan') returns 0.0 on Python
	compiled with icc
Message-ID: <1396864952.24.0.891595123462.issue21167@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i?:

On a Python compiled with Intel C compiler, float('nan') returns 0.0. This behavior can be reproduced with icc versions 11 and 12.

The definition of Py_NAN in include/pymath.h expects `HUGE_VAL * 0.0` to compile to a NaN value on IEEE754 platforms:

/* Py_NAN
 * A value that evaluates to a NaN. On IEEE 754 platforms INF*0 or
 * INF/INF works. Define Py_NO_NAN in pyconfig.h if your platform
 * doesn't support NaNs.
 */
#if !defined(Py_NAN) && !defined(Py_NO_NAN)
#define Py_NAN (Py_HUGE_VAL * 0.)
#endif

I don't have a copy of the standard, but a simple test shows that the above does not hold for icc. When compiled with icc without any flags, the following program outputs "inf 0.000000" instead of the expected "inf nan":

#include <stdio.h>
#include <math.h>

int main()
{
  double inf = HUGE_VAL;
  double nan = HUGE_VAL * 0;
  printf("%f %f\n", inf, nan);
  return 0;
}

Compiling the same program with gcc yields the expected output of "inf nan".

This issue can be fixed (or worked around, if it's an icc bug) by using a different definition of Py_NAN. On icc, defining Py_NAN as `Py_HUGE_VAL / Py_HUGE_VAL` produces the intended effect. If this is considered suboptimal on other compilers, the definition can be conditionally compiled for icc only.

The attached patch fixes the issue, taking the conservative approach of only modifying the icc definition of Py_NAN.

----------
components: Interpreter Core
files: intel-nan.diff
keywords: patch
messages: 215687
nosy: hniksic
priority: normal
severity: normal
status: open
title: float('nan') returns 0.0 on Python compiled with icc
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file34746/intel-nan.diff

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

From report at bugs.python.org  Mon Apr  7 13:09:24 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Apr 2014 11:09:24 +0000
Subject: [New-bugs-announce] [issue21168] unicodeobject.c: likely
	type-punning may break	strict-aliasing rules
Message-ID: <1396868964.72.0.411392590222.issue21168@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/48/steps/compile/logs/stdio

Objects/unicodeobject.c: In function '_PyUnicode_Init':
Objects/unicodeobject.c:582: warning: likely type-punning may break strict-aliasing rules: object '*data' of main type 'unsigned int' is referenced at or around Objects/unicodeobject.c:582 and may be aliased to object 'linebreak' of main type 'short unsigned int' which is referenced at or around Objects/unicodeobject.c:14933.

According to koobs, it's gcc 4.2.1 on this buildbot.

----------
messages: 215694
nosy: haypo
priority: normal
severity: normal
status: open
title: unicodeobject.c: likely type-punning may break strict-aliasing rules
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr  7 13:23:55 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 07 Apr 2014 11:23:55 +0000
Subject: [New-bugs-announce] [issue21169] getpass.getpass() fails with
	non-ASCII characters in	prompt
Message-ID: <1396869835.69.0.462900859226.issue21169@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

getpass.getpass() fails with non-ASCII characters in prompt.

The attached example scripts (for Python 2 and 3) contain non-ASCII unicode prompt (Polish "has?o" == English "password") written in UTF-8.
Python-2 version fails always. Python-3 version fails in non-UTF-8 locale.

$ ./getpass_test_python2
Traceback (most recent call last):
  File "./getpass_test_python2", line 5, in <module>
    getpass.getpass(u"Has?o: ")
  File "/usr/lib64/python2.7/getpass.py", line 71, in unix_getpass
    passwd = _raw_input(prompt, stream, input=input)
  File "/usr/lib64/python2.7/getpass.py", line 128, in _raw_input
    prompt = str(prompt)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142' in position 3: ordinal not in range(128)
$ LC_ALL="en_US.UTF-8" ./getpass_test_python3
Has?o: 
$ LC_ALL="C" ./getpass_test_python3
Traceback (most recent call last):
  File "./getpass_test_python3", line 5, in <module>
    getpass.getpass("Has\u0142o: ")
  File "/usr/lib64/python3.4/getpass.py", line 78, in unix_getpass
    passwd = _raw_input(prompt, stream, input=input)
  File "/usr/lib64/python3.4/getpass.py", line 138, in _raw_input
    stream.write(prompt)
UnicodeEncodeError: 'ascii' codec can't encode character '\u0142' in position 3: ordinal not in range(128)
$

----------
components: Library (Lib)
keywords: easy
messages: 215697
nosy: Arfrever
priority: normal
severity: normal
stage: needs patch
status: open
title: getpass.getpass() fails with non-ASCII characters in prompt
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr  7 16:39:19 2014
From: report at bugs.python.org (Volodymyr Sapsai)
Date: Mon, 07 Apr 2014 14:39:19 +0000
Subject: [New-bugs-announce] [issue21170] Incorrect signature
	for	unittest.TestResult.startTestRun(), .stopTestRun()
Message-ID: <1396881559.52.0.157201741461.issue21170@psf.upfronthosting.co.za>


New submission from Volodymyr Sapsai:

Steps to reproduce:
1. Open docs for unittest.TestResult class.
2. Look at startTestRun() and stopTestRun() methods signatures (https://docs.python.org/3.4/library/unittest.html#unittest.TestResult.startTestRun)

Actual result:
It is stated that aforementioned methods accept 1 argument 'test'.

Expected result:
These methods don't accept any arguments, it should be stated so in the docs.

----------
assignee: docs at python
components: Documentation
messages: 215710
nosy: Volodymyr.Sapsai, docs at python
priority: normal
severity: normal
status: open
title: Incorrect signature for unittest.TestResult.startTestRun(), .stopTestRun()
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Apr  7 18:25:51 2014
From: report at bugs.python.org (=?utf-8?b?0JzQuNGF0LDQuNC7INCc0LjRiNCw0LrQuNC9?=)
Date: Mon, 07 Apr 2014 16:25:51 +0000
Subject: [New-bugs-announce] [issue21171] Outdated usage
	str.encode('rot-13') in rot13 codec
Message-ID: <1396887951.87.0.0918755245814.issue21171@psf.upfronthosting.co.za>


New submission from ?????? ???????:

Function rot13 in file "encodings/rot_13.py" throws exception:

LookupError: 'rot-13' is not a text encoding; use codecs.encode() to handle arbitrary codecs

----------
messages: 215712
nosy: Pix
priority: normal
severity: normal
status: open
title: Outdated usage str.encode('rot-13') in rot13 codec
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr  7 19:04:37 2014
From: report at bugs.python.org (Alan Briolat)
Date: Mon, 07 Apr 2014 17:04:37 +0000
Subject: [New-bugs-announce] [issue21172] Unexpected behaviour with
	logging.LogRecord "first arg	is dict" case
Message-ID: <1396890277.61.0.522199976389.issue21172@psf.upfronthosting.co.za>


New submission from Alan Briolat:

The logging.LogRecord class is more restrictive with its "first arg is dict" case than the formatting operator it uses requires.  As far as I can tell, for "%(foo)s" % bar, the minimum contract is that bar.__getitem__("foo") succeeds, not that bar is an instance of dict.  However, fulfilling only this minimum contract results in LogRecord raising an exception at the point of applying the string format, which is confusing considering the "same" expression succeeds outside of logging.  See the attached file for how 2 "equivalent" expressions behave completely differently.

For resolution, I wonder if checking for "hasattr(..., '__getitem__')" instead of "isinstance(..., dict)" would be sufficient?

----------
components: Library (Lib)
files: logging_format_bug.py
messages: 215713
nosy: alan.briolat
priority: normal
severity: normal
status: open
title: Unexpected behaviour with logging.LogRecord "first arg is dict" case
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34750/logging_format_bug.py

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

From report at bugs.python.org  Mon Apr  7 22:17:27 2014
From: report at bugs.python.org (Philip Jenvey)
Date: Mon, 07 Apr 2014 20:17:27 +0000
Subject: [New-bugs-announce] [issue21173] WeakKeyDictionary.__len__ fragile
	w/ _IterationGuards
Message-ID: <1396901847.85.0.817641964544.issue21173@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

len() on WeakKeyDictionarys can fail with ValueErrors when _IterationGuards are kept alive

Attached is a test showing this:

======================================================================
ERROR: test_weak_keys_len_destroy_while_iterating (__main__.MappingTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_weakref.py", line 1336, in test_weak_keys_len_destroy_while_iterating
    self.assertEqual(len(dict), 0)
ValueError: __len__() should return >= 0


One probably shouldn't keep them alive like this, but __len__ shouldn't be blowing up either. On non ref counting GC platforms this situation is easier to trigger unintentionally

----------
components: Library (Lib)
messages: 215716
nosy: pitrou, pjenvey
priority: normal
severity: normal
status: open
title: WeakKeyDictionary.__len__ fragile w/ _IterationGuards
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr  7 23:10:31 2014
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 07 Apr 2014 21:10:31 +0000
Subject: [New-bugs-announce] [issue21174] A typo in the docs for "exception
	GeneratorExit"
Message-ID: <1396905031.09.0.19522982785.issue21174@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak:

The docs for the exception GeneratorExit starts like this:
Raise when a generator?s close() method is called.

The sentece should start with the first word "Raise" to say "Raised". You can find this particular doc sentence on this link: https://docs.python.org/2/library/exceptions.html#exceptions.GeneratorExit

This is a small fix. Just add the letter "d".

----------
assignee: docs at python
components: Documentation
messages: 215717
nosy: Zvezdoslovec, docs at python
priority: normal
severity: normal
status: open
title: A typo in the docs for "exception GeneratorExit"
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr  8 01:10:56 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 07 Apr 2014 23:10:56 +0000
Subject: [New-bugs-announce] [issue21175] Refcounting error in str.translate
	fastpath
Message-ID: <1396912256.62.0.455754100462.issue21175@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Py_None is not being properly decref-ed in the str.translate fast path. I've attached a simple patch that fixes this (also corrects some comments and types in the same function).

No idea is Py_None ref leaks are considered a serious problem, but I figure it's better to be safe than sorry.

----------
files: fix_translate_none.patch
keywords: patch
messages: 215718
nosy: haypo, josh.rosenberg
priority: normal
severity: normal
status: open
title: Refcounting error in str.translate fastpath
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34752/fix_translate_none.patch

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

From report at bugs.python.org  Tue Apr  8 04:51:35 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Apr 2014 02:51:35 +0000
Subject: [New-bugs-announce] [issue21176] Implement matrix multiplication
	operator (PEP 465)
Message-ID: <1396925495.01.0.281917881542.issue21176@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

[Nathaniel Smith at numpy-discussion]

Guido just formally accepted PEP 465:
  https://mail.python.org/pipermail/python-dev/2014-April/133819.html
  http://legacy.python.org/dev/peps/pep-0465/#implementation-details

Yay.

The next step is to implement it, in CPython and in numpy. I have time
to advise on this, but not to do it myself, so, any volunteers? Ever
wanted to hack on the interpreter itself, with BDFL guarantee your
patch will be accepted (if correct)?

The todo list for CPython is here:
    http://legacy.python.org/dev/peps/pep-0465/#implementation-details
There's one open question which is where the type slots should be
added. I'd just add them to PyNumberMethods and then if someone
objects during patch review it can be changed.

----------
assignee: belopolsky
components: Interpreter Core
messages: 215724
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement matrix multiplication operator (PEP 465)
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Apr  8 10:54:10 2014
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Tue, 08 Apr 2014 08:54:10 +0000
Subject: [New-bugs-announce] [issue21177] ValueError: byte must be in
	range(0, 256)
Message-ID: <1396947250.75.0.807471111064.issue21177@psf.upfronthosting.co.za>


New submission from Konstantin Zemlyak:

Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> bytearray([256])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: byte must be in range(0, 256)
>>> bytes([256])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: bytes must be in range(0, 256)
>>> 


Tested on 2.7, 3.2, 3.3, 3.4. Frankly, this looks like an off-by-one error to me.

----------
components: Interpreter Core
messages: 215744
nosy: zart
priority: normal
severity: normal
status: open
title: ValueError: byte must be in range(0, 256)
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr  8 12:49:06 2014
From: report at bugs.python.org (=?utf-8?q?Ontje_L=C3=BCnsdorf?=)
Date: Tue, 08 Apr 2014 10:49:06 +0000
Subject: [New-bugs-announce] [issue21178] doctest cause warnings in tests
	using generators
Message-ID: <1396954146.87.0.0393521418681.issue21178@psf.upfronthosting.co.za>


New submission from Ontje L?nsdorf:

The attached doctest raises a warning since Python 3.4:

$ python -m doctest doctest.txt
Exception ignored in: <generator object foo at 0x7f9ee38aaca8>
Traceback (most recent call last):
  File "<doctest doctest.txt[1]>", line 4, in foo
NameError: name 'socket' is not defined

My guess is that doctest cleans up globals() of the test snippet (thereby deleting socket). Afterwards python cleans up the generator by sending in a GeneratorExit exception. The except block will now fail because socket is not available anymore.

----------
components: Tests
files: doctest.txt
messages: 215750
nosy: oluensdorf
priority: normal
severity: normal
status: open
title: doctest cause warnings in tests using generators
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34760/doctest.txt

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

From report at bugs.python.org  Tue Apr  8 12:58:58 2014
From: report at bugs.python.org (Clinton Curry)
Date: Tue, 08 Apr 2014 10:58:58 +0000
Subject: [New-bugs-announce] [issue21179] Rounding half to even
Message-ID: <1396954738.37.0.54879370291.issue21179@psf.upfronthosting.co.za>


New submission from Clinton Curry:

In the current Python 2.7 documentation, Section 5.4

https://docs.python.org/2.7/library/stdtypes.html

the result of the round function is described as "x rounded to n digits, rounding half to even. If n is omitted, it defaults to 0."  However, my observed behavior (Python 2.7.4 (default, Apr  6 2013, 19:55:15) [MSC v.1500 64 bit (AMD64)] on win32) does not round half to even, but rounds half away from zero.

>>> round(1.5)
2.0
>>> round(2.5)
3.0
>>> round(-1.5)
-2.0
>>> round(-2.5)
-3.0

I observe similar behavior on other platforms.

----------
assignee: docs at python
components: Documentation
messages: 215753
nosy: Clinton.Curry, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Rounding half to even
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  8 15:32:06 2014
From: report at bugs.python.org (Paul Sokolovsky)
Date: Tue, 08 Apr 2014 13:32:06 +0000
Subject: [New-bugs-announce] [issue21180] Cannot efficiently create empty
	array.array of given	size, inconsistency with bytearray
Message-ID: <1396963926.18.0.0845457465299.issue21180@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

With bytearray, you can do:

>>> bytearray(3)
bytearray(b'\x00\x00\x00')

However, with arrays:

>>> array.array('i', 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable

Given that int passed as seconf argument is not handled specially in array, I'd like to propose to make it an initial size of a zero-filled array to create. This will make it: a) consitent with bytearray; b) efficient for the scenarios where one needs to pre-create array of given length, pass to some (native) function to fill in, then do rest of processing. For the latter case, assuming that both fill-in and further processing is efficient (e.g. done by native function), the initial array creation becomes a bottleneck.

----------
components: Library (Lib)
messages: 215757
nosy: pfalcon
priority: normal
severity: normal
status: open
title: Cannot efficiently create empty array.array of given size, inconsistency with bytearray
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Tue Apr  8 18:35:50 2014
From: report at bugs.python.org (Jim Peterson)
Date: Tue, 08 Apr 2014 16:35:50 +0000
Subject: [New-bugs-announce] [issue21181] Inconsistent Definition
	of	collections.namedtuple.__dict__ in _source
Message-ID: <1396974950.77.0.151698168246.issue21181@psf.upfronthosting.co.za>


New submission from Jim Peterson:

The result returned by somenamedtuple._source seem inconsistent, in that it defines __dict__ as:

    __dict__ = property(_asdict)

even though it imports property as:

from builtins import property as _property

and the namedtuple fields are defined using _property, instead.  It still compiles and functions properly, but whatever compelled the developer to declare the named fields using _property seems to be ignored in the definition of __dict__.

----------
components: Library (Lib)
messages: 215772
nosy: Jim.Peterson
priority: normal
severity: normal
status: open
title: Inconsistent Definition of collections.namedtuple.__dict__ in _source
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr  9 01:42:13 2014
From: report at bugs.python.org (Yakov Keselman)
Date: Tue, 08 Apr 2014 23:42:13 +0000
Subject: [New-bugs-announce] [issue21182] json.loads errors out on valid JSON
Message-ID: <1397000533.56.0.918232006199.issue21182@psf.upfronthosting.co.za>


New submission from Yakov Keselman:

Run the following Python JSON parsing script on valid JSON:

import json
json.loads( '["[\"Residential | Furniture | Cabinets\",\"119.99\"]"]' )

Result:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python33\lib\json\__init__.py", line 319, in loads
    return _default_decoder.decode(s)
  File "C:\Python33\lib\json\decoder.py", line 352, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "C:\Python33\lib\json\decoder.py", line 368, in raw_decode
    obj, end = self.scan_once(s, idx)
ValueError: Expecting ',' delimiter: line 1 column 5 (char 4)

----------
components: IO
messages: 215780
nosy: Yakov.Keselman
priority: normal
severity: normal
status: open
title: json.loads errors out on valid JSON
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr  9 04:13:51 2014
From: report at bugs.python.org (Osvaldo Santana Neto)
Date: Wed, 09 Apr 2014 02:13:51 +0000
Subject: [New-bugs-announce] [issue21183] Doctest capture only
	AssertionError but not printed text
Message-ID: <1397009631.06.0.545133190838.issue21183@psf.upfronthosting.co.za>


New submission from Osvaldo Santana Neto:

The following doctest should pass, but it fails:

    >>> def spam(): print("eggs")
    ...
    >>> assert spam()
    eggs
    Traceback (most recent call last):
    AssertionError

But if we remove the print output from printed results the test pass:

    >>> def spam(): print("eggs")
    ...
    >>> assert spam()
    Traceback (most recent call last):
    AssertionError

I'm writing the 2nd edition of a book about Python (covering python3) and Django and I'm using doctest to run the interactive sessions that I use as examples in book.

----------
components: Library (Lib)
files: doctest_bug.py
messages: 215796
nosy: osantana
priority: normal
severity: normal
status: open
title: Doctest capture only AssertionError but not printed text
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file34771/doctest_bug.py

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

From report at bugs.python.org  Wed Apr  9 05:14:30 2014
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 09 Apr 2014 03:14:30 +0000
Subject: [New-bugs-announce] [issue21184] statistics.pvariance with known
	mean does not work as	expected
Message-ID: <1397013270.92.0.0743559681991.issue21184@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

If you know the population mean mu, you should calculate the sample variance by passing mu as an explicit argument to statistics.pvariance. Unfortunately, it doesn't work as designed:

py> data = [1, 2, 2, 2, 3, 4]  # sample from a population with mu=2.5
py> statistics.pvariance(data)  # uses the sample mean 2.3333...
0.8888888888888888
py> statistics.pvariance(data, 2.5)  # using known population mean
0.8888888888888888

The second calculation ought to be 0.91666... not 0.88888...

The problem lies with the _ss private function which calculates the sum of square deviations. Unfortunately it is too clever: it includes an error adjustment term

ss -= _sum((x-c) for x in data)**2/len(data)

which mathematically is expected to be zero when c is calculated as the mean of data, but due to rounding may not be quite zero. But when c is given explicitly, as happens if the caller provides an explicit mu argument to pvariance, then the error adjustment has the effect of neutralizing the explicit mu.

The obvious fix is to just skip the adjustment in _ss when c is explicitly given, but I'm not sure if that's the best approach.

----------
assignee: stevenjd
components: Library (Lib)
messages: 215802
nosy: stevenjd
priority: normal
severity: normal
stage: needs patch
status: open
title: statistics.pvariance with known mean does not work as expected
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr  9 10:06:33 2014
From: report at bugs.python.org (wchlm)
Date: Wed, 09 Apr 2014 08:06:33 +0000
Subject: [New-bugs-announce] [issue21185] heapq fails to print in sorted
	order for certain inputs
Message-ID: <1397030793.41.0.486579475537.issue21185@psf.upfronthosting.co.za>


New submission from wchlm:

I observe the following in Python 2.6.1 in CentOS 5.9 and in Python 2.7.5 in MacOS 10.9.2.

A heapified 3-element array containing elements in the order [low, high, medium] fails to print in sorted order, as shown below: 

>>> import heapq
>>> lista = [1, 6, 5, 4]
>>> heapq.heapify(lista)
>>> lista # Gives sorted order, as expected
[1, 4, 5, 6]
>>> 
>>> listb = [1, 6, 5]
>>> heapq.heapify(listb)
>>> listb # Gives unsorted order -- unexpected and presumably a bug
[1, 6, 5]
>>> 
>>> [heapq.heappop(listb) for i in range(len(listb))] # But heappop works
[1, 5, 6]

----------
components: Devguide
messages: 215805
nosy: ezio.melotti, wchlm
priority: normal
severity: normal
status: open
title: heapq fails to print in sorted order for certain inputs
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  9 10:53:03 2014
From: report at bugs.python.org (Adam Groszer)
Date: Wed, 09 Apr 2014 08:53:03 +0000
Subject: [New-bugs-announce] [issue21186] RawConfigParser __name__ option
	handling inconsistent
Message-ID: <1397033583.06.0.34789258522.issue21186@psf.upfronthosting.co.za>


New submission from Adam Groszer:

In RawConfigParser the "__name__" option handling is inconsistent:

RawConfigParser.options() and items() works hard to hide it, but has_options() does not

----------
components: Library (Lib)
messages: 215809
nosy: Adam.Groszer
priority: normal
severity: normal
status: open
title: RawConfigParser __name__ option handling inconsistent
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  9 11:21:17 2014
From: report at bugs.python.org (=?utf-8?q?Herv=C3=A9_Coatanhay?=)
Date: Wed, 09 Apr 2014 09:21:17 +0000
Subject: [New-bugs-announce] [issue21187] 2.7 build-installer.py with OS X
	10.9
Message-ID: <1397035277.67.0.354917057695.issue21187@psf.upfronthosting.co.za>


New submission from Herv? Coatanhay:

With XCode 5.1 some changes were made to clang, making it impossible to build Mac OS X installer.

Shipped SQLite and Sleepycat DB pass CFLAGS and LDFLAGS to compiler in their compiler check in configure script.

In particular -syslibroot option is a linker option not a compiler option, and since XCode 5.1 unused command line options are considered as errors.

I manage to work around this problem with the following extra CFLAGS:
-Wno-error=unused-command-line-argument-hard-error-in-future

I joined my modified version of build-installer.py

----------
assignee: ronaldoussoren
components: Macintosh
files: build-installer.py
messages: 215810
nosy: Alzakath, ronaldoussoren
priority: normal
severity: normal
status: open
title: 2.7 build-installer.py with OS X 10.9
versions: Python 2.7
Added file: http://bugs.python.org/file34773/build-installer.py

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

From report at bugs.python.org  Wed Apr  9 15:41:35 2014
From: report at bugs.python.org (LtWorf)
Date: Wed, 09 Apr 2014 13:41:35 +0000
Subject: [New-bugs-announce] [issue21188] Broken link
Message-ID: <1397050895.39.0.221241316975.issue21188@psf.upfronthosting.co.za>


New submission from LtWorf:

gcmodule.c lists a few reference links.

  http://www.arctrix.com/nas/python/gc/
  http://www.python.org/pipermail/python-dev/2000-March/003869.html
  http://www.python.org/pipermail/python-dev/2000-March/004010.html
  http://www.python.org/pipermail/python-dev/2000-March/004022.html

The last ones do not exist so they aren't very useful.

----------
components: Interpreter Core
messages: 215818
nosy: tiposchi
priority: normal
severity: normal
status: open
title: Broken link
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  9 15:42:56 2014
From: report at bugs.python.org (LtWorf)
Date: Wed, 09 Apr 2014 13:42:56 +0000
Subject: [New-bugs-announce] [issue21189] Broken link to patch
Message-ID: <1397050976.2.0.0354182649484.issue21189@psf.upfronthosting.co.za>


New submission from LtWorf:

This page

https://mail.python.org/mailman/listinfo/patches

suggests to go here: http://www.python.org/patches/ to know how to send patches. However that page doesn't exist.

----------
assignee: docs at python
components: Documentation
messages: 215819
nosy: docs at python, tiposchi
priority: normal
severity: normal
status: open
title: Broken link to patch
type: enhancement

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

From report at bugs.python.org  Wed Apr  9 16:48:36 2014
From: report at bugs.python.org (Selena Deckelmann)
Date: Wed, 09 Apr 2014 14:48:36 +0000
Subject: [New-bugs-announce] [issue21190] Broken download link on README for
	CPython docs
Message-ID: <1397054916.95.0.591389338462.issue21190@psf.upfronthosting.co.za>


New submission from Selena Deckelmann:

The page: https://github.com/python/cpython/blob/master/Doc/README.txt

Links to: http://docs.python.org/download/

Which is now a 404. A URL which may be correct is: https://docs.python.org/3/download.html

I'm unsure what the org policy is on linking most recent documentation, however. In the Postgres community, we have a 'current' symlink that always links to the most recent version.

----------
assignee: docs at python
components: Documentation
messages: 215821
nosy: Selena.Deckelmann, docs at python
priority: normal
severity: normal
status: open
title: Broken download link on README for CPython docs
type: enhancement

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

From report at bugs.python.org  Wed Apr  9 20:24:55 2014
From: report at bugs.python.org (Dima Tisnek)
Date: Wed, 09 Apr 2014 18:24:55 +0000
Subject: [New-bugs-announce] [issue21191] os.fdopen() may eat file
	descriptor and still raise	exception
Message-ID: <1397067895.73.0.194150876234.issue21191@psf.upfronthosting.co.za>


New submission from Dima Tisnek:

os.fdopen() should either:
* consume file descriptor and return file/io object, or
* leave file descriptor alone and raise an exception

this invariant is broken in the following test case:
fd = os.open("/", os.O_RDONLY)
try:
    obj = os.fdopen(fd, "r")
except EnvironmentError:
    os.close(fd)  # cleanup

what happens:
fd = os.open("/", os.O_RDONLY) --> some fd
os.fdopen(fd, "r") --> exception, fd refers to a directory
os.close(fd) --> exception, no such fd


For reference:
1. invariant is held in Python 3.3.
2. following positive test case works correctly
fd = os.open("/etc/passwd", os.O_RDONLY)
try: obj = os.fdopen(fd, "r")  # success
except EnvironmentError: os.close(fd)  # not reached
3. following negative test case works correctly
fd = os.open("/etc/passwd", os.O_RDONLY)
try: obj = os.fdopen(fd, "w")  # wrong mode on purpose
except EnvironmentError: os.close(fd)  # closed ok

----------
components: IO
messages: 215832
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: os.fdopen() may eat file descriptor and still raise exception
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  9 23:24:46 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Apr 2014 21:24:46 +0000
Subject: [New-bugs-announce] [issue21192] Idle: Print filename when running
	a file from editor
Message-ID: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Upon restarting the user process, Idle prints a separator bar in the shell:
====================================== RESTART=====================....
When restart is due to running a file with F5, print "RUN filename" instead of "RESTART". Idea from Adnan Umer, pydev list. For Shell / Restart Shell Cntl+F6, maybe change to "RESTART Shell" (my additional idea).

----------
messages: 215846
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: Print filename when running a file from editor
type: enhancement

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

From report at bugs.python.org  Thu Apr 10 02:24:57 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 10 Apr 2014 00:24:57 +0000
Subject: [New-bugs-announce] [issue21193] pow(a, b,
	c) should not raise TypeError when b is negative and c is provided
Message-ID: <1397089497.66.0.725830795875.issue21193@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

While checking the exceptions used to compare existing behavior while investigating #20539, I noticed a weird behavior in pow() (implemented by long_pow in longobject.c). If a 3rd argument (the modulus) is provided, and the 2nd argument (the exponent) is negative, the function raises TypeError. To my knowledge, TypeError should never be used for this purpose; some functions raise OverflowError for negative values (which violates the documented purpose of OverflowError, but the documents don't match CPython's implementation), others use ValueError (which I believe is appropriate, since it's not a matter of a C type limitation, the function is just logically restricted to the range [0,Largest possible PyLong]. 

I recommend switching to ValueError, possibly with a deprecation notice before making the switch if people think someone might rely on this behavior.

Related: #457066

----------
components: Interpreter Core
messages: 215860
nosy: josh.rosenberg
priority: normal
severity: normal
status: open
title: pow(a, b, c) should not raise TypeError when b is negative and c is provided
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr 10 11:31:10 2014
From: report at bugs.python.org (Weeble)
Date: Thu, 10 Apr 2014 09:31:10 +0000
Subject: [New-bugs-announce] [issue21194] json.dumps with ensure_ascii=False
	doesn't escape	control characters
Message-ID: <1397122270.44.0.660092890474.issue21194@psf.upfronthosting.co.za>


New submission from Weeble:

The JSON spec (http://www.json.org/) does not allow unescaped control characters. (See the railroad diagram for strings and the grammar on the right.) If json.dumps is called with ensure_ascii=False, it fails to escape control codes in the range U+007F to U+009F. Here's an example:

>>> import json
>>> import unicodedata
>>> for i in range(256):
...     jsonstring = json.dumps(chr(i), ensure_ascii=False)
...     if any(unicodedata.category(ch) == 'Cc' for ch in jsonstring):
...         print("Fail:",repr(chr(i)))
Fail: '\x7f'
Fail: '\x80'
Fail: '\x81'
Fail: '\x82'
Fail: '\x83'
Fail: '\x84'
Fail: '\x85'
Fail: '\x86'
Fail: '\x87'
Fail: '\x88'
Fail: '\x89'
Fail: '\x8a'
Fail: '\x8b'
Fail: '\x8c'
Fail: '\x8d'
Fail: '\x8e'
Fail: '\x8f'
Fail: '\x90'
Fail: '\x91'
Fail: '\x92'
Fail: '\x93'
Fail: '\x94'
Fail: '\x95'
Fail: '\x96'
Fail: '\x97'
Fail: '\x98'
Fail: '\x99'
Fail: '\x9a'
Fail: '\x9b'
Fail: '\x9c'
Fail: '\x9d'
Fail: '\x9e'
Fail: '\x9f'

----------
components: Library (Lib)
messages: 215868
nosy: weeble
priority: normal
severity: normal
status: open
title: json.dumps with ensure_ascii=False doesn't escape control characters
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 10 14:19:35 2014
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Thu, 10 Apr 2014 12:19:35 +0000
Subject: [New-bugs-announce] [issue21195] None float format: incomplete
	documentation
Message-ID: <1397132375.36.0.349385981395.issue21195@psf.upfronthosting.co.za>


New submission from Eric O. LEBIGOT:

The documentation for a None (empty) format for floats indicates that it is equivalent to the g format. This does not appear to be correct (http://stackoverflow.com/questions/16525924/precise-definition-of-float-string-formatting).

The Python?3.4 documentation (https://docs.python.org/3.4/library/string.html#format-specification-mini-language) seems to be much closer to what Python?2.7 does.

It would be useful to have a more correct documentation for the effect of a None format for floats in Python?2.7 (maybe by copying the Python?3.4 documentation if it applies).

----------
assignee: docs at python
components: Documentation
messages: 215871
nosy: docs at python, lebigot
priority: normal
severity: normal
status: open
title: None float format: incomplete documentation
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 10 14:31:20 2014
From: report at bugs.python.org (Chandan Kumar)
Date: Thu, 10 Apr 2014 12:31:20 +0000
Subject: [New-bugs-announce] [issue21196] Name mangling example in Python
	tutorial
Message-ID: <1397133080.37.0.870141660622.issue21196@psf.upfronthosting.co.za>


New submission from Chandan Kumar:

The example used for demonstrating name mangling could be better if two versions of code are shown - one with name mangling and one without.  I have modified the original example to incorporate this (see attached).

----------
assignee: docs at python
components: Documentation
files: name_mangling_works.py
messages: 215872
nosy: chandan, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Name mangling example in Python tutorial
type: enhancement
Added file: http://bugs.python.org/file34781/name_mangling_works.py

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

From report at bugs.python.org  Thu Apr 10 15:50:32 2014
From: report at bugs.python.org (Matthias Dahl)
Date: Thu, 10 Apr 2014 13:50:32 +0000
Subject: [New-bugs-announce] [issue21197] venv does not create lib64
	directory and appropriate	symlinks
Message-ID: <1397137832.25.0.881871760177.issue21197@psf.upfronthosting.co.za>


New submission from Matthias Dahl:

Creating a new venv on a multilib system does not install an appropriate link from lib to lib64 or the other way around. Currently, venv creates a single lib dir, but everything installed with pip within the venv, will be installed to lib64/... instead while lib will remain empty. For some third party apps, this is confusing.

virtualenv, for example, installs a lib64 symlink to lib automatically. IMHO, more correctly would be a lib to lib64 symlink.

----------
components: Library (Lib)
messages: 215883
nosy: BinaryKhaos
priority: normal
severity: normal
status: open
title: venv does not create lib64 directory and appropriate symlinks
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 10 18:43:47 2014
From: report at bugs.python.org (Andrew Scheller)
Date: Thu, 10 Apr 2014 16:43:47 +0000
Subject: [New-bugs-announce] [issue21198] Minor tarfile documentation bug
Message-ID: <1397148227.41.0.631676560193.issue21198@psf.upfronthosting.co.za>


New submission from Andrew Scheller:

I've just noticed that the documentation for TarInfo.type says
"To determine the type of a TarInfo object more conveniently, use the is_*() methods below."

However none of the methods mentioned actually contain an underscore, so I believe the documentation should be updated to "...use the is*() methods below."

(for comparison, the documentation for stat.S_IFMT correctly talks about "is*() functions")

----------
assignee: docs at python
components: Documentation
messages: 215892
nosy: docs at python, lurchman
priority: normal
severity: normal
status: open
title: Minor tarfile documentation bug
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr 10 18:58:53 2014
From: report at bugs.python.org (Matt Mackall)
Date: Thu, 10 Apr 2014 16:58:53 +0000
Subject: [New-bugs-announce] [issue21199] Python on 64-bit Windows uses
	signed 32-bit type for	read length
Message-ID: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za>


New submission from Matt Mackall:

Python's file_read uses an 'l' type to parse its args which results in a 31-bit size limit on reads on 64-bit Windows. It should instead use an ssize_t.

Related Mercurial bug:

http://bz.selenic.com/show_bug.cgi?id=4215

----------
components: IO
messages: 215893
nosy: Matt.Mackall, larry, ncoghlan
priority: normal
severity: normal
status: open
title: Python on 64-bit Windows uses signed 32-bit type for read length
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 11 16:07:35 2014
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Apr 2014 14:07:35 +0000
Subject: [New-bugs-announce] [issue21200] pkgutil.get_loader() fails on
	"__main__"
Message-ID: <1397225255.72.0.022634576387.issue21200@psf.upfronthosting.co.za>


New submission from Eric Snow:

Prior to 3.4, pkgutil.get_loader('__main__') would return None.  Now it results in an ImportError.  That's because it calls importlib.util.find_spec() which fails if an existing module does not have __spec__ or it is None.

----------
components: Library (Lib)
keywords: 3.4regression
messages: 215926
nosy: brett.cannon, eric.snow, larry, ncoghlan
priority: release blocker
severity: normal
stage: test needed
status: open
title: pkgutil.get_loader() fails on "__main__"
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Apr 11 19:20:20 2014
From: report at bugs.python.org (Wojciech Walczak)
Date: Fri, 11 Apr 2014 17:20:20 +0000
Subject: [New-bugs-announce] [issue21201] Uninformative error message in
	multiprocessing.Manager()
Message-ID: <1397236820.61.0.692426224091.issue21201@psf.upfronthosting.co.za>


New submission from Wojciech Walczak:

While using multiprocessing.Manager() to send data between processes I've noticed that one of the traceback messages is not very informative:

Traceback (most recent call last):
  File "age_predict.py", line 39, in <module>
    train_data, train_target, test_data = prepare_data()
  File "age_predict.py", line 30, in prepare_data
    train_data = q.get(True, 10000)
  File "<string>", line 2, in get
  File "/usr/lib/python2.7/multiprocessing/managers.py", line 777, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------
Unserializable message: ('#RETURN', [A WHOLE LOT OF DATA GOES HERE]
 

The real problem here is that my machine is running out of memory, but the traceback message shadows this information and reports "Unserializable message" instead.

After a simple path (see: attached file) the traceback message is as follows:


Traceback (most recent call last):
  File "age_predict.py", line 39, in <module>
    train_data, train_target, test_data = prepare_data()
  File "age_predict.py", line 30, in prepare_data
    train_data = q.get(True, 10000)
  File "<string>", line 2, in get
  File "/usr/lib/python2.7/multiprocessing/managers.py", line 775, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------
Unserializable message: Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/managers.py", line 288, in serve_client
    send(msg)
MemoryError: out of memory


Here's another example (see: http://bugs.python.org/issue6766):

This python3 code:

from multiprocessing import Manager
manager = Manager()
ns_proxy = manager.Namespace()
evt_proxy = manager.Event()
ns_proxy.my_event_proxy = evt_proxy
print(ns_proxy.my_event_proxy)


Produces following traceback message:


Traceback (most recent call last):
  File "test.py", line 6, in <module>
    print(ns_proxy.my_event_proxy)
  File "/cpython/Lib/multiprocessing/managers.py", line 1032, in __getattr__
    return callmethod('__getattribute__', (key,))
  File "/cpython/Lib/multiprocessing/managers.py", line 748, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
----------------------------------------------------------------------
Unserializable message: ('#RETURN', <threading.Event object at 0x7f9484aff278>)
----------------------------------------------------------------------


...and after applying the attached patch it becomes clearer what's going on:


Traceback (most recent call last):
  File "test.py", line 6, in <module>
    print(ns_proxy.my_event_proxy)
  File "/cpython/Lib/multiprocessing/managers.py", line 1032, in __getattr__
    return callmethod('__getattribute__', (key,))
  File "/cpython/Lib/multiprocessing/managers.py", line 748, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
----------------------------------------------------------------------
Unserializable message: Traceback (most recent call last):
  File "/cpython/Lib/multiprocessing/managers.py", line 276, in serve_client
    send(msg)
  File "/cpython/Lib/multiprocessing/connection.py", line 206, in send
    self._send_bytes(ForkingPickler.dumps(obj))
  File "/cpython/Lib/multiprocessing/reduction.py", line 50, in dumps
    cls(buf, protocol).dump(obj)
_pickle.PicklingError: Can't pickle <class '_thread.lock'>: attribute lookup lock on _thread failed

This patch doesn't break any tests.

----------
components: Library (Lib)
files: managers_tb_msg.patch
keywords: patch
messages: 215934
nosy: wojtekwalczak
priority: normal
severity: normal
status: open
title: Uninformative error message in multiprocessing.Manager()
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34785/managers_tb_msg.patch

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

From report at bugs.python.org  Fri Apr 11 20:05:51 2014
From: report at bugs.python.org (Madison May)
Date: Fri, 11 Apr 2014 18:05:51 +0000
Subject: [New-bugs-announce] [issue21202] Naming a file` io.py` causes
	cryptic error message
Message-ID: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za>


New submission from Madison May:

Naming a file `io.py` in the root directory of a project causes the following error on 2.7: 

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

Similar issues arise on 3.x., although the error message is a bit more useful:

    Fatal Python error: Py_Initialize: can't initialize sys standard streams
    AttributeError: 'module' object has no attribute 'OpenWrapper'

At the very least we should ensure that the error message is a bit more straightforward and clear, as I imagine its not all that uncommon to cause this kind of conflict.

----------
assignee: docs at python
components: Documentation, IO
messages: 215940
nosy: docs at python, madison.may
priority: normal
severity: normal
status: open
title: Naming a file` io.py` causes cryptic error message
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 11 23:39:28 2014
From: report at bugs.python.org (Jure Koren)
Date: Fri, 11 Apr 2014 21:39:28 +0000
Subject: [New-bugs-announce] [issue21203] logging configurators ignoring
	documented options
Message-ID: <1397252368.02.0.0923177521945.issue21203@psf.upfronthosting.co.za>


New submission from Jure Koren:

2.7's logging.config.DictConfig does not respect the "class" option, but fileConfig does.

The default branch logging.config has the same problem in DictConfig, but also lacks "style" support in fileConfig.

----------
components: Library (Lib)
files: logging_config_2_7.diff
hgrepos: 233
keywords: patch
messages: 215954
nosy: Jure.Koren
priority: normal
severity: normal
status: open
title: logging configurators ignoring documented options
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file34787/logging_config_2_7.diff

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

From report at bugs.python.org  Sat Apr 12 03:50:40 2014
From: report at bugs.python.org (jmaki)
Date: Sat, 12 Apr 2014 01:50:40 +0000
Subject: [New-bugs-announce] [issue21204] published examples don't work
Message-ID: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za>


New submission from jmaki:

Would you consider putting examples given in official documentation as part of release testing?  e.g. (from official python.org documentation):
----------------- snip ---------------------

An example of how a pool of worker processes can each run a SimpleHTTPServer.HttpServer instance while sharing a single listening socket.

#
# Example where a pool of http servers share a single listening socket
#
# On Windows this module depends on the ability to pickle a socket
# object so that the worker processes can inherit a copy of the server
# object.  (We import `multiprocessing.reduction` to enable this pickling.)
#
# Not sure if we should synchronize access to `socket.accept()` method by
# using a process-shared lock -- does not seem to be necessary.
#
# Copyright (c) 2006-2008, R Oudkerk
# All rights reserved.
#

import os
import sys

from multiprocessing import Process, current_process, freeze_support
from BaseHTTPServer import HTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler

if sys.platform == 'win32':
    import multiprocessing.reduction    # make sockets pickable/inheritable


def note(format, *args):
    sys.stderr.write('[%s]\t%s\n' % (current_process().name, format%args))


class RequestHandler(SimpleHTTPRequestHandler):
    # we override log_message() to show which process is handling the request
    def log_message(self, format, *args):
        note(format, *args)

def serve_forever(server):
    note('starting server')
    try:
        server.serve_forever()
    except KeyboardInterrupt:
        pass


def runpool(address, number_of_processes):
    # create a single server object -- children will each inherit a copy
    server = HTTPServer(address, RequestHandler)

    # create child processes to act as workers
    for i in range(number_of_processes-1):
        Process(target=serve_forever, args=(server,)).start()

    # main process also acts as a worker
    serve_forever(server)


def test():
    DIR = os.path.join(os.path.dirname(__file__), '..')
    ADDRESS = ('localhost', 8000)
    NUMBER_OF_PROCESSES = 4

    print 'Serving at http://%s:%d using %d worker processes' % \
          (ADDRESS[0], ADDRESS[1], NUMBER_OF_PROCESSES)
    print 'To exit press Ctrl-' + ['C', 'Break'][sys.platform=='win32']

    os.chdir(DIR)
    runpool(ADDRESS, NUMBER_OF_PROCESSES)


if __name__ == '__main__':
    freeze_support()
    test()
----------------- snip ---------------------
does not work on windows...

Regards,
John

----------
components: Cross-Build
messages: 215957
nosy: jmaki
priority: normal
severity: normal
status: open
title: published examples don't work
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 12 13:14:07 2014
From: report at bugs.python.org (=?utf-8?q?Szieberth_=C3=81d=C3=A1m?=)
Date: Sat, 12 Apr 2014 11:14:07 +0000
Subject: [New-bugs-announce] [issue21205] Unable to make decorated generator
	object to inherit	generator function's __name__
Message-ID: <1397301247.66.0.634427842107.issue21205@psf.upfronthosting.co.za>


New submission from Szieberth ?d?m:

I faced this particular issue by writing decorators for asyncio coroutines. 

I even posted a question to SO: http://stackoverflow.com/questions/23015626/how-to-decorate-an-asyncio-coroutine-to-retain-its-name

However, since that I realized the problem is more general. I believe that a generator object should inherit its function's __name__ attribute instead of ignoring it. Example:


################################################################
import functools

def decorated(genfunc):
    @functools.wraps(genfunc)
    def wrapper(*args, **kargs):
        print('inside wrapper')
        for x in genfunc(*args, **kargs):
            yield 'decorated: {!r}'.format(x)
    print('outside wrapper')
    print('wrapper.__name__: {!r}'.format(wrapper.__name__))
    return wrapper

@decorated
def simple_genfunc():
    """Testdoc."""
    yield from range(10)

if __name__ == '__main__':
    print('simple_genfunc.__name__: {!r}'.format(
        simple_genfunc.__name__))
    print('simple_genfunc().__name__: {!r}'.format(
        simple_genfunc().__name__))
################################################################

And its result:

Z:\>python -i genfuncdec.py
outside wrapper
wrapper.__name__: 'simple_genfunc'
simple_genfunc.__name__: 'simple_genfunc'
simple_genfunc().__name__: 'wrapper'
>>> simple_genfunc
<function simple_genfunc at 0x00C30420>
>>> simple_genfunc.__wrapped__
<function simple_genfunc at 0x00C304B0>
>>> simple_genfunc()
<generator object wrapper at 0x00C0EE18>
>>> simple_genfunc.__wrapped__()
<generator object simple_genfunc at 0x00C0ED28>

As you can see the generator object's __name__ remained the hardcoded one.

----------
messages: 215968
nosy: SzieberthAdam
priority: normal
severity: normal
status: open
title: Unable to make decorated generator object to inherit generator function's __name__
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 12 14:29:43 2014
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 12 Apr 2014 12:29:43 +0000
Subject: [New-bugs-announce] [issue21206] Provide legit HTTPS certificate
	for	http://bugs.python.org/, redirect HTTP to HTTPS
Message-ID: <1397305783.0.0.175051224011.issue21206@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Otherwise people could MITM our passwords.

----------
components: Demos and Tools
messages: 215970
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Provide legit HTTPS certificate for http://bugs.python.org/, redirect HTTP to HTTPS

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

From report at bugs.python.org  Sat Apr 12 17:33:39 2014
From: report at bugs.python.org (Steven Hiscocks)
Date: Sat, 12 Apr 2014 15:33:39 +0000
Subject: [New-bugs-announce] [issue21207] urandom persistent fd - not
	re-openned after fd close
Message-ID: <1397316819.31.0.463593532744.issue21207@psf.upfronthosting.co.za>


New submission from Steven Hiscocks:

I've seen an issue with using urandom on Python 3.4. I've traced down to fd being closed (not by core CPython, but by third party library code). After this, access to urandom fails.

I assume this is related to persistent fd for urandom in http://bugs.python.org/issue18756

$ python -c "import os;os.urandom(1);os.closerange(3,256);os.urandom(1)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor

----------
messages: 215973
nosy: kwirk
priority: normal
severity: normal
status: open
title: urandom persistent fd - not re-openned after fd close
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 12 23:58:04 2014
From: report at bugs.python.org (Karl Richter)
Date: Sat, 12 Apr 2014 21:58:04 +0000
Subject: [New-bugs-announce] [issue21208] Change default behavior of
	arguments with type bool when	options are specified
Message-ID: <1397339884.4.0.416428545862.issue21208@psf.upfronthosting.co.za>


New submission from Karl Richter:

As arguments with type bool are the only ones whose values can be manipulated without passing an option to the argument on CLI, the default behavior for those should be changed from ignoring options to failing when options are specified. Consider the following example:
<code>

import argparse

cache_size_default=1000
cache_size_option = "c"
cache_size_option_long = "cache-size"
start_db_default = False
start_db_option = "t"
start_db_option_long = "start-db"


parser = argparse.ArgumentParser(description='Process some integers.')               
parser.add_argument("-%s" % start_db_option, "--%s" % start_db_option_long, default=start_db_default, type=bool, nargs='?',
                   help='@TODO', dest=start_db_option_long)
parser.add_argument("-%s" % cache_size_option, "--%s" % cache_size_option_long, type=int, nargs='?', default=cache_size_default, 
                   help='size of osm2pgsql cache', dest=cache_size_option_long)

def osm_postgis_transform(cache_size=cache_size_default, start_db=start_db_default):
    print(start_db, cache_size)

if __name__ == "__main__":
    args = vars(parser.parse_args())
    osm_postgis_transform(cache_size=args[cache_size_option_long], start_db=args[start_db_option_long])
</code>

When the script is invoked with 
<code>
python issue-argparse.py --start-db False --cache-size 2000
</code>
The value for start-db is True which is not really intuitive. Changing the default behavior to either fail at argument parsing or overwrite the argument value would be an improvement in my opinion.

----------
components: Library (Lib)
messages: 215983
nosy: krichter
priority: normal
severity: normal
status: open
title: Change default behavior of arguments with type bool when options are specified
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr 13 03:10:42 2014
From: report at bugs.python.org (Richard Kiss)
Date: Sun, 13 Apr 2014 01:10:42 +0000
Subject: [New-bugs-announce] [issue21209] q.put(some_tuple) fails when
	PYTHONASYNCIODEBUG=1
Message-ID: <1397351442.01.0.248805040826.issue21209@psf.upfronthosting.co.za>


New submission from Richard Kiss:

import asyncio
import os

def t1(q):
    yield from asyncio.sleep(0.5)
    q.put_nowait((0, 1, 2, 3, 4, 5))

def t2(q):
    v = yield from q.get()
    print(v)

q = asyncio.Queue()
asyncio.get_event_loop().run_until_complete(asyncio.wait([t1(q), t2(q)]))



When PYTHONASYNCIODEBUG is set to 1, this causes a strange error:

TypeError: send() takes 2 positional arguments but 7 were given

See also https://gist.github.com/richardkiss/10564363

----------
components: Library (Lib)
files: put_get_bug.py
messages: 215991
nosy: richard.kiss
priority: normal
severity: normal
status: open
title: q.put(some_tuple) fails when PYTHONASYNCIODEBUG=1
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34795/put_get_bug.py

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

From report at bugs.python.org  Sun Apr 13 12:19:27 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 13 Apr 2014 10:19:27 +0000
Subject: [New-bugs-announce] [issue21210] Warnings in Doc/library/json.rst
Message-ID: <1397384367.1.0.38760092166.issue21210@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Warnings during building of documentation (with Sphinx 1.2.2):

${cpython_working_copy}/Doc/library/json.rst:593: WARNING: Malformed option description '[<infile>]', should look like "opt", "-opt args", "--opt args" or "/opt args"
${cpython_working_copy}/Doc/library/json.rst:609: WARNING: Malformed option description '[<outfile>]', should look like "opt", "-opt args", "--opt args" or "/opt args"


Probably introduced by:

New changeset a2ad16e86e60 by Benjamin Peterson in branch 'default':
improve the command-line interface of json.tool (closes #21000)
http://hg.python.org/cpython/rev/a2ad16e86e60

----------
assignee: docs at python
components: Documentation
messages: 216012
nosy: Arfrever, benjamin.peterson, berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Warnings in Doc/library/json.rst
versions: Python 3.5

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

From report at bugs.python.org  Mon Apr 14 03:48:18 2014
From: report at bugs.python.org (Eric Snow)
Date: Mon, 14 Apr 2014 01:48:18 +0000
Subject: [New-bugs-announce] [issue21211] pkgutil.find_loader() raises
	ImportError instead of	returning None
Message-ID: <1397440098.66.0.10150246835.issue21211@psf.upfronthosting.co.za>


New submission from Eric Snow:

In 3987667bf98f pkgutil.find_loader() switched from using pkgutil.iter_importers() to importlib.find_module().  importlib.find_module() checks the module's __loader__ (and raises ImportError when invalid) whereas iter_importers() does no such check.  In 3.4 pkgutil.find_loader() switched over to importlib.util.find_spec(), but the same issue remains.

The documentation (and the previous behavior) implies that the ImportError case coming out of find_spec() should result in pkgutil.find_loader() returning None rather than propagating the ImportError.  However, it may make more sense to do an explicit check for module.__spec__ before calling find_spec().

----------
components: Library (Lib)
keywords: 3.3regression
messages: 216047
nosy: brett.cannon, eric.snow, ncoghlan
priority: high
severity: normal
stage: test needed
status: open
title: pkgutil.find_loader() raises ImportError instead of returning None
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 14 12:27:52 2014
From: report at bugs.python.org (Bill)
Date: Mon, 14 Apr 2014 10:27:52 +0000
Subject: [New-bugs-announce] [issue21212] Documentation of octal
	representation
Message-ID: <1397471272.26.0.476582477816.issue21212@psf.upfronthosting.co.za>


New submission from Bill:

This documentation section:
https://docs.python.org/3/faq/programming.html?highlight=octal#how-do-i-convert-a-string-to-a-number
seems still to refer to Python 2 octal representation rules.  So I think it needs updating.

----------
assignee: docs at python
components: Documentation
messages: 216069
nosy: docs at python, ees1wc
priority: normal
severity: normal
status: open
title: Documentation of octal representation
versions: Python 3.5

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

From report at bugs.python.org  Mon Apr 14 12:56:20 2014
From: report at bugs.python.org (saaj)
Date: Mon, 14 Apr 2014 10:56:20 +0000
Subject: [New-bugs-announce] [issue21213] Memory bomb by incorrect custom
	serializer to json.dumps
Message-ID: <1397472980.58.0.747239124099.issue21213@psf.upfronthosting.co.za>


New submission from saaj:

I was chaning an implementation of the function that is passed to json.dumps to extend serializable types. By a mistake (**return** instead of **raise**) it turned into, which at its minum can be expressed as::

  def d(obj):
    return TypeError(repr(obj))

  json.dumps(1j, default = d) 

After a few moments by laptop froze, though after a minute I could open shell in separate session, and top command showed that python interpretter is consuming about 4GiB of memory and 50% of 4 logical cores. 

Worst about it it doesn't end with any exception, it just keeps running. Without ``repr`` it ends up with somewhat expected ``RuntimeError: maximum recursion depth exceeded while getting the str of an object``.

The same behaviour is on python3, where it just consumes memory with less speed.

OS:
Linux Mint 15 Olivia
Linux 3.8.0-31-generic #46-Ubuntu SMP Tue Sep 10 20:03:44 UTC 2013 x86_64

Packages are last available:
python  2.7.4-0ubuntu1
python3 3.3.1-0ubuntu1

P.S. Sorry for confirming on console at python.org.

----------
components: Library (Lib)
messages: 216071
nosy: saaj
priority: normal
severity: normal
status: open
title: Memory bomb by incorrect custom serializer to json.dumps
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Apr 14 12:56:48 2014
From: report at bugs.python.org (Max)
Date: Mon, 14 Apr 2014 10:56:48 +0000
Subject: [New-bugs-announce] [issue21214] PEP8 doesn't verifies last line.
Message-ID: <1397473008.16.0.589712563866.issue21214@psf.upfronthosting.co.za>


New submission from Max:

PEP8 doesn't verifies last line at all. Also W292 will never be checked.
Reproducible on PEP8 >= 1.5.0

----------
messages: 216072
nosy: f1ashhimself
priority: normal
severity: normal
status: open
title: PEP8 doesn't verifies last line.
type: behavior

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

From report at bugs.python.org  Mon Apr 14 16:18:49 2014
From: report at bugs.python.org (Glenn Jones)
Date: Mon, 14 Apr 2014 14:18:49 +0000
Subject: [New-bugs-announce] [issue21215] build-deps instructions for Ubuntu
Message-ID: <1397485129.87.0.0518806030798.issue21215@psf.upfronthosting.co.za>


New submission from Glenn Jones:

The package listed in the dev guide may not exist depending on the version of Ubuntu. It may be necessary to use python3.3 or python3.4.

----------
components: Devguide
messages: 216080
nosy: Glenn.Jones, ezio.melotti
priority: normal
severity: normal
status: open
title: build-deps instructions for Ubuntu

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

From report at bugs.python.org  Mon Apr 14 19:21:43 2014
From: report at bugs.python.org (Julien Palard)
Date: Mon, 14 Apr 2014 17:21:43 +0000
Subject: [New-bugs-announce] [issue21216] getaddrinfo is wrongly considered
	thread safe on linux
Message-ID: <1397496103.55.0.0681287877532.issue21216@psf.upfronthosting.co.za>


New submission from Julien Palard:

I just found that python consider linux implementation of getaddrinfo thread safe :

./python2.6-2.6.8/Modules/socketmodule.c:180

/* On systems on which getaddrinfo() is believed to not be thread-safe,                                                                                                                                                             
   (this includes the getaddrinfo emulation) protect access with a lock. */
#if defined(WITH_THREAD) && (defined(__APPLE__) || \
    (defined(__FreeBSD__) && __FreeBSD_version+0 < 503000) || \
    defined(__OpenBSD__) || defined(__NetBSD__) || \
    defined(__VMS) || !defined(HAVE_GETADDRINFO))
#define USE_GETADDRINFO_LOCK
#endif

Badly, it's wrong on my version of linux, and maybe others : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722075

So for me, looping in three threads on getaddrinfo leads me to a rapid deadlock, while reading on a NETLINK socket, after another thread wrote a DNS query on it and trying to get a response on it.

It may only be reproductible when your getaddrinfo use a NETLINK to get informations about your interfaces before doing the DNS query.

----------
messages: 216121
nosy: Julien.Palard
priority: normal
severity: normal
status: open
title: getaddrinfo is wrongly considered thread safe on linux

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

From report at bugs.python.org  Mon Apr 14 19:31:00 2014
From: report at bugs.python.org (Thomas Ballinger)
Date: Mon, 14 Apr 2014 17:31:00 +0000
Subject: [New-bugs-announce] [issue21217] inspect.getsourcelines finds wrong
	lines when lambda	used argument to decorator
Message-ID: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za>


New submission from Thomas Ballinger:

https://gist.github.com/thomasballinger/10666031

"""
inspect.getsourcelines incorrectly guesses what lines correspond
to the function foo
 
see getblock in inspect.py
once it finds a lambda, def or class it finishes it then stops
so get getsourcelines returns only the first two noop decorator
lines of bar, while normal behavior is to return all decorators
as it does for foo
"""
import inspect
from pprint import pprint
 
def noop(arg):
    def inner(func):
        return func
    return inner
 
@noop(1)
@noop(2)
def foo():
    return 1
 
@noop(1)
@noop(lambda: None)
@noop(1)
def bar():
    return 1
 
pprint(inspect.getsourcelines(foo))
pprint(inspect.getsourcelines(bar))

----------
components: Library (Lib)
messages: 216127
nosy: ballingt
priority: normal
severity: normal
status: open
title: inspect.getsourcelines finds wrong lines when lambda used argument to decorator
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 14 19:57:48 2014
From: report at bugs.python.org (Jeff Ramnani)
Date: Mon, 14 Apr 2014 17:57:48 +0000
Subject: [New-bugs-announce] [issue21218] Test failure for
	test_ssl.test_default_ecdh_curve on OS X
Message-ID: <1397498268.54.0.53776547909.issue21218@psf.upfronthosting.co.za>


New submission from Jeff Ramnani:

The unittest, test_ssl.test_default_ecdh_curve, is failing on OS X (and FreeBSD 9).

The test fails with the error message:
"""
======================================================================
ERROR: test_default_ecdh_curve (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/jramnani/code/cpython/Lib/test/test_ssl.py", line 2596, in test_default_ecdh_curve
    context.set_ciphers("ECDH")
ssl.SSLError: ('No cipher can be selected.',)

----------------------------------------------------------------------
"""

It looks to be related to issue, #21015 (changesets 3b81d1b3f9d1 and 869277faf3dc).


OS Info:
* Version: OS X 10.9.2
* OpenSSL version: OpenSSL 0.9.8y 5 Feb 2013


The problem looks like OpenSSL on OS X is reporting that it has ECDH when it does not.

Python 3.5.0a0 (default:8cf384852680, Apr 14 2014, 13:32:46)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.HAS_ECDH
True

----------
components: Tests
messages: 216138
nosy: jramnani
priority: normal
severity: normal
status: open
title: Test failure for test_ssl.test_default_ecdh_curve on OS X
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 14 20:16:10 2014
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 14 Apr 2014 18:16:10 +0000
Subject: [New-bugs-announce] [issue21219] WARNING: Inline literal
	start-string without end-string.
Message-ID: <1397499370.92.0.332930990444.issue21219@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

When I build the documentation, I get a warning about the NEWS file. Just add a new patch for this warning.


> (sphinx) make html
sphinx-build -b html -d build/doctrees -D latex_paper_size=  . build/html
Making output directory...
Running Sphinx v1.2.2
loading pickled environment... not yet created
building [html]: targets for 455 source files that are out of date
updating environment: 455 added, 0 changed, 0 removed
reading sources... [100%] whatsnew/index
../../Misc/NEWS:44: WARNING: Inline literal start-string without end-string.
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done

----------
assignee: docs at python
components: Documentation
messages: 216149
nosy: docs at python, matrixise
priority: normal
severity: normal
status: open
title: WARNING: Inline literal start-string without end-string.
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon Apr 14 20:23:06 2014
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 14 Apr 2014 18:23:06 +0000
Subject: [New-bugs-announce] [issue21220] Enhance obmalloc allocation
	strategy
Message-ID: <1397499786.06.0.606856949694.issue21220@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

A new allocation policy, "lowest address strategy" improves fragmentation of memory in obmalloc.  pools with available memory are chosen by lowest address preference.  This increases the likelihood that unused pools are released to their corresponding arenas.  Arenas with available pools are similarly chosen by lowest address.
This significantly helps fragmentation in programs with dynamic memory usage, e.g. long running programs.  Initial tests also indicate some minor performance benefits of the pybench, probably due to better cache behaviour.

----------
components: Interpreter Core
files: obmalloc.patch
keywords: patch
messages: 216156
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Enhance obmalloc allocation strategy
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file34836/obmalloc.patch

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

From report at bugs.python.org  Mon Apr 14 20:29:20 2014
From: report at bugs.python.org (Andrew Scheller)
Date: Mon, 14 Apr 2014 18:29:20 +0000
Subject: [New-bugs-announce] [issue21221] Minor struct_time documentation bug
Message-ID: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za>


New submission from Andrew Scheller:

The documentation for time.struct_time (in Doc/library/time.rst) explains tm_isdst as "0, 1 or -1; see below" but then doesn't really go into further detail below, other than to say "A -1 argument as the daylight savings flag, passed to mktime() will usually result in the correct daylight savings state to be filled in.".

In Modules/timemodule.c there's a section which says:
{"tm_isdst", "1 if summer time is in effect, 0 if not, and -1 if unknown"},

IMHO it would be nice if this more accurate info was also present in the HTML documentation.

----------
assignee: docs at python
components: Documentation
messages: 216158
nosy: docs at python, lurchman
priority: normal
severity: normal
status: open
title: Minor struct_time documentation bug
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 14 21:54:11 2014
From: report at bugs.python.org (Kushal Das)
Date: Mon, 14 Apr 2014 19:54:11 +0000
Subject: [New-bugs-announce] [issue21222] Mock create_autospec with name
	argument fails
Message-ID: <1397505251.05.0.288307474202.issue21222@psf.upfronthosting.co.za>


New submission from Kushal Das:

>>> from unittest import mock
>>> def b():
...   print("hello")
... 
>>> q = mock.create_autospec(b, name="a")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/kdas/code/python/cpython3/Lib/unittest/mock.py", line 2092, in create_autospec
    name=_name, **_kwargs)
TypeError: type object got multiple values for keyword argument 'name'

The issue was originally reported on mock bug tracker. I am working on a patch for the same.

----------
components: Library (Lib)
messages: 216190
nosy: kushaldas
priority: normal
severity: normal
status: open
title: Mock create_autospec with name argument fails
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Apr 14 22:25:13 2014
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 14 Apr 2014 20:25:13 +0000
Subject: [New-bugs-announce] [issue21223] fix test_site/test_startup_imports
	when some of the	extensions are built as builtins
Message-ID: <1397507113.83.0.846424139619.issue21223@psf.upfronthosting.co.za>


New submission from Matthias Klose:

fix test_site/test_startup_imports when some of the extensions are built as builtins.

--- a/Lib/test/test_site.py	Mon Apr 14 12:24:37 2014 -0400
+++ b/Lib/test/test_site.py	Mon Apr 14 22:17:57 2014 +0200
@@ -459,7 +459,8 @@
         # http://bugs.python.org/issue19218>
         collection_mods = {'_collections', 'collections', 'functools',
                            'heapq', 'itertools', 'keyword', 'operator',
-                           'reprlib', 'types', 'weakref'}
+                           'reprlib', 'types', 'weakref'
+                          }.difference(sys.builtin_module_names)
         self.assertFalse(modules.intersection(collection_mods), stderr)

the test now passes indepedent of the status of _collections (builtin or extension).

----------
components: Tests
keywords: patch
messages: 216200
nosy: doko, eric.snow
priority: normal
severity: normal
stage: patch review
status: open
title: fix test_site/test_startup_imports when some of the extensions are built as builtins
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 14 22:43:52 2014
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 14 Apr 2014 20:43:52 +0000
Subject: [New-bugs-announce] [issue21224] BaseHTTPRequestHandler,
	update the protocol version to http 1.1 by default?
Message-ID: <1397508232.09.0.0337317788686.issue21224@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

Hi,

With this issue, I would like to ask you to use the last version of the HTTP protocol in the BaseHTTPRequestHandler for Python 3.5.
Because this one uses the version 1.0 of the protocol for the backward-compatibility.

https://docs.python.org/3/library/http.server.html?highlight=protocol_version#http.server.BaseHTTPRequestHandler.protocol_version

When we develop an web app with Flask/Werkzeug or an other tool, the default version of 
the protocol is "HTTP/1.0". If we use Gunicorn, the protocol version is HTTP/1.1 and not 1.0, but this one can support the old version.

So, I propose to change the default version to the HTTP/1.1. It seems that the code of the server can handle this version without any problem.

HTTP 1.0 - http://www.ietf.org/rfc/rfc1945.txt - 1996
HTTP 1.1 - http://www.ietf.org/rfc/rfc2616.txt - 1999

In 2014, I think we can move to HTTP 1.1 by default.

Regards,

Stephane

----------
components: Library (Lib)
messages: 216206
nosy: matrixise
priority: normal
severity: normal
status: open
title: BaseHTTPRequestHandler, update the protocol version to http 1.1 by default?
versions: Python 3.5

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

From report at bugs.python.org  Mon Apr 14 22:50:46 2014
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 14 Apr 2014 20:50:46 +0000
Subject: [New-bugs-announce] [issue21225] io.py: Improve docstrings for
	classes
Message-ID: <1397508646.21.0.210626779275.issue21225@psf.upfronthosting.co.za>


New submission from A.M. Kuchling:

io.py contains the following to declare ABCs for some of its classes:

class IOBase(_io._IOBase, metaclass=abc.ABCMeta):
    pass

(and similarly for RawIOBase, BufferedIOBase, TextIOBase).

_io._IOBase has an extensive docstring, but IOBase doesn't. (Python doesn't inherit parent-class docstrings, on the theory that the subclass may change things that make the docstring invalid.)

I propose the attached patch.

----------
files: io-copy-docstrings.patch
keywords: easy, patch
messages: 216210
nosy: akuchling
priority: normal
severity: normal
stage: patch review
status: open
title: io.py: Improve docstrings for classes
type: enhancement
Added file: http://bugs.python.org/file34847/io-copy-docstrings.patch

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

From report at bugs.python.org  Mon Apr 14 23:04:27 2014
From: report at bugs.python.org (Trevor Caira)
Date: Mon, 14 Apr 2014 21:04:27 +0000
Subject: [New-bugs-announce] [issue21226] PyImport_ExecCodeModuleObject not
	setting module	attributes
Message-ID: <1397509467.13.0.547431443442.issue21226@psf.upfronthosting.co.za>


New submission from Trevor Caira:

In Python/import.c, PyImport_ExecCodeModuleObject creates a new module object but doesn't set all of the attributes required for modules, such as __spec__ or __loader__.

This breaks mod_wsgi from 3.3 and up, which depends on PyImport_ExecCodeModuleEx, which delegates to PyImport_ExecCodeModuleObject for its module creation logic. See https://code.google.com/p/modwsgi/source/browse/mod_wsgi/mod_wsgi.c#6289

----------
components: Library (Lib)
messages: 216217
nosy: brett.cannon, eric.snow, ncoghlan, trevor3
priority: normal
severity: normal
status: open
title: PyImport_ExecCodeModuleObject not setting module attributes
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 15 02:02:39 2014
From: report at bugs.python.org (leewz)
Date: Tue, 15 Apr 2014 00:02:39 +0000
Subject: [New-bugs-announce] [issue21227] Decimal class error messages for
	integer division aren't	good
Message-ID: <1397520159.39.0.440264883295.issue21227@psf.upfronthosting.co.za>


New submission from leewz:

Python's `decimal.Decimal` doesn't seem to like taking modulo or intdiv of large Decimals by integers (where "large" depends on how many digits are internally stored).

    >>> from decimal import *
    >>> getcontext().prec
    28
    >>> Decimal(10**29)%1
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    decimal.InvalidOperation: [<class 'decimal.DivisionImpossible'>]
    >>> getcontext().prec=50
    >>> Decimal(10**29)%1
    Decimal('0')

Same for `Decimal(10**29)//1`

This is a logical problem: "Alice has a 100-digit number which begins with 1543256. What is the last digit?"

But I found the error hard to understand. Searching for "DivisionImpossible" didn't turn up anything immediate (it wasn't added to the official docs?). I was most of the way through writing out a question to StackOverflow when it clicked. (Also, why is it an InvalidOperation that holds an exception as a message? Never saw that before.)

Suggestions:
- Improve docs with further examples. The examples of InvalidOperation are logical MATH errors (e.g. division by 0), not logical PROGRAMMING errors.
- Uh, maybe the error message could be changed to something like, "The answer you seek lies beyond the mantissa." Or more sanely, "Not enough precision to compute the answer." Or something else that hints to me to look into precision.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 216253
nosy: docs at python, leewz
priority: normal
severity: normal
status: open
title: Decimal class error messages for integer division aren't good
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 15 02:08:03 2014
From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=)
Date: Tue, 15 Apr 2014 00:08:03 +0000
Subject: [New-bugs-announce] [issue21228] Missing enumeration of
	HTTPResponse Objects methods of	urllib.request.urlopen's
	http.client.HTTPResponse?
Message-ID: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>


New submission from Evens Fortun?:

In the Python Library documentation, in section "21.6. urllib.request ? Extensible library for opening URLs", in the description of the urllib.request.urlopen() function it is writen:

---------

[?]
For http and https urls, this function returns a http.client.HTTPResponse object which has the following HTTPResponse Objects methods.

For ftp, file, and data urls and requests explicity handled by legacy [?]

---------

The first sentence seemed to imply that something is supposed to be specified if I understand correctly. Is it me missing something??

----------
assignee: docs at python
components: Documentation
messages: 216254
nosy: EvensF, docs at python
priority: normal
severity: normal
status: open
title: Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse?
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 15 02:36:23 2014
From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=)
Date: Tue, 15 Apr 2014 00:36:23 +0000
Subject: [New-bugs-announce] [issue21229] Path used for HTTP PUT request
	doesn't match the	description
Message-ID: <1397522183.41.0.398189687255.issue21229@psf.upfronthosting.co.za>


New submission from Evens Fortun?:

In the Python Standard Library, at the end of :
 - Section "20.7.3. Examples" of "20.7. httplib ? HTTP protocol client" (for Python 2.7.6) 
 - Section "20.10.3. Examples" of "20.10. http.client ? HTTP protocol client" (for Python 3.2.5)
 - Section "21.12.3. Examples" of "21.12. http.client ? HTTP protocol client" (for Python 3.3.5, Python 3.4.0, and Python 3.5a0)

the last example is described this way (change httplib for http.client for Python 3.2+):

--------

>>> # This creates an HTTP message
>>> # with the content of BODY as the enclosed representation
>>> # for the resource http://localhost:8080/foobar
...
>>> import httplib
>>> BODY = "***filecontents***"
>>> conn = httplib.HTTPConnection("localhost", 8080)
>>> conn.request("PUT", "/file", BODY)
>>> response = conn.getresponse()
>>> print response.status, response.reason
200, OK

--------

Is it possible that the request method should have been called this way:

conn.request("PUT", "/foobar", BODY)
                      ^^^^^^
Thank you

----------
assignee: docs at python
components: Documentation
messages: 216257
nosy: EvensF, docs at python
priority: normal
severity: normal
status: open
title: Path used for HTTP PUT request doesn't match the description
type: enhancement
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/issue21229>
_______________________________________

From report at bugs.python.org  Tue Apr 15 03:13:51 2014
From: report at bugs.python.org (Faiz Abbasi)
Date: Tue, 15 Apr 2014 01:13:51 +0000
Subject: [New-bugs-announce] [issue21230] imghdr does not accept adobe
	photoshop mime type
Message-ID: <1397524431.49.0.471880586962.issue21230@psf.upfronthosting.co.za>


New submission from Faiz Abbasi:

Python 2.7

I noticed a recurring bug we've had attempting to send a particular JPEG image in emails:

email.mime.image.__init__
<unknown>: Could not guess image MIME subtype

After looking into the imghdr.what and tests source code, I noticed that this JPEG image begins with the following data: 
'\xff\xd8\xff\xee\x00\x0eAdobe\x00d\x00\x00\x00\x00\x00\xff\xed\x008Photoshop '

I've attached the image in question to this bug report.

There's two functions for asserting an image is JPEG format, test_jpeg and test_exif. I'd like to propose another function for resolving Adobe Photoshop image formats.

Unless, of course, this is expected behavior?

Thanks!

----------
components: email
files: image.jpeg
messages: 216260
nosy: barry, benjamin.peterson, faiz, r.david.murray
priority: normal
severity: normal
status: open
title: imghdr does not accept adobe photoshop mime type
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file34862/image.jpeg

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

From report at bugs.python.org  Tue Apr 15 05:01:53 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 15 Apr 2014 03:01:53 +0000
Subject: [New-bugs-announce] [issue21231] Issue a python 3 warning when old
	style classes are	defined.
Message-ID: <1397530913.57.0.912065211904.issue21231@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

This will assist in porting applications from Python2 to Python3.

----------
files: old-style-classes.diff
keywords: patch
messages: 216273
nosy: alex
priority: normal
severity: normal
status: open
title: Issue a python 3 warning when old style classes are defined.
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file34865/old-style-classes.diff

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

From report at bugs.python.org  Tue Apr 15 08:06:37 2014
From: report at bugs.python.org (Jayanth Koushik)
Date: Tue, 15 Apr 2014 06:06:37 +0000
Subject: [New-bugs-announce] [issue21232] Use of '1' instead of 'True' as
	'splitlines' argument in	difflib documentation
Message-ID: <1397541997.96.0.890116395425.issue21232@psf.upfronthosting.co.za>


Changes by Jayanth Koushik <jnkoushik at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, jayanthkoushik
priority: normal
severity: normal
status: open
title: Use of '1' instead of 'True' as 'splitlines' argument in difflib documentation
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 15 10:56:01 2014
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 15 Apr 2014 08:56:01 +0000
Subject: [New-bugs-announce] [issue21233] Add *Calloc functions to CPython
	memory allocation API
Message-ID: <1397552161.67.0.235704351339.issue21233@psf.upfronthosting.co.za>


New submission from Nathaniel Smith:

Numpy would like to switch to using the CPython allocator interface in order to take advantage of the new tracemalloc infrastructure in 3.4. But, numpy relies on the availability of calloc(), and the CPython allocator API does not expose calloc().
  https://docs.python.org/3.5/c-api/memory.html#c.PyMemAllocator

So, we should add *Calloc variants. This met general approval on python-dev. Thread here:
  https://mail.python.org/pipermail/python-dev/2014-April/133985.html

This would involve adding a new .calloc field to the PyMemAllocator struct, exposed through new API functions PyMem_RawCalloc, PyMem_Calloc, PyObject_Calloc. [It's not clear that all 3 would really be used, but since we have only one PyMemAllocator struct that they all share, it'd be hard to add support to only one or two of these domains and not the rest. And the higher-level calloc variants might well be used. Numpy array buffers are often small (e.g., holding only a single value), and these small buffers benefit from small-alloc optimizations; meanwhile, large buffers benefit from calloc optimizations. So it might be optimal to use a single allocator that has both.]

We might also have to rename the PyMemAllocator struct to ensure that compiling old code with the new headers doesn't silently leave garbage in the .calloc field and lead to crashes.

----------
components: Interpreter Core
messages: 216281
nosy: njs
priority: normal
severity: normal
status: open
title: Add *Calloc functions to CPython memory allocation API
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Apr 15 15:04:23 2014
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 15 Apr 2014 13:04:23 +0000
Subject: [New-bugs-announce] [issue21234] __contains__ and friends should
	check "is" for all	elements first
Message-ID: <1397567063.59.0.649029276797.issue21234@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos:

It all started when adding an __equals__ method to a self made class.
The effect was that my program slowed down enormously, which came as a surprise.

This is because when doing an operation that does linear search through a container, the interpreter checks all items one by one, first checking identity and then equality.
If the __equals__ method is slow, this is slower than needed.

In python, you effectively get:
class myContainer:
  def __contains__(self, obj):
    for i in range(len(self)):
      if self[i] is obj: return True
      if self[i]==obj: return True
    return False

My proposal is to change this to:
class myContainer:
  def __contains__(self, obj):
    for i in range(len(self)):
      if self[i] is obj: return True
    for i in range(len(self)):
      if self[i]==obj: return True
    return False

The net effect would be approximately:
- if the object is exactly in the container, the speedup is significant.
- if the object is not in the container, there is no difference.
- if an object is in the container that is equal to the object, it will be slower, but not very much.

In the normal use case, this will probably feel to the user as a speed improvement, especially when the __equals__ is slow.

I tried to find cases in which this would change behaviour of programs, but I couldn't find any. If this _does_ change behaviour in some noticeable and unwanted way, let me know! (Documenting would also be a good idea, then.)

The accompanying file gives some timings to show what I mean, e.g.
Time in us to find an exact match (begin, middle, end):
0.042335559340708886 31.610660936887758 62.69573781716389
Time in us to find an equal match (begin, middle, end):
0.3730294263293299 31.421928646805195 63.177373531221896
Time if not found:
63.44531546956001
And now for an object that has no __equal__:
Time in us to find a thing (begin, middle, end):
0.03555453901338268 9.878883646121661 19.656711762284473
Time if not found:
19.676395048315776

(Python 2.7 does something completely different with objects without __equal__, so the test gives quite different results.)

----------
components: Interpreter Core
files: containsDemo.py
messages: 216286
nosy: jneb
priority: normal
severity: normal
status: open
title: __contains__ and friends should check "is" for all elements first
type: performance
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34867/containsDemo.py

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

From report at bugs.python.org  Tue Apr 15 16:24:41 2014
From: report at bugs.python.org (Armin Ronacher)
Date: Tue, 15 Apr 2014 14:24:41 +0000
Subject: [New-bugs-announce] [issue21235] importlib's spec module create
	algorithm is not exposed
Message-ID: <1397571881.77.0.850697644958.issue21235@psf.upfronthosting.co.za>


New submission from Armin Ronacher:

3.4 deprecates load_module on the loaders and now proposes to use create_module (optionally) and exec_module.  Unfortunately for external callers these interfaces are not useful because you need to reimplement _SpecMethods.create and a whole bunch of other stuff for it.

Right now a caller can get hold of _SpecMethods by importing from _frozen_importlib but that seems very unsupported and is obviously entirely not exposed.

Is there a reason those methods are not on the ModuleSpec directly but on a private wrapper?

Example usage:

from types import ModuleType
from importlib.machinery import ModuleSpec, SourceFileLoader
from _frozen_importlib import _SpecMethods

loader = SourceFileLoader('plugin_base', 'my_file.py')
spec = ModuleSpec(name=loader.name, loader=loader)
mod = _SpecMethods(spec).create()

In the absence of _SpecMethods a caller needs to do this:

from importlib.machinery import ModuleSpec, SourceFileLoader

loader = SourceFileLoader('plugin_base', 'my_file.py')
spec = ModuleSpec(name=loader.name, loader=loader)
if not hasattr(loader, 'create_module'):
    module = types.ModuleType(loader.name)
else:
    module = loader.create_module(spec)
module.__loader__ = loader
module.__spec__ = spec
try:
    module.__package__ = spec.parent
except AttributeError:
    pass
loader.exec_module(module)

(And that is not the whole logic yet)

----------
keywords: 3.4regression
messages: 216295
nosy: aronacher
priority: normal
severity: normal
status: open
title: importlib's spec module create algorithm is not exposed
versions: Python 3.4

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

From report at bugs.python.org  Tue Apr 15 17:33:35 2014
From: report at bugs.python.org (Michael Stahl)
Date: Tue, 15 Apr 2014 15:33:35 +0000
Subject: [New-bugs-announce] [issue21236] patch to use cabinet.lib instead
	of fci.lib (fixes build	with Windows SDK 8.0)
Message-ID: <1397576015.94.0.746613486015.issue21236@psf.upfronthosting.co.za>


New submission from Michael Stahl:

building with MSVC2012 and the Windows SDK 8.0 fails

according to this page, the fci.lib is no longer available
and cabinet.lib should be used instead:

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/3b85f36e-dffe-4589-adc3-13673b349812/

"For Windows 8 onward fci.lib and fdi.lib will become private internal libraries and will not included in Windows SDK"

here is a patch to do that:
http://cgit.freedesktop.org/libreoffice/core/tree/external/python3/python-3.3.0-msvc2012.patch.1

the author of the patch is Peter Foley.

----------
components: Windows
messages: 216309
nosy: mst
priority: normal
severity: normal
status: open
title: patch to use cabinet.lib instead of fci.lib (fixes build with Windows SDK 8.0)
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 15 17:45:50 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Apr 2014 15:45:50 +0000
Subject: [New-bugs-announce] [issue21237] Update Python 2/3 porting HOWTO's
	suggestion for dealing	with map()
Message-ID: <1397576750.55.0.0117658136784.issue21237@psf.upfronthosting.co.za>


New submission from Brett Cannon:

In Python 2.6 and newer you can import future_builtins and use everything from there. In Python 2.5 it should be itertools.imap(). This is much cleaner than the current suggestion at https://docs.python.org/2/howto/pyporting.html#update-map-for-imbalanced-input-sequences

----------
assignee: brett.cannon
components: Documentation
keywords: easy
messages: 216315
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Update Python 2/3 porting HOWTO's suggestion for dealing with map()
type: enhancement

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

From report at bugs.python.org  Tue Apr 15 17:51:18 2014
From: report at bugs.python.org (Michael Foord)
Date: Tue, 15 Apr 2014 15:51:18 +0000
Subject: [New-bugs-announce] [issue21238] unittest.mock.Mock should not
	allow you to use	non-existent assert methods
Message-ID: <1397577078.96.0.678735725627.issue21238@psf.upfronthosting.co.za>


New submission from Michael Foord:

A common problem with unittest.mock.Mock is to mistype an assert method. Because mocks create attributes on demand your test will pass without error.

We should raise an AttributeError if you access any attribute name (that doesn't exist) starting with assert or assret. There should also be a keyword argument allowing you to get the old behaviour if you need it (but this new feature should be on by default).

Will also need docs.

----------
assignee: michael.foord
components: Library (Lib)
messages: 216320
nosy: kushal.das, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest.mock.Mock should not allow you to use non-existent assert methods
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Apr 15 17:54:31 2014
From: report at bugs.python.org (Michael Foord)
Date: Tue, 15 Apr 2014 15:54:31 +0000
Subject: [New-bugs-announce] [issue21239] unittest.mock.patch.stopall
	intermittently doesn't work	when the same thing is patched
	multiple times
Message-ID: <1397577271.48.0.402954348215.issue21239@psf.upfronthosting.co.za>


New submission from Michael Foord:

stopall does not always stop all patches to single target
http://code.google.com/p/mock/issues/detail?id=226

What steps will reproduce the problem?

python code to reproduce error

import mock

def myfunc():
   return 'hello'

m = mock.patch('__main__.myfunc').start()
m.return_value = 'firstmock'
myfunc()

m2 = mock.patch('__main__.myfunc').start()
m2.return_value = 'secondmock'
myfunc()

mock.patch.stopall()
myfunc()


What is the expected output? What do you see instead?
I would expect the output from above to be:
'firstmock'
'secondmock'
'hello'

Instead, sometimes it comes out as:
'firstmock'
'secondmock'
'firstmock'

This result is non-deterministic though so it may also come out as expected. Re-run several times to get the error.

This is a result of using a set to store the active patches. Conversion from a set to a list is non-deterministic because the set has no notion of order.

Please provide any additional information below.

This use case may seem strange, but it shows up in large unit tests where a base class sets up a default patch to catch external calls or something similar and then an individual unit test requiring specific mock behavior patches it differently.

I have a patch here that fixes the problem using a list to store the patches to maintain order and call them in reverse order to stop them in the correct order.

https://code.google.com/r/blak111-mockfix/source/detail?r=3c2f72b0253075d628afb333a79b7cb118132294

----------
assignee: michael.foord
messages: 216322
nosy: michael.foord
priority: normal
severity: normal
stage: patch review
status: open
title: unittest.mock.patch.stopall intermittently doesn't work when the same thing is patched multiple times
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 15 17:57:26 2014
From: report at bugs.python.org (Eric Snow)
Date: Tue, 15 Apr 2014 15:57:26 +0000
Subject: [New-bugs-announce] [issue21240] Add an abstactmethod directive to
	the Python ReST domain
Message-ID: <1397577446.45.0.129673687933.issue21240@psf.upfronthosting.co.za>


New submission from Eric Snow:

I'd like to be able to mark abstract methods in the docs more explicitly and have their presentation in the docs be more obvious.  So I'd like to propose "abstractmethod" as a new directive to join the existing ones (classmethod, staticmethod, etc.).

(This is motivated by msg216314.)

----------
assignee: docs at python
components: Documentation
messages: 216323
nosy: docs at python, eric.snow
priority: normal
severity: normal
status: open
title: Add an abstactmethod directive to the Python ReST domain
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 15 18:41:05 2014
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Tue, 15 Apr 2014 16:41:05 +0000
Subject: [New-bugs-announce] [issue21241] Variable name with number causes
	interactive console to	crash
Message-ID: <1397580065.89.0.773898256837.issue21241@psf.upfronthosting.co.za>


New submission from Henk-Jaap Wagenaar:

Executing in the interactive console: "foo1 = 0" and then "foo1" gives "Segmentation Fault: 11" on OS X 10.9.2, Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]

If foo1 is defined in a program, and interactive mode is entered, assigning a value to it seg faults the console as well, but executing "foo1" *does* work.

It does not seem to crash problems on my friends PC (running Ubuntu).

----------
messages: 216334
nosy: Henk-Jaap.Wagenaar
priority: normal
severity: normal
status: open
title: Variable name with number causes interactive console to crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 15 19:50:05 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Apr 2014 17:50:05 +0000
Subject: [New-bugs-announce] [issue21242] Generalize configure check for
	working Python executable
Message-ID: <1397584205.03.0.366670026915.issue21242@psf.upfronthosting.co.za>


New submission from Brett Cannon:

configure.ac has a check that sets ASDLGEN based on what Python interpreter to use for running various scripts which generate files related to the AST. It probably should be generalized so that there's only one check for any script usage in Makefile.pre.in since there is really no need to check multiple times for the same thing.

----------
components: Build
messages: 216346
nosy: brett.cannon, kushal.das
priority: low
severity: normal
stage: needs patch
status: open
title: Generalize configure check for working Python executable
versions: Python 3.5

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

From report at bugs.python.org  Tue Apr 15 20:12:29 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Apr 2014 18:12:29 +0000
Subject: [New-bugs-announce] [issue21243] Auto-generate exceptions.c from a
	Python file
Message-ID: <1397585549.14.0.873533303783.issue21243@psf.upfronthosting.co.za>


New submission from Brett Cannon:

There isn't very much that's special about the various exceptions (although maybe there will be some day). Anyway, it seems like we could, if we so desired, define the exceptions in Python and then auto-generate the C code.

The other option is to obviously just load the exceptions from Python code, store the various objects in various C attributes, and update the C API for exceptions to operate off of the Python-defined exception objects (question is what performance impact that would have).

The key question, though, is whether any of this is actually worth it. =)

----------
components: Interpreter Core
messages: 216354
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Auto-generate exceptions.c from a Python file
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Apr 15 21:16:26 2014
From: report at bugs.python.org (Kent Frazier)
Date: Tue, 15 Apr 2014 19:16:26 +0000
Subject: [New-bugs-announce] [issue21244] distutils fails to build C
	extensions with XCode 5.1 and	OS X 10.9 (Mavericks)
Message-ID: <1397589386.91.0.235020854992.issue21244@psf.upfronthosting.co.za>


New submission from Kent Frazier:

Using the stock Python shipped by Apple with OS X 10.9 Mavericks and XCode 5.1, Mercurial (and other Python extensions) encounter an error like:

cc -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c mercurial/base85.c -o /private/var/folders/qv/tv81r5_9119bs3jwj3g2rp540000gn/T/hgtests._a6HZj/build/temp.macosx-10.9-intel-2.7/mercurial/base85.o
clang: error: unknown argument: '-mno-fused-madd' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
error: command 'cc' failed with exit status 1
make: *** [tests] Error 1
 
This can be worked around with:
 
export CFLAGS=-Qunused-arguments

On my machine, Python was build with clang-500.0.68 and the XCode 5.1 updates it to clang-503.0.40. I will include a simple setup.py that can be run against Mercurial's head to demonstrate the issue.

----------
components: Distutils
files: toysetup.py
messages: 216363
nosy: dstufft, eric.araujo, jason.coombs, kfrazier
priority: normal
severity: normal
status: open
title: distutils fails to build C extensions with XCode 5.1 and OS X 10.9 (Mavericks)
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file34889/toysetup.py

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

From report at bugs.python.org  Tue Apr 15 22:19:59 2014
From: report at bugs.python.org (Cameron Lee)
Date: Tue, 15 Apr 2014 20:19:59 +0000
Subject: [New-bugs-announce] [issue21245] Logging Logger.exception
	documentation
Message-ID: <1397593199.67.0.956489214078.issue21245@psf.upfronthosting.co.za>


New submission from Cameron Lee:

The documentation doesn't indicate that the Logger.exception method can accept kwargs like the other logging methods (Logger.debug, Logger.info, etc...) such as exc_info, stack_info, and extra.

https://docs.python.org/2.7/library/logging.html#logging.Logger.exception

The method signature is documented as: 

Logger.exception(msg, *args)

It should be:

Logger.exception(msg, *args, **kwargs)

It appears that this functionality was added in between Python 2.7.3 and 2.7.4 (http://bugs.python.org/issue15541) but that the documentation was never changed for the newer versions.

----------
assignee: docs at python
components: Documentation
messages: 216379
nosy: Cameron.Lee, docs at python
priority: normal
severity: normal
status: open
title: Logging Logger.exception documentation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 15 22:22:28 2014
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Tue, 15 Apr 2014 20:22:28 +0000
Subject: [New-bugs-announce] [issue21246] test_ssl handshake failure
Message-ID: <1397593348.91.0.829573885546.issue21246@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

Not sure if this is related with issue #13626 which is the only thing that Google knows about these handshake failures. In case it matters:

$ openssl version
OpenSSL 1.0.1f 6 Jan 2014

== CPython 2.7.6 (default, Apr 14 2014, 15:12:21) [GCC 4.8.2]
==   Linux-2.6.32-358.el6.x86_64-x86_64-with-redhat-6.4-Santiago little-endian
==   /glade/scratch/ddvento/build/Python-2.7.6/build/test_python_18521
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_ssl
test_sslwrap_simple (test.test_ssl.BasicTests) ... ok
test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok
test_ciphers (test.test_ssl.BasicSocketTests) ... ok
test_constants (test.test_ssl.BasicSocketTests) ... ok
test_openssl_version (test.test_ssl.BasicSocketTests) ... ok
test_parse_cert (test.test_ssl.BasicSocketTests) ... 
{'notAfter': 'Oct  5 23:01:56 2020 GMT',
 'subject': ((('countryName', u'XY'),),
             (('localityName', u'Castle Anthrax'),),
             (('organizationName', u'Python Software Foundation'),),
             (('commonName', u'localhost'),)),
 'subjectAltName': (('DNS', 'localhost'),)}

{'issuer': ((('countryName', u'US'),),
            (('organizationName', u'VeriSign, Inc.'),),
            (('organizationalUnitName', u'VeriSign Trust Network'),),
            (('organizationalUnitName',
              u'Terms of use at https://www.verisign.com/rpa (c)10'),),
            (('commonName',
              u'VeriSign Class 3 International Server CA - G3'),)),
 'notAfter': 'Sep 20 23:59:59 2012 GMT',
 'notBefore': 'Sep 21 00:00:00 2011 GMT',
 'serialNumber': '2EE6EA7640A075CEE5005F4D7C79549A',
 'subject': ((('countryName', u'FI'),),
             (('stateOrProvinceName', u'Espoo'),),
             (('localityName', u'Espoo'),),
             (('organizationName', u'Nokia'),),
             (('organizationalUnitName', u'BI'),),
             (('commonName', u'projects.developer.nokia.com'),)),
 'subjectAltName': (('DNS', 'projects.developer.nokia.com'),
                    ('DNS', 'projects.forum.nokia.com')),
 'version': 3}
ok
test_parse_cert_CVE_2013_4238 (test.test_ssl.BasicSocketTests) ... 
{'issuer': ((('countryName', u'US'),),
            (('stateOrProvinceName', u'Oregon'),),
            (('localityName', u'Beaverton'),),
            (('organizationName', u'Python Software Foundation'),),
            (('organizationalUnitName', u'Python Core Development'),),
            (('commonName', u'null.python.org\x00example.org'),),
            (('emailAddress', u'python-dev at python.org'),)),
 'notAfter': 'Aug  7 13:12:52 2013 GMT',
 'notBefore': 'Aug  7 13:11:52 2013 GMT',
 'serialNumber': '00',
 'subject': ((('countryName', u'US'),),
             (('stateOrProvinceName', u'Oregon'),),
             (('localityName', u'Beaverton'),),
             (('organizationName', u'Python Software Foundation'),),
             (('organizationalUnitName', u'Python Core Development'),),
             (('commonName', u'null.python.org\x00example.org'),),
             (('emailAddress', u'python-dev at python.org'),)),
 'subjectAltName': (('DNS', 'altnull.python.org\x00example.com'),
                    ('email', 'null at python.org\x00user at example.org'),
                    ('URI', 'http://null.python.org\x00http://example.org'),
                    ('IP Address', '192.0.2.1'),
                    ('IP Address', '2001:DB8:0:0:0:0:0:1\n')),
 'version': 3}
ok
test_random (test.test_ssl.BasicSocketTests) ... 
 RAND_status is 1 (sufficient randomness)
ok
test_refcycle (test.test_ssl.BasicSocketTests) ... ok
test_wrapped_unconnected (test.test_ssl.BasicSocketTests) ... ok
test_algorithms (test.test_ssl.NetworkedTests) ... skipped 'remote host needs SNI, only available on Python 3.2+'
test_connect (test.test_ssl.NetworkedTests) ... ok
test_connect_ex (test.test_ssl.NetworkedTests) ... ok
test_connect_ex_error (test.test_ssl.NetworkedTests) ... ok
test_get_server_certificate (test.test_ssl.NetworkedTests) ... ERROR
test_makefile_close (test.test_ssl.NetworkedTests) ... ok
test_non_blocking_connect_ex (test.test_ssl.NetworkedTests) ... ok
test_non_blocking_handshake (test.test_ssl.NetworkedTests) ... 
Needed 3 calls to do_handshake() to establish session.
ok
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok
test_asyncore_server (test.test_ssl.ThreadedTests)
Check the example asyncore integration. ... 
 server:  new connection from 127.0.0.1:48912
 client:  sending 'TEST MESSAGE of mixed case\n'...
 client:  read 'test message of mixed case\n'
 client:  closing connection.
 cleanup: stopping server.
 cleanup: joining server thread.
 server:  closed connection <ssl.SSLSocket object at 0x2399140>
 cleanup: successfully joined.
ok
test_default_ciphers (test.test_ssl.ThreadedTests) ... ok
test_echo (test.test_ssl.ThreadedTests)
Basic test of an SSL client connecting to a server ... 
 server:  new connection from ('127.0.0.1', 43993)
 server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256)
 client:  sending 'FOO\n'...
 server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)...
 client:  read 'foo\n'
 client:  sending bytearray(b'FOO\n')...
 server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)...
 client:  read 'foo\n'
 client:  sending <memory at 0x237f510>...
 server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)...
 client:  read 'foo\n'
 client:  closing connection.
 server: client closed connection
ok
test_empty_cert (test.test_ssl.ThreadedTests)
Connecting with an empty cert file ... 
SSLError is _ssl.c:354: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
ok
test_getpeercert (test.test_ssl.ThreadedTests) ... 
{'notAfter': 'Oct  5 23:01:56 2020 GMT',
 'subject': ((('countryName', u'XY'),),
             (('localityName', u'Castle Anthrax'),),
             (('organizationName', u'Python Software Foundation'),),
             (('commonName', u'localhost'),)),
 'subjectAltName': (('DNS', 'localhost'),)}
Connection cipher is ('AES256-GCM-SHA384', 'TLSv1/SSLv3', 256).
ok
test_handshake_timeout (test.test_ssl.ThreadedTests) ... ok
test_malformed_cert (test.test_ssl.ThreadedTests)
Connecting with a badly formatted certificate (syntax error) ... 
SSLError is _ssl.c:368: error:140DC009:SSL routines:SSL_CTX_use_certificate_chain_file:PEM lib
ok
test_malformed_key (test.test_ssl.ThreadedTests)
Connecting with a badly formatted key (syntax error) ... 
SSLError is _ssl.c:354: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
ok
test_nonexisting_cert (test.test_ssl.ThreadedTests)
Connecting with a non-existing cert file ... 
SSLError is _ssl.c:507: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
ok
test_protocol_sslv2 (test.test_ssl.ThreadedTests)
Connecting to an SSLv2 server with various client options ... 
 SSLv2->SSLv2 CERT_NONE
 SSLv2->SSLv2 CERT_OPTIONAL
 SSLv2->SSLv2 CERT_REQUIRED
 SSLv23->SSLv2 CERT_NONE
 {SSLv3->SSLv2} CERT_NONE
 {TLSv1->SSLv2} CERT_NONE
ok
test_protocol_sslv23 (test.test_ssl.ThreadedTests)
Connecting to an SSLv23 server with various client options ... 
 SSLv3->SSLv23 CERT_NONE
 SSLv23->SSLv23 CERT_NONE
 TLSv1->SSLv23 CERT_NONE
 SSLv3->SSLv23 CERT_OPTIONAL
 SSLv23->SSLv23 CERT_OPTIONAL
 TLSv1->SSLv23 CERT_OPTIONAL
 SSLv3->SSLv23 CERT_REQUIRED
 SSLv23->SSLv23 CERT_REQUIRED
 TLSv1->SSLv23 CERT_REQUIRED
ok
test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 server with various client options ... 
 SSLv3->SSLv3 CERT_NONE
 SSLv3->SSLv3 CERT_OPTIONAL
 SSLv3->SSLv3 CERT_REQUIRED
 {SSLv2->SSLv3} CERT_NONE
 {TLSv1->SSLv3} CERT_NONE
ok
test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1 server with various client options ... 
 TLSv1->TLSv1 CERT_NONE
 TLSv1->TLSv1 CERT_OPTIONAL
 TLSv1->TLSv1 CERT_REQUIRED
 {SSLv2->TLSv1} CERT_NONE
 {SSLv3->TLSv1} CERT_NONE
ok
test_recv_send (test.test_ssl.ThreadedTests)
Test recv(), send() and friends. ... 
 server:  new connection from ('127.0.0.1', 56710)
 server: connection cipher is now ('AES256-SHA', 'TLSv1/SSLv3', 256)
ok
test_rude_shutdown (test.test_ssl.ThreadedTests)
A brutal shutdown of an SSL server should raise an IOError ... ok
test_socketserver (test.test_ssl.ThreadedTests)
Using a SocketServer to create and manage SSL connections. ... 
 server (('127.0.0.1', 42188):42188 ('AES256-GCM-SHA384', 'TLSv1/SSLv3', 256)):
   [15/Apr/2014 14:14:53] "GET /keycert.pem HTTP/1.0" 200 -
 client: read 1783 bytes from remote server '<SocketServerHTTPSServer <HTTPSServer localhost.localdomain:42188>>'
ok
test_starttls (test.test_ssl.ThreadedTests)
Switching from clear text to encrypted and back again. ... 
 client:  sending 'msg 1'...
 server:  new connection from ('127.0.0.1', 50624)
 server: read 'msg 1' (unencrypted), sending back 'msg 1' (unencrypted)...
 client:  read 'msg 1' from server
 client:  sending 'MSG 2'...
 server: read 'MSG 2' (unencrypted), sending back 'msg 2' (unencrypted)...
 client:  read 'msg 2' from server
 client:  sending 'STARTTLS'...
 server: read STARTTLS from client, sending OK...
 client:  read 'OK\n' from server, starting TLS...
 client:  sending 'MSG 3'...
 server: read 'MSG 3' (encrypted), sending back 'msg 3' (encrypted)...
 client:  read 'msg 3' from server
 client:  sending 'msg 4'...
 server: read 'msg 4' (encrypted), sending back 'msg 4' (encrypted)...
 client:  read 'msg 4' from server
 client:  sending 'ENDTLS'...
 server: read ENDTLS from client, sending OK...
 client:  read 'OK\n' from server, ending TLS...
 server: connection is now unencrypted...
 client:  sending 'msg 5'...
 server: read 'msg 5' (unencrypted), sending back 'msg 5' (unencrypted)...
 client:  read 'msg 5' from server
 client:  sending 'msg 6'...
 server: read 'msg 6' (unencrypted), sending back 'msg 6' (unencrypted)...
 client:  read 'msg 6' from server
 client:  closing connection.
 server: client closed connection
ok
test_wrapped_accept (test.test_ssl.ThreadedTests)
Check the accept() method on SSL sockets. ... test test_ssl failed -- Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/test/test_ssl.py", line 387, in test_get_server_certificate
    pem = ssl.get_server_certificate(("svn.python.org", 443))
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 448, in get_server_certificate
    s.connect(addr)
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 333, in connect
    self._real_connect(addr, False)
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 323, in _real_connect
    self.do_handshake()
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 305, in do_handshake
    self._sslobj.do_handshake()
SSLError: [Errno 1] _ssl.c:507: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure


 server:  wrapped server socket as <ssl.SSLSocket object at 0x2399140>
 client:  sending 'FOO\n'...
 server:  new connection from ('127.0.0.1', 40291)
 client cert is {'notAfter': 'Oct  5 23:01:56 2020 GMT',
 'subject': ((('countryName', u'XY'),),
             (('localityName', u'Castle Anthrax'),),
             (('organizationName', u'Python Software Foundation'),),
             (('commonName', u'localhost'),)),
 'subjectAltName': (('DNS', 'localhost'),)}
 cert binary is 600 bytes
 server: connection cipher is now ('AES256-GCM-SHA384', 'TLSv1/SSLv3', 256)
 server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)...
 client:  read 'foo\n'
 client:  sending bytearray(b'FOO\n')...
 server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)...
 client:  read 'foo\n'
 client:  sending <memory at 0x240ecc8>...
 server: read 'FOO\n' (encrypted), sending back 'foo\n' (encrypted)...
 client:  read 'foo\n'
 client:  closing connection.
 server: client closed connection
ok

======================================================================
ERROR: test_get_server_certificate (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/test/test_ssl.py", line 387, in test_get_server_certificate
    pem = ssl.get_server_certificate(("svn.python.org", 443))
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 448, in get_server_certificate
    s.connect(addr)
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 333, in connect
    self._real_connect(addr, False)
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 323, in _real_connect
    self.do_handshake()
  File "/glade/scratch/ddvento/build/Python-2.7.6/Lib/ssl.py", line 305, in do_handshake
    self._sslobj.do_handshake()
SSLError: [Errno 1] _ssl.c:507: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

----------------------------------------------------------------------
Ran 37 tests in 4.950s

FAILED (errors=1, skipped=1)
1 test failed:
    test_ssl

----------
messages: 216380
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: test_ssl handshake failure
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 15 23:33:52 2014
From: report at bugs.python.org (Orion Poplawski)
Date: Tue, 15 Apr 2014 21:33:52 +0000
Subject: [New-bugs-announce] [issue21247] test_asyncio:
	test_subprocess_send_signal hangs on	Fedora builders
Message-ID: <1397597632.61.0.772376521638.issue21247@psf.upfronthosting.co.za>


New submission from Orion Poplawski:

Trying to build Python 3.4.0 for Fedora we are seeing test_asyncio test_subprocess_send_signal hang every time, on all architectures.  Unfortunately I cannot reproduce this locally.  These builds are done inside of chroots, and the host has the kernel version 3.12.8-300.fc20 which is used for all build targets.  We see hangs building for Fedora Rawhide and RHEL 7.  We do *not* see hangs on our COPR builders which among other possible differences use RHEL6 hosts with kernel 2.6.32-358.el6.

I've attached an strace of the hanging test.  The calling process seems to be stuck in epoll_wait().

Tried using the watchdog patch from issue #19652 but that doesn't seem to manage to kill things.  In fact, the tests are never killed but the 1 hour timeout in the test runner.

----------
files: test_signal.out
messages: 216392
nosy: opoplawski
priority: normal
severity: normal
status: open
title: test_asyncio: test_subprocess_send_signal hangs on Fedora builders
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34899/test_signal.out

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

From report at bugs.python.org  Tue Apr 15 23:37:05 2014
From: report at bugs.python.org (David Turner)
Date: Tue, 15 Apr 2014 21:37:05 +0000
Subject: [New-bugs-announce] [issue21248] BROWSER env var described
	inaccurately in webbrowser docs
Message-ID: <1397597825.94.0.182594358629.issue21248@psf.upfronthosting.co.za>


New submission from David Turner:

https://docs.python.org/2/library/webbrowser.html says "If the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers, as a os.pathsep-separated list of browsers to try in order."

This is not actually what happens; instead, it is prepended to the platform-default list of browsers.

----------
assignee: docs at python
components: Documentation
messages: 216393
nosy: docs at python, dturner-tw
priority: normal
severity: normal
status: open
title: BROWSER env var described inaccurately in webbrowser docs
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 16 00:16:21 2014
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 15 Apr 2014 22:16:21 +0000
Subject: [New-bugs-announce] [issue21249] removing pythonXY.zip from
	sys.path results in	additional test failures
Message-ID: <1397600181.83.0.758754205227.issue21249@psf.upfronthosting.co.za>


New submission from Matthias Klose:

At least Linux distros never ship pythonXY.zip, so I'm removing it from sys.path to save the extra lookup for a file which never exists.  This did work in 2.x and 3.x up to 3.3.  In 3.4 it does cause additional test failures:

Re-running test 'test_cmd_line_script' in verbose mode
[...]
test_zipfile_compiled (test.test_cmd_line_script.CmdLineTest) ... ok
test_zipfile_error (test.test_cmd_line_script.CmdLineTest) ... FAIL

======================================================================
FAIL: test_directory_error (test.test_cmd_line_script.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/buildd/python3.4-3.4.0/Lib/test/test_cmd_line_script.py", line 213, in test_directory_error
    self._check_import_error(script_dir, msg)
  File "/build/buildd/python3.4-3.4.0/Lib/test/test_cmd_line_script.py", line 156, in _check_import_error
    self.assertIn(expected_msg.encode('utf-8'), err)
AssertionError: b"can't find '__main__' module in '/tmp/tmpc2iybbmi'" not found in b"Could not import runpy module\nImportError: No module named 'runpy'"

======================================================================
FAIL: test_zipfile_error (test.test_cmd_line_script.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/buildd/python3.4-3.4.0/Lib/test/test_cmd_line_script.py", line 235, in test_zipfile_error
    self._check_import_error(zip_name, msg)
  File "/build/buildd/python3.4-3.4.0/Lib/test/test_cmd_line_script.py", line 156, in _check_import_error
    self.assertIn(expected_msg.encode('utf-8'), err)
AssertionError: b"can't find '__main__' module in '/tmp/tmp34n7w8gj/test_zip.zip'" not found in b"Could not import runpy module\nImportError: No module named 'runpy'"

----------------------------------------------------------------------
Ran 24 tests in 1.906s

FAILED (failures=2)
test test_cmd_line_script failed

Re-running test 'test_zipimport_support' in verbose mode
test_doctest_issue4197 (test.test_zipimport_support.ZipSupportTests) ... ok
test_doctest_main_issue4197 (test.test_zipimport_support.ZipSupportTests) ... FAIL
test_inspect_getsource_issue4223 (test.test_zipimport_support.ZipSupportTests) ... ok
test_pdb_issue4201 (test.test_zipimport_support.ZipSupportTests) ... ok

======================================================================
FAIL: test_doctest_main_issue4197 (test.test_zipimport_support.ZipSupportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/build/buildd/python3.4-3.4.0/Lib/test/test_zipimport_support.py", line 209, in test_doctest_main_issue4197
    rc, out, err = assert_python_ok(zip_name)
  File "/build/buildd/python3.4-3.4.0/Lib/test/script_helper.py", line 69, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/build/buildd/python3.4-3.4.0/Lib/test/script_helper.py", line 55, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Could not import runpy module
ImportError: No module named 'runpy'

----------
components: Tests
files: no-zip-on-sys.path.diff
keywords: patch
messages: 216402
nosy: brett.cannon, doko, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: removing pythonXY.zip from sys.path results in additional test failures
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34900/no-zip-on-sys.path.diff

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

From report at bugs.python.org  Wed Apr 16 09:52:41 2014
From: report at bugs.python.org (Alex Lord)
Date: Wed, 16 Apr 2014 07:52:41 +0000
Subject: [New-bugs-announce] [issue21250] sqlite3 doesn't have unit tests
	for 'insert or	[algorithm]' functionality.
Message-ID: <1397634761.6.0.834429340049.issue21250@psf.upfronthosting.co.za>


New submission from Alex Lord:

In Lib/sqlite3/tests/dbapi.py there are no unit tests which test out sqlite3's 'insert or [algorithm].' These algorithms are also referred to as SQL 'insert on conflict.'

More details at,
https://www.sqlite.org/lang_conflict.html

Not having unit tests for these features, especially 'insert or rollback,' seems like an easy way for timing and threading bugs to get lost in the database api.

----------
components: Tests
messages: 216448
nosy: Alex.Lord
priority: normal
severity: normal
status: open
title: sqlite3 doesn't have unit tests for 'insert or [algorithm]' functionality.
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 16 14:42:17 2014
From: report at bugs.python.org (Martin Kolman)
Date: Wed, 16 Apr 2014 12:42:17 +0000
Subject: [New-bugs-announce] [issue21251] Standard library trace module
	crashes with exception
Message-ID: <1397652137.22.0.406999160837.issue21251@psf.upfronthosting.co.za>


New submission from Martin Kolman:

We are currently working on adding tracing support to Anaconda, the Fedora/Red Hat Enterprise Linux installer and we have encountered some pretty strange behavior of the trace module. Anaconda (or to be concrete the Blivet storage library used by Anaconda) uses the pyblock module, but just importing it crashes the trace module with a strange exception.

It can be reproduced like this:
0. install pyblock (on Fedora is is provided by the python-pyblock package)

1. write some python code that imports the "block" module provided by pyblock

echo "import block" > pyblock_trace.py

2. try to trace the code

python -m trace -t pyblock_trace.py

The trace module starts tracing but after a few seconds it crashes with the following traceback:


Traceback (most recent call last):
  File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/lib64/python2.7/trace.py", line 830, in <module>
    main()
  File "/usr/lib64/python2.7/trace.py", line 818, in main
    t.runctx(code, globs, globs)
  File "/usr/lib64/python2.7/trace.py", line 513, in runctx
    exec cmd in globals, locals
  File "pyblock_trace.py", line 1, in <module>
    import block
  File "/usr/lib64/python2.7/site-packages/block/__init__.py", line 47, in <module>
    import dmraid
  File "<string>", line 1, in <module>
  File "/usr/lib64/python2.7/trace.py", line 609, in globaltrace_lt
    filename = frame.f_globals.get('__file__', None)
AttributeError: 'module' object has no attribute 'get'


The dmraid module is written in C and we have looked though its source[1] code but have found nothing extraordinary. Most importantly there is no code touching the globals, but it still fails.

When looking what actually is in frame.f_globals we found that in all successful calls it has the globals dictionary but for the dmraid module it for some reason contains the module instance instead. Module instance is not a dictionary, so it doesn't have the get method and this leads to the exception above.

This is not the only C module we use, but this is the only one that triggers the crash in trace.


Additional information
Python version: 2.7.5
architecture: X86_64
OS: Fedora 20


[1] https://git.fedorahosted.org/cgit/pyblock.git/tree/dmraid.c

----------
components: Library (Lib)
files: trace.log
messages: 216459
nosy: mkolman
priority: normal
severity: normal
status: open
title: Standard library trace module crashes with exception
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file34908/trace.log

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

From report at bugs.python.org  Wed Apr 16 17:34:14 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 16 Apr 2014 15:34:14 +0000
Subject: [New-bugs-announce] [issue21252] Lib/asyncio/events.py has tons of
	docstrings which are	just "XXX"
Message-ID: <1397662454.57.0.604020798852.issue21252@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

It would be nice if these said something useful. (http://hg.python.org/cpython/file/default/Lib/asyncio/events.py)

----------
components: Library (Lib)
messages: 216478
nosy: alex
priority: normal
severity: normal
status: open
title: Lib/asyncio/events.py has tons of docstrings which are just "XXX"
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 16 17:54:46 2014
From: report at bugs.python.org (Nina Zakharenko)
Date: Wed, 16 Apr 2014 15:54:46 +0000
Subject: [New-bugs-announce] [issue21253] Difflib
Message-ID: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za>


New submission from Nina Zakharenko:

When difflib.compare() is used on two moderately large sequences with little or no common elements, a RuntimeError: maximum recursion depth exceeded occurs. 

This error became apparent when testing another bug (see: issue 19217) in the AssertEquals() method of the unit test library.

A sample program to reproduce this issue in 3.4 is attached. To repo in 2.7 remove the list() wrapper from the range call.

----------
components: Library (Lib)
files: diff_bug34.py
messages: 216479
nosy: gregory.p.smith, nnja, r.david.murray
priority: normal
severity: normal
status: open
title: Difflib
type: crash
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file34911/diff_bug34.py

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

From report at bugs.python.org  Wed Apr 16 18:15:17 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 16 Apr 2014 16:15:17 +0000
Subject: [New-bugs-announce] [issue21254] PropertyMock refuses to raise
	AttributeErrror as a side	effect
Message-ID: <1397664917.5.0.84660783066.issue21254@psf.upfronthosting.co.za>


New submission from Michael Foord:

What steps will reproduce the problem?

>>> import mock
>>> a_mock = mock.MagicMock()
>>> no_attribute = mock.PropertyMock(side_effect=AttributeError)
>>> type(a_mock).property = no_attribute



What is the expected output? What do you see instead?

I would expect the above to raise an AttributeError. Instead it returns a MagicMock instance.

>>> a_mock.property
<MagicMock name='mock.property' id='140165240345424'>

I would expect it to have the same effect as calling a PropertyMock with any other exception as a side effect:

>>> mock_value_error = mock.PropertyMock(side_effect=ValueError)
>>> type(a_mock).other_property = mock_value_error
>>> a_mock.other_property
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 2365, in __get__
    return self()
  File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 955, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 1010, in _mock_call
    raise effect
ValueError



What version of the product are you using? On what operating system?

Using version mock-1.0.1-py2.6 on CentOS 6.4



Please provide any additional information below.

PropertyMock objects apparently won't raise sublcasses of AttributeError either:

>>> class MockAttributeError(AttributeError): pass
... 
>>> no_attr = mock.PropertyMock(side_effect=MockAttributeError)
>>> type(a_mock).property = no_attr
>>> a_mock.property
<MagicMock name='mock.property' id='140165240345424'>

Works fine for subclasses of other Exceptions:

>>> class MockKeyError(KeyError): pass
... 
>>> no_key = mock.PropertyMock(side_effect=MockKeyError)
>>> type(a_mock).property = no_key
>>> a_mock.property
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 2365, in __get__
    return self()
  File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 955, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/home/ahammel/bin/python/mock-1.0.1-py2.6.egg/mock.py", line 1010, in _mock_call
    raise effect
__main__.MockKeyError

----------
assignee: michael.foord
keywords: easy
messages: 216487
nosy: kushal.das, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: PropertyMock refuses to raise AttributeErrror as a side effect
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 16 18:19:15 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 16 Apr 2014 16:19:15 +0000
Subject: [New-bugs-announce] [issue21255] Attaching a PropertyMock records
	calls
Message-ID: <1397665155.65.0.579203534798.issue21255@psf.upfronthosting.co.za>


New submission from Michael Foord:

What steps will reproduce the problem?

    >>> foo = Mock(name='foo')
    >>> prop = PropertyMock(name='prop')
    >>> type(foo).prop = prop
    >>> foo.attach_mock(prop, 'prop')
    >>> foo.mock_calls
    [call.prop(<PropertyMock name='foo.prop' id='4300017296'>)]

Expected:

    >>> foo.mock_calls
    []

What version of the product are you using? On what operating system?

    % pip freeze | grep mock
    mock==1.0.1

    OS X 10.8.4

Please provide any additional information below.

    It would be even cooler if attaching a property mock made calls to the property appear in the mock_calls for the hosting mock without having to attach it, the way it does with a non-property method :)

    I use mock every day now and am firmly of the opinion it is far, far more awesome than sliced bread. Thanks for making it available to the Python community :)

----------
assignee: michael.foord
components: Library (Lib)
messages: 216488
nosy: kushal.das, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Attaching a PropertyMock records calls
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 16 18:37:06 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 16 Apr 2014 16:37:06 +0000
Subject: [New-bugs-announce] [issue21256] Sort keyword arguments in mock
	_format_call_signature
Message-ID: <1397666226.17.0.060483995874.issue21256@psf.upfronthosting.co.za>


New submission from Michael Foord:

Printing call args produces non-deterministic results, making them more or less useless in doctests.

kwargs_string = ', '.join([
        '%s=%r' % (key, value) for key, value in kwargs.items()
    ])

should be:

kwargs_string = ', '.join([
        '%s=%r' % (key, value) for key, value in sorted(kwargs.items())
    ])

----------
assignee: michael.foord
keywords: easy
messages: 216491
nosy: kushal.das, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Sort keyword arguments in mock _format_call_signature
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 16 18:44:59 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Apr 2014 16:44:59 +0000
Subject: [New-bugs-announce] [issue21257] Document parse_headers function of
	http.client
Message-ID: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

It is undocumented. While fixing a doc issue issue18229 for http.server I noticed that I referenced that function and when I looked up for the documentation, it was lacking.

----------
assignee: orsenthil
messages: 216494
nosy: orsenthil
priority: normal
severity: normal
status: open
title: Document parse_headers function of http.client
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 16 19:56:45 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 16 Apr 2014 17:56:45 +0000
Subject: [New-bugs-announce] [issue21258] Add __iter__ support for mock_open
Message-ID: <1397671005.18.0.0743040241878.issue21258@psf.upfronthosting.co.za>


New submission from Michael Foord:

mock_open returns a mock object suitable for using as a mock file handle. File handles support iteration, so mock_open should support that. If possible it should be integrated with the current read/readlines support (only if possible), so the suggested patch may not be enough.


1.    Want to mock this:
with open(source_file, 'r') as f:             
    for line_num, line_text in enumerate(f):
        print line_text

2.  Tried this:
with patch('__builtin__.open', mock_open(read_data='text'), create=True) as p:

3.  enumerate causes a call to __iter__() which is not handled by the mock_open code.


What is the expected output? What do you see instead?

The __iter__ is allowed on the returned file handle

What version of the product are you using? On what operating system?

latest

Please provide any additional information below.

Patch would have mock_open setup handle.__iter__.return_value to a passed in parm or if none, possibly a iter(StringIO(read_data)) on the existing read_data parm to keep the interface unchanged.

----------
assignee: michael.foord
components: Library (Lib)
files: 213.patch
keywords: patch
messages: 216522
nosy: kushal.das, michael.foord
priority: normal
severity: normal
stage: patch review
status: open
title: Add __iter__ support for mock_open
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file34917/213.patch

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

From report at bugs.python.org  Wed Apr 16 19:56:55 2014
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 16 Apr 2014 17:56:55 +0000
Subject: [New-bugs-announce] [issue21259] replace "except: pass" by "except
	Exception: pass"
Message-ID: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

Hi guys,

Via this issue, I will attach a patch where I replace all the "except: pass" in the source code by a clear "except Exception: pass".

----------
components: Library (Lib)
messages: 216524
nosy: matrixise
priority: normal
severity: normal
status: open
title: replace "except: pass" by "except Exception: pass"
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 16 20:16:50 2014
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 16 Apr 2014 18:16:50 +0000
Subject: [New-bugs-announce] [issue21260] python malloc mach_vm_map failed
Message-ID: <1397672210.34.0.991766687359.issue21260@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

Hi all,

Sometimes, I get this error on my laptop : OSX 10.9 with Python 3.5


[386/388] test_io
python.exe(33496,0x7fff7367d310) malloc: *** mach_vm_map(size=9223372036854779904) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(33496,0x7fff7367d310) malloc: *** mach_vm_map(size=9223372036854779904) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(33496,0x7fff7367d310) malloc: *** mach_vm_map(size=9223372036854779904) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
[387/388] test_tokenize

Stephane

----------
components: Interpreter Core
messages: 216539
nosy: matrixise
priority: normal
severity: normal
status: open
title: python malloc mach_vm_map failed
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 16 20:21:12 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 16 Apr 2014 18:21:12 +0000
Subject: [New-bugs-announce] [issue21261] Teach IDLE to Autocomplete
	dictionary keys
Message-ID: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

IDLE can autocomplete global variable, method names, and filenames.  But, it cannot complete dictionary keys.

Here's what we want:

   >>> d = {'long_key': '10, 'short_key': 20}
   >>> d['lo<tab>

----------
components: IDLE
messages: 216542
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Teach IDLE to Autocomplete dictionary keys
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 16 20:30:13 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 16 Apr 2014 18:30:13 +0000
Subject: [New-bugs-announce] [issue21262] assert_not_called method for mocks
Message-ID: <1397673013.96.0.498096187317.issue21262@psf.upfronthosting.co.za>


New submission from Michael Foord:

A shortcut for asserting that the call_count of a mock is 0.

----------
assignee: kushal.das
messages: 216546
nosy: kushal.das, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: assert_not_called method for mocks
type: behavior

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

From report at bugs.python.org  Wed Apr 16 20:50:57 2014
From: report at bugs.python.org (Sam Kimbrel)
Date: Wed, 16 Apr 2014 18:50:57 +0000
Subject: [New-bugs-announce] [issue21263] test_gdb failures on os x 10.9.2
Message-ID: <1397674257.45.0.239061101467.issue21263@psf.upfronthosting.co.za>


New submission from Sam Kimbrel:

test_gdb fails under OS X 10.9.2 and gdb 7.6.1 (built with homebrew on Apple LLVM version 5.1 (clang-503.0.40)):

FAIL: test_pycfunction (test.test_gdb.PyBtTests)
Verify that "py-bt" displays invocations of PyCFunction instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/skimbrel/cpython/Lib/test/test_gdb.py", line 789, in test_pycfunction
    cmds_after_breakpoint=['bt', 'py-bt'],
  File "/Users/skimbrel/cpython/Lib/test/test_gdb.py", line 182, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ['No stack.', "Python Exception <class 'gd[109 chars]ed.'] != []

First list contains 3 additional elements.
First extra element 0:
No stack.

+ []
- ['No stack.',
-  "Python Exception <class 'gdb.error'> No frame is currently selected.: ",
-  'Error occurred in Python command: No frame is currently selected.']

======================================================================
FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/skimbrel/cpython/Lib/test/test_gdb.py", line 736, in test_threads
    self.assertIn('Waiting for the GIL', gdb_output)
AssertionError: 'Waiting for the GIL' not found in 'Breakpoint 1 at 0x1001c78f0: file Python/bltinmodule.c, line 991.\n[New Thread 0x170b of process 41733]\n[New Thread 0x1803 of process 41733]\n[New Thread 0x1903 of process 41733]\n[New Thread 0x1a03 of process 41733]\n\nBreakpoint 1, builtin_id (self=<module at remote 0x100603358>, v=42) at Python/bltinmodule.c:991\n991\t    return PyLong_FromVoidPtr(v);\n\nThread 5 (Thread 0x1a03 of process 41733):\nTraceback (most recent call first):\n\nThread 4 (Thread 0x1903 of process 41733):\nTraceback (most recent call first):\n\nThread 3 (Thread 0x1803 of process 41733):\nTraceback (most recent call first):\n\nThread 2 (Thread 0x170b of process 41733):\nTraceback (most recent call first):\n\nThread 1 (Thread 0x1503 of process 41733):\nTraceback (most recent call first):\n  File "<string>", line 18, in <module>\n'

----------------------------------------------------------------------
Ran 45 tests in 19.277s

FAILED (failures=2)

----------
assignee: ronaldoussoren
components: Macintosh, Tests
messages: 216551
nosy: ronaldoussoren, sam.kimbrel
priority: normal
severity: normal
status: open
title: test_gdb failures on os x 10.9.2
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 16 20:59:40 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 16 Apr 2014 18:59:40 +0000
Subject: [New-bugs-announce] [issue21264] test_compileall fails to build in
	the installed location
Message-ID: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the installation directory is non-writable, and the byte code files don't exist.

[1/1] test_compileall
test test_compileall failed -- Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_compileall.py", line 194, in test_no_args_respects_force_flag
    self.assertRunOK('-f', PYTHONPATH=self.directory)
  File "/usr/lib/python3.4/test/test_compileall.py", line 144, in assertRunOK
    *self._get_run_args(args), **env_vars)
  File "/usr/lib/python3.4/test/script_helper.py", line 69, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/lib/python3.4/test/script_helper.py", line 55, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:


1 test failed:
    test_compileall
Re-running failed tests in verbose mode
Re-running test 'test_compileall' in verbose mode

======================================================================
FAIL: test_no_args_respects_force_flag (test.test_compileall.CommandLineTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_compileall.py", line 194, in test_no_args_respects_force_flag
    self.assertRunOK('-f', PYTHONPATH=self.directory)
  File "/usr/lib/python3.4/test/test_compileall.py", line 144, in assertRunOK
    *self._get_run_args(args), **env_vars)
  File "/usr/lib/python3.4/test/script_helper.py", line 69, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/lib/python3.4/test/script_helper.py", line 55, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:

----------
messages: 216553
nosy: doko
priority: normal
severity: normal
status: open
title: test_compileall fails to build in the installed location

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

From report at bugs.python.org  Wed Apr 16 21:00:24 2014
From: report at bugs.python.org (metagriffin)
Date: Wed, 16 Apr 2014 19:00:24 +0000
Subject: [New-bugs-announce] [issue21265] ConfigParser allows "get(*,
	raw=True), but no corresponding "set(*, raw=True)"
Message-ID: <1397674824.07.0.686320086238.issue21265@psf.upfronthosting.co.za>


New submission from metagriffin:

the ConfigParser classes allow option values with interpolation syntax violations to be loaded from an INI file, and to be extracted as long as the `raw` parameter is set to True in the get*() methods. the following code demonstrates this asymmetry:

``` python
import configparser
import io

buf = io.StringIO('[time]\nfmt = %H:%M:%S\n')
cfg = configparser.SafeConfigParser()
cfg.readfp(buf)

# prove that "%H:%M:%S" is valid in a SafeConfigParser:
assert cfg.get('time', 'fmt', raw=True) == '%H:%M:%S'

# but it cannot be set:
cfg.set('time', 'fmt', '%I:%M %p')
# => raises configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%I:%M %p'
```

the intuitive resolution to this asymmetry is to add a `raw` parameter to set(), which would allow:

``` python
cfg.set('time', 'fmt', '%I:%M %p', raw=True)
assert cfg.get('time', 'fmt', raw=True) == '%I:%M %p'
```

note that this is a new problem to python 3, which added the following lines to the ConfigParser.set() method:

``` python
if value:
    value = self._interpolation.before_set(self, section, option,
                                            value)
```

----------
components: Library (Lib)
messages: 216554
nosy: metagriffin
priority: normal
severity: normal
status: open
title: ConfigParser allows "get(*, raw=True), but no corresponding "set(*, raw=True)"
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 16 21:03:23 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 16 Apr 2014 19:03:23 +0000
Subject: [New-bugs-announce] [issue21266] test_zipfile fails to run in the
	installed location
Message-ID: <1397675003.86.0.260943331629.issue21266@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the installation directory is non-writable, and the byte code files don't exist.

test_write_filtered_python_package (test.test_zipfile.PyZipFileTests) ... ERROR
test_write_pyfile (test.test_zipfile.PyZipFileTests) ... ERROR
test_write_with_optimization (test.test_zipfile.PyZipFileTests) ... ERROR

======================================================================
ERROR: test_write_filtered_python_package (test.test_zipfile.PyZipFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_zipfile.py", line 638, in test_write_filtered_python_package
    zipfp.writepy(packagedir)
  File "/usr/lib/python3.4/zipfile.py", line 1628, in writepy
    basename)
  File "/usr/lib/python3.4/zipfile.py", line 1705, in _get_codename
    if _compile(file_py):
  File "/usr/lib/python3.4/zipfile.py", line 1670, in _compile
    py_compile.compile(file, doraise=True, optimize=optimize)
  File "/usr/lib/python3.4/py_compile.py", line 142, in compile
    importlib._bootstrap._write_atomic(cfile, bytecode, mode)
  File "<frozen importlib._bootstrap>", line 106, in _write_atomic
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.4/test/__pycache__/memory_watchdog.cpython-34.pyc.139687366844208'

======================================================================
ERROR: test_write_pyfile (test.test_zipfile.PyZipFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_zipfile.py", line 599, in test_write_pyfile
    zipfp.writepy(fn)
  File "/usr/lib/python3.4/zipfile.py", line 1653, in writepy
    fname, arcname = self._get_codename(pathname[0:-3], basename)
  File "/usr/lib/python3.4/zipfile.py", line 1705, in _get_codename
    if _compile(file_py):
  File "/usr/lib/python3.4/zipfile.py", line 1670, in _compile
    py_compile.compile(file, doraise=True, optimize=optimize)
  File "/usr/lib/python3.4/py_compile.py", line 142, in compile
    importlib._bootstrap._write_atomic(cfile, bytecode, mode)
  File "<frozen importlib._bootstrap>", line 106, in _write_atomic
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.4/test/__pycache__/test_zipfile.cpython-34.pyc.139687366825440'
======================================================================
ERROR: test_write_with_optimization (test.test_zipfile.PyZipFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_zipfile.py", line 667, in test_write_with_optimization
    zipfp.writepy(packagedir)
  File "/usr/lib/python3.4/zipfile.py", line 1607, in writepy
    fname, arcname = self._get_codename(initname[0:-3], basename)
  File "/usr/lib/python3.4/zipfile.py", line 1720, in _get_codename
    if not _compile(file_py, optimize=self._optimize):
  File "/usr/lib/python3.4/zipfile.py", line 1670, in _compile
    py_compile.compile(file, doraise=True, optimize=optimize)
  File "/usr/lib/python3.4/py_compile.py", line 142, in compile
    importlib._bootstrap._write_atomic(cfile, bytecode, mode)
  File "<frozen importlib._bootstrap>", line 106, in _write_atomic
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.4/email/__pycache__/__init__.cpython-34.pyo.139687366825104'

----------
components: Tests
messages: 216556
nosy: doko
priority: normal
severity: normal
status: open
title: test_zipfile fails to run in the installed location
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 16 22:00:03 2014
From: report at bugs.python.org (akira)
Date: Wed, 16 Apr 2014 20:00:03 +0000
Subject: [New-bugs-announce] [issue21267] mktime_tz may return wrong result
	for past dates before	Python 2.7.4
Message-ID: <1397678403.49.0.851331817917.issue21267@psf.upfronthosting.co.za>


New submission from akira:

>>> from email.utils import mktime_tz, parsedate_tz
>>> mktime_tz(parsedate_tz('Thu, 1 Jan 1970 00:00:00 GMT'))
3600.0

It must returns `0` instead of `3600.0` assuming POSIX timestamp.

UTC offsets in 1970 and today are different from each other by one hour in my local timezone (`time.mktime(1970, ..)` uses one UTC offset and `time.timezone` another). There are around a hundred such timezones.

Note: `time.timezone == time.altzone` in my local timezone i.e., it can't be the documented DST issue.

The bug is present in Python 2.6.9 (the last 2.6 release). 
The bug is present in Python 2.7.3 (Ubuntu 12.04 LTS supported until 2017)

It is fixed in Python 2.7.4+ while replacing `time.mktime` with `calendar.timegm` in issue 14653.

----------
components: email
messages: 216572
nosy: akira, barry, r.david.murray
priority: normal
severity: normal
status: open
title: mktime_tz may return wrong result for past dates before Python 2.7.4
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 16 22:26:52 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Apr 2014 20:26:52 +0000
Subject: [New-bugs-announce] [issue21268] Update pydoc module docstring
Message-ID: <1397680012.16.0.887791975702.issue21268@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

?In the Python interpreter, do "from pydoc import help" to provide online help.?

?online? has changed meaning in the last decades, and help is a semi-builtin automatically added by the site module on startup.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 216581
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Update pydoc module docstring
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 16 22:47:42 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 16 Apr 2014 20:47:42 +0000
Subject: [New-bugs-announce] [issue21269] Provide args and kwargs attributes
	on mock call objects
Message-ID: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za>


New submission from Michael Foord:

The unittest.mock.call object could have args/kwargs attributes to easily access the arguments it was called with.

----------
messages: 216585
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Provide args and kwargs attributes on mock call objects

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

From report at bugs.python.org  Wed Apr 16 22:49:19 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 16 Apr 2014 20:49:19 +0000
Subject: [New-bugs-announce] [issue21270] unittest.mock.call object has
	inherited count method
Message-ID: <1397681359.44.0.204245756188.issue21270@psf.upfronthosting.co.za>


New submission from Michael Foord:

The unittest.mock.call object inherits methods from tuple that prevent you using them as normal call attributes. They should be overridden.

----------
assignee: michael.foord
messages: 216587
nosy: kushal.das, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest.mock.call object has inherited count method
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 16 22:51:44 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 16 Apr 2014 20:51:44 +0000
Subject: [New-bugs-announce] [issue21271] reset_mock needs parameters to
	also reset return_value	and side_effect
Message-ID: <1397681504.34.0.196484984277.issue21271@psf.upfronthosting.co.za>


New submission from Michael Foord:

unittest.mock.Mock.reset_mock deliberately doesn't reset the return_value and side_effect. It would be nice if it gained parameters so that it *could*.

----------
assignee: michael.foord
components: Library (Lib)
messages: 216588
nosy: kushal.das, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: reset_mock needs parameters to also reset return_value and side_effect
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Apr 17 00:12:08 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 16 Apr 2014 22:12:08 +0000
Subject: [New-bugs-announce] [issue21272] use _sysconfigdata.py in
	distutils.sysconfig to	initialize distutils.sysconfig
Message-ID: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za>


New submission from Matthias Klose:

distutils/sysconfig still parses the Makefile and config header; it should use the same approach now as the toplevel sysconfig module.

----------
components: Library (Lib)
files: distutils-init.diff
keywords: patch
messages: 216609
nosy: doko
priority: normal
severity: normal
status: open
title: use _sysconfigdata.py in distutils.sysconfig to initialize distutils.sysconfig
versions: Python 3.5
Added file: http://bugs.python.org/file34931/distutils-init.diff

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

From report at bugs.python.org  Thu Apr 17 00:30:07 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 16 Apr 2014 22:30:07 +0000
Subject: [New-bugs-announce] [issue21273] don't defined socket constants
	which are not implemented	for GNU/Hurd
Message-ID: <1397687407.58.0.755430574464.issue21273@psf.upfronthosting.co.za>


New submission from Matthias Klose:

Comment out constant exposed on the API which are not implemented on
GNU/Hurd. They would not work at runtime anyway.

----------
components: Extension Modules
files: hurd-disable-nonworking-constants.diff
keywords: patch
messages: 216610
nosy: doko
priority: normal
severity: normal
status: open
title: don't defined socket constants which are not implemented for GNU/Hurd
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34932/hurd-disable-nonworking-constants.diff

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

From report at bugs.python.org  Thu Apr 17 00:32:56 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 16 Apr 2014 22:32:56 +0000
Subject: [New-bugs-announce] [issue21274] define PATH_MAX for GNU/Hurd in
	Python/pythonrun.c
Message-ID: <1397687576.16.0.104530346632.issue21274@psf.upfronthosting.co.za>


New submission from Matthias Klose:

PATH_MAX is not defined on GNU/Hurd. Take the same approach as taken for Windows in the very same file and define it in terms of MAXPATHLEN.

----------
components: Interpreter Core
files: hurd-path_max.diff
keywords: patch
messages: 216611
nosy: doko
priority: normal
severity: normal
status: open
title: define PATH_MAX for GNU/Hurd in Python/pythonrun.c
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34933/hurd-path_max.diff

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

From report at bugs.python.org  Thu Apr 17 00:38:33 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 16 Apr 2014 22:38:33 +0000
Subject: [New-bugs-announce] [issue21275] fix a socket test on KFreeBSD
Message-ID: <1397687913.02.0.0778138511124.issue21275@psf.upfronthosting.co.za>


New submission from Matthias Klose:

Fix a socket test on KFreeBSD

----------
components: Tests
files: kfreebsd-testsuite.diff
keywords: patch
messages: 216612
nosy: doko
priority: normal
severity: normal
status: open
title: fix a socket test on KFreeBSD
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34934/kfreebsd-testsuite.diff

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

From report at bugs.python.org  Thu Apr 17 00:39:55 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 16 Apr 2014 22:39:55 +0000
Subject: [New-bugs-announce] [issue21276] don't define USE_XATTRS on
	kfreebsd and the Hurd
Message-ID: <1397687995.9.0.529028609843.issue21276@psf.upfronthosting.co.za>


New submission from Matthias Klose:

don't define USE_XATTRS on kfreebsd and the Hurd, not available there.

----------
files: kfreebsd-xattrs.diff
keywords: patch
messages: 216613
nosy: doko
priority: normal
severity: normal
status: open
title: don't define USE_XATTRS on kfreebsd and the Hurd
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34935/kfreebsd-xattrs.diff

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

From report at bugs.python.org  Thu Apr 17 00:44:26 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 16 Apr 2014 22:44:26 +0000
Subject: [New-bugs-announce] [issue21277] don't try to link _ctypes with a
	ffi_convenience library
Message-ID: <1397688266.23.0.303919517358.issue21277@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the ffi_convenience library was once built and installed with oldish GCC versions. Either remove it completely from the search path, or search for  the standard libffi system library.

--- a/setup.py
+++ b/setup.py
@@ -1939,7 +1939,7 @@
                         break
         ffi_lib = None
         if ffi_inc is not None:
-            for lib_name in ('ffi_convenience', 'ffi_pic', 'ffi'):
+            for lib_name in ('ffi', 'ffi_convenience', 'ffi_pic', 'ffi'):
                 if (self.compiler.find_library_file(lib_dirs, lib_name)):
                     ffi_lib = lib_name
                     break

----------
components: Build
messages: 216614
nosy: doko
priority: normal
severity: normal
status: open
title: don't try to link _ctypes with a ffi_convenience library
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr 17 01:02:40 2014
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Wed, 16 Apr 2014 23:02:40 +0000
Subject: [New-bugs-announce] [issue21278] Running the test suite with -v
	makes the test_ctypes and	the test_zipimport erroneously
	reported as failed
Message-ID: <1397689360.76.0.544034222842.issue21278@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

Running 

EXTRATESTOPTS='-x test_gdb -uall -v' make testall

Produces:

....
test_csv
test_ctypes
test test_ctypes produced unexpected output:
**********************************************************************
Trying:
    from ctypes import *
Expecting nothing
ok
Trying:
    array = (c_char_p * 5)()
Expecting nothing
ok
Trying:
    print array._objects
Expecting:
    None
ok
Trying:
    array[4] = 'foo bar'
Expecting nothing
ok
Trying:
    array._objects
Expecting:
    {'4': 'foo bar'}
ok
Trying:
    array[4]
Expecting:
    'foo bar'
ok
Trying:
    class X(Structure):
        _fields_ = [("x", c_int), ("y", c_int), ("array", c_char_p * 5)]
Expecting nothing
ok
Trying:
    x = X()
Expecting nothing
ok
Trying:
    print x._objects
Expecting:
    None
ok
Trying:
    print x.array._b_base_ # doctest: +ELLIPSIS
Expecting:
    <ctypes.test.test_objects.X object at 0x...>
ok
Trying:
    x.array[0] = 'spam spam spam'
Expecting nothing
ok
Trying:
    x._objects
Expecting:
    {'0:2': 'spam spam spam'}
ok
Trying:
    x.array._b_base_._objects
Expecting:
    {'0:2': 'spam spam spam'}
ok
2 items had no tests:
    ctypes.test.test_objects.TestCase
    ctypes.test.test_objects.TestCase.test
1 items passed all tests:
  13 tests in ctypes.test.test_objects
13 tests in 3 items.
13 passed and 0 failed.
Test passed.

**********************************************************************
test_curses
.....
test_zipimport
test test_zipimport produced unexpected output:
**********************************************************************
Trying:
    log.append(True)
Expecting nothing
ok
1 items passed all tests:
   1 tests in xyz.txt
1 tests in 1 items.
1 passed and 0 failed.
Test passed.
Trying:
    log.append(True)
Expecting nothing
ok
1 items passed all tests:
   1 tests in xyz.txt
1 tests in 1 items.
1 passed and 0 failed.
Test passed.

**********************************************************************
test_zipimport_support
test_zlib
366 tests OK.
4 tests failed:
    test_ctypes test_urllib2net test_urllibnet test_zipimport
26 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_curses test_dl test_gl
    test_imageop test_imgfile test_kqueue test_linuxaudiodev
    test_macos test_macostools test_msilib test_ossaudiodev
    test_pep277 test_scriptpackages test_startfile test_sunaudiodev
    test_winreg test_winsound test_zipfile64
2 skips unexpected on linux2:
    test_bsddb test_bsddb3

Clearly the test_ctypes and the test_zipimport are not failing but the test suite thinks so. In fact, rerunning without the -v let them succeed.

----------
messages: 216616
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 17 03:01:22 2014
From: report at bugs.python.org (bob gailer)
Date: Thu, 17 Apr 2014 01:01:22 +0000
Subject: [New-bugs-announce] [issue21279] str.translate documentation
	incomplete
Message-ID: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za>


New submission from bob gailer:

Documentation for str.translate only mentions a dictionary for the translation table. Actually any iterable can be used, as long as its elements are integer, None or str.

Recommend wording:

str.translate(translation_table)

Return a copy of the s where all characters have been "mapped" through the translation_table - which must be either a dictionary mapping Unicode ordinals (integers) to Unicode ordinals, strings or None,
or an iterable. In this case the ord() of each character in s is used as an index into the iterable; the corresponding element of the iterable replaces the character. If ord() of the character exceeds the index range of the iterator, no substitution is made.

Example: to shift any of the first 255 ASCII characters to the next:

>>> 'Now is the time for all good men'.translate(range(1, 256))
'Opx!jt!uif!ujnf!gps!bmm!hppe!nfo'

COMMENT: I placed mapped in quotes as technically this only applies to dictionaries. Not sure what the best word is.

----------
assignee: docs at python
components: Documentation
messages: 216630
nosy: bgailer, docs at python
priority: normal
severity: normal
status: open
title: str.translate documentation incomplete
type: enhancement
versions: Python 3.3

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

From barry at python.org  Thu Apr 17 04:49:25 2014
From: barry at python.org (Barry Warsaw)
Date: Wed, 16 Apr 2014 22:49:25 -0400
Subject: [New-bugs-announce] [issue21272] use _sysconfigdata.py in
 distutils.sysconfig to	initialize distutils.sysconfig
In-Reply-To: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za>
References: <1397686328.42.0.129070062942.issue21272@psf.upfronthosting.co.za>
Message-ID: <20140416224925.05ccf7f2@anarchist.localdomain>

On Apr 16, 2014, at 10:12 PM, Matthias Klose wrote:

>
>distutils/sysconfig still parses the Makefile and config header; it should
>use the same approach now as the toplevel sysconfig module.

Why do we still have two sysconfig modules?

From report at bugs.python.org  Thu Apr 17 10:09:59 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 17 Apr 2014 08:09:59 +0000
Subject: [New-bugs-announce] [issue21280] shutil.make_archive() with default
	"root_dir" parameter	raises FileNotFoundError: [Errno 2] No
	such file or directory: ''
Message-ID: <1397722199.92.0.999945404475.issue21280@psf.upfronthosting.co.za>


New submission from Martin Panter:

>>> from shutil import make_archive; make_archive("a", "tar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/shutil.py", line 783, in make_archive
    filename = func(base_name, base_dir, **kwargs)
  File "/usr/lib/python3.4/shutil.py", line 605, in _make_tarball
    os.makedirs(archive_dir)
  File "/usr/lib/python3.4/os.py", line 244, in makedirs
    mkdir(name, mode)
FileNotFoundError: [Errno 2] No such file or directory: ''

Looking at the code, it calls os.path.dirname("a.tar") -> "", which would be the cause of this bug.

The workaround for me was adding an explicit make_archive(root_dir=".") parameter.

I was also surprised to see the code calling os.makedirs(archive_dir). Usually if you try to make a file in a non-existent directory, it fails, rather than automatically creating the directory for you. But maybe that?s just a general spirit of the ?shutil? module that I didn?t pick up on.

----------
components: Library (Lib)
messages: 216672
nosy: vadmium
priority: normal
severity: normal
status: open
title: shutil.make_archive() with default "root_dir" parameter raises FileNotFoundError: [Errno 2] No such file or directory: ''
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Apr 17 10:52:07 2014
From: report at bugs.python.org (Sebastian Jylanki)
Date: Thu, 17 Apr 2014 08:52:07 +0000
Subject: [New-bugs-announce] [issue21281] DEBUGGING: Simultaneous stopping
	of all threads on	breakpoint and switching between threads
Message-ID: <1397724727.36.0.728876639251.issue21281@psf.upfronthosting.co.za>


New submission from Sebastian Jylanki:

When debugging with some of the other very popular tools like GDB all the threads are halted when a breakpoint is hit on any of the threads. Then threads can be switched and analyzed separately at the current state of execution.

When debugging with PDB only the thread that hits the breakpoint is halted. This makes it quite hard to debug multi-threaded programs (like IO based programs). Also it's annoying that the console output will be shown from other threads when the debugger is stopped.

I think it would be extremely helpful for many people to have PDB behave like GDB when debugging multithreaded applications: halt execution on all threads when breakpoint is hit and continue execution on all threads when execution is continued from the debugger.

----------
components: Interpreter Core
messages: 216677
nosy: azyr
priority: normal
severity: normal
status: open
title: DEBUGGING: Simultaneous stopping of all threads on breakpoint and switching between threads
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr 17 13:09:22 2014
From: report at bugs.python.org (Lukas Vacek)
Date: Thu, 17 Apr 2014 11:09:22 +0000
Subject: [New-bugs-announce] [issue21282] setup.py: More informative error
	msg for modules which	built but failed import check
Message-ID: <1397732962.82.0.641060383961.issue21282@psf.upfronthosting.co.za>


New submission from Lukas Vacek:

Hey,

Currently when a module builds successfully during cpython build but it can't be imported (import check around line 330 in setup.py) the module shows in "Failed to build these modules: " which can be misleading.

Especially when linking against libraries in non-standard locations the user would set LD_FLAGS and CPPFLAGS and then ... wonder why the cpython build process is not picking the libraries up and the module is not built.

I think the modules which *have built* but were removed because of a failed import check should be marked as such so the user knows what happens and can take appropriate actions (set LD_LIBRARY_PATH as well, for example).

A patch attached - it's a very simple change (about 10 lines), created with "hg export".

Thanks,
Lucas

----------
components: Build
files: setup_failed_import_hgexport
messages: 216684
nosy: Lukas.Vacek
priority: normal
severity: normal
status: open
title: setup.py: More informative error msg for modules which built but failed import check
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34942/setup_failed_import_hgexport

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

From report at bugs.python.org  Thu Apr 17 15:54:45 2014
From: report at bugs.python.org (Tito Bouzout)
Date: Thu, 17 Apr 2014 13:54:45 +0000
Subject: [New-bugs-announce] [issue21283] A escape character is used when a
	REGEXP is an argument	of "strip" string function
Message-ID: <1397742885.45.0.765313151501.issue21283@psf.upfronthosting.co.za>


New submission from Tito Bouzout:

Hello!

I got a report that the character "\" was removed from a string using the following code

> "\\server\path\to".strip(r'"\'<>') 

At first insight, looks like a bug, because I don't expect the use of the escape character at all. Then I noticed, that our mistake there is that the "strip" argument should be a "string" not a REGEXP.

Kinda weird to read, and I've no idea if this is expected behaviour in Python, as I'm relatively very new. So just informing, 

Kind regards, 

-- 
Tito

----------
components: Regular Expressions
messages: 216687
nosy: Tito.Bouzout, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: A escape character is used when a REGEXP is an argument of "strip" string function
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 17 17:19:39 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Apr 2014 15:19:39 +0000
Subject: [New-bugs-announce] [issue21284] IDLE reformat tests fail in
	presence of non-default	FormatParagraph setting
Message-ID: <1397747979.02.0.575213731893.issue21284@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

When a user sets FormatParagraph to anything other than 70,
test_idle.py has 4 failing tests:

test_comment_block (idlelib.idle_test.test_formatparagraph.FormatEventTest) ... FAIL
test_long_line (idlelib.idle_test.test_formatparagraph.FormatEventTest) ... FAIL
test_multiple_lines (idlelib.idle_test.test_formatparagraph.FormatEventTest) ... FAIL
test_short_line (idlelib.idle_test.test_formatparagraph.FormatEventTest) ... FAIL

The solution is to make these tests setup by:
  1) save the user's default configuration
  2) set the paragraph reformat width to 70
and tear-down by:
  1) restoring the user's default configuration

----------
components: IDLE
keywords: easy
messages: 216695
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE reformat tests fail in presence of non-default FormatParagraph setting
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr 17 18:04:16 2014
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 17 Apr 2014 16:04:16 +0000
Subject: [New-bugs-announce] [issue21285] refactor anfd fix curses configure
	checks
Message-ID: <1397750656.23.0.437739592471.issue21285@psf.upfronthosting.co.za>


New submission from Matthias Klose:

this refactors the curses configure checks, and fixes the build with ncursesw.  In it's current form the curses feature checks are run without the additional include path which leads to wrong results if the only the nurses headers are installed.

----------
components: Build
files: ncurses-configure.diff
keywords: patch
messages: 216704
nosy: doko
priority: normal
severity: normal
status: open
title: refactor anfd fix curses configure checks
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34949/ncurses-configure.diff

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

From report at bugs.python.org  Thu Apr 17 18:38:54 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Apr 2014 16:38:54 +0000
Subject: [New-bugs-announce] [issue21286] Refcounting information missing in
	docs for Python 3.4	and above.
Message-ID: <1397752734.97.0.965637829315.issue21286@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

It looks as though the information from refcounts.dat isn't making it into the online docs for 3.4 and 3.5.  See e.g., the documentation for PyList_GetItem.  For 3.3 [2], there's a "Return value: Borrowed reference." annotation supplied by Sphinx's refcounting extension.  For the 3.4 and 3.5 docs that annotation is missing.

Issue originally reported by Jianfeng Mao on the python-dev mailing list [1].

[1] https://mail.python.org/pipermail/python-dev/2014-April/134089.html
[2] https://docs.python.org/3.3/c-api/list.html?highlight=pylist_getitem#PyList_GetItem

----------
assignee: docs at python
components: Documentation
messages: 216707
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Refcounting information missing in docs for Python 3.4 and above.
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr 17 20:39:07 2014
From: report at bugs.python.org (=?utf-8?b?0JjQs9C+0YDRjCDQn9Cw0YjQtdCy?=)
Date: Thu, 17 Apr 2014 18:39:07 +0000
Subject: [New-bugs-announce] [issue21287] Better support for AF_PACKET on
	opensolaris (illumos)
Message-ID: <1397759947.91.0.17620010785.issue21287@psf.upfronthosting.co.za>


New submission from ????? ?????:

SIOCGIFINDEX could be defined in illumos (aka OpenSolaris) if BSD_COMP macro defined. This causes known error: no member ifr_ifindex in struct ifreq.

But OpenSolaris provides newer interface with struct lifreq and SIOCGLIFINDEX.

Attached patch tries to use it.

----------
components: Library (Lib)
files: dyson-socketmodule-ifindex.patch
keywords: patch
messages: 216727
nosy: ?????.?????
priority: normal
severity: normal
status: open
title: Better support for AF_PACKET on opensolaris (illumos)
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file34952/dyson-socketmodule-ifindex.patch

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

From report at bugs.python.org  Thu Apr 17 20:44:52 2014
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 17 Apr 2014 18:44:52 +0000
Subject: [New-bugs-announce] [issue21288] hashlib.pbkdf2_hmac Hash
	Constructor
Message-ID: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za>


New submission from Armin Ronacher:

Is there a specific reason why hashlib.pbkdf2_hmac now has a completely inconsistent API with the rest of the stdlib?  So far the concept in both hashlib and hmac has been to accept hash constructors as parameters.

As such you would expect the API to look like this:

hashlib.pbkdf2_hmac(hashlib.sha256, b'password', b'salt', 100000)

Instead the API now is string based.

This is annoying because a lot of code already in the past exposed a pbkdf2 implementation that allows passing in a hashlib constructor by passing it to HMAC.

If such code now wants to use the stdlib pbkdf2_hmac implementation it has to special case known implementations.  If a non known implementation is found it needs to dispatch to a separate implementation of PBKDF2.

In addition to that there is no nice way to detect if a algorithm is not supported as the exception raised for an invalid algorithm is the same as an invalid parameter for the iteration count (ValueError).

I would propose to change the API to allow hash constructors to be passed in in addition to strings.

----------
messages: 216728
nosy: aronacher
priority: normal
severity: normal
status: open
title: hashlib.pbkdf2_hmac Hash Constructor
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 17 22:14:03 2014
From: report at bugs.python.org (Dave Sawyer)
Date: Thu, 17 Apr 2014 20:14:03 +0000
Subject: [New-bugs-announce] [issue21289] make.bat not building documentation
Message-ID: <1397765643.91.0.331086007996.issue21289@psf.upfronthosting.co.za>


New submission from Dave Sawyer:

With Python 3.5, some refactoring of the documentation structure has been done. Building the documentation targets directly works, but using the supplied make.bat fails, not finding the sphinx python file.

----------
assignee: docs at python
components: Documentation
messages: 216737
nosy: docs at python, dsawyer
priority: normal
severity: normal
status: open
title: make.bat not building documentation
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Thu Apr 17 23:42:34 2014
From: report at bugs.python.org (Aaron Briel)
Date: Thu, 17 Apr 2014 21:42:34 +0000
Subject: [New-bugs-announce] [issue21290] imaplib.error when importing email
	package
Message-ID: <1397770954.41.0.647416164199.issue21290@psf.upfronthosting.co.za>


New submission from Aaron Briel:

I see an error when attempting to import the email package on a mac running Python 2.7.6rc1 (v2.7.6rc1:4913d0e9be30+, Oct 27 2013, 20:52:11) .  This does not occur on another system running Python 2.7.3 (default, Mar 25 2013, 15:56:58) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2.

aaron-mbp15:core aaronb$ python2.7
Python 2.7.6rc1 (v2.7.6rc1:4913d0e9be30+, Oct 27 2013, 20:52:11) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "email.py", line 7, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py", line 443, in fetch
    typ, dat = self._simple_command(name, message_set, message_parts)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py", line 1070, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/imaplib.py", line 905, in _command_complete
    raise self.error('%s command error: %s %s' % (name, typ, data))
imaplib.error: FETCH command error: BAD ['Could not parse command']
>>>

----------
components: email
messages: 216752
nosy: barry, r.david.murray, teraincognita
priority: normal
severity: normal
status: open
title: imaplib.error when importing email package
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 17 23:49:43 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Apr 2014 21:49:43 +0000
Subject: [New-bugs-announce] [issue21291] subprocess Popen objects are not
	thread safe w.r.t.	wait() and returncode being set
Message-ID: <1397771383.14.0.251860763766.issue21291@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Executing the supplied test code you either get:

sys.version = 3.4.0+ (3.4:635817da596d, Apr 17 2014, 14:30:34) 
[GCC 4.6.3]
--------
Results with <class 'subprocess.Popen'>:
  r0    = None, expected None 
  r1    = None, expected None 
  ri0   = None, expected None 
  ri1   = -9, expected -9 
  ri2   = -9, expected -9 
  r2    = 0, expected -9 *** MISMATCH ***
  r3    = 0, expected -9 *** MISMATCH ***

or

Results with <class 'subprocess.Popen'>:
  r0    = None, expected None 
  r1    = None, expected None 
  ri0   = None, expected None 
  ri1   = -9, expected -9 
  ri2   = -9, expected -9 
  r2    = 0, expected -9 *** MISMATCH ***
  r3    = 0, expected -9 *** MISMATCH ***

At first glance it appears that the .returncode attribute is not safely set after the wait call... This test code is using the Popen object from multiple threads at once.

----------
assignee: gregory.p.smith
files: subprocess_wait_problem.py
messages: 216757
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: subprocess Popen objects are not thread safe w.r.t. wait() and returncode being set
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34955/subprocess_wait_problem.py

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

From report at bugs.python.org  Thu Apr 17 23:51:18 2014
From: report at bugs.python.org (Steve)
Date: Thu, 17 Apr 2014 21:51:18 +0000
Subject: [New-bugs-announce] [issue21292] C API in debug fails
Message-ID: <1397771478.75.0.526004579779.issue21292@psf.upfronthosting.co.za>


New submission from Steve:

Although not a bug, it annoys me enough that it is a bug in my head!

The problem is that trying to compile an application in debug that embeds Python fails.

Case in point; we canned the idea of embedding Python (went with Lua) for that reason only.  We did not have the option of incorporating a Python build into our build system and not being able to compile in debug was not an option either.  We would have been happy to compile in debug with a release lib of Python, but since it was not possible, it got killed.

The fix: It should be possible for someone to compile an application in debug that embeds python without having the Python debug libraries.

----------
components: Library (Lib)
messages: 216759
nosy: Banger
priority: normal
severity: normal
status: open
title: C API in debug fails
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 18 01:55:53 2014
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 17 Apr 2014 23:55:53 +0000
Subject: [New-bugs-announce] [issue21293] Remove "capsule hack" from
	object.c?
Message-ID: <1397778953.55.0.677894894827.issue21293@psf.upfronthosting.co.za>


New submission from Larry Hastings:

I noticed this code in Objects/object.c today:

    /* Hack to force loading of pycapsule.o */
    PyTypeObject *_PyCapsule_hack = &PyCapsule_Type;

What is this doing?  Note that PyCapsule_Type is referred to inside _Py_ReadyTypes(), so there's already a reference to it from this module.  This global seems redundant.

Attached is a patch that removes it.  Trunk compiles and all tests pass with it applied, though I only tried on 64-bit Linux so I concede if this is handling some obscure edge case I probably wouldn't have hit it.

----------
files: larry.remove.no.capsule.hack.1.diff
keywords: patch
messages: 216766
nosy: larry
priority: low
severity: normal
stage: patch review
status: open
title: Remove "capsule hack" from object.c?
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file34958/larry.remove.no.capsule.hack.1.diff

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

From report at bugs.python.org  Fri Apr 18 06:19:33 2014
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 18 Apr 2014 04:19:33 +0000
Subject: [New-bugs-announce] [issue21294] len wrong help
Message-ID: <1397794773.2.0.687727547467.issue21294@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

>From recently, help(len) gives the wrong signature of len.

Help on built-in function len in module builtins:

len(...)
    len(module, object)
        ^^^^^^^^
    Return the number of items of a sequence or mapping.

I tried to track it down, I think it happened here: http://bugs.python.org/file33655/larry.support.text_signature.on.more.types.6.txt

I realize it was a part of some big fix, so I don't know how easy it is to fix independently. Also, you might think it's not so big an issue. But I teach Python, and my pupils are really confused because of this. Please fix it if anyhow possible. Tnx.

----------
assignee: docs at python
components: Documentation
messages: 216771
nosy: Vedran.?a?i?, docs at python
priority: normal
severity: normal
status: open
title: len wrong help
versions: Python 3.4

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

From report at bugs.python.org  Fri Apr 18 12:49:40 2014
From: report at bugs.python.org (Aivar Annamaa)
Date: Fri, 18 Apr 2014 10:49:40 +0000
Subject: [New-bugs-announce] [issue21295] Python 3.4 gives wrong col_offset
	for Call nodes	returned from ast.parse
Message-ID: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>


New submission from Aivar Annamaa:

Following program gives correct result in Python versions older than 3.4, but incorrect result in 3.4:

----------------------
import ast
tree = ast.parse("sin(0.5)")
first_stmt = tree.body[0]
call = first_stmt.value
print("col_offset of call expression:", call.col_offset)
print("col_offset of func of the call:", call.func.col_offset)
-----------------------

it should print:
col_offset of call expression: 0
col_offset of func of the call: 0

but in 3.4 it prints:
col_offset of call expression: 3
col_offset of func of the call: 0

----------
components: Interpreter Core
files: py34_ast_call_bug.py
messages: 216777
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse
versions: Python 3.4
Added file: http://bugs.python.org/file34962/py34_ast_call_bug.py

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

From report at bugs.python.org  Fri Apr 18 13:03:16 2014
From: report at bugs.python.org (Luiji Maryo)
Date: Fri, 18 Apr 2014 11:03:16 +0000
Subject: [New-bugs-announce] [issue21296] smtplib Sends Commands in
	Lower-Case
Message-ID: <1397818996.26.0.83241644449.issue21296@psf.upfronthosting.co.za>


New submission from Luiji Maryo:

It has occurred to me while testing an SMTP server with smtplib that it sends commands in lower-case. This is problematic because, although most SMTP servers seem to be case-insensitive, RFC 5321 (SMTP) doesn't seem to explicitly require this and there may be systems out there which require upper-case commands. Additionally, the output just looks unclean because the parameters are given capitalized (e.g. we get "mail FROM:<guy at example.com>" instead of "MAIL FROM:<guy at example.com>" or "mail from:<guy at example.com>".

I would propose that putcmd() use cmd.upper(). Alternatively, all instances of putcmd() and docmd() could be updated to have the commands in capitalized form so that, should the user desire, they could send lower-case commands, though I don't quite see what would be useful about that.

----------
messages: 216779
nosy: luiji
priority: normal
severity: normal
status: open
title: smtplib Sends Commands in Lower-Case
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Apr 18 13:52:21 2014
From: report at bugs.python.org (Daniel Andersson)
Date: Fri, 18 Apr 2014 11:52:21 +0000
Subject: [New-bugs-announce] [issue21297] skipinitialspace in the csv module
	only skips spaces, not "whitespace" in general
Message-ID: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za>


New submission from Daniel Andersson:

Regarding the `skipinitialspace` parameter to the different CSV reader dialects in the `csv` module, the official documentation asserts:

    When True, whitespace immediately following the delimiter is ignored.

and the `help(csv)` style module documentation says:

    * skipinitialspace - specifies how to interpret whitespace which
      immediately follows a delimiter.  It defaults to False, which
      means that whitespace immediately following a delimiter is part
      of the following field.

"Whitespace" is a bit too general in both cases (at least a red herring in the second case), since it only skips spaces and not e.g. tabs [1].

In `Modules/_csv.c`, it more correctly describes the parameter. At line 81:

    int skipinitialspace;       /* ignore spaces following delimiter? */

and the actual implementation at line 638:

    else if (c == ' ' && dialect->skipinitialspace)
        /* ignore space at start of field */
        ;

No-one will probably assume that the whole UTF-8 spectrum of "whitespace" is skipped, but at least I initially assumed that the tab character was included.

[1]: http://en.wikipedia.org/wiki/Whitespace_character

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 216780
nosy: Daniel.Andersson, docs at python
priority: normal
severity: normal
status: open
title: skipinitialspace in the csv module only skips spaces, not "whitespace" in general
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Apr 18 14:04:52 2014
From: report at bugs.python.org (Thomas Levine)
Date: Fri, 18 Apr 2014 12:04:52 +0000
Subject: [New-bugs-announce] [issue21298] Cheese shop registration stopped
	working for me recently
Message-ID: <1397822692.79.0.7421176535.issue21298@psf.upfronthosting.co.za>


New submission from Thomas Levine:

This command used to work just fine for me. ::

    python setup.py register

Now it doesn't. For example, ::

    $ python3 setup.py register
    /usr/lib/python3.3/distutils/dist.py:257: UserWarning: Unknown distribution option: 'install_requires'
      warnings.warn(msg)
    /usr/lib/python3.3/distutils/dist.py:257: UserWarning: Unknown distribution option: 'tests_require'
      warnings.warn(msg)
    running register
    running check
    Registering sheetmusic to http://pypi.python.org/pypi
    Server response (401): Unauthorized

But I can submit just fine with the form at
https://pypi.python.org/pypi?%3Aaction=submit_form,
and the following works once I do that. ::

    python setup.py sdist upload

The attached setup.py file is from this package
https://pypi.python.org/pypi/sheetmusic

----------
components: Distutils
files: setup.py
messages: 216781
nosy: dstufft, eric.araujo, tlevine
priority: normal
severity: normal
status: open
title: Cheese shop registration stopped working for me recently
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file34963/setup.py

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

From report at bugs.python.org  Fri Apr 18 14:54:56 2014
From: report at bugs.python.org (Bernie Keimel)
Date: Fri, 18 Apr 2014 12:54:56 +0000
Subject: [New-bugs-announce] [issue21299] Einladung in mein Netzwerk bei
	LinkedIn
Message-ID: <1461749625.20636330.1397825684014.JavaMail.app@ela4-app1549.prod>


New submission from Bernie Keimel:

LinkedIn
------------

Ich m?chte Sie zu meinem beruflichen Netzwerk auf LinkedIn hinzuf?gen.

- Bernard Keimel

Bernard Keimel
Business bei privat
Berlin und Umgebung, Deutschland

Best?tigen, dass Sie Bernard Keimel kennen:
https://www.linkedin.com/e/-3qcne3-hu5hbkmh-1s/isd/16078050493/NNc4mKPz/?hs=false&tok=0SvHBVq3J6v6c1

--
Sie erhalten Einladungen zum Netwerkbeitritt per E-Mail. Klicken Sie hier, wenn Sie kein Interesse daran haben:
http://www.linkedin.com/e/-3qcne3-hu5hbkmh-1s/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I6913898468_1/?hs=false&tok=35uA1JgJ56v6c1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043, USA

----------
messages: 216782
nosy: Bernie.Keimel
priority: normal
severity: normal
status: open
title: Einladung in mein Netzwerk bei LinkedIn

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

From report at bugs.python.org  Fri Apr 18 15:51:28 2014
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 18 Apr 2014 13:51:28 +0000
Subject: [New-bugs-announce] [issue21300] Docs (incorrectly) suggest
	email.policy.default is the	default policy
Message-ID: <1397829088.9.0.524887326408.issue21300@psf.upfronthosting.co.za>


New submission from Merlijn van Deen:

Which would make sense, but email.policy.Compat32 is *actually* the default policy. This patch adapts the documentation to reflect this.

----------
assignee: docs at python
components: Documentation
files: defaultpolicy.diff
keywords: patch
messages: 216783
nosy: docs at python, r.david.murray, valhallasw
priority: normal
severity: normal
status: open
title: Docs (incorrectly) suggest email.policy.default is the default policy
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34964/defaultpolicy.diff

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

From report at bugs.python.org  Fri Apr 18 21:31:05 2014
From: report at bugs.python.org (Alain Mellan)
Date: Fri, 18 Apr 2014 19:31:05 +0000
Subject: [New-bugs-announce] [issue21301] pathlib missing
	Path.expandvars(env=os.environ)
Message-ID: <1397849465.53.0.177138390921.issue21301@psf.upfronthosting.co.za>


New submission from Alain Mellan:

A lot of times paths are manipulated with environment variables that may even be expanded multiple times in a loop. For example, I have a path defined as "$RUNDIR/logfile.txt" and expanding the path for a bunch of different RUNDIRs in a loop.

By default, it should take os.environ and optionally a different dictionary.

Just like os.path.expandvars(), it should expand $VAR, ${VAR} and %VAR%

----------
components: Library (Lib)
messages: 216796
nosy: Alain.Mellan
priority: normal
severity: normal
status: open
title: pathlib missing Path.expandvars(env=os.environ)
type: enhancement

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

From report at bugs.python.org  Fri Apr 18 22:12:03 2014
From: report at bugs.python.org (Shankar Unni)
Date: Fri, 18 Apr 2014 20:12:03 +0000
Subject: [New-bugs-announce] [issue21302] time.sleep (floatsleep()) should
	use clock_nanosleep()	on Linux
Message-ID: <1397851923.06.0.0550198760464.issue21302@psf.upfronthosting.co.za>


New submission from Shankar Unni:

I know that an earlier request to use nanosleep() has been rejected as "wontfix", but I'm filing this one for a different reason.

Today, timemodule.c:floatsleep() calls select() on platforms that support it. On Linux, select() with a timeout has an unfortunate property that it is very sensitive to clock jumps, because it computes a sleep end time based on the current kernel timestamp.

If the system clock is yanked back (by ntpd, or other processes), then the process can end up sleeping for a very long time. (E.g. if the clock is yanked back by half an hour while we are in the middle of, say, a sleep(10), then the process will sleep until "original_kernel_clock+10", which will turn into a half-hour sleep.

Yes, systems shouldn't jerk their clocks around, but we can't often control this sort of thing on end-user environments.

Using clock_nanosleep(CLOCK_MONOTONIC, 0, <timespec>, NULL) makes the sleep a much more reliable thing, and mostly insensitive to such jumps. (It'll still be affected by any adjtime(), but that's OK in this case).

----------
components: Library (Lib)
messages: 216799
nosy: shankarunni
priority: normal
severity: normal
status: open
title: time.sleep (floatsleep()) should use clock_nanosleep() on Linux
type: behavior

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

From report at bugs.python.org  Fri Apr 18 22:31:42 2014
From: report at bugs.python.org (Michael Boldischar)
Date: Fri, 18 Apr 2014 20:31:42 +0000
Subject: [New-bugs-announce] [issue21303] Python 2.7 Spinbox Format Behaves
	Differently On Windows	Versus Linux
Message-ID: <1397853102.02.0.000549588678959.issue21303@psf.upfronthosting.co.za>


New submission from Michael Boldischar:

Here is my code:

   self._image_set_number = Spinbox(self._ramp_group, from_=0, to=999, command=self.reset_rep, format="%03.0f")
   self._repetition_change = Spinbox(self._ramp_group, from_=00, to=99, format="%02.0f")

On Linux, the spinners behave as expected. There are always three digits in "_image_set_number" and two digits in "_repetition_change". The values are padded on the left by zeros. When I use the small arrows to increase the value, it works as expected.

But, on Windows 7 64-bit, the small arrows do not behave as expected. They go up to "008" and then go back to "000" on the next click. Am I missing something or is this a bug in the the Windows version of Tkinter?

----------
messages: 216800
nosy: mboldisc
priority: normal
severity: normal
status: open
title: Python 2.7 Spinbox Format Behaves Differently On Windows Versus Linux

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

From report at bugs.python.org  Sat Apr 19 02:49:06 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 19 Apr 2014 00:49:06 +0000
Subject: [New-bugs-announce] [issue21304] Backport hashlib.pbkdf2_hmac to
	Python 2.7
Message-ID: <1397868546.19.0.546105502788.issue21304@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Pursuant to PEP466, this is a backport of Python 3.4's hashlib.pbkdf2_hmac.

Of note in this patch:

* None of the utilities for testing both a python and a C implementation simultaneously were present, so this only tests whichever implementation is available.
* Due to a variety of API changes and missing APIs, the code is not an exact copy-paste, tough luck :-)
* I haven't done docs yet.
* It currently accepts unicode values because the ``y*`` format from Python3 doesn't have any parallel in Python2. I'm not sure whether consistency with the rest of the 2-verse is more important than consistency with a sane way to treat data / the 3-verse.

----------
components: Extension Modules, Library (Lib)
files: pbkdf2.diff
keywords: patch, security_issue
messages: 216823
nosy: alex
priority: normal
severity: normal
status: open
title: Backport hashlib.pbkdf2_hmac to Python 2.7
versions: Python 2.7
Added file: http://bugs.python.org/file34968/pbkdf2.diff

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

From report at bugs.python.org  Sat Apr 19 02:51:14 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 19 Apr 2014 00:51:14 +0000
Subject: [New-bugs-announce] [issue21305] PEP 466: update os.urandom
Message-ID: <1397868674.52.0.918643592406.issue21305@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Tracker issue for the os.urandom persistent file descriptor backport to 2.7 described in PEP 466.

----------
messages: 216824
nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 466: update os.urandom
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 19 02:53:07 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 19 Apr 2014 00:53:07 +0000
Subject: [New-bugs-announce] [issue21306] PEP 466: backport
	hmac.compare_digest
Message-ID: <1397868787.47.0.118679212536.issue21306@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Tracker issue for the hmac.compare_digest backport to 2.7 described in PEP 466.

----------
messages: 216826
nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 466: backport hmac.compare_digest
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 19 02:54:56 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 19 Apr 2014 00:54:56 +0000
Subject: [New-bugs-announce] [issue21307] PEP 466: backport hashlib changes
Message-ID: <1397868896.33.0.304799131089.issue21307@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Tracker issue for the hashlib PBKDF2 and algorithm availability details backport to 2.7 described in PEP 466.

----------
messages: 216827
nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 466: backport hashlib changes
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 19 02:55:56 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 19 Apr 2014 00:55:56 +0000
Subject: [New-bugs-announce] [issue21308] PEP 466: backport ssl changes
Message-ID: <1397868956.56.0.0572466011298.issue21308@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 466: backport ssl changes
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 19 04:17:06 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Apr 2014 02:17:06 +0000
Subject: [New-bugs-announce] [issue21309] Confusing "see also" for generic
	C-level __init__	methods in help output
Message-ID: <1397873826.04.0.28447838355.issue21309@psf.upfronthosting.co.za>


New submission from R. David Murray:

>>> help(ImportError.__init__)
    Help on wrapper_descriptor:

    __init__(self, /, *args, **kwargs)
        Initialize self.  See help(type(self)) for accurate signature.

The above also appears (without the wrapper_descriptor bit) in the help output for help(ImportError).  In neither case does 'help(type(self))' tell the naive user anything useful, since 'self' doesn't exist in the scope in which they are executing help.  I don't know where this text is coming from (Argument Clinic?), but it could use improvement.  I believe it is trying to say that one should see the help information for the class object.  I'm not sure how you'd spell that usefully.  Maybe "See the object's main help for a more accurate signature"?

And maybe I shouldn't have said naive user: I'm an experienced python developer, and I tried 'help(type(ImportError))', since I saw the above when I'd typed 'help(ImportError)', and it was only when I got the help for 'type' that I realized what it was trying to tell me.  Now, I tried this because the ImportError help does not in fact give the "more accurate signature", which is a different issue, but you get the point.  

We also have:

    >>> x = ImportError()
    >>> help(x.__init__)
    Help on method-wrapper object:

    __init__ = class method-wrapper(object)
     |  Methods defined here:
     |  
     |  __call__(self, /, *args, **kwargs)
     |      Call self as a function.

Maybe that's another bug?  Maybe not.

NB: in 3.3 the text is:

  |  __init__(...)
  |      x.__init__(...) initializes x; see help(type(x)) for signature

So that was worse, since the only time you would see in isolation would be when you are calling help on the class (help(ImportError.__init__)...in which case 'x' is ImportError, and type(x) is...type.  So 3.4 is *better*, but I don't think it is as good as we can do.

----------
components: Interpreter Core
messages: 216836
nosy: larry, r.david.murray
priority: normal
severity: normal
status: open
title: Confusing "see also" for generic C-level __init__ methods in help output
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Apr 19 05:23:49 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 19 Apr 2014 03:23:49 +0000
Subject: [New-bugs-announce] [issue21310] ResourceWarning when open() fails
	with	io.UnsupportedOperation: File or stream is not seekable
Message-ID: <1397877829.49.0.0015217310404.issue21310@psf.upfronthosting.co.za>


New submission from Martin Panter:

>>> f = open("/dev/stdout", "w+b")  # Or any non-seekable file, pipe, etc
__main__:1: ResourceWarning: unclosed file <_io.FileIO name='/dev/stdout' mode='rb+'>
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: File or stream is not seekable.

It is mainly just the annoyance of the ResourceWarning, so nothing major. I think this was previously identified in Issue 18116, but it looks like that bug was side-stepped by removing an equivalent fdopen() call.

No ResourceWarning happens with an unbuffered file. I haven?t looked at the code but I guess the UnsupportedOperation might only be raised after trying to wrap the open FileIO object in a BufferedWriter object.

----------
components: IO
messages: 216838
nosy: vadmium
priority: normal
severity: normal
status: open
title: ResourceWarning when open() fails with io.UnsupportedOperation: File or stream is not seekable
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 19 15:21:02 2014
From: report at bugs.python.org (John Szakmeister)
Date: Sat, 19 Apr 2014 13:21:02 +0000
Subject: [New-bugs-announce] [issue21311] Fix compiler detection when brew's
	ccache is installed	on Mac OS X
Message-ID: <1397913662.53.0.885648478854.issue21311@psf.upfronthosting.co.za>


New submission from John Szakmeister:

It's pretty typical for ccache packages to install symlinks for compilers that may not be present on the system, such as Homebrew's ccache package.  Unfortunately, the _osx_support.py file is mislead by the presence of the symlink and ends up backtracing.

This issue is present in 2.7 and onwards.  I'm attaching two possible fixes for the problem, both created against 2.7.  The issue is that the symlink in detected, but _read_output() returns None, which then fails when the output is examined (if 'str' in None...).  The first patch does a simple non-empty check.  The alternate version makes _read_output() return an empty string instead of None.

----------
components: Distutils
files: fix-osx-llvm-detection-with-ccache.patch
keywords: patch
messages: 216856
nosy: dstufft, eric.araujo, jszakmeister
priority: normal
severity: normal
status: open
title: Fix compiler detection when brew's ccache is installed on Mac OS X
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34972/fix-osx-llvm-detection-with-ccache.patch

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

From report at bugs.python.org  Sat Apr 19 19:30:33 2014
From: report at bugs.python.org (Jack McCracken)
Date: Sat, 19 Apr 2014 17:30:33 +0000
Subject: [New-bugs-announce] [issue21312] Update thread_foobar.h to include
	timed locking and TLS	support
Message-ID: <1397928633.2.0.869900067411.issue21312@psf.upfronthosting.co.za>


New submission from Jack McCracken:

The thread_foobar.h reference for the interface for abstracting the platform-specific thread implementation does not include newer features such as timed locking and TLS support.

----------
components: Interpreter Core
files: update_thread_foobar.diff
keywords: patch
messages: 216867
nosy: Jack.McCracken
priority: normal
severity: normal
status: open
title: Update thread_foobar.h to include timed locking and TLS support
type: enhancement
Added file: http://bugs.python.org/file34974/update_thread_foobar.diff

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

From report at bugs.python.org  Sun Apr 20 00:17:18 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 19 Apr 2014 22:17:18 +0000
Subject: [New-bugs-announce] [issue21313] Py_GetVersion() is broken when
	using mqueue and a long	patch name
Message-ID: <1397945838.86.0.227153547567.issue21313@psf.upfronthosting.co.za>


New submission from Eric Snow:

Py_GetVersion() (in Python/getversion.c) builds the version string returned by sys.version:

  PyOS_snprintf(version, sizeof(version), "%.80s (%.80s) %.80s",
            PY_VERSION, Py_GetBuildInfo(), Py_GetCompiler());

In turn, Py_GetBuildInfo() (in Modules/getbuildinfo.c) returns the "build" portion of Python's version string.  When available, the tag returned by "hg id -t" constitutes part of that build string.

The problem is that when using mqueue the result of "hg id -t" can be pretty long.  For example:

  issue21226-fix-PyImport_ExecCodeModuleObject.diff qbase qtip tip

That's 74 characters for just part of a build string that may be well over 100 characters.  However, Py_GetVersion() truncates it to 80 characters.

The consequence is that this value of sys.version causes platform._sys_version() to fail since the version string does not match the expected pattern.

So either Py_GetVersion() should relax (-1) or Py_GetBuildInfo() should restrict the length of the resulting build string (+1).  Would it work to truncate just the hgid part so that the whole string returned by Py_GetBuildInfo() is no more than length 80?  E.g.


-    PyOS_snprintf(buildinfo, sizeof(buildinfo),
-                  "%s%s%s, %.20s, %.9s", hgid, sep, revision, DATE, TIME);
+    PyOS_snprintf(buildinfo, 80,
+                  "%.43s%.1s%.13s, %.20s, %.9s", hgid, sep, revision, DATE, TIME);

----------
components: Interpreter Core
messages: 216883
nosy: eric.snow
priority: normal
severity: normal
stage: patch review
status: open
title: Py_GetVersion() is broken when using mqueue and a long patch name
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr 20 12:07:19 2014
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 20 Apr 2014 10:07:19 +0000
Subject: [New-bugs-announce] [issue21314] Bizarre help
Message-ID: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

Please look at the output of help(object.__ge__).

1. What's that $ in front of self? lt and gt don't have it.

2. What's that / as a third argument? Many wrapper functions have it (for example, see help(tuple.__len__).

3. What's that -- as the first line of doc? Similar methods don't have it.

----------
assignee: docs at python
components: Documentation
messages: 216899
nosy: Vedran.?a?i?, docs at python
priority: normal
severity: normal
status: open
title: Bizarre help
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr 20 17:58:18 2014
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 20 Apr 2014 15:58:18 +0000
Subject: [New-bugs-announce] [issue21315] email._header_value_parser does
	not recognise in-line	encoding changes
Message-ID: <1398009498.59.0.139606640186.issue21315@psf.upfronthosting.co.za>


New submission from Merlijn van Deen:

Bugzilla sends e-mail in a format where =?UTF-8 is not preceded by whitespace. This makes email.headerregistry.UnstructuredHeader (and email._header_value_parser on the background) not recognise the structure.

>>> import email.headerregistry, pprint
>>> x = {}; email.headerregistry.UnstructuredHeader.parse('[Bug 64155]\tNew:=?UTF-8?Q?=20non=2Dascii=20bug=20t=C3=A9st?=;\trussian text:=?UTF-8?Q?=20=D0=90=D0=91=D0=92=D0=93=D2=90=D0=94', x); pprint.pprint(x)
{'decoded': '[Bug 64155]\tNew:=?UTF-8?Q?=20non=2Dascii=20bug=20t=C3=A9st?=;\t'
            'russian text:=?UTF-8?Q?=20=D0=90=D0=91=D0=92=D0=93=D2=90=D0=94',
 'parse_tree': UnstructuredTokenList([ValueTerminal('[Bug'), WhiteSpaceTerminal(' '), ValueTerminal('64155]'), WhiteSpaceTerminal('\t'), ValueTerminal('New:=?UTF-8?Q?=20non=2Dascii=20bug=20t=C3=A9st?=;'), WhiteSpaceTerminal('\t'), ValueTerminal('russian'), WhiteSpaceTerminal(' '), ValueTerminal('text:=?UTF-8?Q?=20=D0=90=D0=91=D0=92=D0=93=D2=90=D0=94')])}

versus

>>> x = {}; email.headerregistry.UnstructuredHeader.parse('[Bug 64155]\tNew: =?UTF-8?Q?=20non=2Dascii=20bug=20t=C3=A9st?=;\trussian text: =?UTF-8?Q?=20=D0=90=D0=91=D0=92=D0=93=D2=90=D0=94', x); pprint.pprint(x)
{'decoded': '[Bug 64155]\tNew:  non-ascii bug t?st;\trussian text:  ??????',
 'parse_tree': UnstructuredTokenList([ValueTerminal('[Bug'), WhiteSpaceTerminal(' '), ValueTerminal('64155]'), WhiteSpaceTerminal('\t'), ValueTerminal('New:'), WhiteSpaceTerminal(' '), EncodedWord([WhiteSpaceTerminal(' '), ValueTerminal('non-ascii'), WhiteSpaceTerminal(' '), ValueTerminal('bug'), WhiteSpaceTerminal(' '), ValueTerminal('t?st')]), ValueTerminal(';'), WhiteSpaceTerminal('\t'), ValueTerminal('russian'), WhiteSpaceTerminal(' '), ValueTerminal('text:'), WhiteSpaceTerminal(' '), EncodedWord([WhiteSpaceTerminal(' '), ValueTerminal('??????')])])}

I have attached the raw e-mail as attachment.


Judging by the code, this is supposed to work (while raising a Defect --  "missing whitespace before encoded word"), but the code splits by whitespace:

tok, *remainder = _wsp_splitter(value, 1)

which swallows the encoded section in one go. In a second attachment, I added a patch which 1) adds a test case for this and 2) implements a solution, but the solution is unfortunately not in the style of the rest of the module.


In the meanwhile, I've chosen a monkey-patching approach to work around the issue:

import email._header_value_parser, email.headerregistry
def get_unstructured(value):
    value = value.replace("=?UTF-8?Q?=20", " =?UTF-8?Q?")
    return email._header_value_parser.get_unstructured(value)
email.headerregistry.UnstructuredHeader.value_parser = staticmethod(get_unstructured)

----------
components: email
files: 000359.raw
messages: 216908
nosy: barry, r.david.murray, valhallasw
priority: normal
severity: normal
status: open
title: email._header_value_parser does not recognise in-line encoding changes
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34984/000359.raw

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

From report at bugs.python.org  Sun Apr 20 20:36:52 2014
From: report at bugs.python.org (Aapo Rantalainen)
Date: Sun, 20 Apr 2014 18:36:52 +0000
Subject: [New-bugs-announce] [issue21316] mark test_devpoll to be
	meaningfull only for Solaris
Message-ID: <1398019012.76.0.381361357153.issue21316@psf.upfronthosting.co.za>


New submission from Aapo Rantalainen:

[ 96/389/2] test_devpoll
Actual happened:
 test_devpoll skipped -- select.devpoll not defined
Excepted:
 test works only on Solaris


Took me a while until I read documentation: 
 select.devpoll()
  ->     (Only supported on Solaris and derivatives.)

Even test itself, test_devpoll.py, doesn't mention it is only for Solaris.

----------
components: Tests
messages: 216913
nosy: AapoRantalainen
priority: normal
severity: normal
status: open
title: mark test_devpoll to be meaningfull only for Solaris
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr 21 02:18:07 2014
From: report at bugs.python.org (Dolda2000)
Date: Mon, 21 Apr 2014 00:18:07 +0000
Subject: [New-bugs-announce] [issue21317] Home page certificate troubles
Message-ID: <1398039487.2.0.185470776483.issue21317@psf.upfronthosting.co.za>


New submission from Dolda2000:

This is misfiled under "Documentation" since it affects the documentation peripherally and I couldn't find any better component to file it under.

To get to the point, the website seems to have certificate troubles for some URLs affecting the older versions of documentation. For instance, at this URL:

    <https://docs.python.org/3.0/c-api/arg.html>

For me at least, it says "400 Bad Request // The SSL certificate error [sic] // nginx". I am also not allowed to access it over HTTP, since that just redirects me to the HTTPS version.

(As an aside, you may also want to fix the typo in the error message while your at it. ;)

----------
assignee: docs at python
components: Documentation
messages: 216928
nosy: Dolda2000, docs at python
priority: normal
severity: normal
status: open
title: Home page certificate troubles
type: crash

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

From report at bugs.python.org  Mon Apr 21 02:31:06 2014
From: report at bugs.python.org (Jan Gosmann)
Date: Mon, 21 Apr 2014 00:31:06 +0000
Subject: [New-bugs-announce] [issue21318] sdist fails with symbolic links do
	non-existing files
Message-ID: <1398040266.25.0.437462468374.issue21318@psf.upfronthosting.co.za>


New submission from Jan Gosmann:

If there is a symbolic link to a non-existing file anywhere in the source tree "python setup.py sdist" fails with an output like the following:

    running sdist
    running check
    warning: check: missing required meta-data: url

    error: abc: No such file or directory

Pruning the problematic path with a MANIFEST.in file does not help.

I could locate the culprit in filelist.py <http://hg.python.org/cpython/file/c82dcad83438/Lib/distutils/filelist.py> in line 267:

            stat = os.stat(fullname)

fails for symlinks to non-existing files. Maybe os.lstat should be used? Or it should be checked before os.stat if it is a symlink to a nonexisting file?

In case you wonder why I have links to non-existing files in my source tree: Those can be left behind by automated tests I'm using and are not supposed to be part of the source (or any other) distribution. But as I said, the error is not prevented by excluding them with a MANIFEST.in file. My current workaround is to delete all the leftovers from the test as first thing in setup.py.

----------
components: Distutils
messages: 216930
nosy: dstufft, eric.araujo, jgosmann
priority: normal
severity: normal
status: open
title: sdist fails with symbolic links do non-existing files
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Apr 21 07:04:26 2014
From: report at bugs.python.org (Eric Snow)
Date: Mon, 21 Apr 2014 05:04:26 +0000
Subject: [New-bugs-announce] [issue21319] WindowsRegistryFinder never added
	to sys.meta_path
Message-ID: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za>


New submission from Eric Snow:

For #14578 we added WindowsRegistryFinder to importlib and try adding it to sys.meta_path during bootstrap (see bd58c421057c).

I happened to notice that in _install() in Lib/importlib/_bootstrap.py we check os.__name__.  Shouldn't it be os.name?  os.__name__ is always going to be "os"!

p.s. I'm guessing that finder doesn't get used a whole lot. ;)

----------
components: Interpreter Core
messages: 216936
nosy: brett.cannon, eric.snow, loewis
priority: normal
severity: normal
stage: test needed
status: open
title: WindowsRegistryFinder never added to sys.meta_path
type: behavior

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

From report at bugs.python.org  Mon Apr 21 13:54:59 2014
From: report at bugs.python.org (Cyphase)
Date: Mon, 21 Apr 2014 11:54:59 +0000
Subject: [New-bugs-announce] [issue21320] dict() allows keyword expansion
	with integer keys, e.g. dict(**{5:'v'})
Message-ID: <1398081299.38.0.288058317096.issue21320@psf.upfronthosting.co.za>


New submission from Cyphase:

Python 2.7.6: Affected
Python 3.2.3: Not affected

dict() allows keyword expansion using a dict() with integer keys, whereas attempting to do so with most other functions raises a TypeError with the message, "keywords must be strings". The same thing happens with collections.defaultdict(), but not collections.Counter() or collections.OrderedDict, presumably because they override dict.__init__().

>>> old_dict = {'a': 1, 2: 'b'}
>>> old_dict
{'a': 1, 2: 'b'}
>>> other_dict = {'c': 3, 4: 'd'}
>>> other_dict
>>> new_dict = dict(old_dict, **other_dict)
>>> new_dict
{'a': 1, 2: 'b', 4: 'd', 'c': 3}

I feel like this must be known, but I didn't find anything with a search.

----------
components: Interpreter Core
messages: 216938
nosy: Cyphase
priority: normal
severity: normal
status: open
title: dict() allows keyword expansion with integer keys, e.g. dict(**{5:'v'})
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 21 14:13:50 2014
From: report at bugs.python.org (Anton Afanasyev)
Date: Mon, 21 Apr 2014 12:13:50 +0000
Subject: [New-bugs-announce] [issue21321] itertools.islice() doesn't release
	reference to the	source iterator when the slice is exhausted
Message-ID: <1398082430.51.0.59207810702.issue21321@psf.upfronthosting.co.za>


New submission from Anton Afanasyev:

This issue results in redundant memory consumption for e.g. in this case:

================================================
from itertools import *

def test_islice():

    items, lookahead = tee(repeat(1, int(1e9)))
    lookahead = islice(lookahead, 10)

    for item in lookahead:
        pass

    for item in items:
        pass

if __name__ == "__main__":
    test_islice()
================================================
This demo is taken from real case where one needs to look ahead input stream before processing it. For my PC this demo stops with 'Segmentation fault' message after exhausting all PC memory, while running it with patched python consumes only 0.1% of memory till the end.

When one uses pure pythonic implementation of itertools.islice() (taken from docs), the issue goes away as well, since this implementation doesn't store redundant reference to source iterator.

================================================
def islice(iterable, *args):
    s = slice(*args)
    it = iter(xrange(s.start or 0, s.stop or sys.maxint, s.step or 1))
    nexti = next(it)
    for i, element in enumerate(iterable):
        if i == nexti:
            yield element
            nexti = next(it)
================================================

Attaching patch for this issue. Have to change '__reduce__()' method since now unpickling of exhausted 'islice()' object cannot return old source iterator.

----------
components: Extension Modules
files: patch_3.4_8c8315bac6a8.diff
keywords: patch
messages: 216939
nosy: Anton.Afanasyev, rhettinger
priority: normal
severity: normal
status: open
title: itertools.islice() doesn't release reference to the source iterator when the slice is exhausted
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34990/patch_3.4_8c8315bac6a8.diff

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

From report at bugs.python.org  Mon Apr 21 18:42:49 2014
From: report at bugs.python.org (=?utf-8?q?I=C3=B1igo_Serna?=)
Date: Mon, 21 Apr 2014 16:42:49 +0000
Subject: [New-bugs-announce] [issue21322] Pathlib .owner() and .group()
	methods fail on broken	links
Message-ID: <1398098569.86.0.723629898468.issue21322@psf.upfronthosting.co.za>


New submission from I?igo Serna:

Pathlib .owner() and .group() methods fail on broken symlinks.

They use:
    return pwd.getpwuid(self.stat().st_uid).pw_name
and:
    return grp.getgrgid(self.stat().st_gid).gr_name

It should be self.lstat().

Attached simple fix as unified diff.

----------
components: Library (Lib)
files: pathlib-34-owner_group_fixed.diff
keywords: patch
messages: 216950
nosy: inigoserna
priority: normal
severity: normal
status: open
title: Pathlib .owner() and .group() methods fail on broken links
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file34992/pathlib-34-owner_group_fixed.diff

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

From report at bugs.python.org  Mon Apr 21 21:05:31 2014
From: report at bugs.python.org (Konstantin S. Solnushkin)
Date: Mon, 21 Apr 2014 19:05:31 +0000
Subject: [New-bugs-announce] [issue21323] CGI HTTP server not running
	scripts from subdirectories
Message-ID: <1398107131.28.0.812868414728.issue21323@psf.upfronthosting.co.za>


New submission from Konstantin S. Solnushkin:

Somewhere between Python 3.3 and 3.4, a bug was introduced that forbids the "http.server" module, working in CGI server mode, to run scripts residing in subdirectories.

This will break existing software that relies on this feature.

How to reproduce the bug:

1. Create a temporary directory and enter it.
2. Create a directory "cgi-bin", and then directory "test" inside "cgi-bin".
3. Create a file "test.py" in "cgi-bin/test" with the following contents (see also attachment to this bug report):

print("""Content-type: text/plain

CGI script executed successfully!
""")

4. When run, it should print the following:

Content-type: text/plain

CGI script executed successfully!

5. Now, run Python 3.3 in CGI HTTP server mode:

c:\Python33\python.exe -m http.server --cgi 8000

A request to "http://localhost:8000/cgi-bin/test/test.py" then produces the following in the HTTP server log:

Serving HTTP on 0.0.0.0 port 8000 ...
127.0.0.1 - - [21/Apr/2014 22:59:11] "GET /cgi-bin/test/test.py HTTP/1.0" 200 -
127.0.0.1 - - [21/Apr/2014 22:59:11] command: c:\Python33\python.exe -u C:\TMP\cgi-bin\test\test.py ""
127.0.0.1 - - [21/Apr/2014 22:59:11] CGI script exited OK

6. Now, try this with Python 3.4, and the request will fail with the following in the log:

C:\TMP>c:\Python34\python.exe -m http.server --cgi 8000
Serving HTTP on 0.0.0.0 port 8000 ...
127.0.0.1 - - [21/Apr/2014 23:02:38] code 403, message CGI script is not a plain file ('/cgi-bin/test')
127.0.0.1 - - [21/Apr/2014 23:02:38] "GET /cgi-bin/test/test.py HTTP/1.0" 403 -

This _could_ be related to the change introduced by issue 19435, although I am not sure.

Tested with Windows XP SP3.

----------
files: test.py
messages: 216960
nosy: k.s.solnushkin
priority: normal
severity: normal
status: open
title: CGI HTTP server not running scripts from subdirectories
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file34993/test.py

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

From report at bugs.python.org  Mon Apr 21 21:54:44 2014
From: report at bugs.python.org (Marcin Szewczyk)
Date: Mon, 21 Apr 2014 19:54:44 +0000
Subject: [New-bugs-announce] [issue21324] dbhash leaks random memory
	fragments to a database
Message-ID: <1398110084.7.0.0365348726476.issue21324@psf.upfronthosting.co.za>


New submission from Marcin Szewczyk:

As stated in the subject. Example is in a remote Git repository:
https://bitbucket.org/wodny/python-dbm-experiments/
It shows how some random data gets into the database (into some gaps between keys and values). There is also a C example which hasn't been caught on leaking.

----------
components: Library (Lib)
messages: 216966
nosy: wodny
priority: normal
severity: normal
status: open
title: dbhash leaks random memory fragments to a database
type: security
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 22 04:04:33 2014
From: report at bugs.python.org (karl)
Date: Tue, 22 Apr 2014 02:04:33 +0000
Subject: [New-bugs-announce] [issue21325] Missing Generic EXIF library for
	images in the standard	library
Message-ID: <1398132273.77.0.903866563155.issue21325@psf.upfronthosting.co.za>


New submission from karl:

There is a room for a consistent and good EXIF library for the Python Standard Library.

----------
components: Library (Lib)
messages: 216978
nosy: karlcow
priority: normal
severity: normal
status: open
title: Missing Generic EXIF library for images in the standard library
type: enhancement

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

From report at bugs.python.org  Tue Apr 22 10:12:43 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Apr 2014 08:12:43 +0000
Subject: [New-bugs-announce] [issue21326] asyncio: request clearer error
	message when event loop	closed
Message-ID: <1398154363.0.0.853788262895.issue21326@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

In the new asyncio library, it's easy for newbies (like me) to accidentally try to run a coroutine on a closed event loop.  Doing so leads to a rather inscrutable exception and traceback:

>>> loop.run_until_complete(compute())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 203, in run_until_complete
    self.run_forever()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 184, in run_forever
    self._run_once()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 778, in _run_once
    event_list = self._selector.select(timeout)
AttributeError: 'NoneType' object has no attribute 'select'

Is it possible to replace this with something clearer?  For example, something like: RuntimeError("Can't schedule coroutine on closed event loop.")


Here's the full code snippet:


Python 3.4.0 (default, Mar 25 2014, 11:07:05) 
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> @asyncio.coroutine
... def compute():
...     print("Starting computation")
...     yield from asyncio.sleep(2.0)
...     print("Complete")
... 
>>> loop = asyncio.get_event_loop()
>>> loop.run_until_complete(compute())
Starting computation
Complete
>>> loop.close()  # whoops
>>> # some time later
... 
>>> loop = asyncio.get_event_loop()
>>> loop.run_until_complete(compute())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 203, in run_until_complete
    self.run_forever()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 184, in run_forever
    self._run_once()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 778, in _run_once
    event_list = self._selector.select(timeout)
AttributeError: 'NoneType' object has no attribute 'select'

----------
components: Library (Lib)
messages: 216994
nosy: gvanrossum, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: asyncio: request clearer error message when event loop closed
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Apr 22 13:55:07 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Apr 2014 11:55:07 +0000
Subject: [New-bugs-announce] [issue21327] socket.type value changes after
	using settimeout()
Message-ID: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

>>> s = socket.socket()
>>> s.type
<SocketType.SOCK_STREAM: 1>
>>> s.settimeout(2)
>>> s.type
2049
>>> 

I can reproduce this with Python 3.5, 3.4 and 3.3.
2.7 is not affected.

----------
messages: 216999
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: socket.type value changes after using settimeout()
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 22 16:02:29 2014
From: report at bugs.python.org (Dustin Oprea)
Date: Tue, 22 Apr 2014 14:02:29 +0000
Subject: [New-bugs-announce] [issue21328] Resize doesn't change reported
	length on	create_string_buffer()
Message-ID: <1398175349.63.0.548870170471.issue21328@psf.upfronthosting.co.za>


New submission from Dustin Oprea:

The memory is resized, but the value returned by len() doesn't change:

>>> b = ctypes.create_string_buffer(23)
>>> len(b)
23
>>> b.raw = '0' * 23
>>> b.raw = '0' * 24
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: string too long

>>> ctypes.resize(b, 28)
>>> len(b)
23
>>> b.raw = '0' * 28
>>> b.raw = '0' * 29
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: string too long

----------
components: ctypes
messages: 217005
nosy: Dustin.Oprea
priority: normal
severity: normal
status: open
title: Resize doesn't change reported length on create_string_buffer()
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 22 17:27:33 2014
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Tue, 22 Apr 2014 15:27:33 +0000
Subject: [New-bugs-announce] [issue21329] configparser can't parse MySQL
	style config
Message-ID: <1398180453.28.0.0252275500481.issue21329@psf.upfronthosting.co.za>


New submission from Dani?l van Eeden:

With Python 2.7 the ConfigParser was enriched with the allow_no_value option which resulted in a much more usable configparser for MySQL configs.

It can now parse configs like this:
[mysqld]
log_bin
innodb_file_per_table
innodb_io_capacity=800

However it can't parse this config:
[mysqld]
log_bin
innodb_file_per_table
innodb_io_capacity=800
replicate-do-db="test1"
replicate-do-db="test2"

A comma separated config might have been better, but that's not the case with many MySQL config (and probably doesn't even work for this option).

>From http://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#option_mysqld_replicate-do-db
"To specify more than one database, use this option multiple times, once for each database"


The dict/orderedDict which is used by configparser doesn't easlily allow to store a config like this.

The MySQL config file is used as an example in the documentation:
https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour

This could be solved by having a list of values if the key exists more than once.

Python 3 improves this a bit by giving a DuplicateOptionError by default.

----------
components: Library (Lib)
files: demo.py
messages: 217012
nosy: dveeden
priority: normal
severity: normal
status: open
title: configparser can't parse MySQL style config
versions: Python 3.4
Added file: http://bugs.python.org/file35001/demo.py

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

From report at bugs.python.org  Tue Apr 22 21:18:51 2014
From: report at bugs.python.org (Jayanth Raman)
Date: Tue, 22 Apr 2014 19:18:51 +0000
Subject: [New-bugs-announce] [issue21330] Typo in "Unicode HOWTO"
	documentation
Message-ID: <1398194331.3.0.966698777318.issue21330@psf.upfronthosting.co.za>


New submission from Jayanth Raman:

It should be "128 such characters" in the following sentence:

For example, you can?t fit both the accented characters used in Western Europe and the Cyrillic alphabet used for Russian into the 128-255 range because there are more than 127 such characters.

----------
assignee: docs at python
components: Documentation
messages: 217016
nosy: docs at python, jayanth
priority: normal
severity: normal
status: open
title: Typo in "Unicode HOWTO" documentation
type: behavior
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/issue21330>
_______________________________________

From report at bugs.python.org  Tue Apr 22 22:58:23 2014
From: report at bugs.python.org (Sworddragon)
Date: Tue, 22 Apr 2014 20:58:23 +0000
Subject: [New-bugs-announce] [issue21331] Reversing an encoding with
	unicode-escape returns a	different result
Message-ID: <1398200303.74.0.876201125787.issue21331@psf.upfronthosting.co.za>


New submission from Sworddragon:

I have made some tests with encoding/decoding in conjunction with unicode-escape and got some strange results:

>>> print('?')
?
>>> print('?'.encode('utf-8'))
b'\xc3\xa4'
>>> print('?'.encode('utf-8').decode('unicode-escape'))
??
>>> print('?'.encode('utf-8').decode('unicode-escape').encode('unicode-escape'))
b'\\xc3\\xa4'
>>> print('?'.encode('utf-8').decode('unicode-escape').encode('unicode-escape').decode('utf-8'))
\xc3\xa4


Shouldn't .decode('unicode-escape').encode('unicode-escape') nullify itself and so "'?'.encode('utf-8').decode('unicode-escape').encode('unicode-escape')" return the same result as '?'.encode('utf-8')?

----------
components: Unicode
messages: 217021
nosy: Sworddragon, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Reversing an encoding with unicode-escape returns a different result
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 23 01:35:45 2014
From: report at bugs.python.org (raylu)
Date: Tue, 22 Apr 2014 23:35:45 +0000
Subject: [New-bugs-announce] [issue21332] subprocess bufsize=1 docs are
	misleading
Message-ID: <1398209745.28.0.851161689347.issue21332@psf.upfronthosting.co.za>


New submission from raylu:

https://docs.python.org/3.3/library/subprocess.html says

"bufsize will be supplied as the corresponding argument to the open() function when creating the stdin/stdout/stderr pipe file objects: ... 1 means line buffered"

but it calls io.open with 'wb' and 'rb': http://hg.python.org/cpython/file/c9cb931b20f4/Lib/subprocess.py#l828

This puts the file in binary mode, and https://docs.python.org/3.3/library/functions.html#open says

"1 to select line buffering (only usable in text mode)"

Even with universal_newlines=True, the TextIOWrapper isn't passed line_buffering=True. There's actually no way to get line buffering any more.

----------
components: Library (Lib)
messages: 217044
nosy: raylu
priority: normal
severity: normal
status: open
title: subprocess bufsize=1 docs are misleading
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 23 07:57:14 2014
From: report at bugs.python.org (Stefan Schwarzer)
Date: Wed, 23 Apr 2014 05:57:14 +0000
Subject: [New-bugs-announce] [issue21333] Document recommended exception for
	objects that	shouldn't be pickled
Message-ID: <1398232634.34.0.847410110548.issue21333@psf.upfronthosting.co.za>


New submission from Stefan Schwarzer:

I recently was confused whether to raise a `PicklingError` or `TypeError` in `__getstate__` if objects of my class can't and shouldn't be pickled. [1]

Terry Reedy advised I should use `TypeError`. [2]

I wonder if the `pickle` module documention should explicitly recommend using `TypeError` if a class wants to say that its objects can't be pickled. What do you think?

[1] https://mail.python.org/pipermail/python-list/2014-April/670987.html
[2] https://mail.python.org/pipermail/python-list/2014-April/671002.html

----------
assignee: docs at python
components: Documentation
messages: 217054
nosy: docs at python, sschwarzer
priority: normal
severity: normal
status: open
title: Document recommended exception for objects that shouldn't be pickled
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 23 11:42:41 2014
From: report at bugs.python.org (randomcoder1)
Date: Wed, 23 Apr 2014 09:42:41 +0000
Subject: [New-bugs-announce] [issue21334] nntplib throws exceptions making
	sinntp unusable
Message-ID: <1398246161.17.0.601121532503.issue21334@psf.upfronthosting.co.za>


New submission from randomcoder1:

Sinntp is a nntp client. It uses nntplib from Python as a nntp library to fetch messages from NNTP servers.

I've tested this on two environments with the following package versions:

1) Ubuntu 12.04.4 , python-support 1.0.14ubuntu2, Python 2.7.3-0ubuntu2.2 , sinntp 1.4-1 , libpython2.7 2.7.3-0ubuntu3.4
2) Debian jessie , python-support 1.0.15, Python 2.7.5-5, sinntp 1.5-1 , libpython2.7 version 2.7.6-8

sinntp crashed on 2) and threw NNTP* exceptions which are described in more detail in the bugreport-data.tgz file that comes with this  bugreport. I was also able to isolate one NNTP article that caused it to crash, that's also included.

I've included above the libpython2.7 version because
user at machine:/tmp$ sudo apt-file -x search 'nntplib.py$'
[..]
libpython2.7-stdlib: /usr/lib/python2.7/nntplib.py
[..]

Upon trying to replace the sinntp 1.5-1 on 2) with the one in 1) , the problem was still present, so I believe sinntp can be excluded.

I think the bug is caused by the newer version of libpython2.7 in 2).

----------
components: Library (Lib)
files: bureport-data.tgz
messages: 217060
nosy: randomcoder1
priority: normal
severity: normal
status: open
title: nntplib throws exceptions making sinntp unusable
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file35008/bureport-data.tgz

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

From report at bugs.python.org  Wed Apr 23 17:01:51 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 23 Apr 2014 15:01:51 +0000
Subject: [New-bugs-announce] [issue21335] Update importlib.__init__ to reset
	_frozen_imnportlib's	loader to SourceFileLoader
Message-ID: <1398265311.8.0.131352279084.issue21335@psf.upfronthosting.co.za>


New submission from Brett Cannon:

When importlib.__init__ tries to mask the fact that _frozen_importlib is frozen it should also reset __loader__ to be an instance of SourceFileLoader. This will allow tracebacks to include source lines thanks to SourceFileLoader.get_source().

----------
assignee: brett.cannon
components: Library (Lib)
messages: 217073
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Update importlib.__init__ to reset _frozen_imnportlib's loader to SourceFileLoader
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 23 18:57:20 2014
From: report at bugs.python.org (Ben Ma)
Date: Wed, 23 Apr 2014 16:57:20 +0000
Subject: [New-bugs-announce] [issue21336] ntpath.splitdrive fails on None
	argument
Message-ID: <1398272240.06.0.678669968331.issue21336@psf.upfronthosting.co.za>


New submission from Ben Ma:

>>> import ntpath
>>> ntpath.splitdrive(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "E:\python3\lib\ntpath.py", line 159, in splitdrive
    if p and len(p) > 1:
TypeError: object of type 'NoneType' has no len()

Solution: (that I've found)

Lib/ntpath.py
#in function splitdrive
...
    empty = _get_empty(p)
+++ if p and len(p) > 1:
--- if len(p) > 1:
        sep = _get_sep(p)
...
            return p[:2], p[2:]
+++ else:
+++     p = ''
    return empty, p
...

----------
components: Library (Lib)
messages: 217077
nosy: runapp
priority: normal
severity: normal
status: open
title: ntpath.splitdrive fails on None argument
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 23 22:46:48 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 23 Apr 2014 20:46:48 +0000
Subject: [New-bugs-announce] [issue21337] Add tests for Tix
Message-ID: <1398286008.45.0.411979424173.issue21337@psf.upfronthosting.co.za>


New submission from Zachary Ware:

We should have some tests for Tix, which currently has none.  The Windows buildbots will be able to run the tests, but Tix is not guaranteed to be available elsewhere.

----------
components: Tests, Tkinter
keywords: easy
messages: 217089
nosy: zach.ware
priority: low
severity: normal
stage: needs patch
status: open
title: Add tests for Tix
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Apr 24 01:29:32 2014
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 23 Apr 2014 23:29:32 +0000
Subject: [New-bugs-announce] [issue21338] Silent mode for compileall
Message-ID: <1398295772.24.0.550494832702.issue21338@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

The compileall module's command line interface has a -q (quiet) flag which suppresses most of the output, but it still prints error messages. I'd like an entirely silent mode with no output.

My use case is byte-compiling Python files as part of a graphical installer. I do this by running:

py -${PY_QUALIFIER} -m compileall -q "$INSTDIR\pkgs"

I'd like to be able to use pyw so a terminal doesn't pop up, but if I do that, it exits early. I think this is due to the issue with stdout/stderr buffers filling up on pythonw.

----------
components: Library (Lib)
messages: 217100
nosy: takluyver
priority: normal
severity: normal
status: open
title: Silent mode for compileall

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

From report at bugs.python.org  Thu Apr 24 02:45:14 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Apr 2014 00:45:14 +0000
Subject: [New-bugs-announce] [issue21339] IDLE crash on OS X 1.9 upon
	shut-down with many windows	open
Message-ID: <1398300314.38.0.176461050226.issue21339@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

*** Internal Error: rpc.py:SocketIO.localcall()

 Object: gui_adapter 
 Method: <bound method GUIAdapter.interaction of <idlelib.RemoteDebugger.GUIAdapter instance at 0x120e71f80>> 
 Args: ('bug.py:1: <module>()', 4350545536, None)

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/rpc.py", line 188, in localcall
    ret = method(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/RemoteDebugger.py", line 284, in interaction
    self.gui.interaction(message, frame, modified_info)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/Debugger.py", line 198, in interaction
    b.configure(state="disabled")
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1262, in configure
    return self._configure('configure', cnf, kw)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1253, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
TclError: invalid command name ".4846984656.4846982712.4846983792"

----------
components: IDLE
messages: 217105
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE crash on OS X 1.9 upon shut-down with many windows open
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 24 04:13:42 2014
From: report at bugs.python.org (Jack Murray)
Date: Thu, 24 Apr 2014 02:13:42 +0000
Subject: [New-bugs-announce] [issue21340] Possible bug in asyncio
Message-ID: <1398305622.34.0.507325141901.issue21340@psf.upfronthosting.co.za>


New submission from Jack Murray:

AttributeError in /usr/lib/python3.4/asyncio/tasks.py feels like it might be a concurrency issue. I can't reproduce it, and my python isn't good enough to know how to simulate raising the exception at a random time during the execution of the program. Here's the PoC:

import asyncio
import sys
from asyncio import async
import time
import random
asyncio.tasks._DEBUG = True


loop = asyncio.get_event_loop()

def read_something():
  print(input())

@asyncio.coroutine
def func(arg):
  while True:
    sys.stdout.write("\rtest"+str(arg))
    yield from asyncio.sleep(0)

loop.add_reader(sys.stdin, read_something)
loop.call_soon(async, func(1))
loop.call_soon(async, func(2))
loop.call_soon(async, func(3))
loop.call_soon(async, func(4))

time.sleep(1)

try:
  loop.run_forever()
except KeyboardInterrupt:
  print("handled\n")
  pass
finally:
  pass

and here is the stack trace:

ktn:~/ $ python asynctest.py                                                                                       [11:55:03]
test3^Chandled

Future/Task exception was never retrieved
future: Task(<func>)<exception=KeyboardInterrupt()>
Traceback (most recent call last):
  File "asynctest.py", line 29, in <module>
    loop.run_forever()
  File "/usr/lib/python3.4/asyncio/base_events.py", line 184, in run_forever
    self._run_once()
  File "/usr/lib/python3.4/asyncio/base_events.py", line 800, in _run_once
    handle._run()
  File "/usr/lib/python3.4/asyncio/events.py", line 39, in _run
    self._callback(*self._args)
  File "/usr/lib/python3.4/asyncio/tasks.py", line 337, in _wakeup
    self._step(value, None)
  File "/usr/lib/python3.4/asyncio/tasks.py", line 283, in _step
    result = next(coro)
  File "/usr/lib/python3.4/asyncio/tasks.py", line 50, in __next__
    return next(self.gen)
  File "asynctest.py", line 18, in func
    yield from asyncio.sleep(0)
  File "/usr/lib/python3.4/asyncio/tasks.py", line 94, in wrapper
    w = CoroWrapper(coro(*args, **kwds), func)
  File "/usr/lib/python3.4/asyncio/tasks.py", line 42, in __init__
    assert inspect.isgenerator(gen), gen
KeyboardInterrupt
Exception ignored in: <bound method CoroWrapper.__del__ of <asyncio.tasks.CoroWrapper object at 0x7f0dedaf79d8>>
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/tasks.py", line 62, in __del__
    frame = self.gen.gi_frame
AttributeError: gen

----------
messages: 217112
nosy: Jack.Murray
priority: normal
severity: normal
status: open
title: Possible bug in asyncio
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr 24 06:12:12 2014
From: report at bugs.python.org (Barron)
Date: Thu, 24 Apr 2014 04:12:12 +0000
Subject: [New-bugs-announce] [issue21341] Configuring 'font' with ttk.Style
	for 'TEntry' does not	change displayed font
Message-ID: <1398312732.28.0.174880904692.issue21341@psf.upfronthosting.co.za>


New submission from Barron:

After using the configure() method of a ttk.Style object to configure the font of TEntry, Entry widgets will still have the original default font.

The following 6 lines will demonstrate this in IDLE:

>>> from tkinter import ttk
>>> s = ttk.Style()
>>> s.configure('TButton', font = ('Courier', 24))
>>> s.configure('TEntry', font = ('Courier', 24))
>>> ttk.Button(text = 'Button').pack()
>>> ttk.Entry().pack()

The Button will be displayed using the newly configured font, but the Entry widget will retain the default font.

Calling the lookup() method after the above code reveals the following:

>>> s.lookup('TEntry', 'font')
'Courier 24'

This shows that the font property for TEntry is getting set properly, but it is not being displayed.

Configuring the font property directly on individual Entry widgets does display correctly.

----------
components: Tkinter
messages: 217114
nosy: barron
priority: normal
severity: normal
status: open
title: Configuring 'font' with ttk.Style for 'TEntry' does not change displayed font
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 24 08:00:51 2014
From: report at bugs.python.org (Steinn Steinsen)
Date: Thu, 24 Apr 2014 06:00:51 +0000
Subject: [New-bugs-announce] [issue21342] multiprocessing RLock and Lock
	raise incorrect	exceptions when releasing an unlocked lock.
Message-ID: <1398319251.34.0.871128764935.issue21342@psf.upfronthosting.co.za>


New submission from Steinn Steinsen:

In the documentation of multiprocessing the locks, RLock and Lock, 
are said to be clones of their respective threading synchronization primitives.

There is an inconsistency in what exceptions are raised when an
unlocked lock is released. According to the threading documentation a 
RuntimeError should be raised.

Lock.release raises ValueError 
RLock.release raises AssertionError

Tested this in python 2.7, 3.2, 3.4, 3.5 and broken in all those versions.

The attached patch fixes this for 3.5

----------
components: Library (Lib)
files: release_exceptions.patch
keywords: patch
messages: 217117
nosy: steinn
priority: normal
severity: normal
status: open
title: multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock.
type: behavior
versions: Python 2.7, Python 3.2, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35017/release_exceptions.patch

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

From report at bugs.python.org  Thu Apr 24 08:40:22 2014
From: report at bugs.python.org (Matt Bachmann)
Date: Thu, 24 Apr 2014 06:40:22 +0000
Subject: [New-bugs-announce] [issue21343] os.path.relpath returns
	inconsistent types
Message-ID: <1398321622.3.0.761606734891.issue21343@psf.upfronthosting.co.za>


New submission from Matt Bachmann:

I noticed an issue passing in unicode to os.path.relpath.

Specifically that in some cases when passing in unicode I would get back unicode and others I would get back a string. Below I demonstrate the issue. I also attached a patch.

Is this an issue or am I misunderstanding something. Is the patch reasonable? Totally willing to improve and i'll admit I cannot test the ntpath version.

Python 2.7.6 (default, Apr  9 2014, 11:48:52)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.relpath(u'.', u'.')
'.'
>>> os.path.relpath(u'.', u'../')
u'bachmann'

----------
components: Library (Lib)
files: reldir.patch
keywords: patch
messages: 217119
nosy: Matt.Bachmann
priority: normal
severity: normal
status: open
title: os.path.relpath returns inconsistent types
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35019/reldir.patch

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

From report at bugs.python.org  Thu Apr 24 16:42:10 2014
From: report at bugs.python.org (Russell Ballestrini)
Date: Thu, 24 Apr 2014 14:42:10 +0000
Subject: [New-bugs-announce] [issue21344] save scores or ratios in difflib
	get_close_matches
Message-ID: <1398350530.77.0.0668395281532.issue21344@psf.upfronthosting.co.za>


New submission from Russell Ballestrini:

The current implementation of difflib's get_close_matches() function computes computationally complex scores (ratios) but then tosses them out without giving the end-user the chance to have at them.

This patch adds an optional "scores" boolean argument that may be passed to alter the return output from a list of words, to a list of (score, word) tuples.

----------
components: Library (Lib)
files: difflib.py
messages: 217123
nosy: russellballestrini
priority: normal
severity: normal
status: open
title: save scores or ratios in difflib get_close_matches
type: enhancement
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file35022/difflib.py

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

From report at bugs.python.org  Thu Apr 24 18:02:44 2014
From: report at bugs.python.org (Johannes Baiter)
Date: Thu, 24 Apr 2014 16:02:44 +0000
Subject: [New-bugs-announce] [issue21345]
	multiprocessing.Pool._handle_workers sleeps too long
Message-ID: <1398355364.53.0.447682013962.issue21345@psf.upfronthosting.co.za>


New submission from Johannes Baiter:

While testing a module that uses multiprocessing.Pool to distribute load across multiple processes, I noticed that my test suite was copmleting very quickly (~0.15s) on Python 2.6, while Python 2.7 and above took around 10x as long (~1.6s).
Upon debugging this, I pinned the slowdown down to the 'Pool.join()' method. Removing it removed the slowdown almost completely.
I then checked the version history of the 'multiprocessing.pool' module between 2.6 and 2.7 and noticed that when the 'maxtasksperchild' parameter was introduced, a thread to handle the workers was introduced, which was 'join()'ed when the pool was joined.

This is the function that is executed in the thread (from latest CPython checkout):

    @staticmethod
    def _handle_workers(pool):
        thread = threading.current_thread()

        # Keep maintaining workers until the cache gets drained, unless the pool
        # is terminated.
        while thread._state == RUN or (pool._cache and thread._state != TERMINATE):
            pool._maintain_pool()
            time.sleep(0.1)  #  <-- Cause of slow 'join()' after 2.6
        # send sentinel to stop workers
        pool._taskqueue.put(None)
        util.debug('worker handler exiting')

I highlighted the portion that makes 'join()' take a rather long time with short-lived processes in Python 2.7 and greater.
Replacing it with 'time.sleep(0)' (as is done in '_help_stuff_finish()' later in the module) makes joining go as fast as in 2.6.

Is there a specific reason why this sleep period was chosen?

----------
components: Library (Lib)
messages: 217129
nosy: Johannes.Baiter
priority: normal
severity: normal
status: open
title: multiprocessing.Pool._handle_workers sleeps too long
type: performance
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr 24 19:31:25 2014
From: report at bugs.python.org (Brian Kearns)
Date: Thu, 24 Apr 2014 17:31:25 +0000
Subject: [New-bugs-announce] [issue21346] typos in test_itertools.py
Message-ID: <1398360685.46.0.636868722693.issue21346@psf.upfronthosting.co.za>


Changes by Brian Kearns <bdkearns at gmail.com>:


----------
files: test_itertools_typos-py27.patch
keywords: patch
nosy: bdkearns
priority: normal
severity: normal
status: open
title: typos in test_itertools.py
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file35025/test_itertools_typos-py27.patch

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

From report at bugs.python.org  Thu Apr 24 21:08:42 2014
From: report at bugs.python.org (akira)
Date: Thu, 24 Apr 2014 19:08:42 +0000
Subject: [New-bugs-announce] [issue21347] Don't use a list argument together
	with shell=True in	subprocess' docs
Message-ID: <1398366522.65.0.954174735085.issue21347@psf.upfronthosting.co.za>


New submission from akira:

*Popen(["something"], shell=True)* works but it is similar to
*Popen(["something", "arg"], shell=True)* that passes "arg" to /bin/sh on POSIX systems instead of "something".

It is best to always use a string if `shell=True` is necessary.

It is a common confusion #20344, msg98732, #7839

http://stackoverflow.com/questions/21029154/understanding-python-subprocess-check-outputs-first-argument-and-shell-true
http://stackoverflow.com/questions/20787712/start-openoffice-process-with-python-to-use-with-pyuno-using-subprocess
http://stackoverflow.com/questions/17880847/python-subprocess-error-in-using-cp
http://stackoverflow.com/questions/17226912/why-does-simple-echo-in-subprocess-not-working
http://stackoverflow.com/questions/15109665/subprocess-call-using-string-vs-using-list
http://stackoverflow.com/questions/20128114/pythons-subprocess-does-not-interpret-as-expected-on-cygwin
http://stackoverflow.com/questions/16840427/python-on-linux-subprocess-popen-works-weird-with-shell-true
...

----------
assignee: docs at python
components: Documentation
files: docs-subprocess-dont_use_list_with_shell_true.patch
keywords: patch
messages: 217136
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: Don't use a list argument together with shell=True in subprocess' docs
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35026/docs-subprocess-dont_use_list_with_shell_true.patch

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

From report at bugs.python.org  Fri Apr 25 01:42:29 2014
From: report at bugs.python.org (Cris)
Date: Thu, 24 Apr 2014 23:42:29 +0000
Subject: [New-bugs-announce] [issue21348] File
	"C:\Python27\lib\distutils\msvc9compiler.py", line 295,
	in query_vcvarsal l raise
	ValueError(str(list(result.keys())))	ValueError: [u'path']
Message-ID: <1398382949.19.0.0972223942804.issue21348@psf.upfronthosting.co.za>


New submission from Cris:

I have Windows 8 64bit and Python 64bit (installed from here: https://www.python.org/ftp/python/2.7/python-2.7.amd64.msi)

I also installed pywin32-214.win-amd64-py2.7 (from here http://downloads.sourceforge.net/project/pywin32/pywin32/Build%20214/pywin32-214.win-amd64-py2.7.exe?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fpywin32%2Ffiles%2Fpywin32%2FBuild%2520214%2F&ts=1398376919&use_mirror=kent)

When I try to install Scrapy it gives me this error:

  File "twisted\runner\topfiles\setup.py", line 14, in <lambda>
  File ".\twisted\python\dist.py", line 413, in _check_header
  File ".\twisted\python\dist.py", line 399, in _compile_helper
  File "C:\Python27\lib\distutils\msvc9compiler.py", line 469, in compile
    self.initialize()
  File "C:\Python27\lib\distutils\msvc9compiler.py", line 379, in initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
  File "C:\Python27\lib\distutils\msvc9compiler.py", line 295, in query_vcvarsal
l
    raise ValueError(str(list(result.keys())))
ValueError: [u'path']

How can I fix it?

----------
messages: 217140
nosy: Cris
priority: normal
severity: normal
status: open
title: File "C:\Python27\lib\distutils\msvc9compiler.py", line 295, in query_vcvarsal l     raise ValueError(str(list(result.keys()))) ValueError: [u'path']
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 25 02:15:16 2014
From: report at bugs.python.org (Brian Kearns)
Date: Fri, 25 Apr 2014 00:15:16 +0000
Subject: [New-bugs-announce] [issue21349] crash in winreg SetValueEx with
	memoryview
Message-ID: <1398384916.2.0.500531469924.issue21349@psf.upfronthosting.co.za>


Changes by Brian Kearns <bdkearns at gmail.com>:


----------
files: fix_winreg_setvalueex-py27.patch
keywords: patch
nosy: bdkearns
priority: normal
severity: normal
status: open
title: crash in winreg SetValueEx with memoryview
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file35030/fix_winreg_setvalueex-py27.patch

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

From report at bugs.python.org  Fri Apr 25 18:40:21 2014
From: report at bugs.python.org (Brian Kearns)
Date: Fri, 25 Apr 2014 16:40:21 +0000
Subject: [New-bugs-announce] [issue21350] bug in file.writelines accepting
	buffers
Message-ID: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za>


New submission from Brian Kearns:

In file.writelines, the conditions in this if statement are bogus. If f->f_binary and AsReadBuffer succeeds (returns 0), AsCharBuf is still tried. So, for example, passing an array('c') to a file('wb').writelines fails, when it seems the intention of the code/comments was to have it succeed.

----------
files: fix_file_writelines-py27.patch
keywords: patch
messages: 217162
nosy: bdkearns
priority: normal
severity: normal
status: open
title: bug in file.writelines accepting buffers
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35036/fix_file_writelines-py27.patch

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

From report at bugs.python.org  Fri Apr 25 21:39:06 2014
From: report at bugs.python.org (Min RK)
Date: Fri, 25 Apr 2014 19:39:06 +0000
Subject: [New-bugs-announce] [issue21351] refcounts not respected at process
	exit
Message-ID: <1398454746.98.0.985879059912.issue21351@psf.upfronthosting.co.za>


New submission from Min RK:

Reference counts appear to be ignored at process cleanup, which allows inter-dependent `__del__` methods to hang on exit. The problem does not seem to occur for garbage collection of any other context (functions, etc.).

I have a case where one object must be cleaned up after some descendent objects. Those descendents hold a reference on the parent and not vice versa, which should guarantee that they are cleaned up before the parent. This guarantee is satisfied by Python 3.3 and below, but not 3.4.

The attached test script hangs at exit on most (not all) runs on 3.4, but exits cleanly on earlier versions.

----------
components: Interpreter Core
files: tstgc.py
messages: 217168
nosy: minrk
priority: normal
severity: normal
status: open
title: refcounts not respected at process exit
versions: Python 3.4
Added file: http://bugs.python.org/file35041/tstgc.py

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

From report at bugs.python.org  Fri Apr 25 22:27:41 2014
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2014 20:27:41 +0000
Subject: [New-bugs-announce] [issue21352] improve indexing
Message-ID: <1398457661.12.0.679738685491.issue21352@psf.upfronthosting.co.za>


New submission from bob gailer:

Inconsistencies / confusion with documentation Index Tab. Example (line numbers added for comments that follow):

1 max
2   built-in function
3 max  (datetime.date attribute)
4   (datetime.datetime attribute)
5   (datetime.time attribute)
6 max() built-in function
7   (decimal.Context method)
8   (decimal.Decimal method)
9   (in module audioloop)

The following all lead to confusion and frustration:
Having 3 rows (1, 3, 6)that begin with max. 
Having an entry (1) that does nothing when double-clicked.
double-clicking (2) takes us to a reference rather than a definition.

RECOMMENDATION:
change to:
max() built-in function
  (sequence operation)
  (decimal.Context method)
  (decimal.Decimal method)
max
  (datetime.date attribute)
  (datetime.datetime attribute)
  (datetime.time attribute)

where double-clicking the first line goes to the max() definition
in 2. Built-in Functions


These comments apply, with a number of variations, to most built-in functions index entries.

----------
assignee: docs at python
components: Documentation
messages: 217170
nosy: bgailer, docs at python
priority: normal
severity: normal
status: open
title: improve indexing
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Apr 26 05:02:53 2014
From: report at bugs.python.org (akira)
Date: Sat, 26 Apr 2014 03:02:53 +0000
Subject: [New-bugs-announce] [issue21353] document Popen.args attribute
Message-ID: <1398481373.88.0.978177813548.issue21353@psf.upfronthosting.co.za>


New submission from akira:

It is convenient to have Popen.args available. Especially when dealing 
with multiple processes e.g., to log failures mentioning the command
that was used to spawn the child process.

subprocess module itself uses it while raising CalledProcessError or TimeoutExpired exceptions.

The documentation patch is attached.

----------
assignee: docs at python
components: Documentation
files: docs-subprocess-document_Popen_args_attribute.patch
keywords: patch
messages: 217183
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: document Popen.args attribute
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35042/docs-subprocess-document_Popen_args_attribute.patch

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

From report at bugs.python.org  Sat Apr 26 10:00:55 2014
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 26 Apr 2014 08:00:55 +0000
Subject: [New-bugs-announce] [issue21354] PyCFunction_New no longer exposed
	by python DLL breaking	bdist_wininst installers
Message-ID: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za>


New submission from Mark Hammond:

Python 3.3 and earlier have in methodobject.c:

/* PyCFunction_New() is now just a macro that calls PyCFunction_NewEx(),
   but it's part of the API so we need to keep a function around that
   existing C extensions can call.
*/

#undef PyCFunction_New
PyAPI_FUNC(PyObject *) PyCFunction_New(PyMethodDef *, PyObject *);

which means PyCFunction_New is exported from the DLL.  Python 3.4 does not have this (which seems a bug in its own right given the comment in 3.3 and earlier) but PC/bdist_wininst/install.c has code that attempts to dynamically load this function from the DLL and fails, causing 3rd party installers to fail.

Assuming the removal of this API was intentional so the problem is that install.c needs to be updated, the following patch fixes the issue.

----------
components: Windows
files: t.patch
keywords: patch
messages: 217185
nosy: mhammond
priority: normal
severity: normal
status: open
title: PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers
type: behavior
Added file: http://bugs.python.org/file35043/t.patch

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

From report at bugs.python.org  Sat Apr 26 14:46:33 2014
From: report at bugs.python.org (Diana Clarke)
Date: Sat, 26 Apr 2014 12:46:33 +0000
Subject: [New-bugs-announce] [issue21355] shallow defaults to true,
	not 1 [filecmp.cmp]
Message-ID: <1398516393.36.0.153160280579.issue21355@psf.upfronthosting.co.za>


New submission from Diana Clarke:

A minor correction to the filecmp.cmp doc string.

    'defaults to 1' -> 'defaults to True'

While shallow used to default to 1 years ago, it now defaults to True.

    def cmp(f1, f2, shallow=True):

PS. I know this diff is annoyingly trivial, but I'm using it to learn the process.

Thanks,

--diana

----------
components: Library (Lib)
files: shallow_defaults_to_true_not_1.patch
keywords: patch
messages: 217192
nosy: diana
priority: normal
severity: normal
status: open
title: shallow defaults to true, not 1 [filecmp.cmp]
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35044/shallow_defaults_to_true_not_1.patch

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

From report at bugs.python.org  Sat Apr 26 16:21:36 2014
From: report at bugs.python.org (Edd Barrett)
Date: Sat, 26 Apr 2014 14:21:36 +0000
Subject: [New-bugs-announce] [issue21356] LibreSSL/RAND_egd fix needed.
Message-ID: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>


New submission from Edd Barrett:

Hi,

I'm sure you have heard about OpenBSD's LibreSSL fork of OpenSSL. There has been a lot of code reorganisation and removal. One function which was removed `RAND_egd()` breaks the CPython build. CPython no longer builds on OpenBSD.

I have submitted a patch against PyPy already. The application library part of the change can probably be re-used since PyPy borrows CPython's application-level standard library (including the `ssl` and `socket` module). However, for the interpreter level change, the build system will probably have to be hacked. We need to check for the existence of `RAND_egd()` at configure time and only build in support if the function is found.

The PyPy patch (and some discussion) is here:
https://bitbucket.org/pypy/pypy/pull-request/233/fix-translation-for-libressl-and-fix-ssl/diff#comment-1744605

I may have a go at doing this myself (for Python-2.7 at least) if no-one steps up in the meantime; for now just making the CPython devs aware.

Thanks

----------
components: Build
messages: 217198
nosy: Edd.Barrett
priority: normal
severity: normal
status: open
title: LibreSSL/RAND_egd fix needed.
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Apr 26 16:50:05 2014
From: report at bugs.python.org (diana)
Date: Sat, 26 Apr 2014 14:50:05 +0000
Subject: [New-bugs-announce] [issue21357] Increase filecmp test coverage
	from 63% to 76%
Message-ID: <1398523805.84.0.496450374391.issue21357@psf.upfronthosting.co.za>


New submission from diana:

- Increase filecmp test coverage from 63% to 76%

- I left the testing style as-is, though it could probably be modernized.

- I did not attempt to add coverage for 'funny_files', 'subdirs', etc, next pass perhaps.

- Before:

diana$ ./python.exe ../coveragepy report --show-missing
Name          Stmts   Miss  Cover   Missing
-------------------------------------------
Lib/filecmp     163     61    63%   64, 80, 126, 130, 159-161, 164-166, 172, 174, 178-180, 190-194, 197-199, 203-224, 227-230, 233-236, 246, 293-302, 305

- After:

diana$ ./python.exe ../coveragepy report --show-missing
Name          Stmts   Miss  Cover   Missing
-------------------------------------------
Lib/filecmp     163     39    76%   64, 80, 126, 130, 159-161, 164-166, 172, 174, 178-180, 192-194, 197-199, 217-218, 220-221, 223-224, 229-230, 235-236, 246, 293-302, 305

Thoughts? Thanks!

----------
components: Library (Lib)
files: increase_filecmp_test_coverage.patch
keywords: patch
messages: 217201
nosy: diana
priority: normal
severity: normal
status: open
title: Increase filecmp test coverage from 63% to 76%
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35045/increase_filecmp_test_coverage.patch

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

From report at bugs.python.org  Sat Apr 26 22:38:59 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Apr 2014 20:38:59 +0000
Subject: [New-bugs-announce] [issue21358] Augmented assignment doc: clarify
	'only evaluated once'
Message-ID: <1398544739.49.0.840910165962.issue21358@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements
"An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a similar, but not exactly equal effect. In the augmented version, x is only evaluated once."

As discussed and demonstrated as part of #21101 (see msg 215560) and following, this is not exactly true in current CPython. If the expression 'x' is 'y[k]', then the subscription is performed twice, once to get and once to set. Both y and k are still evaluated just once.

def ob():
   print('ob fetched')
   return d

def key():
   print('key called')
   return 0

d = [[]]
ob()[key()] += [1]
print(d)

# prints
ob fetched
key called
[[1]]

I suggest changing "x is only evaluated once." to something like

"x is usually only evaluated once. However, if x has the form y[k], y and k are evaluated once but the subscription may be done twice, once to get and once to set."

I intentionally said 'subscription may be' rather than 'subscription is' because implementations should remain free to do the subscription (and the whole expression x) just once -- by directly replacing the reference to the old value in the internals of the mapping structure with a reference to the new value.

#16701 discusses possible ambiguity in the next sentence, about 'in place'.

----------
assignee: docs at python
components: Documentation
messages: 217212
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Augmented assignment doc: clarify 'only evaluated once'
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Apr 26 23:52:44 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Apr 2014 21:52:44 +0000
Subject: [New-bugs-announce] [issue21359] IDLE Redo command accelerator acts
	as Undo with current	OS X Cocoa Tk 8.5.15
Message-ID: <1398549164.45.0.802525173407.issue21359@psf.upfronthosting.co.za>


New submission from Ned Deily:

With the current Cocoa Tk 8.5 (ActiveState 8.5.15), it appears that the IDLE Redo accelerator, Cmd-Shift-Z, has the same effect as the Undo accelerator, Cmd-Z.  This is probably related to the behavior and changes in Cocoa Tk noted in Issue11055.  With the older Apple-supplied Tk 8.5.9 on OS X 10.9, the Cmd-Shift-Z causes two Redos.  Cmd-Shift-Z works correctly with Carbon Tk 8.4.20 (as linked with the 32-bit-only python.org installers) and selecting the Redo menu item, rather than using a keyboard shortcut, appears to work correctly with all versions.

----------
assignee: ned.deily
messages: 217219
nosy: ned.deily
priority: normal
severity: normal
status: open
title: IDLE Redo command accelerator acts as Undo with current OS X Cocoa Tk 8.5.15
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr 27 00:06:43 2014
From: report at bugs.python.org (Lars Wirzenius)
Date: Sat, 26 Apr 2014 22:06:43 +0000
Subject: [New-bugs-announce] [issue21360] mailbox.Maildir should ignore
	files named with a leading	dot
Message-ID: <1398550003.67.0.360972625113.issue21360@psf.upfronthosting.co.za>


New submission from Lars Wirzenius:

The maildir format specification
(see http://cr.yp.to/proto/maildir.html) is clear that files named with leading dots should be ignore:

  Unless you're writing messages to a maildir, the format of a unique 
  name is none of your business. A unique name can be anything that 
  doesn't contain a colon (or slash) and doesn't start with a dot. Do not
  try to extract information from unique names.

Test case:

liw at havelock$ find Maildir -ls
8921206    4 drwxrwxr-x   5 liw      liw          4096 Apr 26 23:03 Maildir
8921207    4 drwxrwxr-x   2 liw      liw          4096 Apr 26 23:03 Maildir/cur
8921209    4 drwxrwxr-x   2 liw      liw          4096 Apr 26 23:03 Maildir/tmp
8921208    4 drwxrwxr-x   2 liw      liw          4096 Apr 26 23:03 Maildir/new
8913523    0 -rw-rw-r--   1 liw      liw             0 Apr 26 23:03 Maildir/new/.foo
liw at havelock$ python -c 'import mailbox
maildir = mailbox.Maildir("Maildir")
print maildir.keys()
'
['.foo']
liw at havelock$ 

The correct output would be the empty list.

"mutt -f Maildir" correctly shows now messages in that folder.

----------
components: Library (Lib)
messages: 217221
nosy: liw
priority: normal
severity: normal
status: open
title: mailbox.Maildir should ignore files named with a leading dot
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 27 06:41:04 2014
From: report at bugs.python.org (Jessica McKellar)
Date: Sun, 27 Apr 2014 04:41:04 +0000
Subject: [New-bugs-announce] [issue21361] Add how to run a single test case
	to the devguide
Message-ID: <1398573664.98.0.323689557818.issue21361@psf.upfronthosting.co.za>


New submission from Jessica McKellar:

I had wanted to run a single TestCase, or single TestCase test method, and saw that how to do this wasn't in the devguide. Pattern-matching from the other rules doesn't work (for now, you have to use unittest instead of test), and asking on IRC, many people didn't know it was possible. :)

This patch adds documentation on how to run a single TestCase. I visually inspected the built HTML to confirm that it looks as desired.

----------
components: Devguide
files: devguide.diff
keywords: easy, needs review, patch
messages: 217239
nosy: ezio.melotti, jesstess
priority: normal
severity: normal
stage: patch review
status: open
title: Add how to run a single test case to the devguide
type: enhancement
Added file: http://bugs.python.org/file35048/devguide.diff

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

From report at bugs.python.org  Sun Apr 27 13:39:29 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 27 Apr 2014 11:39:29 +0000
Subject: [New-bugs-announce] [issue21362] concurrent.futures does not
	validate that max_workers is	proper
Message-ID: <1398598769.27.0.217084820664.issue21362@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Due to some bad math on my side, I passed max_workers=0 to concurrent.futures.ThreadPoolExecutor. This didn't fail properly, but hanged. The same behaviour occurs in ProcessPoolExecutor, but this time it fails internally with something like this:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python34\lib\threading.py", line 921, in _bootstrap_inner
    self.run()
  File "C:\Python34\lib\threading.py", line 869, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Python34\lib\concurrent\futures\process.py", line 225, in _queue_management_worker
    assert sentinels
AssertionError

The attached patch checks that *max_workers* is <= 0 and raises ValueError if so.

----------
components: Library (Lib)
files: futures_max_workers.patch
keywords: patch
messages: 217258
nosy: Claudiu.Popa, bquinlan
priority: normal
severity: normal
status: open
title: concurrent.futures does not validate that max_workers is proper
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35053/futures_max_workers.patch

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

From report at bugs.python.org  Sun Apr 27 14:56:29 2014
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 27 Apr 2014 12:56:29 +0000
Subject: [New-bugs-announce] [issue21363] io.TextIOWrapper always closes
	wrapped files
Message-ID: <1398603389.33.0.793055654008.issue21363@psf.upfronthosting.co.za>


New submission from Armin Ronacher:

I'm trying to write some code that fixes a misconfigured sys.stdin on a case by case bases but unfortunately I cannot use TextIOWrapper for this because it always closes the underlying file:


Python

>>> import io
>>> sys.stdin.encoding
'ANSI_X3.4-1968'
>>> stdin = sys.stdin
>>> correct_stdin = io.TextIOWrapper(stdin.buffer, 'utf-8')
>>> correct_stdin.readline()
foobar
'foobar\n'
>>> del correct_stdin
>>> stdin.readline()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file.

Ideally there would be a way to disable this behavior.

----------
messages: 217260
nosy: aronacher
priority: normal
severity: normal
status: open
title: io.TextIOWrapper always closes wrapped files

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

From report at bugs.python.org  Sun Apr 27 17:03:53 2014
From: report at bugs.python.org (Armin Ronacher)
Date: Sun, 27 Apr 2014 15:03:53 +0000
Subject: [New-bugs-announce] [issue21364] Documentation Recommends Broken
	Pattern
Message-ID: <1398611033.23.0.241148860666.issue21364@psf.upfronthosting.co.za>


New submission from Armin Ronacher:

The documentation recommends replacing sys.stdin with a binary stream currently: https://docs.python.org/3/library/sys.html#sys.stdin

This sounds like a bad idea because it will break pretty much everything in Python in the process.

As example:

>>> import sys
>>> sys.stdin = sys.stdin.detach()
>>> input('Test: ')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: '_io.BufferedReader' object has no attribute 'errors'

>>> sys.stdout = sys.stdout.detach()
>>> print('Hello World!')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' does not support the buffer interface

----------
messages: 217270
nosy: aronacher
priority: normal
severity: normal
status: open
title: Documentation Recommends Broken Pattern

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

From report at bugs.python.org  Sun Apr 27 17:38:18 2014
From: report at bugs.python.org (Paul Sokolovsky)
Date: Sun, 27 Apr 2014 15:38:18 +0000
Subject: [New-bugs-announce] [issue21365] asyncio.Task reference misses the
	most important fact	about it,
	related info spread around intros and example commentary instead
Message-ID: <1398613098.75.0.265677522517.issue21365@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

It caused me a big surprise that asyncio.Task object automatically schedules itself in the main loop for execution upon creation (i.e. in constructor).

Nowhere in the main reference part of section "18.5.2.4. Task" (https://docs.python.org/3.5/library/asyncio-task.html#task) does it mention that fact. Vice versa, it explicitly says that Task is merely "A coroutine object wrapped in a Future.", which surely sets grounds for surprise when finding that Task is not just coroutine wrapped in Future, but exhibits extra behavior unexpected of plain Future.

Docs cursorily mention this property of Task outside main reference section for it. Specifically:

1) "18.5.2.1. Coroutines", end of intro section:

"In the case of a coroutine object, there are two basic ways to start it running: call yield from coroutine from another coroutine (assuming the other coroutine is already running!), or convert it to a Task."

I would argue that this is way too cursorily and doesn't put strong enough emphasis on the property of self-scheduling, to catch attention of novice or casual reader. For example, my entailments after reading the passage above are: "... or convert it to a Task, to schedule it in a loop [explicitly], because a coroutine can't be scheduled in a loop directly, but Task can be".

2) Very end of subsection "18.5.2.4.1. Example: Parallel execution of tasks", a short line squeezed between colored example block and new section heading - a place where some user will miss it outright: "A task is automatically scheduled for execution when it is created."



Based on case study above, I would like to propose:

1). In section "18.5.2.4. Task", in class description, make unmissable fact that instantiating an object makes it scheduled. For example, append after: "A coroutine object wrapped in a Future. Subclass of Future." following: "Instantiating object of this class automatically schedules it to be run in an event loop specified by 'loop' parameter (or default event loop)."

2) Ideally, update 2 excerpts above to convey more explicit information, and be more visible (for case 2, for example, move it before the example, not after).

----------
assignee: docs at python
components: Documentation
messages: 217272
nosy: docs at python, pfalcon
priority: normal
severity: normal
status: open
title: asyncio.Task reference misses the most important fact about it, related info spread around intros and example commentary instead
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Apr 27 18:12:19 2014
From: report at bugs.python.org (Jon Brandvein)
Date: Sun, 27 Apr 2014 16:12:19 +0000
Subject: [New-bugs-announce] [issue21366] Document that return in finally
	overwrites prev value
Message-ID: <1398615139.09.0.290952002497.issue21366@psf.upfronthosting.co.za>


New submission from Jon Brandvein:

def foo():
    try:
      return 1
    finally;
      return 2
  print(foo())  # 2

I've seen this peculiar case discussed on a few blogs lately, but was unable to find confirmation that this behavior is defined.

In the try/finally section of Doc/reference/compound_stmts.rst, immediately after the sentence beginning

> When a return, break, or continue statement is executed

I propose adding something to the effect of:

> A return statement in a finally clause overrides the value of any return statement executed in the try suite.

This wording also handles the case of nested try/finally blocks.

----------
assignee: docs at python
components: Documentation
messages: 217277
nosy: brandjon, docs at python
priority: normal
severity: normal
status: open
title: Document that return in finally overwrites prev value
type: behavior

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

From report at bugs.python.org  Sun Apr 27 19:12:14 2014
From: report at bugs.python.org (Lee Clemens)
Date: Sun, 27 Apr 2014 17:12:14 +0000
Subject: [New-bugs-announce] [issue21367] multiprocessing.JoinableQueue
	requires new kwarg
Message-ID: <1398618734.12.0.810845662855.issue21367@psf.upfronthosting.co.za>


New submission from Lee Clemens:

Not mentioned (at least not specifically) in the release notes, multiprocessing.JoinableQueue now requires 'ctx' keyword argument:
  def __init__(self, maxsize=0, *, ctx):

This causes an application calling JoinableQueue() to work with 3.3.2 (my single test) to work, but not with 3.4.0

TypeError: __init__() missing 1 required keyword-only argument: 'ctx'

The documentation is also incorrect: https://docs.python.org/3.4/library/multiprocessing.html#multiprocessing.JoinableQueue

----------
components: Interpreter Core
messages: 217289
nosy: sftw at leeclemens.net
priority: normal
severity: normal
status: open
title: multiprocessing.JoinableQueue requires new kwarg
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr 27 21:30:25 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Apr 2014 19:30:25 +0000
Subject: [New-bugs-announce] [issue21368] Check for systemd locale on
	startup if current locale is	set to POSIX
Message-ID: <1398627025.84.0.804520187603.issue21368@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 19977 added "surrogateescape" to the fallback settings for the standard streams if Python 3 appears to be running under the POSIX locale (which Python 3 currently reads as setting a default encoding of ASCII, which is almost certainly wrong on any modern Linux system).

If a modern Linux system is using systemd as the process manager, then there will likely be a "/etc/locale.conf" file providing settings like LANG - due to problematic requirements in the POSIX specification, this file (when available) is likely to be a better "source of truth" regarding the system encoding than the environment where the interpreter process is started, at least when the latter is claiming ASCII as the default encoding.

See http://www.freedesktop.org/software/systemd/man/locale.conf.html for more details.

----------
components: Interpreter Core
messages: 217313
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Check for systemd locale on startup if current locale is set to POSIX
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 28 00:26:05 2014
From: report at bugs.python.org (Sworddragon)
Date: Sun, 27 Apr 2014 22:26:05 +0000
Subject: [New-bugs-announce] [issue21369] Extended modes for
	tarfile.TarFile()
Message-ID: <1398637565.27.0.953592639835.issue21369@psf.upfronthosting.co.za>


New submission from Sworddragon:

tarfile.open() does support optionally an compression method on the mode argument in the form of 'filemode[:compression]' but tarfile.TarFile() does only suport 'a', 'r' and 'w'. Is there a special reason that tarfile.TarFile() doesn't directly support an optional compression method? Otherwise it would be nice if they could be used directly on tarfile.TarFile() too.

----------
components: Library (Lib)
messages: 217320
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Extended modes for tarfile.TarFile()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr 28 00:37:53 2014
From: report at bugs.python.org (John Rusnak)
Date: Sun, 27 Apr 2014 22:37:53 +0000
Subject: [New-bugs-announce] [issue21370] segfault from simple
	traceback.format_exc call
Message-ID: <1398638273.35.0.105572602615.issue21370@psf.upfronthosting.co.za>


New submission from John Rusnak:

Launch python3.3 and then

>>> import traceback
>>> tracebacke.format_exc()

Seomteims a long trace about missing attribute is produced, on subequent of sometimes first call, python executable segfaults.  I see this behavior in an app as well then calling format_exc() under a real exception condition.

----------
messages: 217321
nosy: John.Rusnak
priority: normal
severity: normal
status: open
title: segfault from simple traceback.format_exc call
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 28 04:02:39 2014
From: report at bugs.python.org (Li Zhenhua)
Date: Mon, 28 Apr 2014 02:02:39 +0000
Subject: [New-bugs-announce] [issue21371] struct lconv does not have
	decimal_point on android	platform
Message-ID: <1398650559.39.0.586667315036.issue21371@psf.upfronthosting.co.za>


New submission from Li Zhenhua:

When compile python for android, it gets error because struct lconv does not have a member "decimal_point".

----------
components: Cross-Build
files: lconv_member.patch
keywords: patch
messages: 217335
nosy: lizhenhua
priority: normal
severity: normal
status: open
title: struct lconv does not have decimal_point on android platform
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file35066/lconv_member.patch

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

From report at bugs.python.org  Mon Apr 28 10:16:04 2014
From: report at bugs.python.org (Marc Schlaich)
Date: Mon, 28 Apr 2014 08:16:04 +0000
Subject: [New-bugs-announce] [issue21372]
	multiprocessing.util.register_after_fork inconsistency
Message-ID: <1398672964.28.0.985951406539.issue21372@psf.upfronthosting.co.za>


New submission from Marc Schlaich:

multiprocessing.util.register_after_fork does not behave consistently on Windows because the `_afterfork_registry` is not transferred to the subprocess. The following example fails on Windows while it works perfectly on Linux:


import multiprocessing.util


def hook(*args):
    print (args)


def func():
    print ('func')


if __name__ == '__main__':
    multiprocessing.util.register_after_fork(hook, hook)
    p = multiprocessing.Process(target=func)
    p.start()

----------
components: Windows
messages: 217347
nosy: schlamar
priority: normal
severity: normal
status: open
title: multiprocessing.util.register_after_fork inconsistency
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr 28 14:55:25 2014
From: report at bugs.python.org (Maxime Lorant)
Date: Mon, 28 Apr 2014 12:55:25 +0000
Subject: [New-bugs-announce] [issue21373] robotparser: Automatically call
	modified function in	read()
Message-ID: <1398689725.23.0.532137440879.issue21373@psf.upfronthosting.co.za>


New submission from Maxime Lorant:

For the moment, RobotFileParser (on both Python 2.x and 3.x) has a method modified, but it is never called in the class itself, hence the last_checked attribute is always at 0 if the user doesn't call modified() explicitly. 

I would suggest to add a call to modified() at the end of the read() method. It makes more sense to have a last_checked value (returns in mtime()) updated by the class itself. Especially when the doc says: "Returns the time the ``robots.txt`` file was last fetched.". Currently this sentence isn't true, since the value has to be updated by the user.

----------
components: Library (Lib)
files: robotparser.diff
keywords: patch
messages: 217370
nosy: mlorant, orsenthil
priority: normal
severity: normal
status: open
title: robotparser: Automatically call modified function in read()
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35073/robotparser.diff

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

From report at bugs.python.org  Mon Apr 28 18:00:26 2014
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 28 Apr 2014 16:00:26 +0000
Subject: [New-bugs-announce] [issue21374] DecimalTuple.__module__ is set to
	_frozen_importlib
Message-ID: <1398700826.27.0.585241892269.issue21374@psf.upfronthosting.co.za>


New submission from Stefan Krah:

>>> x = Decimal(9).as_tuple()
>>> import pickle
>>> pickle.dumps(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class '_frozen_importlib.DecimalTuple'>: attribute lookup DecimalTuple on _frozen_importlib failed

----------
components: Extension Modules
messages: 217381
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: DecimalTuple.__module__ is set to _frozen_importlib
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 28 19:59:54 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Apr 2014 17:59:54 +0000
Subject: [New-bugs-announce] [issue21375] Fix and test overflow behavior in
	the C version of heapq
Message-ID: <1398707994.45.0.696035798055.issue21375@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The Py_ssizet indexes can overflow the "childpos" variable:

    childpos = 2*pos + 1;    /* leftmost child position  */
    while (childpos < endpos) ...


http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

----------
assignee: rhettinger
components: Extension Modules
messages: 217389
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix and test overflow behavior in the C version of heapq
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 28 20:05:57 2014
From: report at bugs.python.org (Philip Sequeira)
Date: Mon, 28 Apr 2014 18:05:57 +0000
Subject: [New-bugs-announce] [issue21376] asyncio docs refer to wrong
	TimeoutError
Message-ID: <1398708357.06.0.922465155945.issue21376@psf.upfronthosting.co.za>


New submission from Philip Sequeira:

Example: https://docs.python.org/3.4/library/asyncio-task.html
TimeoutError is mentioned several times, and links to the OSError subclass. However, the actual TimeoutError raised by asyncio stuff is the one from concurrent.futures, which is not compatible. The docs as they are seem to suggest that something like "except TimeoutError" would be appropriate, when in fact that would not produce the expected behavior; "except asyncio.TimeoutError" is what you'd want.

----------
assignee: docs at python
components: Documentation
messages: 217390
nosy: docs at python, qmega
priority: normal
severity: normal
status: open
title: asyncio docs refer to wrong TimeoutError
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 28 21:47:24 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Apr 2014 19:47:24 +0000
Subject: [New-bugs-announce] [issue21377] PyBytes_Concat could try to concat
	in-place
Message-ID: <1398714444.35.0.443659487134.issue21377@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently, PyBytes_Concat always creates a new bytes object for the result. However, when Py_REFCNT(*pv) == 1, it could instead call _PyBytes_Resize() and then concat the second argument in place.

(like e.g. _PyUnicode_Append does)

----------
components: Interpreter Core
messages: 217406
nosy: haypo, nikratio, pitrou
priority: normal
severity: normal
status: open
title: PyBytes_Concat could try to concat in-place
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Mon Apr 28 23:02:30 2014
From: report at bugs.python.org (Bill Bergmann)
Date: Mon, 28 Apr 2014 21:02:30 +0000
Subject: [New-bugs-announce] [issue21378] ImportError: No module named
	'concurrent.futures'
Message-ID: <1398718950.31.0.466187960646.issue21378@psf.upfronthosting.co.za>


New submission from Bill Bergmann:

python 3.4 attempting to run example at https://docs.python.org/3/library/concurrent.futures.html
17.4.2.1

$ python3 17_4_2.py 
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 2195, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "17_4_2.py", line 1, in <module>
    import concurrent.futures
ImportError: No module named 'concurrent.futures'; 'concurrent' is not a package

os: OS X 10.6

from $env:
PATH=/Library/Frameworks/Python.framework/Versions/3.4/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin: ...

PYTHONPATH=/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/:/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/: ...

----------
components: Library (Lib)
messages: 217418
nosy: Bill.Bergmann
priority: normal
severity: normal
status: open
title: ImportError: No module named 'concurrent.futures'
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr 28 23:10:29 2014
From: report at bugs.python.org (Hannan Aharonov)
Date: Mon, 28 Apr 2014 21:10:29 +0000
Subject: [New-bugs-announce] [issue21379] StopIteration is silenced when
	raised by generator	within context manager
Message-ID: <1398719429.87.0.781789142964.issue21379@psf.upfronthosting.co.za>


New submission from Hannan Aharonov:

If the code that defines a context manager performs some operations on a generator that cause it to raise StopIteration, this exception is propagated to the context manager's __exit__() method and there swallowed by a try..except block. 

This can cause unexpected/unintuitive behaviour.
The following simplified example shows an infinite loop caused by this:

-------
from contextlib import contextmanager

@contextmanager
def manager(gen):
    yield
    gen.next()

emptygen = (_ for _ in ())

while True:
    with manager(emptygen):
        print "Infinite Loop"
-------

In this case, even though the generator is empty, the loop will never stop, because the generator's StopIteration exception is swallowed by the context manager. (If `gen.next()` was wrapped by try..except that reraises exception as, say, RuntimeError, the program would stop.)

I've looked at the source (here: http://hg.python.org/cpython/file/tip/Lib/contextlib.py line 67)
and I understand why this is happening: the context manager can't tell the difference between the two kinds of StopIteration - one that is raised by its own completion, and one that is raised by a call in its body. 

I don't know if this is a bug or expected behavior of nested generators. In any case, I haven't seen this issue mentioned in the documentation, and the behavior is unintuitive.

I've searched the bug tracker and found a similar issue that handled swallowing of StopIteration in the code wrapped by the context manager (http://bugs.python.org/issue1705170), and another similar issue (http://bugs.python.org/issue16610) that was closed without resolution.

----------
components: Interpreter Core, Library (Lib)
messages: 217421
nosy: hannan.aha, ncoghlan
priority: normal
severity: normal
status: open
title: StopIteration is silenced when raised by generator within context manager
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 28 23:21:42 2014
From: report at bugs.python.org (Michael P. Soulier)
Date: Mon, 28 Apr 2014 21:21:42 +0000
Subject: [New-bugs-announce] [issue21380] timezone support in strftime
	methods broken
Message-ID: <1398720102.85.0.645448692913.issue21380@psf.upfronthosting.co.za>


New submission from Michael P. Soulier:

msoulier at cappuccino:~$ python
Python 2.7.3 (default, Mar 13 2014, 11:03:55)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> now = datetime.now()
>>> now.strftime("%z")
''
>>> import time
>>> time.strftime("%z", time.localtime(time.time()))
'+0000'
>>>

I think those calls should be printing the UTC offset, no?

----------
components: Extension Modules
messages: 217424
nosy: msoulier
priority: normal
severity: normal
status: open
title: timezone support in strftime methods broken
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 29 03:27:38 2014
From: report at bugs.python.org (Christian Tismer)
Date: Tue, 29 Apr 2014 01:27:38 +0000
Subject: [New-bugs-announce] [issue21381] python build crash on Mavericht
Message-ID: <1398734858.53.0.489606157179.issue21381@psf.upfronthosting.co.za>


New submission from Christian Tismer:

Building python on OSX Mavericks (10.9)
of Python 3.4 crashes when this is set:

MACOSX_DEPLOYMENT_TARGET=10.7

This happens with OSX 10.9.2,
all current updates installed,
as of 2014-04-28.

Demo script:
You can use my attached script to validate this error.
The script builds PySide for 16 configurations.
Exactly on Python 3.4 / OSX 10.7 it crashes.

You can easily tweak the creating loop to just build the crashing case.

Cheers -- Chris

----------
components: Build
files: pyside_builder.py
messages: 217458
nosy: Christian.Tismer
priority: low
severity: normal
stage: needs patch
status: open
title: python build crash on Mavericht
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file35081/pyside_builder.py

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

From report at bugs.python.org  Tue Apr 29 10:17:16 2014
From: report at bugs.python.org (rsevcan)
Date: Tue, 29 Apr 2014 08:17:16 +0000
Subject: [New-bugs-announce] [issue21382] Signal module doesnt raises
	ValueError Exception
Message-ID: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za>


New submission from rsevcan:

signal.signal() built-in function doesnt throws a ValueError exception in Windows when is called with a different signal than SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, or SIGTERM, as it is written in the documentation.

https://docs.python.org/2/library/signal.html#signal.signal
https://docs.python.org/3/library/signal.html#signal.signal

It throws an AttributeError Exception

>>> import signal
>>> import sys
>>> sys.platform
'win32'
>>> signal.signal(signal.SIGPIPE, lambda signum, frame: sys.exit(1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'SIGPIPE'
>>>

Regards

----------
assignee: docs at python
components: Documentation
messages: 217486
nosy: docs at python, rsevcan
priority: normal
severity: normal
status: open
title: Signal module doesnt raises ValueError Exception
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 29 10:42:27 2014
From: report at bugs.python.org (Ned Deily)
Date: Tue, 29 Apr 2014 08:42:27 +0000
Subject: [New-bugs-announce] [issue21383] "make touch" fails when the build
	directory is not the	source directory
Message-ID: <1398760947.89.0.691766045615.issue21383@psf.upfronthosting.co.za>


New submission from Ned Deily:

make touch
hg --config extensions.touch=Tools/hg/hgtouch.py touch -v
*** failed to import extension touch from Tools/hg/hgtouch.py: [Errno 2] No such file or directory: 'Tools/hg/hgtouch.py'
hg: unknown command 'touch'

----------
components: Build
messages: 217497
nosy: ned.deily
priority: normal
severity: normal
status: open
title: "make touch" fails when the build directory is not the source directory
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 29 10:59:41 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Apr 2014 08:59:41 +0000
Subject: [New-bugs-announce] [issue21384] Windows: Make handle non
	inheritable by default
Message-ID: <1398761981.56.0.701422046655.issue21384@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PEP 446 was implemented in Python 3.4. All file descriptors are now created non inheritable. The implementation was not finished on Windows, handles may be created inheritable. The Python code should be audoted for that.

For example, hCryptProv in Python/random.c is inheritable or not?

----------
components: Windows
messages: 217501
nosy: haypo, sbt, tim.golden
priority: normal
severity: normal
status: open
title: Windows: Make handle non inheritable by default
versions: Python 3.5

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

From report at bugs.python.org  Tue Apr 29 11:00:10 2014
From: report at bugs.python.org (Antti Haapala)
Date: Tue, 29 Apr 2014 09:00:10 +0000
Subject: [New-bugs-announce] [issue21385] Compiling modified AST crashes on
	debug build unless	linenumbering discarded
Message-ID: <1398762010.89.0.992252148712.issue21385@psf.upfronthosting.co.za>


New submission from Antti Haapala:

We had had problems with our web service occasionally hanging and performing poorly, and as we didn't have much clue about the cause of these, we decided to continuously run our staging build under debug enabled python 3.4, and then attaching gdb as needed. To much dismay we found out that our code generating code that builds AST trees and then compiles them to modules is dumping cores on the debug version. 

The assertion is the much discussed "linenumbers must grow monotonically" at http://hg.python.org/cpython/file/04f714765c13/Python/compile.c#l3969

In our case, the AST is generated from a HTML template with embedded python parts; as we could approximately point out much of the corresponding code in the source template, we decided to reuse the linenumbers in AST, and things seemed to work quite nicely and usually we could get usable tracebacks too.

Under debug build, however, as the ordering of some constructs in the source language are different from python, we need to discard *all* linenumbers and only after then use fix_missing_locations, and thus get completely unusable traces from these parts of code, all happening on line 1. Just using fix_missing_locations does not work. Likewise the rules for which parts of the tree should come in which order in the lnotab is quite hard to deduce.

It seems to me that when the lnotab was created, no one even had in mind that there would be an actually useful AST module that would be used for code generation. Considering that there have been other calls for breaking the correspondence of bytecode addresses to monotonically growing linenumbers, I want to reopen the discussion about changing the lnotab structures now to allow arbitrary mapping of source code locations to bytecode, and especially about the need for this assertion in the debug builds at all.

Attached is an example of code that appends a function to an existing module syntax tree, run under python*-dbg it dumps the core with "Python/compile.c:nnnn: assemble_lnotab: Assertion `d_lineno >= 0' failed." Ofc in this simple case it is easy to just modify the linenumbers so that function "bar" would come after "foo", however in some cases it is hard to know the actual rules; fix_missing_locations does not do this right at all.

I am also pretty sure most of the existing code that combine parsed and generated ASTs and then compile the resulting trees also would fail that assert, but no one is ever running their code under debug builds.

----------
components: Interpreter Core
files: astlinenotest.py
messages: 217502
nosy: Ztane
priority: normal
severity: normal
status: open
title: Compiling modified AST crashes on debug build unless linenumbering discarded
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35090/astlinenotest.py

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

From report at bugs.python.org  Tue Apr 29 13:35:35 2014
From: report at bugs.python.org (Roger Luethi)
Date: Tue, 29 Apr 2014 11:35:35 +0000
Subject: [New-bugs-announce] [issue21386] ipaddress.IPv4Address.is_global
	not implemented
Message-ID: <1398771335.62.0.997727403803.issue21386@psf.upfronthosting.co.za>


New submission from Roger Luethi:

Lib/ipaddress.py does not implement is_global for IPv4Address, in contrast to the documentation which states for IPv4Address.is_global: "True if the address is allocated for public networks."

A patch like the one attached to this report should fix that.

----------
components: Library (Lib)
files: ipv4addr_global.diff
keywords: patch
messages: 217511
nosy: rluethi
priority: normal
severity: normal
status: open
title: ipaddress.IPv4Address.is_global not implemented
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35092/ipv4addr_global.diff

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

From report at bugs.python.org  Tue Apr 29 13:55:37 2014
From: report at bugs.python.org (Evgeniy Stepanov)
Date: Tue, 29 Apr 2014 11:55:37 +0000
Subject: [New-bugs-announce] [issue21387] Memory leaks when embedded
	interpreter is reinitialized
Message-ID: <1398772537.74.0.909134635776.issue21387@psf.upfronthosting.co.za>


New submission from Evgeniy Stepanov:

Following https://docs.python.org/2/c-api/init.html#Py_Finalize, I'm reinitializing embedded python interpreter multiple time in one process.

#include <Python.h>

void f() {
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
      "import datetime\n"
      "print 'Today is',ctime(time())\n");
  Py_Finalize();
}

int main(void) {
  for (int i = 0; i < 30; ++i)
    f();
  return 0;
}

I see 2 sources of memory leaks:

 * _once_registry is never teared down.

==20144==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8120 byte(s) in 29 object(s) allocated from:
    #0 0x4a3e38 in malloc /code/llvm/build0/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:75
    #1 0x4e1524 in _PyObject_GC_Malloc build/Python-2.7.6/Modules/gcmodule.c:1499
    #2 0x4e16ff in _PyObject_GC_New build/Python-2.7.6/Modules/gcmodule.c:1521
    #3 0x57e581 in PyDict_New build/Python-2.7.6/Objects/dictobject.c:277
    #4 0x62b9a7 in _PyWarnings_Init build/Python-2.7.6/Python/_warnings.c:898
    #5 0x4c2985 in Py_InitializeEx build/Python-2.7.6/Python/pythonrun.c:254
    #6 0x4c22a4 in f() build/Python-2.7.6/1.cc:4
    #7 0x4c22a4 in main build/Python-2.7.6/1.cc:14


* datetime module creates a bunch of objects in its initialization function and never destroys them

Direct leak of 8120 byte(s) in 29 object(s) allocated from:
    #0 0x4a3e38 in malloc /code/llvm/build0/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:75
    #1 0x4e1524 in _PyObject_GC_Malloc build/Python-2.7.6/Modules/gcmodule.c:1499
    #2 0x4e16ff in _PyObject_GC_New build/Python-2.7.6/Modules/gcmodule.c:1521
    #3 0x57e581 in PyDict_New build/Python-2.7.6/Objects/dictobject.c:277
    #4 0x6cb976 in PyErr_NewException build/Python-2.7.6/Python/errors.c:577
    #5 0x757227 in initzipimport build/Python-2.7.6/./Modules/zipimport.c:1235
    #6 0x6e5797 in init_builtin build/Python-2.7.6/Python/import.c:1999
    #7 0x6e158d in load_module build/Python-2.7.6/Python/import.c:1928
    #8 0x6e6919 in import_submodule build/Python-2.7.6/Python/import.c:2700
    #9 0x6e5ac7 in load_next build/Python-2.7.6/Python/import.c:2515
    #10 0x6e036c in import_module_level build/Python-2.7.6/Python/import.c:2224
    #11 0x6e036c in PyImport_ImportModuleLevel build/Python-2.7.6/Python/import.c:2288
    #12 0x671e6f in builtin___import__ build/Python-2.7.6/Python/bltinmodule.c:49
    #13 0x502b40 in PyObject_Call build/Python-2.7.6/Objects/abstract.c:2529
    #14 0x502e82 in call_function_tail build/Python-2.7.6/Objects/abstract.c:2561
    #15 0x502e82 in PyObject_CallFunction build/Python-2.7.6/Objects/abstract.c:2585
    #16 0x6df7b0 in PyImport_Import build/Python-2.7.6/Python/import.c:2886
    #17 0x6db9a7 in PyImport_ImportModule build/Python-2.7.6/Python/import.c:2129
    #18 0x6db9a7 in _PyImportHooks_Init build/Python-2.7.6/Python/import.c:239
    #19 0x4c287f in Py_InitializeEx build/Python-2.7.6/Python/pythonrun.c:248
    #20 0x4c22a4 in f() build/Python-2.7.6/1.cc:4
    #21 0x4c22a4 in main build/Python-2.7.6/1.cc:14

----------
components: Extension Modules, Interpreter Core
messages: 217513
nosy: Evgeniy.Stepanov
priority: normal
severity: normal
status: open
title: Memory leaks when embedded interpreter is reinitialized
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 29 15:39:31 2014
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 29 Apr 2014 13:39:31 +0000
Subject: [New-bugs-announce] [issue21388] decimal.InvalidContext is unused
Message-ID: <1398778771.07.0.438455770103.issue21388@psf.upfronthosting.co.za>


New submission from Stefan Krah:

We could remove decimal.InvalidContext, which is completely unused
both in decimal.py and _decimal.

----------
messages: 217519
nosy: mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: decimal.InvalidContext is unused
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 30 04:26:41 2014
From: report at bugs.python.org (Steven Barker)
Date: Wed, 30 Apr 2014 02:26:41 +0000
Subject: [New-bugs-announce] [issue21389] The repr of BoundMethod objects
	sometimes incorrectly	identifies the bound function
Message-ID: <1398824801.68.0.416059453762.issue21389@psf.upfronthosting.co.za>


New submission from Steven Barker:

The "repr" of bound method objects can be misleading in certain situations. The repr is always is of the format:

    <bound method x.y of <object>>

But "x" is often incorrect.

Here are some examples where the current code gets it wrong:

    # inherited method
    class Base(object):
        def foo(self):
            pass

    class Derived(Base):
        pass

    print(Derived().foo)
    # not too bad, prints "<bound method Derived.foo of <__main__.Derived object at 0xXXXX>>"
    # it probably should say "Base.foo" instead of "Derived.foo", but at least they're two names for the same function

    # however, an override and super() it gets very bad
    class Derived2(Base):
        def foo(self):
            pass

    print(super(Derived2, Derived2()).foo)
    # totally wrong, prints "<bound method Dervied2.foo of __main__.derived2 object at 0xXXXX>>"
    # but it actually *is* Base.foo bound to a Derived2 instance!

    # bound class methods:
    class Test(object):
        @classmethod
        def foo(cls):
            pass

    print(Test.foo)
    # wrong, prints <bound method type.foo of <class '__main__.Test'>>

I suggest that rather than trying to assemble the "x.y" pair by from "__self__.__class__" and "__func__.__name__", the BoundMethod should just use the "__func__.__qualname__". In each of the cases above, the function's location would be correctly located this way.

I came across this bug while investigating a confusing (to me) issue with metaclasses and inheritance. The misleading "repr" output made it much harder to figure out that my expectations were wrong. Here's a simplified example of how it led me astray:

    class A(object):
        @classmethod
        def foo(cls):
            return "classmethod from A"

    class BMeta(type):
        def foo(cls):
            return "instancemethod from BMeta"

    class B(A, metaclass=BMeta):
        pass

    print(B.foo()) # surprisingly (to me) prints "classmethod from A"
    print(B.foo)   # incorrectly prints "<bound method BMeta.foo of <class __main__.B>>"

It is presumably not a bug that inherited class methods take precedence over instance methods from a metaclass (though it was surprising to me at the time). The repr of the bound method though, suggested exactly the opposite. Given that it gets many more common situations wrong as well, I think that the repr should be fixed.

The relevant code appears to be in the method_repr function in Objects/Classobject.c .

----------
components: Interpreter Core
messages: 217566
nosy: Steven.Barker
priority: normal
severity: normal
status: open
title: The repr of BoundMethod objects sometimes incorrectly identifies the bound function
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 30 09:33:43 2014
From: report at bugs.python.org (Li Zhenhua)
Date: Wed, 30 Apr 2014 07:33:43 +0000
Subject: [New-bugs-announce] [issue21390] strdup may cause Segment Fault on
	Android
Message-ID: <1398843223.64.0.854948810113.issue21390@psf.upfronthosting.co.za>


New submission from Li Zhenhua:

On Android platform, when run "python" command without any scripts, it may crash, get an error message "Segment Fault". This is because strdup with a NULL pointer. 

Details:
In file 
    Modules/readline.c, 
function
    static void setup_readline(void)

This line:
    char *saved_locale = strdup(setlocale(LC_CTYPE, NULL));

When running on an Android platform, setlocale(LC_CTYPE, NULL) returns NULL, and this causes strdup with a NULL pointer, then Segment Fault occurs.

----------
components: Cross-Build
files: strdup.patch
keywords: patch
messages: 217580
nosy: lizhenhua.dev
priority: normal
severity: normal
status: open
title: strdup may cause Segment Fault on Android
versions: Python 3.5
Added file: http://bugs.python.org/file35105/strdup.patch

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

From report at bugs.python.org  Wed Apr 30 10:49:28 2014
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 30 Apr 2014 08:49:28 +0000
Subject: [New-bugs-announce] [issue21391] PATCH: using the abspath shortcut
	in Lib/shutil
Message-ID: <1398847768.59.0.993653219407.issue21391@psf.upfronthosting.co.za>


Changes by Yinon Ehrlich <yinoneh at users.sourceforge.net>:


----------
components: Library (Lib)
nosy: Yinon
priority: normal
severity: normal
status: open
title: PATCH: using the abspath shortcut in Lib/shutil
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 30 11:15:44 2014
From: report at bugs.python.org (dellair jie)
Date: Wed, 30 Apr 2014 09:15:44 +0000
Subject: [New-bugs-announce] [issue21392] Python on Cygwin: subprocess.call
	BlockingIOError:	[Errno 11] Resource temporarily unavailable
Message-ID: <1398849344.37.0.135899033278.issue21392@psf.upfronthosting.co.za>


New submission from dellair jie:

Folks,

I am running Python 3.4 on Cygwin 1.7.17 on Windows 2008.
The constant error I get is:

Traceback (most recent call last):
  File "M:/sb3_ljie/bce/cmTools/lib/CC.py", line 321, in standAlone
    results = Process.execute (cmd = cmd, opts = opts)
  File "M:/sb3_ljie/bce/cmTools/lib/Process.py", line 327, in execute
    timeout = timeout)
  File "/usr/local/lib/python3.4/subprocess.py", line 535, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/local/lib/python3.4/subprocess.py", line 848, in __init__
    restore_signals, start_new_session)
  File "/usr/local/lib/python3.4/subprocess.py", line 1379, in _execute_child
    restore_signals, start_new_session, preexec_fn)
BlockingIOError: [Errno 11] Resource temporarily unavailable

Python script is invoked via socket (server runs Cygwin inetd).

While the script (snippet) Process.py is as below with relatively large data return:
import subprocess, os, tempfile, re
def execute (cmd = None,
             opts = None,
             log = None,
             verify = False,
             cmdlog = False,
             audit = False,
             logappend = False,
             ignorestatus = False,
             umask = None,
             host = None,
             interrupt = None,
             timeout = None,
             forceaudit = False):
    global __signal
    global __signalList
    returnData = {"status": 0, "rawstatus": 0, "interrupt": 0,
                  "stdout": None, "stderr": None}
    os.environ["ENV"] = ""

    stdOutHandle, stdOut = tempfile.mkstemp (text = True)
    stdErrHandle, stdErr = tempfile.mkstemp (text = True)

    if re.match ("\s", cmd): cmd = "'" + cmd + "'"
    cmd = [cmd]
    opts = opts.split()
    cmd.extend (opts)

    if not verify:
        if umask: originalUmask = os.umask (umask)

        if interrupt:
            for idex, item in enumerate (__signalList):
                if item: signal.signal (idex, interrupt)

        __signal = 0

        returnData["rawstatus"] = subprocess.call (cmd, stdout = stdOutHandle,
                                                   stderr = stdErrHandle,
                                                   timeout = timeout)
        returns = returnData["rawstatus"]
    os.close (stdOutHandle)
    os.close (stdErrHandle)

Br,
Dellair

----------
messages: 217585
nosy: dellair.jie
priority: normal
severity: normal
status: open
title: Python on Cygwin: subprocess.call BlockingIOError: [Errno 11] Resource temporarily unavailable
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 30 11:56:20 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Apr 2014 09:56:20 +0000
Subject: [New-bugs-announce] [issue21393] Python/random.c: close hCryptProv
	at exit
Message-ID: <1398851780.59.0.329794424514.issue21393@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch closes hCryptProv handle at Python exit.

----------
files: random_closehandle.patch
keywords: patch
messages: 217591
nosy: haypo
priority: normal
severity: normal
status: open
title: Python/random.c: close hCryptProv at exit
versions: Python 3.5
Added file: http://bugs.python.org/file35108/random_closehandle.patch

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

From report at bugs.python.org  Wed Apr 30 12:07:47 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Apr 2014 10:07:47 +0000
Subject: [New-bugs-announce] [issue21394] Lib/random.py: use more efficient
	code to convert bytes	to integer
Message-ID: <1398852467.62.0.62846026727.issue21394@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Lib/random.py, I see lines like that:

   long(_hexlify(_urandom(32)), 16)

I guess that something more efficient can be fonud to convert a bytes string to an integer.

bytes.from_bytes() maybe?

----------
keywords: easy
messages: 217595
nosy: haypo
priority: normal
severity: normal
status: open
title: Lib/random.py: use more efficient code to convert bytes to integer
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 30 12:18:47 2014
From: report at bugs.python.org (Brian Gesiak)
Date: Wed, 30 Apr 2014 10:18:47 +0000
Subject: [New-bugs-announce] [issue21395] runtests.rst: link "build Python"
	to setup.rst#compiling
Message-ID: <1398853127.11.0.29558653351.issue21395@psf.upfronthosting.co.za>


New submission from Brian Gesiak:

runtests.rst insists that readers must build Python before
running the tests. For those readers that have not yet
built Python, add a link to more information on how to do so.

----------
components: Devguide
files: runtests.rst.patch
hgrepos: 243
keywords: patch
messages: 217598
nosy: ezio.melotti, modocache
priority: normal
severity: normal
status: open
title: runtests.rst: link "build Python" to setup.rst#compiling
type: enhancement
Added file: http://bugs.python.org/file35110/runtests.rst.patch

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

From report at bugs.python.org  Wed Apr 30 12:36:57 2014
From: report at bugs.python.org (akira)
Date: Wed, 30 Apr 2014 10:36:57 +0000
Subject: [New-bugs-announce] [issue21396] Python io implementation doesn't
	flush with	write_through=True unlike C implementation
Message-ID: <1398854217.51.0.158914324658.issue21396@psf.upfronthosting.co.za>


New submission from akira:

related: msg217596 (bufsize=1 is broken if subprocess module uses Python io)

TextIOWrapper.write behavior:

_pyio.py [1]:

        if self._line_buffering and (haslf or "\r" in s):
            self.flush()

textio.c [2]:

    if (self->write_through)
        needflush = 1;
    else if (self->line_buffering &&
        (haslf ||
         PyUnicode_FindChar(text, '\r', 0, PyUnicode_GET_LENGTH(text), 1) != -1))
        needflush = 1;

C implementation calls flush() if write_through=True, Python implementation doesn't.

[1]: http://hg.python.org/cpython/file/0b2e199ad088/Lib/_pyio.py#l1636
[2]: http://hg.python.org/cpython/file/0b2e199ad088/Modules/_io/textio.c#l1333

----------
components: IO
messages: 217600
nosy: akira
priority: normal
severity: normal
status: open
title: Python io implementation doesn't flush with write_through=True unlike C implementation
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 30 12:47:51 2014
From: report at bugs.python.org (Brian Gesiak)
Date: Wed, 30 Apr 2014 10:47:51 +0000
Subject: [New-bugs-announce] [issue21397] tempfile.py: Fix grammar in
	docstring, comment typos
Message-ID: <1398854871.81.0.354739462705.issue21397@psf.upfronthosting.co.za>


New submission from Brian Gesiak:

Commit 1: tempfile.py: Fix grammar in docstring
Meaning of "just below" in docstring is unclear; it could mean either
"the interfaces listed immediately below this docstring", or "only
the interfaces listed as safe below". Fix wording to take on the
latter meaning.

Commit 2: tempfile.py: Fix typo in comment: s/hget/get/

---

This is my first patch to CPython, but hopefully not my last! Any and all feedback, such as on patch submission etiquette, is very much appreciated!

----------
components: Library (Lib)
files: tempfile.py.patch
hgrepos: 244
keywords: patch
messages: 217602
nosy: modocache
priority: normal
severity: normal
status: open
title: tempfile.py: Fix grammar in docstring, comment typos
versions: Python 3.5
Added file: http://bugs.python.org/file35111/tempfile.py.patch

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

From report at bugs.python.org  Wed Apr 30 13:33:21 2014
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Apr 2014 11:33:21 +0000
Subject: [New-bugs-announce] [issue21398] pydoc heapq leaves terminal in an
	unusable state
Message-ID: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za>


New submission from Stefan Krah:

$ ./python -m pydoc heapq

Traceback (most recent call last):
  File "/home/stefan/hg/cpython/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/stefan/hg/cpython/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 2615, in <module>
    cli()
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 2580, in cli
    help.help(arg)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1862, in help
    elif request: doc(request, 'Help on %s:', output=self._output)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1600, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1408, in pager
    pager(text)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1422, in <lambda>
    return lambda text: pipepager(text, os.environ['PAGER'])
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1449, in pipepager
    pipe.write(text)
UnicodeEncodeError: 'ascii' codec can't encode character '\xe7' in position 3574: ordinal not in range(128)

$ stty sane
$ locale      
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

----------
messages: 217604
nosy: skrah
priority: normal
severity: normal
status: open
title: pydoc heapq leaves terminal in an unusable state
versions: Python 3.5

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

From report at bugs.python.org  Wed Apr 30 14:22:03 2014
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 30 Apr 2014 12:22:03 +0000
Subject: [New-bugs-announce] [issue21399] inspect and class methods
Message-ID: <1398860523.15.0.277604564567.issue21399@psf.upfronthosting.co.za>


New submission from Stefan Krah:

In Python2.7, the cls parameter shows up in pydoc:

    frombuf(cls, buf) from __builtin__.type
        Construct a TarInfo object from a 512 byte string buffer.


In 3.5, it doesn't:

    frombuf(buf, encoding, errors) from builtins.type
        Construct a TarInfo object from a 512 byte bytes object.



inspect.signature shows 'self', but not 'cls':

>>> from tarfile import *
>>> from inspect import *
>>> signature(TarInfo.create_gnu_header)
<Signature at 0x7f50cf110cf0 "(self, info, encoding, errors)">
>>> signature(TarInfo.frombuf)
<Signature at 0x7f50cf11cc88 "(buf, encoding, errors)">


So my guess is that this is an oversight.  How about the C docstrings?
Can we get "$cls" for classmethods?

----------
messages: 217606
nosy: Yury.Selivanov, larry, skrah
priority: normal
severity: normal
status: open
title: inspect and class methods
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Apr 30 17:07:54 2014
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 30 Apr 2014 15:07:54 +0000
Subject: [New-bugs-announce] [issue21400] Code coverage documentation is
	out-of-date.
Message-ID: <1398870474.7.0.668295680228.issue21400@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

In the section "Increase Test Coverage" of the DevGuide : https://docs.python.org/devguide/_sources/coverage.txt

You can read this paragraph where there is a url for a website, but the website is out-of-date and don't reflect the right version of Python.

"""
Choosing what module you want to increase test coverage for can be done in a
couple of ways.
A third-party website at http://coverage.livinglogic.de/ provides an
overall view of how good coverage is for various modules (you will want to
focus on those in the ``Lib`` directory as those are the pure Python modules
from Python's stdlib, and thus easier to work with than the C extension
modules). But since this is a third-party site we cannot promise that it will
always be accessible or have useful information (i.e., be working properly).
"""


"""
Python code coverage
Generated at 2013-08-14 08:28:40

Last commit at 2013-08-14 03:34:49 by Raymond Hettinger

Changeset identification hash ac2f59a6637f0cc69c4a5541195ce752cf34952a

Local revision number 85168
"""

Two options, remove the link or update the site.

----------
messages: 217622
nosy: matrixise
priority: normal
severity: normal
status: open
title: Code coverage documentation is out-of-date.

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

From report at bugs.python.org  Wed Apr 30 20:00:16 2014
From: report at bugs.python.org (Joshua J Cogliati)
Date: Wed, 30 Apr 2014 18:00:16 +0000
Subject: [New-bugs-announce] [issue21401] python2 -3 does not warn about str
	to bytes conversions	and comparisons
Message-ID: <1398880816.89.0.350834147614.issue21401@psf.upfronthosting.co.za>


New submission from Joshua J Cogliati:

The -3 option should warn about str to bytes conversions and str to bytes comparisons:
For example in Python 3 the following happens:

python3
Python 3.3.2 <snip>
Type "help", "copyright", "credits" or "license" for more information.
>>> b"a" + "a"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't concat bytes to str
>>> b"a" == "a"
False
>>> 

But even python2 -3 does not warn about either of these uses:

python2 -3
Python 2.7.5 <snip>
Type "help", "copyright", "credits" or "license" for more information.
>>> b"a" + "a"
'aa'
>>> b"a" == "a"
True
>>> u"a" + "a"
u'aa'
>>> u"a" == "a"
True
>>> 

These two issues are some of the more significant problems I have in trying get python2 code working with python3, and if -3 does not warn about it this is harder to do.

----------
components: Unicode
messages: 217633
nosy: Joshua.J.Cogliati, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: python2 -3 does not warn about str to bytes conversions and comparisons
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 30 21:22:43 2014
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Wed, 30 Apr 2014 19:22:43 +0000
Subject: [New-bugs-announce] [issue21402] tkinter.ttk._val_or_dict assumes
	tkinter._default_root	exists
Message-ID: <1398885763.19.0.937315925175.issue21402@psf.upfronthosting.co.za>


New submission from Stephen Paul Chappell:

If a call is made to tkinter.NoDefaultRoot, then calls to tkinter.ttk._val_or_dict may fail. NoDefaultRoot ends with "del _default_root" (line 174) and removes the variable from the module's namespace. _val_or_dict can try to access this variable but assumes that it exists (line 319). If _default_root does not exist, the function will raise an AttributeError: 'module' object has no attribute '_default_root'.

----------
components: Library (Lib), Tkinter
messages: 217644
nosy: Zero
priority: normal
severity: normal
status: open
title: tkinter.ttk._val_or_dict assumes tkinter._default_root exists
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 30 22:58:00 2014
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 30 Apr 2014 20:58:00 +0000
Subject: [New-bugs-announce] [issue21403] cElementTree node creation with
	attributes is bugged
Message-ID: <1398891480.86.0.531348738543.issue21403@psf.upfronthosting.co.za>


New submission from Santoso Wijaya:

Observe:

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> root = ET.Element('root', attrib={'Name':'Root'})
>>> child = ET.SubElement(root, 'child', attrib={'Name':'Child'})
>>> ET.tostring(root)
'<root Name="Root"><child Name="Child" /></root>'


>>> import xml.etree.cElementTree as cET
>>> root = cET.Element('root', attrib={'Name':'Root'})
>>> child = cET.SubElement(root, 'child', attrib={'Name':'Child'})
>>> cET.tostring(root)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1126, in tostring
    ElementTree(element).write(file, encoding, method=method)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 820, in write
    serialize(write, self._root, encoding, qnames, namespaces)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 932, in _serialize_xml
    v = _escape_attrib(v, encoding)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1092, in _escape_attrib
    _raise_serialization_error(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1052, in _raise_serialization_error
    "cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize {'Name': 'Root'} (type dict)

----------
components: Library (Lib)
messages: 217652
nosy: santa4nt
priority: normal
severity: normal
status: open
title: cElementTree node creation with attributes is bugged
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 30 23:06:56 2014
From: report at bugs.python.org (Sworddragon)
Date: Wed, 30 Apr 2014 21:06:56 +0000
Subject: [New-bugs-announce] [issue21404] Compression level for
	tarfile/zipfile
Message-ID: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za>


New submission from Sworddragon:

The tarfile/zipfile libraries doesn't seem to provide a direct way to specify the compression level. I have now ported my code from subprocess to tarfile/zipfile to achieve platform independency but would be happy if I could also control the compression level. Or is there a special reason not to add this?

----------
components: Library (Lib)
messages: 217655
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Compression level for tarfile/zipfile
versions: Python 3.4

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