From report at bugs.python.org  Tue Mar  1 08:51:44 2016
From: report at bugs.python.org (Ben Knight)
Date: Tue, 01 Mar 2016 13:51:44 +0000
Subject: [New-bugs-announce] [issue26464] str.translate() unexpectedly
 duplicates untranslated characters
Message-ID: <1456840304.03.0.420145350869.issue26464@psf.upfronthosting.co.za>


New submission from Ben Knight:

Python 3.5.1 x86-64, Windows 10

I created a translation map that translated some characters to None and others to strings and found that in some cases str.translate() will duplicate one of the untranslated characters in the returned string.

How to reproduce:

table = str.maketrans({'a': None, 'b': 'cd'})
'axb'.translate(table)

Expected result:

'xcd'

Actual result:

'xxcd'

Mapping 'a' to '' instead of None will produce the desired effect.

----------
messages: 261049
nosy: ben.knight
priority: normal
severity: normal
status: open
title: str.translate() unexpectedly duplicates untranslated characters
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  1 09:26:13 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 01 Mar 2016 14:26:13 +0000
Subject: [New-bugs-announce] [issue26465] Upgrade OpenSSL shipped with
 python installers
Message-ID: <1456842373.05.0.727353806198.issue26465@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://openssl.org/news/secadv/20160301.txt

----------
keywords: security_issue
messages: 261052
nosy: alex, paul.moore, steve.dower, tim.golden, zach.ware
priority: critical
severity: normal
status: open
title: Upgrade OpenSSL shipped with python installers
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Mar  1 10:08:22 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 01 Mar 2016 15:08:22 +0000
Subject: [New-bugs-announce] [issue26466] cannot build python 2.7.11 on AIX
Message-ID: <1456844902.77.0.455974310535.issue26466@psf.upfronthosting.co.za>


New submission from Michael Felt:

Finally noticed the new release, unfortunately it fails to build.

All proceeds normally until...

tail .buildaix/make.out
ar rc libpython2.7.a Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/tokenizer.o
ar rc libpython2.7.a Objects/abstract.o Objects/boolobject.o Objects/bufferobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/cobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/intobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/object.o Objects/obmalloc.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/stringobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/weakrefobject.o Objects/unicodeobject.o Objects/unicodectype.o
ar rc libpython2.7.a Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/errors.o Python/frozen.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/random.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/dtoa.o Python/formatter_unicode.o Python/formatter_string.o Python/dynload_shlib.o   Python/thread.o
ar rc libpython2.7.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o 
ar rc libpython2.7.a Modules/threadmodule.o  Modules/signalmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/zipimport.o  Modules/symtablemodule.o  Modules/xxsubtype.o
ranlib libpython2.7.a
./Modules/makexp_aix Modules/python.exp . libpython2.7.a;  xlc  -Wl,-bE:Modules/python.exp -lld -o python \
                Modules/python.o \
                libpython2.7.a -ldl  -lpthread   -lm  
Makefile:485: recipe for target 'python' failed

more details...

michael at x071:[/data/prj/aixtools/python/python-2.7.11]make
./Modules/makexp_aix Modules/python.exp . libpython2.7.a;  xlc  -Wl,-bE:Modules/python.exp -lld -o python \
                Modules/python.o \
                libpython2.7.a -ldl  -lpthread   -lm  
ld: 0711-596 SEVERE ERROR: Object libpython2.7.a[ceval.o]
        An RLD for section 2 (.data) refers to symbol 0,
        but the storage class of the symbol is not C_EXT or C_HIDEXT.
ld: 0711-596 SEVERE ERROR: Object libpython2.7.a[ceval.o]
        An RLD for section 2 (.data) refers to symbol 0,
        but the storage class of the symbol is not C_EXT or C_HIDEXT.

This is, best guess, an error for 125 symbols...

michael at x071:[/data/prj/aixtools/python/python-2.7.11]nohup make | egrep "^ld" | wc -l

Obviously, if the ceval.o member is removed it cannot complete - BUT - I hope it provides sufficient info that someone may know what I should try next.

michael at x071:[/data/prj/aixtools/python/python-2.7.11]ar d libpython2.7.a ceval.o
michael at x071:[/data/prj/aixtools/python/python-2.7.11]make V=1
./Modules/makexp_aix Modules/python.exp . libpython2.7.a;  xlc  -Wl,-bE:Modules/python.exp -lld -o python \
                Modules/python.o \
                libpython2.7.a -ldl  -lpthread   -lm  
ld: 0711-317 ERROR: Undefined symbol: ._PyEval_SliceIndex
ld: 0711-317 ERROR: Undefined symbol: .PyEval_SaveThread
ld: 0711-317 ERROR: Undefined symbol: .PyEval_RestoreThread
ld: 0711-317 ERROR: Undefined symbol: _PyEval_SliceIndex
ld: 0711-317 ERROR: Undefined symbol: _Py_CheckRecursionLimit
ld: 0711-317 ERROR: Undefined symbol: ._Py_CheckRecursiveCall
ld: 0711-317 ERROR: Undefined symbol: .PyEval_GetFuncName
ld: 0711-317 ERROR: Undefined symbol: .PyEval_GetFuncDesc
ld: 0711-317 ERROR: Undefined symbol: .PyEval_CallObjectWithKeywords
ld: 0711-317 ERROR: Undefined symbol: .PyEval_GetRestricted
ld: 0711-317 ERROR: Undefined symbol: .PyEval_GetGlobals
ld: 0711-317 ERROR: Undefined symbol: _Py_Ticker
ld: 0711-317 ERROR: Undefined symbol: _Py_CheckInterval
ld: 0711-317 ERROR: Undefined symbol: PyEval_GetCallStats
ld: 0711-317 ERROR: Undefined symbol: .PyEval_ReleaseLock
ld: 0711-317 ERROR: Undefined symbol: .PyEval_InitThreads
ld: 0711-317 ERROR: Undefined symbol: .PyEval_AcquireThread
ld: 0711-317 ERROR: Undefined symbol: .PyEval_EvalCode
ld: 0711-317 ERROR: Undefined symbol: .PyEval_GetBuiltins
ld: 0711-317 ERROR: Undefined symbol: ._PyEval_CallTracing
ld: 0711-317 ERROR: Undefined symbol: .Py_GetRecursionLimit
ld: 0711-317 ERROR: Undefined symbol: .Py_SetRecursionLimit
ld: 0711-317 ERROR: Undefined symbol: .PyEval_SetProfile
ld: 0711-317 ERROR: Undefined symbol: .PyEval_SetTrace
ld: 0711-317 ERROR: Undefined symbol: .Py_FlushLine
ld: 0711-317 ERROR: Undefined symbol: .Py_AddPendingCall
ld: 0711-317 ERROR: Undefined symbol: .PyEval_ReInitThreads
ld: 0711-317 ERROR: Undefined symbol: .PyEval_GetFrame
ld: 0711-317 ERROR: Undefined symbol: .PyEval_EvalCodeEx
ld: 0711-317 ERROR: Undefined symbol: .PyEval_GetLocals
ld: 0711-317 ERROR: Undefined symbol: .PyEval_MergeCompilerFlags
ld: 0711-317 ERROR: Undefined symbol: .PyEval_EvalFrameEx
ld: 0711-317 ERROR: Undefined symbol: .Py_MakePendingCalls
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make: *** [python] Error 8

michael at x071:[/data/prj/aixtools/python/python-2.7.11]./Modules/makexp_aix Modules/ceval.exp . Python/ceval.o
michael at x071:[/data/prj/aixtools/python/python-2.7.11]more Modules/ceval.exp
#!.
*
* Generated automatically by makexp_aix  (Tue Mar  1 14:52:11 UTC 2016)
*
* Base Directory: /data/prj/aixtools/python/python-2.7.11
* Input File(s) : Python/ceval.o
*
* NOTE: lists _all_ global symbols defined in the above file(s).
*
PyEval_AcquireLock
PyEval_AcquireThread
PyEval_CallObjectWithKeywords
PyEval_EvalCode
PyEval_EvalCodeEx
PyEval_EvalFrame
PyEval_EvalFrameEx
PyEval_GetBuiltins
PyEval_GetCallStats
PyEval_GetFrame
PyEval_GetFuncDesc
PyEval_GetFuncName
PyEval_GetGlobals
PyEval_GetLocals
PyEval_GetRestricted
PyEval_InitThreads
PyEval_MergeCompilerFlags
PyEval_ReInitThreads
PyEval_ReleaseLock
PyEval_ReleaseThread
PyEval_RestoreThread
PyEval_SaveThread
PyEval_SetProfile
PyEval_SetTrace
PyEval_ThreadsInitialized
Py_AddPendingCall
Py_FlushLine
Py_GetRecursionLimit
Py_MakePendingCalls
Py_SetRecursionLimit
_PyEval_CallTracing
_PyEval_SliceIndex
_Py_CheckInterval
_Py_CheckRecursionLimit
_Py_CheckRecursiveCall
_Py_Ticker


FYI: this may be related to an issue with the assembler not doing the right thing after the changes between. HOWEVER, besides an older AIX 5.3 system that might have had a bad 'as', I get the same error on AIX 6.1 TL5.

>From the APAR description - mine is fixed:
The broken assembler is distributed in all latest service packs of all - as of July 21st, 2011 - supported AIX versions: 
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ98134

So, while a bug is always a possibility - this OLD one is not likely.
michael at x071:[/data/prj/aixtools/python/python-2.7.11]oslevel -s
6100-09-04-1441

Instead, I am thinking that I will try being more specicif with the machine (processor) definition, e.g. power5 rather than common.

Suggestions welcome!

----------
components: Build
messages: 261053
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: cannot build python 2.7.11 on AIX
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  1 17:51:46 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Mar 2016 22:51:46 +0000
Subject: [New-bugs-announce] [issue26467] Add async magic method support to
 unittest.mock.Mock
Message-ID: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Mock doesn't support stuff like __aexit__ which means you can't mock out something like an async context manager.

----------
components: Library (Lib)
messages: 261092
nosy: brett.cannon, michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: Add async magic method support to unittest.mock.Mock
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar  2 04:21:59 2016
From: report at bugs.python.org (=?utf-8?q?Vojt=C4=9Bch_Pachol?=)
Date: Wed, 02 Mar 2016 09:21:59 +0000
Subject: [New-bugs-announce] [issue26468] shutil.copy2 raises OSError if
 filesystem doesn't support chmod
Message-ID: <1456910519.95.0.44073308632.issue26468@psf.upfronthosting.co.za>


New submission from Vojt?ch Pachol:

`copy2` checks if `os` nodule has `chmod` and then it uses it without thinking. 

On filesystems that doesn't support `chmod` it ends with

    OSError: [Errno 95] Operation not supported: <filename>

which is not acceptable since documentation says "copy2() never returns failure".

----------
components: Library (Lib)
messages: 261100
nosy: Vojt?ch Pachol
priority: normal
severity: normal
status: open
title: shutil.copy2 raises OSError if filesystem doesn't support chmod
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar  2 04:40:40 2016
From: report at bugs.python.org (Michael Jacob)
Date: Wed, 02 Mar 2016 09:40:40 +0000
Subject: [New-bugs-announce] [issue26469] Bug in ConfigParser when setting
 new values in extended interpolation
Message-ID: <1456911640.56.0.456152786125.issue26469@psf.upfronthosting.co.za>


New submission from Michael Jacob:

There seems to be a bug in configparser when setting new values in extended interpolation:

python --version
Python 3.5.1

from configparser import ConfigParser, ExtendedInterpolation
c=ConfigParser(interpolation=ExtendedInterpolation)
c.add_section('test')
c.set('test', 'key', 'value')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/configparser.py", line 1190, in set
    super().set(section, option, value)
  File "/usr/lib/python3.5/configparser.py", line 891, in set
    value)
TypeError: before_set() missing 1 required positional argument: 'value'

It works ithout extended interpolation, though.

----------
components: Library (Lib)
messages: 261101
nosy: Michael Jacob
priority: normal
severity: normal
status: open
title: Bug in ConfigParser when setting new values in extended interpolation
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar  2 07:14:53 2016
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 02 Mar 2016 12:14:53 +0000
Subject: [New-bugs-announce] [issue26470] Make OpenSSL module compatible
 with OpenSSL 1.1.0
Message-ID: <1456920893.87.0.933592382559.issue26470@psf.upfronthosting.co.za>


New submission from Christian Heimes:

OpenSSL 1.1.0 is changing a lot of internals. Most structs are opaque, RC4 and SSLv2 are gone. I've a rough patch in my private repos. I'll submit the patch as soon as the code is compatible with OpenSSL 1.0.2, too.

https://github.com/python/cpython/compare/master...tiran:feature/openssl110

----------
assignee: christian.heimes
messages: 261108
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Make OpenSSL module compatible with OpenSSL 1.1.0
type: security
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Wed Mar  2 07:24:40 2016
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 02 Mar 2016 12:24:40 +0000
Subject: [New-bugs-announce] [issue26471] load_verify_locations(cadata)
 should load AUX ASN.1 to supported trusted certs
Message-ID: <1456921480.82.0.773236455463.issue26471@psf.upfronthosting.co.za>


New submission from Christian Heimes:

https://docs.python.org/2/library/ssl.html#ssl.SSLContext.load_verify_locations can load certs from a file, a directory or from memory. OpenSSL's loaders for cafile and capath load auxiliary data of trusted certs. The custom loader for cadata ignores AUX data because it uses PEM_read_bio_X509() instead of PEM_read_bio_X509_AUX().

With the recent fix of OpenSSL 1.0.2 https://github.com/openssl/openssl/commit/a3baa171053547488475709c7197592c66e427cf trusted certificates now work again. I propose to change cadata to load trust settings, too.

----------
assignee: christian.heimes
components: Extension Modules
messages: 261109
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: load_verify_locations(cadata) should load AUX ASN.1 to supported trusted certs
type: security
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Mar  2 08:22:54 2016
From: report at bugs.python.org (Tibichte)
Date: Wed, 02 Mar 2016 13:22:54 +0000
Subject: [New-bugs-announce] [issue26472] Infinite loop
Message-ID: <1456924974.81.0.368543659162.issue26472@psf.upfronthosting.co.za>


New submission from Tibichte:

The code below runs indefinitely:

with open(False) as f:
    for line in f:
        print(line)

----------
components: IO
messages: 261113
nosy: DarkMagus
priority: normal
severity: normal
status: open
title: Infinite loop
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar  2 13:25:08 2016
From: report at bugs.python.org (Slava)
Date: Wed, 02 Mar 2016 18:25:08 +0000
Subject: [New-bugs-announce] [issue26473] Python 3.5 not run
Message-ID: <1456943108.9.0.414596574581.issue26473@psf.upfronthosting.co.za>


New submission from Slava:

Python 3.5 not run on Windows Server 2003 (PE mode). Python 3.5 installer not work too.

----------
components: Windows
files: Clipboard01.jpg
messages: 261134
nosy: newillusion, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.5 not run
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42064/Clipboard01.jpg

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

From report at bugs.python.org  Wed Mar  2 16:59:56 2016
From: report at bugs.python.org (John Snow)
Date: Wed, 02 Mar 2016 21:59:56 +0000
Subject: [New-bugs-announce] [issue26474] Memory leak at malloc_closure.c
Message-ID: <1456955996.67.0.137119059365.issue26474@psf.upfronthosting.co.za>


New submission from John Snow:

malloc_closere.c holds a static list of items: free_list.
The items are being allocated in the more_core method using VirtualAlloc / mmap. However they never get released.

Here is the allocation code:

#ifdef MS_WIN32
    item = (ITEM *)VirtualAlloc(NULL,
                                           count * sizeof(ITEM),
                                           MEM_COMMIT,
                                           PAGE_EXECUTE_READWRITE);
    if (item == NULL)
        return;
#else
    item = (ITEM *)mmap(NULL,
                        count * sizeof(ITEM),
                        PROT_READ | PROT_WRITE | PROT_EXEC,
                        MAP_PRIVATE | MAP_ANONYMOUS,
                        -1,
                        0);
    if (item == (void *)MAP_FAILED)
        return;
#endif

----------
components: ctypes
messages: 261138
nosy: John_Snow
priority: normal
severity: normal
status: open
title: Memory leak at malloc_closure.c
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar  3 03:19:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Mar 2016 08:19:16 +0000
Subject: [New-bugs-announce] [issue26475] Misleading debugging output for
 verbose regular expressions
Message-ID: <1456993156.69.0.718662373051.issue26475@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When the verbose mode is switched on by using the inline (?x) flag instead of re.VERBOSE argument, the debugging output is duplicated: once for non-verbose mode and then for verbose mode.

>>> import re
>>> re.compile(r' (?x)a', re.DEBUG)
LITERAL 32
LITERAL 97
LITERAL 97
re.compile(' (?x)a', re.VERBOSE|re.DEBUG)

Proposed patch makes the parser to produce only final output for verbose mode.

>>> re.compile(r' (?x)a', re.DEBUG)
LITERAL 97
re.compile(' (?x)a', re.VERBOSE|re.DEBUG)

----------
assignee: serhiy.storchaka
components: Regular Expressions
files: re_verbose_debug.patch
keywords: patch
messages: 261148
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Misleading debugging output for verbose regular expressions
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42066/re_verbose_debug.patch

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

From report at bugs.python.org  Thu Mar  3 05:25:31 2016
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 03 Mar 2016 10:25:31 +0000
Subject: [New-bugs-announce] [issue26476] Constness in _PyErr_BadInternalCall
Message-ID: <1457000731.8.0.704951982949.issue26476@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer:

PyErr_BadInternalCall() calls _PyErr_BadInternalCall(__FILE__, __LINE__). Since __FILE__ is a string constant, the first argument of _PyErr_BadInternalCall should be a "const char*" instead of a "char*".

This is a follow-up to #4949. Most of the patch from #4949 was applied, but not the change to _PyErr_BadInternalCall on Python 2.

----------
components: Interpreter Core
files: PyErr_BadInternalCall_const.patch
keywords: patch
messages: 261156
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: Constness in _PyErr_BadInternalCall
versions: Python 2.7
Added file: http://bugs.python.org/file42068/PyErr_BadInternalCall_const.patch

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

From report at bugs.python.org  Thu Mar  3 13:07:47 2016
From: report at bugs.python.org (Martijn Pieters)
Date: Thu, 03 Mar 2016 18:07:47 +0000
Subject: [New-bugs-announce] [issue26477] typing forward references and
 module attributes
Message-ID: <1457028467.36.0.208660584048.issue26477@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

Forward references to a module can fail, if the module doesn't yet have the required object. The "forward references" section names circular dependencies as one use for forward references, but the following example fails:

$ cat test/__init__.py
from .a import A
from .b import B
$ cat test/a.py
import typing
from . import b

class A:
    def foo(self: 'A', bar: typing.Union['b.B', None]):
        pass
$ cat test/b.py
import typing
from . import a

class B:
    def spam(self: 'B', eggs: typing.Union['a.A', None]):
        pass
$  bin/python -c 'import test'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/mjpieters/Development/venvs/stackoverflow-3.5/test/__init__.py", line 1, in <module>
    from .a import A
  File "/Users/mjpieters/Development/venvs/stackoverflow-3.5/test/a.py", line 2, in <module>
    from . import b
  File "/Users/mjpieters/Development/venvs/stackoverflow-3.5/test/b.py", line 4, in <module>
    class B:
  File "/Users/mjpieters/Development/venvs/stackoverflow-3.5/test/b.py", line 5, in B
    def spam(self: 'B', eggs: typing.Union['a.A', None]):
  File "/Users/mjpieters/Development/Library/buildout.python/parts/opt/lib/python3.5/typing.py", line 537, in __getitem__
    dict(self.__dict__), parameters, _root=True)
  File "/Users/mjpieters/Development/Library/buildout.python/parts/opt/lib/python3.5/typing.py", line 494, in __new__
    for t2 in all_params - {t1} if not isinstance(t2, TypeVar)):
  File "/Users/mjpieters/Development/Library/buildout.python/parts/opt/lib/python3.5/typing.py", line 494, in <genexpr>
    for t2 in all_params - {t1} if not isinstance(t2, TypeVar)):
  File "/Users/mjpieters/Development/Library/buildout.python/parts/opt/lib/python3.5/typing.py", line 185, in __subclasscheck__
    self._eval_type(globalns, localns)
  File "/Users/mjpieters/Development/Library/buildout.python/parts/opt/lib/python3.5/typing.py", line 172, in _eval_type
    eval(self.__forward_code__, globalns, localns),
  File "<string>", line 1, in <module>
AttributeError: module 'test.a' has no attribute 'A'

The forward reference test fails because only NameError exceptions are caught, not AttributeError exceptions.

----------
components: Library (Lib)
messages: 261172
nosy: mjpieters
priority: normal
severity: normal
status: open
title: typing forward references and module attributes
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar  3 18:20:42 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 03 Mar 2016 23:20:42 +0000
Subject: [New-bugs-announce] [issue26478] dict views don't implement
 subtraction correctly
Message-ID: <1457047242.91.0.370937418553.issue26478@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Don't know when the problem was introduced, but dictviews_sub is doing:

    tmp = _PyObject_CallMethodId(result, &PyId_difference_update, "O", other);

to implement subtraction (after creating result as a set of the keys in question). That's violating the CallMethod contract though (which states the format string should produce a tuple), and while it looks like CallMethod does fixups when the contract is violated, this creates some very odd behaviors.

With a list, everything is fine:

    >>> d = {0: 'zero', 1: 'one', 2: 'two', 3: 'three'}
    >>> d.keys() - [0, 2]
    {1, 3}
    >>> d.keys() - (0, 2)
    TypeError: 'int' object is not iterable

Basically, the fix up doesn't get applied when you subtract a tuple, so it's as if it's trying to call:

    result.difference_update(*(0, 2))  # Unpacking used to illustrate, effect is  result.difference_update(0, 2)

With the list, it's wrapping to make a one element tuple, so it behaves like:

    result.difference_update(*([0, 2],))  # Unpacking used to illustrate, effect is  result.difference_update([0, 2])

For more details, see http://stackoverflow.com/q/35784258/364696

Fix should be to change call line to:

    tmp = _PyObject_CallMethodObjArgsId(result, &PyId_difference_update, other, NULL);

(assuming _PyObject_CallMethodObjArgsId is a thing), or if it's not a thing, to fix the format string to force tuple wrapping:

    tmp = _PyObject_CallMethodId(result, &PyId_difference_update, "(O)", other);

----------
messages: 261180
nosy: josh.r
priority: normal
severity: normal
status: open
title: dict views don't implement subtraction correctly
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar  4 08:14:18 2016
From: report at bugs.python.org (Samuel Colvin)
Date: Fri, 04 Mar 2016 13:14:18 +0000
Subject: [New-bugs-announce] [issue26479] Init documentation typo "may be
 return" > "may NOT be returned"
Message-ID: <1457097258.8.0.064409213234.issue26479@psf.upfronthosting.co.za>


New submission from Samuel Colvin:

https://docs.python.org/3/reference/datamodel.html#object.__init__

"no non-None value may be returned by __init__();" should read "no non-None value may *not* be returned by __init__();"

----------
assignee: docs at python
components: Documentation
messages: 261185
nosy: Samuel Colvin, docs at python
priority: normal
severity: normal
status: open
title: Init documentation typo "may be return" > "may NOT be returned"
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar  4 11:46:13 2016
From: report at bugs.python.org (yuriy_levchenko)
Date: Fri, 04 Mar 2016 16:46:13 +0000
Subject: [New-bugs-announce] [issue26480] add a flag that will not give the
 set a sys.stdin
Message-ID: <1457109973.75.0.047131092344.issue26480@psf.upfronthosting.co.za>


New submission from yuriy_levchenko:

i have Fatal Error 

"Py_Initialize: can't initialize sys standard streams"

because fail to create

fd = fileno(stdin);

std = create_stdio(iomod, fd, 0, "<stdin>", encoding, errors);

I do not need to create this input|output

if i comment this code, and setup 

__stdin__= None
__stdout__= None
__stderr__= None

all workin fine

----------
messages: 261191
nosy: yuriy_levchenko
priority: normal
severity: normal
status: open
title: add a flag that will not give the set a sys.stdin
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar  4 12:09:32 2016
From: report at bugs.python.org (Stefan Seefeld)
Date: Fri, 04 Mar 2016 17:09:32 +0000
Subject: [New-bugs-announce] [issue26481] unittest discovery process not
 working without .py source files
Message-ID: <1457111372.53.0.54879325378.issue26481@psf.upfronthosting.co.za>


New submission from Stefan Seefeld:

The unittest test discovery right now only looks into sub-packages if they contain a `__init__.py` file. That's an unnecessary requirement, as packages are also importable if only `__init__.pyc` is present.

----------
components: Library (Lib)
messages: 261192
nosy: stefan
priority: normal
severity: normal
status: open
title: unittest discovery process not working without .py source files

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

From report at bugs.python.org  Fri Mar  4 13:40:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Mar 2016 18:40:44 +0000
Subject: [New-bugs-announce] [issue26482] Restore pickling recursive dequeues
Message-ID: <1457116844.37.0.00274743770094.issue26482@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Pickling recursive dequeues was added in issue1062279. But then it was reverted in 73f49656420b (unknown issue number).

Proposed patch restores pickling recursive dequeues.

----------
assignee: rhettinger
components: Library (Lib)
files: pickle_recursive_deque.patch
keywords: patch
messages: 261194
nosy: alexandre.vassalotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Restore pickling recursive dequeues
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42069/pickle_recursive_deque.patch

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

From report at bugs.python.org  Fri Mar  4 15:04:57 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 04 Mar 2016 20:04:57 +0000
Subject: [New-bugs-announce] [issue26483] docs unclear on difference between
 isdigt() and isdecimal()
Message-ID: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>


New submission from Ethan Furman:

The docs use different explanations for what constitutes a decimal verses a digit character; consequently I can't tell if they are the same or different, and if different what the differences are.

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

https://docs.python.org/3/library/stdtypes.html?#str.isdecimal

Return true if all characters in the string are decimal characters and there is at least one character, false otherwise. Decimal characters are those from general category ?Nd?. This category includes digit characters, and all characters that can be used to form decimal-radix numbers, e.g. U+0660, ARABIC-INDIC DIGIT ZERO.

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

https://docs.python.org/3/library/stdtypes.html?#str.isdigit

Return true if all characters in the string are digits and there is at least one character, false otherwise. Digits include decimal characters and digits that need special handling, such as the compatibility superscript digits. Formally, a digit is a character that has the property value Numeric_Type=Digit or Numeric_Type=Decimal.

----------
messages: 261195
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: docs unclear on difference between isdigt() and isdecimal()
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar  4 18:59:01 2016
From: report at bugs.python.org (Julien)
Date: Fri, 04 Mar 2016 23:59:01 +0000
Subject: [New-bugs-announce] [issue26484] Broken table in
 /2.7/library/sets.html#set-objects
Message-ID: <1457135941.69.0.584697860353.issue26484@psf.upfronthosting.co.za>


New submission from Julien:

Hi,

Since: https://github.com/python/cpython/commit/5fdcdab5794d18adc4c66abdce8639440433ed24#diff-c191394dee92fb4800d40d9a8ba431ee

the table is broken (...Doc/library/sets.rst:76: ERROR: Malformed table.                                                                                                       ) so it is no longer displayed here: https://docs.python.org/2.7/library/sets.html#set-objects

Bests

----------
assignee: docs at python
components: Documentation
messages: 261202
nosy: docs at python, gregory.p.smith, sizeof
priority: normal
severity: normal
status: open
title: Broken table in /2.7/library/sets.html#set-objects
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar  4 19:14:52 2016
From: report at bugs.python.org (Julien)
Date: Sat, 05 Mar 2016 00:14:52 +0000
Subject: [New-bugs-announce] [issue26485] Missing newline, raising a warning,
 in /Doc/license.rst
Message-ID: <1457136892.69.0.383889491062.issue26485@psf.upfronthosting.co.za>


New submission from Julien:

o/

While fixing sphinx-doc warnings, I found this missing newline.

Yet the documentation is still correctly rendered.

----------
assignee: docs at python
components: Documentation
files: missing_newline_in_licence.rst
messages: 261204
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Missing newline, raising a warning, in /Doc/license.rst
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file42070/missing_newline_in_licence.rst

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

From report at bugs.python.org  Sat Mar  5 03:41:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Mar 2016 08:41:19 +0000
Subject: [New-bugs-announce] [issue26486] Backport some tests to 2.7
Message-ID: <1457167279.6.0.631210847326.issue26486@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch backports some tests that makes sense for 2.7 from 3.x. This adds more assurance that we will not break anything in 2.7 bug fix and didn't break the compatibility unintentionally.

----------
components: Tests
files: pickletests_backport.patch
keywords: patch
messages: 261209
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Backport some tests to 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file42071/pickletests_backport.patch

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

From report at bugs.python.org  Sat Mar  5 14:03:29 2016
From: report at bugs.python.org (hanz)
Date: Sat, 05 Mar 2016 19:03:29 +0000
Subject: [New-bugs-announce] [issue26487] Machine value for fat PowerPC build
Message-ID: <1457204609.38.0.708821287838.issue26487@psf.upfronthosting.co.za>


New submission from hanz:

Building on Mac OS X 10.5.8 (Power Mac G5) for ppc and ppc64 fails with

  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_python27/python27/work/Python-2.7.11/Lib/_osx_support.py", line 485, in get_platform_osx
    "Don't know machine value for archs=%r" % (archs,))
ValueError: Don't know machine value for archs=('ppc', 'ppc64')
generate-posix-vars failed
make: *** [pybuilddir.txt] Error 1


If I apply the attached patch, it builds and works fine.
Would it be possible to include these changes in Python?

----------
components: Build, Distutils, Macintosh
files: patch-plat-ppc-fat.diff
keywords: patch
messages: 261220
nosy: dstufft, eric.araujo, hanz, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Machine value for fat PowerPC build
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file42073/patch-plat-ppc-fat.diff

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

From report at bugs.python.org  Sat Mar  5 16:54:26 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 05 Mar 2016 21:54:26 +0000
Subject: [New-bugs-announce] [issue26488] hashlib command line interface
Message-ID: <1457214866.19.0.989950954277.issue26488@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

I am suggesting to add a command line interface to the hashlib module. A simple example of the api I suggest is:
$ python -m hashlib md5 /bin/sh
$ d985d0ea551c1253c2305140c583d11f

A patch is included.

----------
components: Library (Lib)
files: hashlib-script-mod.patch
keywords: patch
messages: 261225
nosy: christian.heimes, gregory.p.smith, palaviv
priority: normal
severity: normal
status: open
title: hashlib command line interface
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42074/hashlib-script-mod.patch

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

From report at bugs.python.org  Sat Mar  5 17:00:40 2016
From: report at bugs.python.org (Guo Ci Teo)
Date: Sat, 05 Mar 2016 22:00:40 +0000
Subject: [New-bugs-announce] [issue26489] dictionary unpacking operator in
 dict expression
Message-ID: <1457215240.85.0.6201995069.issue26489@psf.upfronthosting.co.za>


New submission from Guo Ci Teo:

The attached patch enables the unparse.py tool to unparse dictionary unpacking operators (**) in a dict expression, for example,

{**{'y': 2}, 'x': 1}

, as described in PEP 0448.

----------
components: Demos and Tools
files: unpack_in_dict.patch
keywords: patch
messages: 261226
nosy: guoci
priority: normal
severity: normal
status: open
title: dictionary unpacking operator in dict expression
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42075/unpack_in_dict.patch

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

From report at bugs.python.org  Sat Mar  5 18:58:36 2016
From: report at bugs.python.org (Ben Finney)
Date: Sat, 05 Mar 2016 23:58:36 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue26490=5D_Leading_=E2=80=9C0?=
 =?utf-8?q?=E2=80=9D_allowed=2C_only_for_decimal_zero?=
Message-ID: <1457222316.54.0.23701049885.issue26490@psf.upfronthosting.co.za>


New submission from Ben Finney:

The language reference carves out a special case for decimal zero literals: they may have leading ?0? digits. Non-zero decimal literals may not. This is apparently deliberate:

    Note that leading zeros in a non-zero decimal number are not allowed. This is for disambiguation with C-style octal literals, which Python used before version 3.0.

    reference/lexical_analysis.html#integer-literals

But the expressed rationale (?for disambiguation with C-style octal literals?) does not explain making decimal zero special compared with non-zero.

Is there a good reason for this inconsistency::

    0000    # valid syntax for zero literal
    0003    # SyntaxError
    0123    # SyntaxError

To my reading, they should all cause SyntaxError. What is the rationale for the special case of the first one?

----------
components: Interpreter Core
messages: 261227
nosy: bignose
priority: normal
severity: normal
status: open
title: Leading ?0? allowed, only for decimal zero
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Mar  6 05:23:02 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Mar 2016 10:23:02 +0000
Subject: [New-bugs-announce] [issue26491] Defer DECREFs until enum object is
 in a consistent state for re-entrancy
Message-ID: <1457259782.6.0.6533551123.issue26491@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: serhiy.storchaka
components: Interpreter Core
files: enumerate_defer_decref.diff
keywords: patch
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Defer DECREFs until enum object is in a consistent state for re-entrancy
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42076/enumerate_defer_decref.diff

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

From report at bugs.python.org  Sun Mar  6 11:04:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Mar 2016 16:04:40 +0000
Subject: [New-bugs-announce] [issue26492] Exhausted array iterator should
 left exhausted
Message-ID: <1457280280.79.0.892048425987.issue26492@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is general rule that after raising StopIteration the iterator should always raise StopIteration even if new data is added to iterating sequence. Array iterators don't obey this rule.

Proposed patch makes array iterator to left in exhausted state since it achieved. As a side (or may be primary) effect of this change, iterating sequence can be freed just after iterating is finished.

Added tests for other iterators of resizable sequences.

I don't know whether this patch should be applied to maintained releases or only to default branch. Note that array pickling tests broken by this patch were just added. They just expose current (presumably incorrect) behavior.

----------
assignee: rhettinger
components: Extension Modules
files: exhausted_array_iterator.patch
keywords: patch
messages: 261260
nosy: benjamin.peterson, larry, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Exhausted array iterator should left exhausted
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42079/exhausted_array_iterator.patch

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

From report at bugs.python.org  Sun Mar  6 11:56:29 2016
From: report at bugs.python.org (=?utf-8?b?UmHDumwgTsO6w7FleiBkZSBBcmVuYXM=?=)
Date: Sun, 06 Mar 2016 16:56:29 +0000
Subject: [New-bugs-announce] [issue26493] Bad formatting in WinError 193
 when using subprocess.check_call
Message-ID: <1457283389.71.0.286389844503.issue26493@psf.upfronthosting.co.za>


New submission from Ra?l N??ez de Arenas:

Python 3.5.1 x64 @ Windows 10 x64

The error message in the traceback for OSError/WinError 193 has bad formatting and the offending file name is not printed.

For example, this code:
----
import subprocess

testfile = open('testfile.notexecutable', 'wb')
testfile.close()
subprocess.check_call(['testfile.notexecutable'])
----

produces this output:
----
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    subprocess.check_call(['testfile.notexecutable'])
  File "C:\Program Files\Python35\lib\subprocess.py", line 579, in check_call
    retcode = call(*popenargs, **kwargs)
  File "C:\Program Files\Python35\lib\subprocess.py", line 560, in call
    with Popen(*popenargs, **kwargs) as p:
  File "C:\Program Files\Python35\lib\subprocess.py", line 950, in __init__
    restore_signals, start_new_session)
  File "C:\Program Files\Python35\lib\subprocess.py", line 1220, in _execute_child
    startupinfo)
OSError: [WinError 193] %1 is not a valid Win32 application
----

Please note the "%1 is not a valid..." on the last line. Instead of the "%1" placeholder, the filename ("testfile.notexecutable") should appear instead.

Thanks :)

----------
messages: 261262
nosy: Ra?l N??ez de Arenas
priority: normal
severity: normal
status: open
title: Bad formatting in WinError 193 when using subprocess.check_call
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar  6 13:26:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Mar 2016 18:26:04 +0000
Subject: [New-bugs-announce] [issue26494] Double deallocation on iterator
 exhausting
Message-ID: <1457288764.94.0.168287313304.issue26494@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Following example causes double deallocation of a sequence and crashing.

class A(list):
    def __del__(self):
        next(it)

it = iter(A())
next(it)

The same is for subclass of tuple, str, bytes and bytearray.

Proposed patch fixes this issue.

----------
components: Interpreter Core
files: free_after_iterating.patch
keywords: patch
messages: 261263
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Double deallocation on iterator exhausting
type: crash
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42080/free_after_iterating.patch

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

From report at bugs.python.org  Sun Mar  6 13:47:20 2016
From: report at bugs.python.org (Antti Haapala)
Date: Sun, 06 Mar 2016 18:47:20 +0000
Subject: [New-bugs-announce] [issue26495] super() does not work nested
Message-ID: <1457290040.33.0.0538313246288.issue26495@psf.upfronthosting.co.za>


New submission from Antti Haapala:

super() without arguments is

----------
messages: 261264
nosy: ztane
priority: normal
severity: normal
status: open
title: super() does not work nested

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

From report at bugs.python.org  Sun Mar  6 13:53:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Mar 2016 18:53:27 +0000
Subject: [New-bugs-announce] [issue26496] Exhausted dequeue iterator should
 free a reference to a deque
Message-ID: <1457290407.19.0.35859236491.issue26496@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It is common that exhausted iterator frees a reference to iterating sequence. All builtin sequences (list, tuple, str, bytes, bytearray), set and dict support this. It would be nice if dequeue will support this too.

----------
components: Extension Modules
messages: 261265
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Exhausted dequeue iterator should free a reference to a deque
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Mar  6 17:58:26 2016
From: report at bugs.python.org (Alessandro Molina)
Date: Sun, 06 Mar 2016 22:58:26 +0000
Subject: [New-bugs-announce] [issue26497] Documentation - HOWTO Use Python
 in the web paragraph on TurboGears still mentions it's based on Pylons
Message-ID: <1457305106.46.0.783108408481.issue26497@psf.upfronthosting.co.za>


New submission from Alessandro Molina:

https://docs.python.org/3.6/howto/webservers.html#turbogears still mentions "TurboGears 2 is based on the WSGI stack of another popular component-based web framework, Pylons." which is not true anymore since TurboGears 2.3.0.

TurboGears switched to its own micro-framework core since version 2.3.0 as Pylons wasn't Python3 compatible.

Also The TGBook is still mentioned even though it's 10 years old and not reliable anymore since TurboGears 1.0

----------
assignee: docs at python
components: Documentation
messages: 261274
nosy: Alessandro Molina, docs at python
priority: normal
severity: normal
status: open
title: Documentation - HOWTO Use Python in the web paragraph on TurboGears still mentions it's based on Pylons
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Mar  7 00:30:41 2016
From: report at bugs.python.org (Larry)
Date: Mon, 07 Mar 2016 05:30:41 +0000
Subject: [New-bugs-announce] [issue26498] _io.so flat namespace
Message-ID: <1457328641.48.0.673687775956.issue26498@psf.upfronthosting.co.za>


New submission from Larry:

On OSX El Capitan, Python v2.7.10 and 2.7.11 (standard installer)...

When importing urllib2 it crashes with a flat namespace error then loading _io.so.  Shortest test case: "python -c 'import urllib2'"

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 94, in <module>
    import httplib
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 80, in <module>
    import mimetools
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/mimetools.py", line 6, in <module>
    import tempfile
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tempfile.py", line 32, in <module>
    import io as _io
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
    import _io
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
  Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
  Expected in: flat namespace
 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so

This error occurs under both v2.7.10 and v2.7.11.  When I regress to 2.7.9 and all is well.

----------
components: IO, Library (Lib)
messages: 261278
nosy: bugbee
priority: normal
severity: normal
status: open
title: _io.so flat namespace
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  7 05:10:53 2016
From: report at bugs.python.org (Peter)
Date: Mon, 07 Mar 2016 10:10:53 +0000
Subject: [New-bugs-announce] [issue26499] http.client.IncompleteRead from
 HTTPResponse read after part reading file
Message-ID: <1457345453.59.0.0327827539319.issue26499@psf.upfronthosting.co.za>


New submission from Peter:

This is a regression in Python 3.5 tested under Linux and Mac OS X, spotted from a failing test in Biopython https://github.com/biopython/biopython/issues/773 where we would parse a file from the internet. The trigger is partially reading the network handle line by line (e.g. until an end record marker is found), and then calling handle.read() to fetch any remaining data. Self contained examples below.

Note that partially reading a file like this still works:


$ python3.5
Python 3.5.0 (default, Sep 14 2015, 12:13:24) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> from urllib.request import urlopen
>>> handle = urlopen("http://www.python.org")
>>> chunk = handle.read(50)
>>> rest = handle.read()
>>> handle.close()


However, the following variants read a few lines and then attempt to call handle.read() and fail. The URL is not important (as long as it has over four lines in these examples).

Using readline,


>>> from urllib.request import urlopen
>>> handle = urlopen("http://www.python.org")
>>> for i in range(4):
...     line = handle.readline()
... 
>>> rest = handle.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/xxx/lib/python3.5/http/client.py", line 446, in read
    s = self._safe_read(self.length)
  File "/Users/xxx/lib/python3.5/http/client.py", line 594, in _safe_read
    raise IncompleteRead(b''.join(s), amt)
http.client.IncompleteRead: IncompleteRead(46698 bytes read, 259 more expected)


Using line iteration via next,


>>> from urllib.request import urlopen
>>> handle = urlopen("http://www.python.org")
>>> for i in range(4):
...      line = next(handle)
... 
>>> rest = handle.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/xxx/lib/python3.5/http/client.py", line 446, in read
    s = self._safe_read(self.length)
  File "/Users/xxx/lib/python3.5/http/client.py", line 594, in _safe_read
    raise IncompleteRead(b''.join(s), amt)
http.client.IncompleteRead: IncompleteRead(46698 bytes read, 259 more expected)


Using line iteration directly,


>>> from urllib.request import urlopen
>>> count = 0
>>> handle = urlopen("http://www.python.org")
>>> for line in handle:
...     count += 1
...     if count == 4:
...         break
... 
>>> rest = handle.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/xxx/lib/python3.5/http/client.py", line 446, in read
    s = self._safe_read(self.length)
  File "/Users/xxx/lib/python3.5/http/client.py", line 594, in _safe_read
    raise IncompleteRead(b''.join(s), amt)
http.client.IncompleteRead: IncompleteRead(46698 bytes read, 259 more expected)



These examples all worked on Python 3.3 and 3.4 so this is a regression.

----------
components: Library (Lib)
messages: 261287
nosy: maubp
priority: normal
severity: normal
status: open
title: http.client.IncompleteRead from HTTPResponse read after part reading file
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar  7 05:22:15 2016
From: report at bugs.python.org (Jaivish Kothari)
Date: Mon, 07 Mar 2016 10:22:15 +0000
Subject: [New-bugs-announce] [issue26500] Document of star operator missing.
 It must be documented for better understanding.
Message-ID: <1457346135.37.0.589425731268.issue26500@psf.upfronthosting.co.za>


New submission from Jaivish Kothari:

Star operator in python for unpacking could be documented for better understanding.

----------
assignee: docs at python
components: Documentation
messages: 261288
nosy: docs at python, janonymous
priority: normal
severity: normal
status: open
title: Document of star operator missing. It must be documented for better understanding.
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar  7 05:26:20 2016
From: report at bugs.python.org (Paul Moore)
Date: Mon, 07 Mar 2016 10:26:20 +0000
Subject: [New-bugs-announce] [issue26501] bytes splitlines() method returns
 strings without decoding
Message-ID: <1457346380.72.0.879606385641.issue26501@psf.upfronthosting.co.za>


New submission from Paul Moore:

See the following test (in Python 3.5):

>>> u'a\nb?'.encode('utf-8').splitlines()
['a', 'b\xc2\xa3']

I encode a string in UTF-8, then use the (bytes) splitlines function on it. The return value is a list of strings, containing encoded byte values.

The bytes object isn't even documented as having a splitlines method - and if it does, then it should be returning a list of bytes objects.

----------
components: Interpreter Core
messages: 261289
nosy: paul.moore
priority: normal
severity: normal
status: open
title: bytes splitlines() method returns strings without decoding
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Mar  7 06:15:48 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 07 Mar 2016 11:15:48 +0000
Subject: [New-bugs-announce] [issue26502] traceback.extract_tb breaks
 compatibility by returning FrameSummary
Message-ID: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

According to the docs [0], traceback.extract_tb should return 4-tuples (filename, line number, function name, text).

[0] https://docs.python.org/3/library/traceback.html#traceback.extract_tb

Instead, since Python 3.5, it returns FrameSummary objects, which are not tuples, nor tuple subclasses, nor even sequences. (This broke some code in the wild that called len() on FrameSummary.)

Issue 25111 pointed out another tuple incompatibility, which was fixed. Should __len__ be added as well? Or the whole Sequence ABC?

I can provide a patch when those questions are answered.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 261296
nosy: docs at python, encukou
priority: normal
severity: normal
status: open
title: traceback.extract_tb breaks compatibility by returning FrameSummary
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Mar  7 07:18:16 2016
From: report at bugs.python.org (Mohankumar)
Date: Mon, 07 Mar 2016 12:18:16 +0000
Subject: [New-bugs-announce] [issue26503] argparse with required field ,
 not having new line separator in -help dispaly
Message-ID: <1457353096.4.0.167120061283.issue26503@psf.upfronthosting.co.za>


New submission from Mohankumar:

We are using Python argsparse library here to display below --help message .
In --help option , new line option not handled correctly , Especially in "mandatory parameters" (required=True) better to place a new line before for better readability , Since it not having any separators like list brackets in "Non Mandatory parameters".

For example In below help , there must be a new line before "--protocol" and " --action" for better readability


Neutron firewall-rule-create [-h]
                                    [-f {html,json,json,shell,table,value,yaml,yaml}]
                                    [-c COLUMN] [--max-width <integer>]
                                    [--noindent] [--prefix PREFIX]
                                    [--request-format {json,xml}]
                                    [--tenant-id TENANT_ID] [--name NAME]
                                    [--description DESCRIPTION] [--shared]
                                    [--source-ip-address SOURCE_IP_ADDRESS]
                                    [--destination-ip-address DESTINATION_IP_ADDRESS]
                                    [--source-port SOURCE_PORT]
                                    [--destination-port DESTINATION_PORT]
                                    [--enabled {True,False}] --protocol
                                    {tcp,udp,icmp,any} --action
                                    {allow,deny,reject}

----------
components: Library (Lib)
messages: 261297
nosy: mohankumar
priority: normal
severity: normal
status: open
title: argparse with required field , not having new line separator in -help dispaly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  7 08:46:25 2016
From: report at bugs.python.org (Roger Mosher)
Date: Mon, 07 Mar 2016 13:46:25 +0000
Subject: [New-bugs-announce] [issue26504] tclErr: invalid command name
 "PyAggImagePhoto"
Message-ID: <1457358385.73.0.791027295001.issue26504@psf.upfronthosting.co.za>


New submission from Roger Mosher:

when trying to show a FigureCanvasTkAgg the program crashes.  Debugging eventually leads me to TkAgg.blit method where we find the following line:
        tk.call(
            "PyAggImagePhoto", photoimage,
            id(data), colormode, id(bbox_array))

which generates a TclError, namely that "PyAggImagePhoto" is an invalid command.  I am using tkinter 8.6

Full details at: 
http://stackoverflow.com/questions/35829961/using-matplotlib-with-tkinter-tkagg

----------
components: Tkinter
messages: 261300
nosy: r mosher
priority: normal
severity: normal
status: open
title: tclErr: invalid command name "PyAggImagePhoto"
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar  7 09:02:09 2016
From: report at bugs.python.org (Alex Willmer)
Date: Mon, 07 Mar 2016 14:02:09 +0000
Subject: [New-bugs-announce] [issue26505] [PATCH] Spelling of ANY in the
 license of Modules/getaddrinfo.c
Message-ID: <1457359329.6.0.772560988126.issue26505@psf.upfronthosting.co.za>


New submission from Alex Willmer:

The license of Modules/getaddrinfo.c misspells ANY as GAI_ANY. I'm assuming a sed invocation was the cause. The same file later uses GAI_ANY as a wildcard for socket type, protocol and port.

It looks like this mistake was present when the code was first committed.

----------
files: getaddrinfo-license-ANY.patch
keywords: patch
messages: 261301
nosy: Alex.Willmer
priority: normal
severity: normal
status: open
title: [PATCH] Spelling of ANY in the license of Modules/getaddrinfo.c
Added file: http://bugs.python.org/file42083/getaddrinfo-license-ANY.patch

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

From report at bugs.python.org  Mon Mar  7 12:47:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Mar 2016 17:47:03 +0000
Subject: [New-bugs-announce] [issue26506] hex() documentation: mention "%x"
 % int
Message-ID: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I regulary see Python code using hex(value)[2:], whereas "%x" % value does the same thing. We should mention "%x" % value in the hex() doc. Maybe also mention "%#X" % value to format in upper case?

----------
assignee: docs at python
components: Documentation
messages: 261308
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: hex() documentation: mention "%x" % int
versions: Python 3.6

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

From report at bugs.python.org  Mon Mar  7 21:11:25 2016
From: report at bugs.python.org (Ed Behn)
Date: Tue, 08 Mar 2016 02:11:25 +0000
Subject: [New-bugs-announce] [issue26507] Use highest pickle protocol in
 multiprocessing
Message-ID: <1457403085.0.0.0995776764652.issue26507@psf.upfronthosting.co.za>


New submission from Ed Behn:

Currently, the default pickle protocol is used to return worker results in a multiprocessing pool. The highest protocol should be used because backwards compatibility is not an issue.

----------
components: Extension Modules
files: patch
messages: 261318
nosy: ebehn
priority: normal
severity: normal
status: open
title: Use highest pickle protocol in multiprocessing
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42086/patch

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

From report at bugs.python.org  Mon Mar  7 21:25:22 2016
From: report at bugs.python.org (pablo sacristan)
Date: Tue, 08 Mar 2016 02:25:22 +0000
Subject: [New-bugs-announce] [issue26508] Infinite crash leading to DoS
Message-ID: <1457403922.14.0.94490204521.issue26508@psf.upfronthosting.co.za>


New submission from pablo sacristan:

import ctypes, struct, sys, os
while 1:
    os.system('python /Users/pabstersac/Desktop/Python\ Files/crash.py') #Change to your full path to the file
    inner = ()
    outer = (inner,)
    c_outer = (ctypes.c_char * sys.getsizeof(outer)).from_address(id(outer))
    inner_index = c_outer[:].find(struct.pack('P', id(inner)))
    c_outer[inner_index:inner_index+struct.calcsize('P')] = struct.pack('P', id(outer))
    print outer
    #construct and print a self-referencing tuple
run it and wait around 10 sec for it to happen, but once it starts you will be forced to force it to shut because it will keep on crashing infinitely which is extremely annoying, and even while it says it crashed it still runs and keeps on running infinitely, which if you do on an unexpecting victim, they will probably shut down the computer directly.
There are basically two problems here, the way you construct and then print a self-referencing tuple, and the way you handle when it is put in an infinite loop with itself calling its own file (which if you wait long enough will see the effect goes quicker every second, it goes up exponentially) and you don't stop it correctly.

----------
files: crash.py
messages: 261319
nosy: pabstersac
priority: normal
severity: normal
status: open
title: Infinite crash leading to DoS
type: security
Added file: http://bugs.python.org/file42088/crash.py

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

From report at bugs.python.org  Mon Mar  7 23:44:16 2016
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Tue, 08 Mar 2016 04:44:16 +0000
Subject: [New-bugs-announce] [issue26509] spurious ConnectionAbortedError
 logged on Windows
Message-ID: <1457412256.22.0.929855467044.issue26509@psf.upfronthosting.co.za>


New submission from Sebastien Bourdeauducq:

https://github.com/python/asyncio/issues/319

On Windows, asyncio servers sometimes print such log messages when clients disconnect:

```
ERROR:master:asyncio:Fatal write error on pipe transport
protocol: <asyncio.streams.StreamReaderProtocol object at 0x0000000003F63FD0>
transport: <_ProactorSocketTransport fd=756>
Traceback (most recent call last):
  File "C:\Users\User\Miniconda3\lib\asyncio\proactor_events.py", line 283, in _loop_writing
    self._write_fut = self._loop._proactor.send(self._sock, data)
  File "C:\Users\User\Miniconda3\lib\asyncio\windows_events.py", line 450, in send
    ov.WSASend(conn.fileno(), buf, flags)
ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software on your host machine.
```

I guess that this line:
https://github.com/python/asyncio/blob/39c135baf73762830148236da622787052efba19/asyncio/proactor_events.py#L291

should be changed to also catch ``ConnectionAbortedError``, as this exception also happens when connections are closed on Windows, in addition to ``ConnectionResetError``.

----------
components: asyncio
messages: 261321
nosy: gvanrossum, haypo, sebastien.bourdeauducq, yselivanov
priority: normal
severity: normal
status: open
title: spurious ConnectionAbortedError logged on Windows
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  8 08:56:01 2016
From: report at bugs.python.org (Memeplex)
Date: Tue, 08 Mar 2016 13:56:01 +0000
Subject: [New-bugs-announce] [issue26510] Add required argument to
 add_subparsers
Message-ID: <1457445361.5.0.530669445668.issue26510@psf.upfronthosting.co.za>


New submission from Memeplex:

It's useful in combination with dest. Currently you have to set required as an attribute. This is not only inconsistent but not even documented as a valid usage (in general, it's not clear from the docs whether attribute setting -vs argument passing- is a valid usage).

----------
components: Library (Lib)
messages: 261358
nosy: memeplex
priority: normal
severity: normal
status: open
title: Add required argument to add_subparsers
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  8 10:39:22 2016
From: report at bugs.python.org (Mike Vertolli)
Date: Tue, 08 Mar 2016 15:39:22 +0000
Subject: [New-bugs-announce] [issue26511] Add link to id() built-in in
 comparison operator documentation for "is"
Message-ID: <1457451562.01.0.849547274402.issue26511@psf.upfronthosting.co.za>


New submission from Mike Vertolli:

Here's the doc: https://docs.python.org/2/reference/expressions.html#is

It would be great if this line:
"The operators is and is not test for object identity: x is y is true if and only if x and y are the same object. x is not y yields the inverse truth value.[7]"

Could link to the id() builtin doc:
https://docs.python.org/2/library/functions.html#id

One way to rephrase this could be:
"The operators is and is not test for object identity: x is y is true if and only if x and y are the same object or id(x) == id(y). x is not y yields the inverse truth value.[7]"

And, the id's can be hyperlinks.

It would also be nice if that reference linked to a page on integer caching in Python.

----------
assignee: docs at python
components: Documentation
messages: 261364
nosy: Mike Vertolli, docs at python
priority: normal
severity: normal
status: open
title: Add link to id() built-in in comparison operator documentation for "is"
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  8 16:24:04 2016
From: report at bugs.python.org (Julien)
Date: Tue, 08 Mar 2016 21:24:04 +0000
Subject: [New-bugs-announce] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
Message-ID: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>


New submission from Julien:

o/

TL;DR: I think the various usages of "Integral" in https://docs.python.org/3.5/library/stdtypes.html#numeric-types-int-float-complex are either wrong or too hard to understand and should be rewriten as "int".


While translating the documentation I found the sentence "x truncated to Integral" in https://docs.python.org/3.5/library/stdtypes.html#numeric-types-int-float-complex for the `math.floor(x)` method.

By "Integral" I assume you're speaking about the ABC `numbers.Integral`, whish is already not clear, but the capital I helps.

According to pydoc and PEP3141, the `numbers.Integral` ABC inherits from Rational, which inherits from Real which inherits from Complex which inherits from Number. So number is the broader ABC and integral the opposite, the representation of an integer.

I do _NOT_ assume that someone reading the stdtypes.html section is aware of those ABCs, so I don't think it's nice for them to use them without linking to them.

So I infer than "x truncated to integral" means "x truncated to the nearest integer". Which is far more readable.

Two lines after, I found "The greatest integral float <= x" for `math.floor(x)` which is less readable, no capital I to `integral` and what is an `integral float` ?

Also the documentation of `math.floor` states an `int` is returned (as the doc for math.trunc states an Integral is returned).

So there's two possibilities here:

 - The doc uses vocabulary and phrase structures I don't understand and "integral float" actually mean something.
 - The doc is not clear

In both cases, I suggest to either transform "integral" usages to a link to :class:`numbers.Integral` or simply speaking of "int" here.

Context: I'm translating the documentation in French, I achieved `tutorial.html` and `functions.html` and it's until here the hardest sentence to understand (others were simply wrong like in http://bugs.python.org/issue26029) or understandable, so even if those structures are semantically and gramatically correct, they're clearly one of the hardest to understand, which is sad as we're only speaking of rounding numbers. I mean, if there's a goal to sand away spikes in doc readability, this one is a big one.

So, can an english native speaker can enlighten me about this ?

Bests,

----------
assignee: docs at python
components: Documentation
messages: 261380
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Vocabulary: Using "integral" in library/stdtypes.html
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  8 16:41:33 2016
From: report at bugs.python.org (Florian Roth)
Date: Tue, 08 Mar 2016 21:41:33 +0000
Subject: [New-bugs-announce] [issue26513] platform.win32_ver() broken in
 2.7.11
Message-ID: <1457473293.66.0.928061603359.issue26513@psf.upfronthosting.co.za>


New submission from Florian Roth:

Using Python 2.7.9 and 2.7.10 (32bit) on a Windows Server 2008 R2 64bit System platform.win32_ver() shows the following, which is correct:

('2008ServerR2', '6.1.7601', 'SP1', u'Multiprocessor Free')
 
Using Python version 2.7.11 (32bit) on the same Windows 2008 R2 server shows:

('7', '6.1.7601', 'SP1', u'Multiprocessor Free')

which is wrong. 
Platform OS detection seems to be broken with version 2.7.11.

----------
components: Windows
messages: 261384
nosy: Florian Roth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: platform.win32_ver() broken in 2.7.11
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  8 16:55:55 2016
From: report at bugs.python.org (Marc Guetg)
Date: Tue, 08 Mar 2016 21:55:55 +0000
Subject: [New-bugs-announce] [issue26514] Object defines '__ne__' as 'not
 __eq__' if '__ne__' is not implemented
Message-ID: <1457474155.28.0.06785872232.issue26514@psf.upfronthosting.co.za>


New submission from Marc Guetg:

I propose to change __ne__ of `object` in the following form:

	class NewObject(object):
		def __ne__(self, other):
			return not self.__eq__(other)

Currently overwriting the `__eq__` method requires also overwriting `__ne__`. In a vast majority of cases this results in some boilerplate code as:

    (a == b) ^ (a != b) == True

to reduce surprises. Changing the default behavior still allows for the limited number of use cases where we want to implement __ne__ differently.


In short I propose the same behavior than __str__ and __repr__ have for __eq__ and __ne__.
(https://docs.python.org/3/reference/datamodel.html#object.__str__)

----------
components: Interpreter Core
messages: 261385
nosy: Marc Guetg
priority: normal
severity: normal
status: open
title: Object defines '__ne__' as 'not __eq__' if '__ne__' is not implemented
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar  8 21:43:41 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 09 Mar 2016 02:43:41 +0000
Subject: [New-bugs-announce] [issue26515] Update extending/embedding docs to
 new way to build modules in C
Message-ID: <1457491421.2.0.684118231911.issue26515@psf.upfronthosting.co.za>


New submission from Brett Cannon:

https://docs.python.org/3/extending/extending.html#a-simple-example uses PyModule_Create() instead of PyModuleDef_Init().

----------
assignee: docs at python
components: Documentation
messages: 261398
nosy: brett.cannon, docs at python, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Update extending/embedding docs to new way to build modules in C
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Mar  9 06:15:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Mar 2016 11:15:15 +0000
Subject: [New-bugs-announce] [issue26516] Add PYTHONMALLOC env var and add
 support for malloc debug hooks in release mode
Message-ID: <1457522115.12.0.78692190259.issue26516@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch:

- Add PYTHONMALLOC env var which accepts 4 values:

  * pymalloc: use pymalloc for PyObject_Malloc(), malloc for PyMem_Malloc() and PyMem_RawMalloc()
  * pymalloc_debug: pymalloc + debug hooks
  * malloc: use malloc for PyObject_Malloc(), PyMem_Malloc() and PyMem_RawMalloc()
  * malloc_debug: malloc + debug hooks

- Add support for debug hooks in release mode
- Add unit test for debug hooks in test_capi.py
- Add unit on misuse of memory allocators in test_capi.py

PYTHONMALLOC is used even if -E command line option is used, I prefer to keep the code simple. PYTHONMALLOC must be checked before the first call to any Python memory allocator, so it must occur very earlier. Well, it's simply the first instruction of main()...

My main use case is to be able to use debug hooks to detect:

* misuse of python memory allocators like object allocated with PyObject_Malloc() and freed with PyMem_Free()
* buffer overflow
* buffer underlow

----------
files: pymem.patch
keywords: patch
messages: 261413
nosy: haypo, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add PYTHONMALLOC env var and add support for malloc debug hooks in release mode
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42098/pymem.patch

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

From report at bugs.python.org  Wed Mar  9 08:09:45 2016
From: report at bugs.python.org (Jools)
Date: Wed, 09 Mar 2016 13:09:45 +0000
Subject: [New-bugs-announce] [issue26517] Crash in installer
Message-ID: <1457528985.92.0.506941181927.issue26517@psf.upfronthosting.co.za>


New submission from Jools:

Crash when installing python 2.7.11 x64 edition out of the box. x86 version works. I chose to install for all users, and the system has write permissions to the folder (C:\bin\python27).

----------
components: Windows
messages: 261421
nosy: jools, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Crash in installer
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  9 08:15:03 2016
From: report at bugs.python.org (Jools)
Date: Wed, 09 Mar 2016 13:15:03 +0000
Subject: [New-bugs-announce] [issue26518] AttributeError: 'module' object
 has no attribute '_handlerList'
Message-ID: <1457529303.49.0.107361475013.issue26518@psf.upfronthosting.co.za>


New submission from Jools:

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

when trying to install any packages with pip. This one is with trying to install the logging package:

http://pastebin.com/TCUpUMYn

----------
components: Library (Lib)
messages: 261422
nosy: jools
priority: normal
severity: normal
status: open
title: AttributeError: 'module' object has no attribute '_handlerList'
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  9 11:01:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Mar 2016 16:01:57 +0000
Subject: [New-bugs-announce] [issue26519] Cython doesn't work anymore on
 Python 3.6
Message-ID: <1457539317.39.0.81348046338.issue26519@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I tried to run numpy test suite on Python 3.6 compiled in debug mode. I got an assertion error. Then I wanted to try the Git version of numpy, but the "Cythonizing sources" step of the numpy installer fails with:
---
Traceback (most recent call last):
  File "bin/cython", line 9, in <module>
    load_entry_point('Cython==0.23.4', 'console_scripts', 'cython')()
  (...)
  File "lib/python3.6/site-packages/Cython/Compiler/Nodes.py", line 6585, in generate_execution_code
    self.body.generate_execution_code(code)
  File "lib/python3.6/site-packages/Cython/Compiler/Nodes.py", line 7026, in generate_execution_code
    fresh_finally_clause().generate_execution_code(code)
  File "lib/python3.6/site-packages/Cython/Compiler/Nodes.py", line 7013, in fresh_finally_clause
    node_copy = copy.deepcopy(node)
  File "/home/haypo/prog/python/default/Lib/copy.py", line 182, in deepcopy
    y = _reconstruct(x, rv, 1, memo)
  (...)
  File "/home/haypo/prog/python/default/Lib/copy.py", line 314, in _reconstruct
    item = deepcopy(item, memo)
  File "/home/haypo/prog/python/default/Lib/copy.py", line 174, in deepcopy
    rv = reductor(4)
TypeError: can't pickle Argument objects
---
Argument class indirectly comes from Cython.Compiler.Nodes.ExprStatNode.

Command to reproduce the bug:
---
tar -xf mtrand.tar.gz  # download mtrand.tar.gz attached to this issue
python -m venv ENV
ENV/bin/python -m pip install cython
ENV/bin/python ENV/bin/cython --fast-fail -o mtrand.c mtrand.pyx
---

It looks like cython behaviour failed after this change:
---
changeset:   99677:b8d108a2a38e
parent:      99675:80d1faa9735d
parent:      99676:0cd2de69fb66
user:        Serhiy Storchaka <storchaka at gmail.com>
date:        Fri Dec 25 21:05:35 2015 +0200
files:       Lib/test/test_csv.py Misc/NEWS Objects/typeobject.c
description:
Issue #22995: Instances of extension types with a state that aren't
subclasses of list or dict and haven't implemented any pickle-related
methods (__reduce__, __reduce_ex__, __getnewargs__, __getnewargs_ex__,
or __getstate__), can no longer be pickled.  Including memoryview.
---

Sorry, I don't understand yet if it's a regression in Python 3.6 or a real bug in Cython.

----------
files: mtrand.tar.gz
messages: 261437
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Cython doesn't work anymore on Python 3.6
versions: Python 3.6
Added file: http://bugs.python.org/file42105/mtrand.tar.gz

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

From report at bugs.python.org  Wed Mar  9 11:22:10 2016
From: report at bugs.python.org (Erwin Mayer)
Date: Wed, 09 Mar 2016 16:22:10 +0000
Subject: [New-bugs-announce] [issue26520] asyncio.new_event_loop() hangs
Message-ID: <1457540530.17.0.125897820678.issue26520@psf.upfronthosting.co.za>


New submission from Erwin Mayer:

I am using the following function to force a coroutine to run synchronously:

def await_sync(coro: types.CoroutineType, timeout_s: int=None):
    """

    :param coro: a coroutine or lambda loop: coroutine(loop)
    :param timeout_s:
    :return:
    """
    loop = asyncio.new_event_loop()  # type: BaseEventLoop
    if not is_awaitable(coro):
        coro = coro(loop)
    if timeout_s is None:
        fut = asyncio.ensure_future(coro, loop=loop)
    else:
        fut = asyncio.ensure_future(asyncio.wait_for(coro, timeout=timeout_s, loop=loop), loop=loop)
    loop.run_until_complete(fut)
    return fut.result()

def is_awaitable(coro_or_future):
    if isinstance(coro_or_future, futures.Future):
        return coro_or_future
    elif asyncio.coroutines.iscoroutine(coro_or_future):
        return True
    elif asyncio.compat.PY35 and inspect.isawaitable(coro_or_future):
        return True
    else:
        return False

However, intermittently, it will freeze upon simply trying to create a new loop: loop = asyncio.new_event_loop(). Inspecting the stack traces shows me the exact location where it hangs:

File: "/src\system\utils.py", line 34, in await_sync
  loop = asyncio.new_event_loop()  # type: BaseEventLoop
File: "\lib\asyncio\events.py", line 636, in new_event_loop
  return get_event_loop_policy().new_event_loop()
File: "\lib\asyncio\events.py", line 587, in new_event_loop
  return self._loop_factory()
File: "\lib\asyncio\selector_events.py", line 55, in __init__
  self._make_self_pipe()
File: "\lib\asyncio\selector_events.py", line 116, in _make_self_pipe
  self._ssock, self._csock = self._socketpair()
File: "\lib\asyncio\windows_events.py", line 295, in _socketpair
  return windows_utils.socketpair()
File: "\lib\socket.py", line 515, in socketpair
  ssock, _ = lsock.accept()
File: "\lib\socket.py", line 195, in accept
  fd, addr = self._accept()

I am using Python 3.5.1.

StackOverflow question: http://stackoverflow.com/questions/35861175/what-can-cause-asyncio-to-hang-upon-simply-creating-a-new-loop

----------
components: asyncio
messages: 261440
nosy: Erwin Mayer, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.new_event_loop() hangs
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar  9 13:57:36 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 09 Mar 2016 18:57:36 +0000
Subject: [New-bugs-announce] [issue26521] add `extend_enum` to Enum
Message-ID: <1457549856.93.0.164722622997.issue26521@psf.upfronthosting.co.za>


New submission from Ethan Furman:

In this SO question [1] the OP has a need to generate an Enum lazily.  I created an `extend_enum` function to do so.  By the time I was done I realized I would not want anyone to have to create that function by hand, nor keep it up to date (should we ever change the implementation details).

Should we add this to the stdlib?  Note that this does not change anything about subclassing Enum.

[1] http://stackoverflow.com/q/28126314/208880

----------
assignee: ethan.furman
messages: 261464
nosy: barry, eli.bendersky, ethan.furman
priority: low
severity: normal
status: open
title: add `extend_enum` to Enum
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar  9 14:06:43 2016
From: report at bugs.python.org (Richard Futrell)
Date: Wed, 09 Mar 2016 19:06:43 +0000
Subject: [New-bugs-announce] [issue26522] pickle.whichmodule(object.__new__,
 None) = 'email.MIMEAudio'
Message-ID: <1457550403.98.0.525527175536.issue26522@psf.upfronthosting.co.za>


New submission from Richard Futrell:

On Python 2.7.11, pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'

This is unlikely to be the correct module.

----------
components: XML
messages: 261465
nosy: canjobear
priority: normal
severity: normal
status: open
title: pickle.whichmodule(object.__new__, None) = 'email.MIMEAudio'
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  9 15:37:10 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Mar 2016 20:37:10 +0000
Subject: [New-bugs-announce] [issue26523] multiprocessing ThreadPool is
 untested
Message-ID: <1457555830.32.0.570545129367.issue26523@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

There is a mistake in _test_multiprocessing.py which means that ThreadPool is untested, the regular Pool is tested instead by the ThreadsMixin.  Patch attached.

----------
components: Library (Lib), Tests
files: test_threadpool.patch
keywords: patch
messages: 261474
nosy: jnoller, neologix, pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing ThreadPool is untested
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42107/test_threadpool.patch

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

From report at bugs.python.org  Wed Mar  9 16:06:55 2016
From: report at bugs.python.org (John Beck)
Date: Wed, 09 Mar 2016 21:06:55 +0000
Subject: [New-bugs-announce] [issue26524] document what config directory is
 used for
Message-ID: <1457557615.13.0.55098857732.issue26524@psf.upfronthosting.co.za>


New submission from John Beck:

Solaris ships Python versions 2.7, 3.4 and 3.5 at present.  For 2.7,
we ship both 32-bit and 64-bit versions; for 3.4 and 3.5 we only ship
64-bit versions.  For 2.7, we ship /usr/lib/python2.7/config/ with the
usual suspects (Makefile, Setup.config, config.c, install-sh, python.o,
Setup, Setup.local, config.c.in, makesetup) thereunder for the 32-bit
version but for the 64-bit version, we don't ship the equivalent
directory at all.  For 3.4 and 3.5, we ship
/usr/lib/python3.[45]/config-3.[45]m/ with its usual suspects.  We had
a bug filed about the discrepancy in shipping the 32-bit but not the
64-bit version of that directory for 2.7.  An investigation suggested
the directory is not used for 2.7, nor did it seem used (per docs we
could find) for 3.x.  But testing revealed it is used for 3.x, as our
builds failed, e.g.:

error: invalid Python installation: unable to open
    /usr/lib/python3.4/config-3.4m/Makefile (No such file or directory)

when we removed the config-3.[45]m directories.  OK, fine, it was an
experiment, so we'll keep the directories.  But it was not clear to
us from the docs we could find, such as:
    https://docs.python.org/3.6/extending/extending.html
exactly how the config directory is used.  This is a documentation
enhancement request to clarify how the config directory is used.

----------
assignee: docs at python
components: Documentation
messages: 261477
nosy: docs at python, jbeck
priority: normal
severity: normal
status: open
title: document what config directory is used for
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar 10 03:51:32 2016
From: report at bugs.python.org (gladman)
Date: Thu, 10 Mar 2016 08:51:32 +0000
Subject: [New-bugs-announce] [issue26525] Documentation of ord(c) easy to
 misread
Message-ID: <1457599892.41.0.987128084347.issue26525@psf.upfronthosting.co.za>


New submission from gladman:

It is very easy to misread the greek 'nu' used in the ord(c) documentation as ord('v') (i.e. an alphabetic 'v').  This can lead the reader to draw a wrong conclusion about the behaviour of the function. 

Would it not be better if this example used a greek letter that is less easy to misread in this way?  Or, perhaps, add extra text indicating that the greek letter 'nu' is being referenced?

----------
assignee: docs at python
components: Documentation
messages: 261485
nosy: docs at python, gladman
priority: normal
severity: normal
status: open
title: Documentation of ord(c) easy to misread
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 10 04:02:31 2016
From: report at bugs.python.org (A. Skrobov)
Date: Thu, 10 Mar 2016 09:02:31 +0000
Subject: [New-bugs-announce] [issue26526] In parsemodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
Message-ID: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>


New submission from A. Skrobov:

Updating Modules/parsermodule.c for every change in grammar and/or parser is a maintenance burden, listed as such at https://docs.python.org/devguide/grammar.html

The attached patch lets the validation code use the auto-generated DFA structures, thus ensuring it stays up to date with the grammar. It also trims the code by over 2KLOC.

----------
components: Extension Modules
files: patch
messages: 261486
nosy: A. Skrobov, fdrake
priority: normal
severity: normal
status: open
title: In parsemodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42110/patch

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

From report at bugs.python.org  Thu Mar 10 06:04:31 2016
From: report at bugs.python.org (Olivier Le Moign)
Date: Thu, 10 Mar 2016 11:04:31 +0000
Subject: [New-bugs-announce] [issue26527] CGI library - Using unicode in
 header fields
Message-ID: <1457607871.95.0.782640087152.issue26527@psf.upfronthosting.co.za>


New submission from Olivier Le Moign:

According to RFC5987 (http://tools.ietf.org/html/rfc5987), it's possible to use other encoding than ASCII in header fields. 
Specifically in the CGI library, posting files with non-ASCII characters will lead the header to be (for example) filename*=utf-8"xxxxx" which is not recognised:

l 513

if 'filename' in pdict:
    self.filename = pdict['filename']
self._binary_file = self.filename is not None 

The file will thus be treated as a string.
The correction isn't too big but being a total newbie, I'm a bit scared to suggest a patch.

----------
components: Unicode
messages: 261491
nosy: ezio.melotti, haypo, olemoign
priority: normal
severity: normal
status: open
title: CGI library - Using unicode in header fields
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 10 07:09:57 2016
From: report at bugs.python.org (reidfaiv)
Date: Thu, 10 Mar 2016 12:09:57 +0000
Subject: [New-bugs-announce] [issue26528] NameError for built in function
 open when re-raising stored exception from yielded function
Message-ID: <1457611797.69.0.202848672993.issue26528@psf.upfronthosting.co.za>


New submission from reidfaiv:

Builtin open() gets NameError) in context manager __exit__ in case:
* context manager yielding records
* we return another generator when consuming these and
* second generator raises, catches, stores and re-raises an excption


Reduced down code looks like this:
---------------------------------------
#!/usr/bin/env python
# -*- coding: utf-8 -*-


# context manager "query" (open in init, yield rows and close on exit)
class _query():
    def __init__(self, **kwargs):
        pass

    def __enter__(self):
        return [1, 2, 3]

    def __exit__(self, type_, value, tb):
        print('__exit__')           # print() is also built-in, but works
        f = open('test.log', 'wt')  # <-- NameError: name 'open' is not defined
        f.close()


# this works fine
def a():
    try:
        raise Exception('volatile exception')
    except Exception as e:
        raise e


# this does not work
def b():
    try:
        raise Exception('stored exception')
    except Exception as e:
        ee = e  # <-- storing exception and then
    raise ee    # <-- re-raising stored exception triggers the issue


def event_gen(**kwargs):
    with _query() as cursor:
        for _ in cursor:
            yield b     # <--- does not work
            # yield a   # <--- works fine


def run(**kwargs):
    g = event_gen(**kwargs)
    r = next(g)
    r()
    # This also works
    # for r in event_gen(**kwargs):
    #     r()

if __name__ == '__main__':
    run()


---------------------------------------
>python.exe gen_err.py
Traceback (most recent call last):
  File "gen_err.py", line 52, in <module>
    run()
  File "gen_err.py", line 46, in run
    r()
  File "gen_err.py", line 33, in b
    raise ee    # <-- re-raising stored exception triggers the issue
  File "gen_err.py", line 30, in b
    raise Exception('stored exception')
Exception: stored exception
__exit__
Exception ignored in: <generator object event_gen at 0x000001A31F7C4048>
Traceback (most recent call last):
  File "gen_err.py", line 39, in event_gen
  File "gen_err.py", line 15, in __exit__
NameError: name 'open' is not defined


This happens with Python 3.4+
Works with earlier versions as expected.

If exception re-raised immediately, works fine.
If outermost generator is consumed in for loop, works fine.

----------
components: Interpreter Core
files: gen_err.py
messages: 261497
nosy: reidfaiv
priority: normal
severity: normal
status: open
title: NameError for built in function open when re-raising stored exception from yielded function
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file42114/gen_err.py

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

From report at bugs.python.org  Thu Mar 10 07:41:35 2016
From: report at bugs.python.org (Vadim Markovtsev)
Date: Thu, 10 Mar 2016 12:41:35 +0000
Subject: [New-bugs-announce] [issue26529] urllib.request: ftplib's cwd() can
 do harm
Message-ID: <1457613695.97.0.915811579491.issue26529@psf.upfronthosting.co.za>


New submission from Vadim Markovtsev:

urllib/request.py, near line 2345

# Set transfer mode to ASCII!
self.ftp.voidcmd('TYPE A')
# Try a directory listing. Verify that directory exists.
if file:
    pwd = self.ftp.pwd()
    try:
        try:
            self.ftp.cwd(file)
        except ftplib.error_perm as reason:
            raise URLError('ftp error: %r' % reason) from reason
    finally:
        self.ftp.cwd(pwd)
    cmd = 'LIST ' + file
else:
    cmd = 'LIST'
conn, retrlen = self.ftp.ntransfercmd(cmd)

and near line 2314:

def init(self):
    import ftplib
    self.busy = 0
    self.ftp = ftplib.FTP()
    self.ftp.connect(self.host, self.port, self.timeout)
    self.ftp.login(self.user, self.passwd)
    _target = '/'.join(self.dirs)
    self.ftp.cwd(_target)

The fact is, one can download a file from FTP without accessing the listing of it's parent directory. Example: ftp://ftp.apnic.net/apnic/whois-data/APNIC/split/apnic.db.inetnum.gz (African whois db). So these cwd() calls prevent from successfully downloading the file. If the corresponding blocks are commented out, the file is downloaded OK.

I am not sure how to fix this, rather than totally remove cwd() stuff.

----------
components: Library (Lib)
messages: 261498
nosy: Vadim Markovtsev
priority: normal
severity: normal
status: open
title: urllib.request: ftplib's cwd() can do harm
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar 10 09:17:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Mar 2016 14:17:10 +0000
Subject: [New-bugs-announce] [issue26530] tracemalloc: add C API to manually
 track/untrack memory allocations
Message-ID: <1457619430.68.0.0968942184372.issue26530@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The API of Python memory allocators was extended for numpy: calloc() was added (issue #21233). It looks like it's not enough because allocations with an alignment is also required for vector operations (SIMD). For Python, there is the issue #18835 but the benefit for Python code is unclear or negligible.

Instead of extending the API each time, it would be simpler to add an API to allow third party memory allocators to track/untrack memory in tracemalloc. I guess that the API should make the assumption that the GIL is not hold and so try to acquire the GIL (if it's not already hold).

Related numpy issue: https://github.com/numpy/numpy/issues/4663

See also: https://mail.scipy.org/pipermail/numpy-discussion/2015-January/072068.html

----------
messages: 261501
nosy: haypo, njs
priority: normal
severity: normal
status: open
title: tracemalloc: add C API to manually track/untrack memory allocations
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar 10 11:18:45 2016
From: report at bugs.python.org (Joshua Cannell)
Date: Thu, 10 Mar 2016 16:18:45 +0000
Subject: [New-bugs-announce] [issue26531] Keyboard Interrupts not caught
 when used within a class method on Windows 10
Message-ID: <1457626725.91.0.992328225706.issue26531@psf.upfronthosting.co.za>


New submission from Joshua Cannell:

There seems to be an issue capturing keyboard interrupts on Windows 10 when using raw_input() inside of a class method w/python 2.7.x.

So far I have tested this on:
2.7.11 x86 on Windows 10 x64 - Does not capture (Traceback)
2.7.11 x64 on Windows 10 x64 - Does not capture (Traceback)
2.7.11 x86 on Windows XP     - Does capture

So far I've only tested 2.7.11, so I don't know which other version may or may not be affected. The proof of concept code is attached.

If there is anything else I can provide to help, please let me know. I'm not accustomed to posting bugs here so I apologize if I've missed something.

----------
components: Windows
files: keyint_poc.py
messages: 261508
nosy: jecanne, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Keyboard Interrupts not caught when used within a class method on Windows 10
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42117/keyint_poc.py

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

From report at bugs.python.org  Thu Mar 10 15:02:45 2016
From: report at bugs.python.org (shakur shams Mullick)
Date: Thu, 10 Mar 2016 20:02:45 +0000
Subject: [New-bugs-announce] [issue26532] build fails with address sanitizer
Message-ID: <1457640165.38.0.124294976796.issue26532@psf.upfronthosting.co.za>


New submission from shakur shams Mullick:

After configuring with address sanitizer like this:

$ ./configure --with-address-sanitizer --disable-ipv6

build fails when:
$make

gcc -pthread -c -fsanitize=address -fno-omit-frame-pointer  -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Objects/obmalloc.o Objects/obmalloc.c
In file included from /usr/include/features.h:364:0,
                 from /usr/include/limits.h:25,
                 from /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed/limits.h:168,
                 from /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed/limits.h:34,
                 from Include/Python.h:11,
                 from Objects/obmalloc.c:1:
Objects/obmalloc.c: In function ?_PyObject_Realloc?:
/usr/include/x86_64-linux-gnu/bits/string3.h:50:1: error: inlining failed in call to always_inline ?memcpy?: function attribute mismatch
 __NTH (memcpy (void *__restrict __dest, const void *__restrict __src,
 ^
Objects/obmalloc.c:1668:13: error: called from here
             memcpy(bp, p, size);
             ^
Makefile:1538: recipe for target 'Objects/obmalloc.o' failed
make: *** [Objects/obmalloc.o] Error 1

----------
components: Build
messages: 261521
nosy: shakur shams Mullick
priority: normal
severity: normal
status: open
title: build fails with address sanitizer
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 10 17:28:46 2016
From: report at bugs.python.org (Grazfather x)
Date: Thu, 10 Mar 2016 22:28:46 +0000
Subject: [New-bugs-announce] [issue26533] logging.config does not allow
 disable_existing_loggers=True
Message-ID: <1457648926.18.0.758256853063.issue26533@psf.upfronthosting.co.za>


New submission from Grazfather x:

logging.config.FileConfig has a kwarg 'disable_existing_loggers' that defaults to False, but when true will allow you to load a config and not disable all other existing loggers.

logging.config.listen uses FileConfig, but has no option to provide this keyword to it, which is a problem when a logger hierarchy is build using logger.getLogger(__name__) (which is recommended in the documentation).

Proposal: Add kwarg 'disable_existing_loggers' to logging.config.listen which is passed to fileConfig.

----------
components: Library (Lib)
messages: 261526
nosy: Grazfather x
priority: normal
severity: normal
status: open
title: logging.config does not allow disable_existing_loggers=True
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar 10 18:45:31 2016
From: report at bugs.python.org (Daniel Shaulov)
Date: Thu, 10 Mar 2016 23:45:31 +0000
Subject: [New-bugs-announce] [issue26534] subprocess.check_output with
 shell=True ignores the timeout
Message-ID: <1457653531.44.0.556796452495.issue26534@psf.upfronthosting.co.za>


New submission from Daniel Shaulov:

Basically -
subprocess.check_output("ping localhost", shell=True, timeout=5)
Will hang forever.

What happens is that subprocess.run times out on communicate, sends SIGKILL *to the shell* and then calls communicate again without the timeout. But nothing actually closes the "ping" command so the second communicate will never exit.

Even if we put a timeout on the second communicate, it won't be good enough because that "ping" will still be "leaked".

This SO question is about the fact that kill doesn't work when shell=True, and might be relevant for this issue:
http://stackoverflow.com/questions/4789837/how-to-terminate-a-python-subprocess-launched-with-shell-true

As a possible fix I propose doing the following:
1. Add killpg to the Popen class.
2. Add an argument to run - "kill_group" that makes run use killpg instead of kill
3. Users can all:
subprocess.check_output("ping localhost", shell=True, start_new_session=True, kill_group=True, timeout=5)

And have it work fine. This is the best I could come up with, without breaking any existing behavior.

Other options to consider:
1. Not have kill_group argument and to implicitly kill by group when start_new_session is True (but this is not really backwards compatible).
2. Having kill_group as an argument for Popen and not run, and when kill is called, it will call killpg if the option was specified.

A patch is attached with my proposed solution.

----------
components: Library (Lib)
files: killpg.patch
keywords: patch
messages: 261533
nosy: Daniel Shaulov, astrand
priority: normal
severity: normal
status: open
title: subprocess.check_output with shell=True ignores the timeout
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42122/killpg.patch

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

From report at bugs.python.org  Thu Mar 10 21:45:19 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 11 Mar 2016 02:45:19 +0000
Subject: [New-bugs-announce] [issue26535] Minor typo in the docs for
 struct.unpack
Message-ID: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docstring of struct.unpack currently reads

Unpack from the buffer buffer (presumably packed by pack(fmt, ...)) according to the format string fmt. The result is a tuple even if it contains exactly one item. The buffer must contain exactly the amount of data required by the format (len(bytes) must equal calcsize(fmt)).

It should probably read "len(buffer) must equal calcsize(fmt)".

----------
assignee: docs at python
components: Documentation
messages: 261538
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Minor typo in the docs for struct.unpack
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar 10 22:15:28 2016
From: report at bugs.python.org (Daniel Stokes)
Date: Fri, 11 Mar 2016 03:15:28 +0000
Subject: [New-bugs-announce] [issue26536] Add the SIO_LOOPBACK_FAST_PATH
 option to socket.ioctl
Message-ID: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za>


New submission from Daniel Stokes:

Adding the SIO_LOOPBACK_FAST_PATH option to socket.ioctl on Windows allows Windows users to enable the loopback fast path option available on Windows 8+. This allows for much better TCP loopback performance on Windows.

For more information on TCP Loopback Fast Path, see:
  * https://msdn.microsoft.com/en-us/library/windows/desktop/jj841212%28v=vs.85%29.aspx
  * http://blogs.technet.com/b/wincat/archive/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path.aspx

----------
components: IO
files: loopback_fast_path.patch
keywords: patch
messages: 261539
nosy: Daniel Stokes
priority: normal
severity: normal
status: open
title: Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42124/loopback_fast_path.patch

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

From report at bugs.python.org  Fri Mar 11 01:40:17 2016
From: report at bugs.python.org (Gereon Kaiping)
Date: Fri, 11 Mar 2016 06:40:17 +0000
Subject: [New-bugs-announce] [issue26537] ConfigParser has optoinxform,
 but not sectionxform
Message-ID: <1457678417.52.0.410667040467.issue26537@psf.upfronthosting.co.za>


New submission from Gereon Kaiping:

configparser.ConfigParser (resp. ConfigParser.RawConfigParser for python2) has a optionxform function which converts the option names in a section to lower case by default.

A similar function for section titles would be expected (cf. https://github.com/lmaurits/BEASTling/issues/46#issuecomment-195131900), but it does not exist.

If ConfigParser called such a function (reasonably named sectionxform), which would default to None (or the identity function) for backward compatibility, that would be nice and consistent.

----------
components: Library (Lib)
messages: 261543
nosy: Anaphory
priority: normal
severity: normal
status: open
title: ConfigParser has optoinxform, but not sectionxform
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar 11 06:44:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Mar 2016 11:44:27 +0000
Subject: [New-bugs-announce] [issue26538] regrtest: setup_tests() must not
 replace module.__path__ (_NamespacePath) with a simple list // importlib &
 abspath
Message-ID: <1457696667.94.0.108519122037.issue26538@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Extract of test.libregrtest.setup_tests():

    for module in sys.modules.values():
        if hasattr(module, '__path__'):
            module.__path__ = [os.path.abspath(path)
                               for path in module.__path__]
        if hasattr(module, '__file__'):
            module.__file__ = os.path.abspath(module.__file__)

Because of this code, it's not possible to store test files outside Lib/test/. For the issue #26295 (test_regrtest), I would like to create a temporary directory and then a subdirectory test/ to create temporary test files.

Attached patch adds _NamespacePath.__setitem__() method and modify setup_tests() to keep the _NamespacePath type of module.__path__.

Maybe we should move this abspath() code somewhere in importlib. The site module already contains similar code, abs_paths() function:

    for m in set(sys.modules.values()):
        if (getattr(getattr(m, '__loader__', None), '__module__', None) not in
                ('_frozen_importlib', '_frozen_importlib_external')):
            continue   # don't mess with a PEP 302-supplied __file__
        try:
            m.__file__ = os.path.abspath(m.__file__)
        except (AttributeError, OSError):
            pass
        try:
            m.__cached__ = os.path.abspath(m.__cached__)
        except (AttributeError, OSError):
            pass

Since this code looks to depend on the implementation of importlib (the __loader__ test), IMHO it makes sense to move the code directly somewhere in importlib.

----------
files: libregrtest_module_path.patch
keywords: patch
messages: 261562
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: regrtest: setup_tests() must not replace module.__path__ (_NamespacePath) with a simple list // importlib & abspath
versions: Python 3.6
Added file: http://bugs.python.org/file42130/libregrtest_module_path.patch

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

From report at bugs.python.org  Fri Mar 11 08:03:41 2016
From: report at bugs.python.org (Daniel Shaulov)
Date: Fri, 11 Mar 2016 13:03:41 +0000
Subject: [New-bugs-announce] [issue26539] frozen executables should have an
 empty path
Message-ID: <1457701421.75.0.0409884963304.issue26539@psf.upfronthosting.co.za>


New submission from Daniel Shaulov:

A frozen python executable should have an empty path, so it doesn't accidentally run something it was not supposed to.

The attached file achieves that by setting Py_NoSiteFlag and Py_IsolatedFlag in Python/frozenmain.c

It also checks for Py_FrozenFlag in Python/sysmodule.c in makepathobject and just returns an empty list if it is set.

I originally tried doing it without changing sysmodule, by calling Py_SetPath as suggested in the comment in getpath.c, but calling Py_SetPath(L"") will leave me with a path that cointains a single empty string. There is no way to set an empty path with Py_SetPath.

Other options include allowing Py_SetPath to accept NULL and making sure that NULL results in an empty list, or changing the behavior of makepathobject so an empty string will result in an empty list instead of a list with an empty string.

----------
components: Demos and Tools
files: freeze_path.patch
keywords: patch
messages: 261566
nosy: Daniel Shaulov, twouters
priority: normal
severity: normal
status: open
title: frozen executables should have an empty path
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42133/freeze_path.patch

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

From report at bugs.python.org  Fri Mar 11 12:18:22 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Fri, 11 Mar 2016 17:18:22 +0000
Subject: [New-bugs-announce] [issue26540] Python Macros
Message-ID: <1457716702.76.0.922286771482.issue26540@psf.upfronthosting.co.za>


New submission from Devyn Johnson:

Would it be a good idea to add macros to Python? This would allow developers to test a condition (such as, "is this code running on Linux?" or "is this Python version 3.6?"). Then, the compiled bytecode will already contain the needed code, as opposed to testing the conditions during each execution.

----------
components: Interpreter Core
messages: 261582
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python Macros
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Mar 11 12:56:37 2016
From: report at bugs.python.org (Memeplex)
Date: Fri, 11 Mar 2016 17:56:37 +0000
Subject: [New-bugs-announce] [issue26541] Add stop_after parameter to setup()
Message-ID: <1457718997.42.0.688813904458.issue26541@psf.upfronthosting.co.za>


New submission from Memeplex:

The current implementation offers a stop_after parameter for run_setup() but not for setup(). This design has some shortcomings:

1. It couples the possibility to stop setup after some phase to the fact that the setup function resides in another file. But the feature is also useful when directly invoking setup (for example, if you want to tweak the dist before running it).

2. The other parameters to run_setup are already parameters to setup. It would be more consistent to make all three parameters common to both methods.

3. Arguably messy global variable manipulation to communicate run_setup and setup.

----------
components: Distutils
messages: 261588
nosy: dstufft, eric.araujo, memeplex
priority: normal
severity: normal
status: open
title: Add stop_after parameter to setup()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 11 13:20:27 2016
From: report at bugs.python.org (Dmitry Shachnev)
Date: Fri, 11 Mar 2016 18:20:27 +0000
Subject: [New-bugs-announce] [issue26542] Wrongly formatted doctest block in
 difflib documentation
Message-ID: <1457720427.82.0.520743466398.issue26542@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev:

Look at the documentation of difflib.SequenceMatcher.get_opcodes:
https://docs.python.org/dev/library/difflib.html#difflib.SequenceMatcher.get_opcodes

There, the result part of the example is rendered as plain reStructuredText, separately from the code block itself.
The attached patch fixes it.

----------
assignee: docs at python
components: Documentation
files: doctest.diff
keywords: patch
messages: 261591
nosy: docs at python, mitya57
priority: normal
severity: normal
status: open
title: Wrongly formatted doctest block in difflib documentation
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42137/doctest.diff

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

From report at bugs.python.org  Fri Mar 11 18:23:43 2016
From: report at bugs.python.org (Stephen Evans)
Date: Fri, 11 Mar 2016 23:23:43 +0000
Subject: [New-bugs-announce] [issue26543] imaplib noop Debug
Message-ID: <1457738623.54.0.0867122071018.issue26543@psf.upfronthosting.co.za>


New submission from Stephen Evans:

With the imaplib.Debug=3 (or greater) imaplib.noop() will crash if there are any untagged responses present.

The _dump_ur() function has not been converted to expect bytes in the lambda variable x[1]. An abbreviate example of the 'dict' parameter would be:

{'READ-WRITE': [b''], 'FETCH': [b'1 (FLAGS (\\Recent NonJunk))']}

This _dump_ur() function needs converting to Python 3.x, say, change the map/lambda line to:
  l = map(lambda x:'%s: %r' % (x[0], x[1]), l)


A sample crash inducing session produced by the attached file (using another email client to produce untagged responses for NOOP):

  20:01.23 imaplib version 2.58
  20:01.23 new IMAP4 connection, tag=b'LMHB'
  20:01.48 CAPABILITIES: ('IMAP4REV1', 'LITERAL+', 'SASL-IR', 'LOGIN-REFERRALS', 'ID', 'ENABLE', 'IDLE', 'NAMESPACE', 'AUTH=PLAIN', 'AUTH=LOGIN')
Traceback (most recent call last):
  File "E:/temp/imap-idle/imaplib-noop.py", line 18, in <module>
    connection.noop()  # Crashes here.
  File "C:\Python35\lib\imaplib.py", line 656, in noop
    self._dump_ur(self.untagged_responses)
  File "C:\Python35\lib\imaplib.py", line 1210, in _dump_ur
    self._mesg('untagged responses dump:%s%s' % (t, t.join(l)))
  File "C:\Python35\lib\imaplib.py", line 1209, in <lambda>
    l = map(lambda x:'%s: "%s"' % (x[0], x[1][0] and '" "'.join(x[1]) or ''), l)
TypeError: sequence item 0: expected str instance, bytes found

----------
components: email
files: imaplib-noop.py
messages: 261615
nosy: Stephen.Evans, barry, r.david.murray
priority: normal
severity: normal
status: open
title: imaplib noop Debug
type: crash
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42140/imaplib-noop.py

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

From report at bugs.python.org  Fri Mar 11 19:36:03 2016
From: report at bugs.python.org (Thomas Waldmann)
Date: Sat, 12 Mar 2016 00:36:03 +0000
Subject: [New-bugs-announce] [issue26544] platform.libc_ver() returns
 incorrect version number
Message-ID: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>


New submission from Thomas Waldmann:

platform.libc_ver() is trivially broken as it uses string comparison internally to determine the maximum libc version number (which is obviously broken as "2.9" > "2.10").

----------
components: Library (Lib)
messages: 261624
nosy: Thomas.Waldmann
priority: normal
severity: normal
status: open
title: platform.libc_ver() returns incorrect version number
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar 11 19:59:00 2016
From: report at bugs.python.org (Thomas Waldmann)
Date: Sat, 12 Mar 2016 00:59:00 +0000
Subject: [New-bugs-announce] [issue26545] os.walk is limited by python's
 recursion limit
Message-ID: <1457744340.04.0.931517157669.issue26545@psf.upfronthosting.co.za>


New submission from Thomas Waldmann:

os.walk calls itself recursively and that limits the directory depth it can "walk" into.

On Linux, one can create directory hierarchies deeper than that.

For some more details see there:

https://github.com/borgbackup/borg/issues/380

----------
components: Library (Lib)
messages: 261626
nosy: Thomas.Waldmann
priority: normal
severity: normal
status: open
title: os.walk is limited by python's recursion limit
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 12 09:50:23 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 14:50:23 +0000
Subject: [New-bugs-announce] [issue26546] Provide translated french
 translation on docs.python.org
Message-ID: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>


New submission from Julien:

Hi,

The [french translation of the Python documentation](https://github.com/afpy/python_doc_fr) just hit a 21% coverage in terms of pageviews (According to statistics [nicely provided by EWDurbin](https://github.com/AFPy/python_doc_fr/issues/32#issuecomment-195071379)). (It's 14% of the total strings to translate).

I think it may be a good time to push the translation to *docs.python.org*, so french speaking people will be able to find it naturally, and more translators will be aware of it, increasing the translation speed.

Also it will probably motivate other translations (http://docs.python.jp/3/, http://docs.python.org.ar/tutorial/3/index.html, others ?) to work in a more standardized ways, and make their translations more discoverable.

So there's two discussions to have: The URL, and the "how".

# URL

I think the only reasonable possibility is *docs.python.org/{country_code}/*

Having a CCTLD per translation is near impossible (a LOT or work and highly time consuming) as some domains are unavailable like python.fr and some other have high restrictions like having a physical presence in the country (like python.ca, python.pt.br) or having a commercial relation with a local company like for python.com.tr).

Also it allows localization via *docs.python.org/fr_FR/* even if I don't think we need it soon.

If you have other ideas, better than *docs.python.org/fr/*, that's why this issue is opened.

# How to

We have a [Makefile](https://github.com/AFPy/python_doc_fr/blob/master/Makefile) which like [docsbuild-scripts](https://github.com/python/docsbuild-scripts) delegates naturally most of its work to the sphinx Makefile in *Doc/Makefile*, and is capable of building french versions of 2.7, 3.3, 3.4, and 3.5 in a simple invocation of `make build_all MODE=autobuild-stable` (cloning itself from the github repository, applying various patches (typically to configure sphinx to generate french). 3.2 is also possible but not built by default (no autobuild-html in its sphinx Makefile). 

I think docsbuild-scripts may delegate the french generation by simply cloning/updating our repository and calling our makefile. A patch (attached) will be necessary in docsbuild-scripts to copy generated doc to /fr/ and send purges to the CDN.

Finally, once all this is running, we'll start a discussion about cross-linking both documentations, probably reopening https://github.com/sphinx-doc/sphinx/issues/1246.

----------
assignee: docs at python
components: Documentation
files: build_doc_fr.patch
keywords: patch
messages: 261654
nosy: benjamin.peterson, docs at python, sizeof
priority: normal
severity: normal
status: open
title: Provide translated french translation on docs.python.org
type: enhancement
Added file: http://bugs.python.org/file42150/build_doc_fr.patch

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

From report at bugs.python.org  Sat Mar 12 17:23:24 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 22:23:24 +0000
Subject: [New-bugs-announce] [issue26547] Undocumented use of the term
 dictproxy in vars() documentation
Message-ID: <1457821404.83.0.465984707802.issue26547@psf.upfronthosting.co.za>


New submission from Julien:

I spotted un undocumented term here : https://docs.python.org/3.5/library/functions.html#vars

in: "Objects such as modules and instances have an updateable __dict__ attribute; however, other objects may have write restrictions on their __dict__ attributes (for example, classes use a dictproxy to prevent direct dictionary updates)."

The term "dictproxy" is not documented anywhere in the documentation, I assume it's a https://docs.python.org/3.4/library/types.html#types.MappingProxyType, which is right:

    >>> class Foo():
    ...     pass
    ... 
    >>> vars(Foo)
    mappingproxy({'__doc__': None, '__weakref__': <attribute '__weakref__' of 'Foo' objects>, '__dict__': <attribute '__dict__' of 'Foo' objects>, '__module__': '__main__'})

So I propose a patch to link to it via a :class:`dictproxy <types.MappingProxyType>`.

Should we leave "dictproxy" or change it to "mappingproxy" ?

----------
assignee: docs at python
components: Documentation
files: dictproxy.patch
keywords: patch
messages: 261665
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Undocumented use of the term dictproxy in vars() documentation
type: enhancement
Added file: http://bugs.python.org/file42152/dictproxy.patch

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

From report at bugs.python.org  Sat Mar 12 17:44:26 2016
From: report at bugs.python.org (Julien)
Date: Sat, 12 Mar 2016 22:44:26 +0000
Subject: [New-bugs-announce] [issue26548] Probably missing word in a
 sentence in the doc of bitwise operations on integer types
Message-ID: <1457822666.05.0.586831290634.issue26548@psf.upfronthosting.co.za>


New submission from Julien:

In https://docs.python.org/3.5/library/stdtypes.html#bitwise-operations-on-integer-types the sentence "this assumes a sufficiently large number of bits that no overflow occurs during the operation" looks wrong to me, so I asked on #python and got from @benzrf:

"this assumes that there are sufficiently many bits for no overflow to occur during the operation"

Which looks better to me.

----------
assignee: docs at python
components: Documentation
messages: 261667
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Probably missing word in a sentence in the doc of bitwise operations on integer types
type: enhancement

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

From report at bugs.python.org  Sat Mar 12 17:45:45 2016
From: report at bugs.python.org (Antti Haapala)
Date: Sat, 12 Mar 2016 22:45:45 +0000
Subject: [New-bugs-announce] [issue26549] co_stacksize is calculated from
 unoptimized code
Message-ID: <1457822745.22.0.972836245522.issue26549@psf.upfronthosting.co.za>


New submission from Antti Haapala:

When answering a question on StackOverflow, I noticed that a function that only loads a constant tuple to a local variable still has a large `co_stacksize` as if it was built with BUILD_TUPLE.

e.g.

    >>> def foo():
    ...     a = (1,2,3,4,5,6,7,8,9,10)
    ...
    >>> foo.__code__.co_stacksize
    10
    >>> dis.dis(foo)
      2           0 LOAD_CONST              11 ((1, 2, 3, 4, 5, 6, 7, 8, 9, 10))
                  3 STORE_FAST               0 (a)
                  6 LOAD_CONST               0 (None)
                  9 RETURN_VALUE

I suspect it is because in the `makecode` the stack usage is calculated from the unoptimized assembler output instead of the actual optimized bytecode. I do not know if there is any optimization that would increase the stack usage, but perhaps it should be calculated from the resulting output.

----------
components: Interpreter Core
messages: 261668
nosy: ztane
priority: normal
severity: normal
status: open
title: co_stacksize is calculated from unoptimized code
versions: Python 3.6

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

From report at bugs.python.org  Sun Mar 13 00:44:29 2016
From: report at bugs.python.org (Alejandro Soini)
Date: Sun, 13 Mar 2016 05:44:29 +0000
Subject: [New-bugs-announce] [issue26550] documentation minor issue : "Step
 back: WSGI" section from "HOWTO Use Python in the web"
Message-ID: <1457847869.95.0.52045610793.issue26550@psf.upfronthosting.co.za>


New submission from Alejandro Soini:

Bad article usage in the following sentence from the WSGI section on HOWTO Use Python in the web (https://docs.python.org/2/howto/webservers.html#wsgi) :

"Authentication is another a problem easily solved using existing middleware."

suggested change:

"Authentication is another problem that is easily solved using existing middleware."

----------
assignee: docs at python
components: Documentation
messages: 261671
nosy: Alejandro Soini, docs at python
priority: normal
severity: normal
status: open
title: documentation minor issue : "Step back: WSGI" section from "HOWTO Use Python in the web"
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Mar 13 06:15:14 2016
From: report at bugs.python.org (Alan Mislove)
Date: Sun, 13 Mar 2016 10:15:14 +0000
Subject: [New-bugs-announce] [issue26551] Regex.finditer infinite loops with
 certain input
Message-ID: <1457864114.42.0.685788531788.issue26551@psf.upfronthosting.co.za>


New submission from Alan Mislove:

I found a regex and input that causes re.finditer() to appear to get into an infinite loop.  Please see the attached minimal python script that triggers the behavior.  I've verified the bug exists on 2.7.6, 3.4.0, and 3.5.1; I haven't yet be able to test whether it also exists in the latest 3.6.

----------
components: Regular Expressions
files: bug.py
messages: 261692
nosy: Alan Mislove, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Regex.finditer infinite loops with certain input
type: crash
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file42154/bug.py

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

From report at bugs.python.org  Sun Mar 13 07:46:10 2016
From: report at bugs.python.org (Damien Nicolas)
Date: Sun, 13 Mar 2016 11:46:10 +0000
Subject: [New-bugs-announce] [issue26552] Failing ensure_future still
 creates a Task
Message-ID: <1457869570.39.0.866858008064.issue26552@psf.upfronthosting.co.za>


New submission from Damien Nicolas:

When calling asyncio.ensure_future() on a coroutine, and if the loop is closed, ensure_future() will raise a RuntimeError. 

However, it still creates a Task, which will generate a RuntimeWarning that we can?t fix since there is no way to cancel the Task.

Here is the code to reproduce the bug:


import asyncio

l = asyncio.get_event_loop()
l.close()

async def foo():
    pass

try:
    # Since the exception raises here, fut is never set
    # so we can't call fut.cancel()
    fut = asyncio.ensure_future(foo())
except RuntimeError:
    pass


# stderr:
# aio.py:12: RuntimeWarning: coroutine 'foo' was never awaited
#   pass

----------
components: asyncio
messages: 261696
nosy: gordon, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Failing ensure_future still creates a Task
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 14 02:23:33 2016
From: report at bugs.python.org (Sudheer Satyanarayana)
Date: Mon, 14 Mar 2016 06:23:33 +0000
Subject: [New-bugs-announce] [issue26553] Write HTTP in uppercase
Message-ID: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>


New submission from Sudheer Satyanarayana:

"The Requests package is recommended for a higher-level http client interface."
Change 'http' to uppercase.
https://docs.python.org/2/library/httplib.html
https://docs.python.org/2/library/urllib.html
https://docs.python.org/3/library/http.client.html

----------
assignee: docs at python
components: Documentation
messages: 261726
nosy: Sudheer Satyanarayana, docs at python
priority: normal
severity: normal
status: open
title: Write HTTP in uppercase

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

From report at bugs.python.org  Mon Mar 14 06:01:41 2016
From: report at bugs.python.org (maddin200)
Date: Mon, 14 Mar 2016 10:01:41 +0000
Subject: [New-bugs-announce] [issue26554] Missing fclose
Message-ID: <1457949701.38.0.834751371072.issue26554@psf.upfronthosting.co.za>


New submission from maddin200:

cpython\PC\bdist_wininst\install.c line 2542
missing fclose(logfile);

----------
components: Windows
messages: 261737
nosy: maddin200, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Missing fclose

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

From report at bugs.python.org  Mon Mar 14 06:29:53 2016
From: report at bugs.python.org (Marco Sulla)
Date: Mon, 14 Mar 2016 10:29:53 +0000
Subject: [New-bugs-announce] [issue26555] string.format(bytes) raise warning
Message-ID: <1457951393.78.0.559454400626.issue26555@psf.upfronthosting.co.za>


New submission from Marco Sulla:

Steps to reproduce

1. create a format_bytes.py with:

"Hello {}".format(b"World")

2. launch it with
python3 -bb format_bytes.py

Result:

Traceback (most recent call last):
  File "format_bytes.py", line 1, in <module>
    "Hello {}".format(b"World")
BytesWarning: str() on a bytes instance



Expected:

No warning

----------
components: Interpreter Core
messages: 261739
nosy: marco.sulla
priority: normal
severity: normal
status: open
title: string.format(bytes) raise warning
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 14 06:31:35 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 14 Mar 2016 10:31:35 +0000
Subject: [New-bugs-announce] [issue26556] Update expat to 2.2.1
Message-ID: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za>


New submission from Christian Heimes:

A new version of expat has been released. 2.2.1 addressed CVE-2015-1283.

----------
components: Extension Modules, XML
messages: 261741
nosy: benjamin.peterson, christian.heimes, georg.brandl, larry
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Update expat to 2.2.1
type: security
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Mar 14 07:19:00 2016
From: report at bugs.python.org (Michael Crouch)
Date: Mon, 14 Mar 2016 11:19:00 +0000
Subject: [New-bugs-announce] [issue26557] dictviews methods not present on
 shelve objects
Message-ID: <1457954340.57.0.630883947605.issue26557@psf.upfronthosting.co.za>


New submission from Michael Crouch:

Shelve types in Python 2.7 don't implement the 'viewkeys', 'viewvalues', and 'viewitems' methods.

Section 11.4 of the Python Standard Library documentation says that "Shelf objects support all methods supported by dictionaries." If those methods can't be added to shelves, the documentation should be clarified.

The use case for this was that I wanted an iterator on a shelf that didn't try to materialize the entire list (since the shelf is very large and I'd prefer to leave most of it on disk).

----------
components: Library (Lib)
messages: 261744
nosy: Michael Crouch
priority: normal
severity: normal
status: open
title: dictviews methods not present on shelve objects
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 14 09:16:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Mar 2016 13:16:41 +0000
Subject: [New-bugs-announce] [issue26558] Fix PyGILState_Check() with
 _testcapi.run_in_subinterp()
Message-ID: <1457961401.7.0.508641923687.issue26558@psf.upfronthosting.co.za>


New submission from STINNER Victor:

assert(PyGILState_Check()) cannot be used in functions called by Py_NewInterpreter(): the assertion fails.

I propose to add a flag to disable PyGILState_Check() while Py_NewInterpreter() is run to be able to add assertions in these functions.

The assertion helps to detect complex bugs like race condition in multithreaded applications.

----------
messages: 261750
nosy: haypo
priority: normal
severity: normal
status: open
title: Fix PyGILState_Check() with _testcapi.run_in_subinterp()
versions: Python 3.6

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

From report at bugs.python.org  Mon Mar 14 14:01:46 2016
From: report at bugs.python.org (David Escott)
Date: Mon, 14 Mar 2016 18:01:46 +0000
Subject: [New-bugs-announce] [issue26559] logging.handlers.MemoryHandler
 flushes on shutdown but not removal
Message-ID: <1457978506.77.0.246614135279.issue26559@psf.upfronthosting.co.za>


New submission from David Escott:

The documentation suggests using a MemoryHandler object to buffer log messages and conditionally output them. https://docs.python.org/3/howto/logging-cookbook.html#buffering-logging-messages-and-outputting-them-conditionally

However the documentation does not make clear that this only works because of the call to super(MemoryHandler, handler).flush() prior to logger.removeHandler(handler).

A direct call to handler.flush(), or simply leaving the handler unflushed until process shutdown will result in the messages still being printed, when the MemoryHandler calls self.flush() during its shutdown routines.

To be honest this behavior of MemoryHandler doesn't make much sense to me, since the MemoryHandler is in fact flushing when flush_level has not been satisfied.

I would suggest adding an option to the MemoryHandler "flush_on_close" defaulting to True, and then simply constructing the MemoryHandler with that option set to False. That would not affect the existing users of the handler, but it would result in a tool which would actually match the only example I have come across of a MemoryHandler in use online.

----------
components: Library (Lib)
messages: 261772
nosy: David Escott
priority: normal
severity: normal
status: open
title: logging.handlers.MemoryHandler flushes on shutdown but not removal
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 14 14:11:47 2016
From: report at bugs.python.org (Peter Inglesby)
Date: Mon, 14 Mar 2016 18:11:47 +0000
Subject: [New-bugs-announce] [issue26560] Error in assertion in
 wsgiref.handlers.BaseHandler.start_response
Message-ID: <1457979107.59.0.709846628148.issue26560@psf.upfronthosting.co.za>


New submission from Peter Inglesby:

The line:

  assert int(status[:3]),"Status message must begin w/3-digit code"

should be something like:

  assert status[:3].isnumeric(), "Status message must begin w/3-digit code"

----------
components: Library (Lib)
messages: 261773
nosy: inglesp
priority: normal
severity: normal
status: open
title: Error in assertion in wsgiref.handlers.BaseHandler.start_response

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

From report at bugs.python.org  Mon Mar 14 14:31:43 2016
From: report at bugs.python.org (Brian Tom)
Date: Mon, 14 Mar 2016 18:31:43 +0000
Subject: [New-bugs-announce] [issue26561] exec function fails to properly
 assign scope to dict like object
Message-ID: <1457980303.17.0.703803860627.issue26561@psf.upfronthosting.co.za>


Changes by Brian Tom <btomtom5 at gmail.com>:


----------
nosy: btomtom5
priority: normal
severity: normal
status: open
title: exec function fails to properly assign scope to dict like object
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 14 17:54:12 2016
From: report at bugs.python.org (Damian Myerscough)
Date: Mon, 14 Mar 2016 21:54:12 +0000
Subject: [New-bugs-announce] [issue26562] Large Involuntary context switches
 during oom-killer
Message-ID: <1457992452.77.0.650639243294.issue26562@psf.upfronthosting.co.za>


New submission from Damian Myerscough:

I have been running a simple script inside a Docker container to cause the container to trigger oom-killer.

>>> mem = {}
>>> for i in range(65535):
...     mem[i] = "A" * 65535

When oom-killer is trigger I see a large number of involuntary context switches and major page faults which causes a spike in CPU
and disk.


# /usr/bin/time --verbose python
Python 2.7.9 (default, Mar  1 2015, 12:57:24) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> mem = {}
>>> for i in range(65535):
...     mem[i] = "A" * 65535
... 
Command terminated by signal 9
	Command being timed: "python"
	User time (seconds): 0.13
	System time (seconds): 3.83
	Percent of CPU this job got: 17%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:22.94
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 2096516
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 33536
	Minor (reclaiming a frame) page faults: 524545
	Voluntary context switches: 30706
	Involuntary context switches: 137852
	Swaps: 0
	File system inputs: 8499072
	File system outputs: 0
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0


I tried the same test using NodeJS/C++ and I could see a lot less involuntary context switches and major page faults which indicates this could
be a Python issue.

# /usr/bin/time --verbose ./alloc_forever 1024 5 524288000
initial_alloc_amount: 1024, sleep_duration: 5, alloc_amount: 524288000
memory: 501.07MB
memory: 1001.29MB
memory: 1501.19MB
memory: 2001.09MB
Command terminated by signal 9
	Command being timed: "./alloc_forever 1024 5 524288000"
	User time (seconds): 0.63
	System time (seconds): 0.97
	Percent of CPU this job got: 7%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:21.61
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 2096536
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 11
	Minor (reclaiming a frame) page faults: 524178
	Voluntary context switches: 17
	Involuntary context switches: 284
	Swaps: 0
	File system inputs: 336
	File system outputs: 0
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

----------
messages: 261781
nosy: DamianMyerscough
priority: normal
severity: normal
status: open
title: Large Involuntary context switches during oom-killer
type: resource usage
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/issue26562>
_______________________________________

From report at bugs.python.org  Mon Mar 14 18:52:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Mar 2016 22:52:53 +0000
Subject: [New-bugs-announce] [issue26563] PyMem_Malloc(): check that the GIL
 is held in debug hooks
Message-ID: <1457995973.59.0.0490877458577.issue26563@psf.upfronthosting.co.za>


New submission from STINNER Victor:

With the issue #26558, debug hooks of PyObject_Malloc() now checks that the GIL is hold.

I left PyMem_Malloc() unchanged, because I am not 100% sure that it's ok yet to implement the same check in PyMem_Malloc(). So I opened this issue.

Python 3 doc explicitly asks that the GIL is hold to call PyMem_Malloc():
https://docs.python.org/dev/c-api/memory.html#memory-interface

Python 2 doc doesn't say anything about the GIL:
https://docs.python.org/2/c-api/memory.html#memory-interface

Usually, functions prefixed by "Py" require the GIL to be hold.

In practice, currently PyMem_Malloc() is implemented with malloc() which is thread-safe.

In the issue #26249, I tested numpy, lxml, Pillow and cryptography with all debug hooks enabled, including GIL checks in PyMem_Malloc() and PyObject_Malloc(). I only found one bug in numpy: https://github.com/numpy/numpy/pull/7404

Attached patch changes debug hooks on PyMem_Malloc() to ensure that the GIL is hold.

----------
files: pymem_gil.patch
keywords: patch
messages: 261787
nosy: haypo
priority: normal
severity: normal
status: open
title: PyMem_Malloc(): check that the GIL is held in debug hooks
versions: Python 3.6
Added file: http://bugs.python.org/file42165/pymem_gil.patch

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

From report at bugs.python.org  Mon Mar 14 20:39:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Mar 2016 00:39:56 +0000
Subject: [New-bugs-announce] [issue26564] Malloc debug hooks: display memory
 block traceback on error
Message-ID: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python implements debug hooks on Python memory allocators:
https://docs.python.org/dev/c-api/memory.html#c.PyMem_SetupDebugHooks

Problem: buffer understand and buffer overflow are only detected when a memory block is released, which may occur far from the code responsible to create the buffer.

Attached patch dumps the traceback where a memory block was allocated on error in malloc debug hooks. The feature requires to enable tracemalloc to record tracebacks.


test.py used in below example:
----
import _testcapi

def f():
    _testcapi.pymem_buffer_overflow()

f()
----


Example:
---
haypo at selma$ ./python -X tracemalloc=5 test.py 
Debug memory block at address p=0x22e8be0: API 'm'
    16 bytes originally requested
    The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected.
    The 8 pad bytes at tail=0x22e8bf0 are not all FORBIDDENBYTE (0xfb):
        at tail+0: 0x78 *** OUCH
        ...
    The block was made by call #37240 to debug malloc/realloc.
    Data at p: cb cb cb cb cb cb cb cb cb cb cb cb cb cb cb cb

Memory block traceback (most recent call first):
  File "test.py", line 4
  File "test.py", line 6

Fatal Python error: bad trailing pad byte

Current thread 0x00007f4a93d9c700 (most recent call first):
  File "test.py", line 4 in f
  File "test.py", line 6 in <module>
Abandon (core dumped)
---

The patch adds the "Memory block traceback" section.

----------
files: pymem_tb.patch
keywords: patch
messages: 261793
nosy: haypo
priority: normal
severity: normal
status: open
title: Malloc debug hooks: display memory block traceback on error
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42167/pymem_tb.patch

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

From report at bugs.python.org  Mon Mar 14 22:02:09 2016
From: report at bugs.python.org (Memeplex)
Date: Tue, 15 Mar 2016 02:02:09 +0000
Subject: [New-bugs-announce] [issue26565] [ctypes] Add value attribute to
 non basic pointers.
Message-ID: <1458007329.36.0.71536825947.issue26565@psf.upfronthosting.co.za>


New submission from Memeplex:

I know one can do addressof(p.contents), but it's a bit inconsistent that c_void_p and c_char_p contain the same information in the value attribute.

----------
components: ctypes
messages: 261794
nosy: memeplex
priority: normal
severity: normal
status: open
title: [ctypes] Add value attribute to non basic pointers.
type: enhancement

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

From report at bugs.python.org  Tue Mar 15 05:47:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Mar 2016 09:47:06 +0000
Subject: [New-bugs-announce] [issue26566] Failures on FreeBSD CURRENT
 buildbot
Message-ID: <1458035226.03.0.186362831064.issue26566@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%20CURRENT%203.x/builds/218/steps/test/logs/stdio

======================================================================
FAIL: test_terminate (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_subprocess.py", line 1679, in test_terminate
    self.assertEqual(p.wait(), -signal.SIGTERM)
AssertionError: 0 != -15

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


======================================================================
FAIL: test_main (test.test_signal.InterProcessSignalTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_signal.py", line 197, in test_main
    self.fail(tb)
AssertionError: Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_signal.py", line 180, in test_main
    self.run_test()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_signal.py", line 117, in run_test
    self.assertTrue(self.a_called)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/case.py", line 677, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true



[ 94/400/2] test_multiprocessing_main_handling
Timeout (1:00:00)!
Thread 0x0000000801815000 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/selectors.py", line 376 in select
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/subprocess.py", line 1709 in _communicate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/subprocess.py", line 1075 in communicate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/support/script_helper.py", line 86 in run_python_until_end
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/support/script_helper.py", line 96 in _assert_python
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/support/script_helper.py", line 135 in assert_python_ok
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_multiprocessing_main_handling.py", line 155 in _check_script
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_multiprocessing_main_handling.py", line 182 in test_ipython_workaround
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/case.py", line 600 in run
(...)



http://buildbot.python.org/all/builders/AMD64%20FreeBSD%20CURRENT%203.x/builds/217/steps/test/logs/stdio


[  6/400] test_multiprocessing_fork
Timeout (1:00:00)!
Thread 0x0000000801815000 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "<string>", line 2 in terminate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/_test_multiprocessing.py", line 1837 in test_terminate
(...)

----------
keywords: buildbot
messages: 261805
nosy: haypo
priority: normal
severity: normal
status: open
title: Failures on FreeBSD CURRENT buildbot
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar 15 09:15:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Mar 2016 13:15:16 +0000
Subject: [New-bugs-announce] [issue26567] Use tracemalloc to display the
 traceback where an object was allocated when a ResourceWarning is emitted
Message-ID: <1458047716.42.0.114286591066.issue26567@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python emits ResourceWarning when an object using limited resource is destroyed without being explicitly closed: files, sockets, etc. The problem is that it's hard to find where the object comes from, since the warning can occur very late, in the garbage collector, etc.

I propose to reuse tracemalloc.get_object_traceback() to show were the object was allocated, when tracemalloc traces memory allocations. In practice, I propose to add a new "source" parameter to warnings.showwarning().

Attached patch:

* Add a new keyword-only source parameter to warnings.showwarning()
* Add C function PyErr_ResourceWarning() to pass source
* showwarning() uses tracemalloc.get_object_traceback() to get the traceback were the object was allocated
* Modify socket.socket, io.FileIO and os.scandir destructor to use PyErr_ResourceWarning()


Backward-compatibility problem: The C function PyErr_ResourceWarning() always call warnings.showwarning() with the keyword parameter source. If an application replaces the warnings.showwarning() function, it will probably fail because it doesn't know the source parameter.

I don't know how to handle this backward compatibility issue.


The patch is incomplete, it's not possible yet to emit a warning in pure Python with a source parameter.


x.py script used for examples below:
-----------------
import warnings
import os
import socket

def func2():
    #f=open("/etc/issue")
    #f=os.scandir('.')
    f=socket.socket()
    f=None

def func():
    func2()

func()
-----------------


Output with Python 3.5:
-----
x.py:9: ResourceWarning: unclosed <socket.socket fd=3, ...>
  f=None
-----


Output with -X tracemalloc=5 command line option and patched Python 3.6:
-----
x.py:9: ResourceWarning: unclosed <socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 0)>
  f=None
Object allocated at (most recent call first):
  File "x.py", lineno 8
    f=socket.socket()
  File "x.py", lineno 12
    func2()
  File "x.py", lineno 14
    func()
-----

It's much easier to understand where the warning comes from, no? At x.py:8, line "f=socket.socket()".

Note: the traceback doesn't contain the function name, since tracemalloc only stores filename and line number.


See also the issue #26564 "Malloc debug hooks: display memory block traceback on error".


For Python < 3.6, I wrote "res_warn.py" script which monkey-patches io.FileIO and socket.socket to implement something similar. The script is a fragile hack. I would prefer to have the feature built-in Python.

https://bitbucket.org/haypo/misc/src/0a40f27360424145bad0f9b62c9e9148ffdbb169/python/res_warn.py

----------
files: warnings_tracemalloc.patch
keywords: patch
messages: 261812
nosy: haypo, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Use tracemalloc to display the traceback where an object was allocated when a ResourceWarning is emitted
versions: Python 3.6
Added file: http://bugs.python.org/file42171/warnings_tracemalloc.patch

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

From report at bugs.python.org  Tue Mar 15 10:32:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Mar 2016 14:32:00 +0000
Subject: [New-bugs-announce] [issue26568] Add a new warnings.showmsg()
 function taking a warnings.WarningMessage object
Message-ID: <1458052320.63.0.791464551893.issue26568@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, the warnings.showformat() function take between 4 and 6 parameters and it's not possible to add new parameters.

warnings.showformat() calls warnings.formatwarnings() with 5 parameters. Again, it's not easy to pass new parameters.

I would like to add a new "source" parameter for ResourceWarning: see issue #26567 "ResourceWarning: Use tracemalloc to display the traceback where an object was allocated when a ResourceWarning is emitted".

To make warnings extensible, I propose to:

* Add new showmsg() and formatmsg() functions to the warnings module, these functions take a warnings.WarningMessage instance
* The _warnings module calls warnings.showmsg() rather than warnings.showwarning()
* For backward compatibility, warnings.showmsg() calls warnings.showwarning() if warnings.showwarning() was replaced. Same for warnings.formatmsg(): call warnings.formatwarning() if replaced.

Attached patch implements these changes.

With these changes, the warnings looks a little bit more like the logging module and its logging.LogRecord class.

The patch is incomplete, it doesn't add much tests yet and it doesn't touch the documentation. I would prefer to get the new API (and the whole idea) approved before going too far.

Note: If warnings.showwarning is deleted ("del warnings.showwarning"), showmsg() uses its own implementation. Same for formatmsg().

----------
files: warnings_showmsg.patch
keywords: patch
messages: 261814
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a new warnings.showmsg() function taking a warnings.WarningMessage object
versions: Python 3.6
Added file: http://bugs.python.org/file42172/warnings_showmsg.patch

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

From report at bugs.python.org  Tue Mar 15 18:56:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Mar 2016 22:56:21 +0000
Subject: [New-bugs-announce] [issue26569] pyclbr.readmodule() and
 pyclbr.readmodule_ex() doens't support packages
Message-ID: <1458082581.41.0.63127238645.issue26569@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While working on the issue #26295 which converts the test module to a package, I noticed that pyclbr doesn't work with packages: test_pyclbr fails when test becomes a package.

Attached patch fixes pyclbr._readmodule():

* Replace "spec.loader.is_package(fullmodule)" test with "spec.submodule_search_locations is not None" to check is the module is a package
* for a package, use spec.submodule_search_locations to build __path__

I don't know importlib well enough to say if my usage of importlib spec is correct.

----------
files: pyclbr.patch
keywords: patch
messages: 261832
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: pyclbr.readmodule() and pyclbr.readmodule_ex() doens't support packages
versions: Python 3.6
Added file: http://bugs.python.org/file42176/pyclbr.patch

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

From report at bugs.python.org  Wed Mar 16 00:29:38 2016
From: report at bugs.python.org (Ilya Kreymer)
Date: Wed, 16 Mar 2016 04:29:38 +0000
Subject: [New-bugs-announce] [issue26570] comma-separated cookies with
 expires header do not parse properly
Message-ID: <1458102578.18.0.474747054638.issue26570@psf.upfronthosting.co.za>


New submission from Ilya Kreymer:

This is a peculiar regression in 3.5 where a comma-separated cookie following an expires field is considered invalid:

Ex: which results in a silent error/empty cookie in 3.5.1

Python 3.5.1 (default, Dec 26 2015, 18:11:22) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from http.cookies import SimpleCookie
>>> SimpleCookie('A=B; expires=Thu, 01-Jan-1970 00:00:00 GMT, C=D')
<SimpleCookie: >

compared to 3.4.2 and 2.7.9

Python 3.4.2 (default, Jan 29 2015, 06:45:30) 
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from http.cookies import SimpleCookie
>>> SimpleCookie('A=B; expires=Thu, 01-Jan-1970 00:00:00 GMT, C=D')
<SimpleCookie: A='B' C='D'>

Python 2.7.9 (default, Jan 29 2015, 06:28:46) 
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Cookie import SimpleCookie
>>> SimpleCookie('A=B; expires=Thu, 01-Jan-1970 00:00:00 GMT, C=D')
<SimpleCookie: A='B' C='D'>




This seems to specifically happen when the expires field is the last field in the cookie.
eg, this works as expected:

>>> SimpleCookie('A=B; expires=Thu, 01-Jan-1970 00:00:00 GMT; Path=/, C=D')
<SimpleCookie: A='B' C='D'>

I'm not sure if this is related to the other comma-related cookie bugs, such as issue26302 as this does not appear to use the same regex at first glance. I have not had a chance to track it down it further.

----------
components: Library (Lib)
messages: 261839
nosy: ikreymer
priority: normal
severity: normal
status: open
title: comma-separated cookies with expires header do not parse properly
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 16 00:59:15 2016
From: report at bugs.python.org (Ellison Marks)
Date: Wed, 16 Mar 2016 04:59:15 +0000
Subject: [New-bugs-announce] [issue26571] turtle regression in 3.5
Message-ID: <1458104355.45.0.620158354917.issue26571@psf.upfronthosting.co.za>


New submission from Ellison Marks:

I noticed some odd behaviour when running some turtle code I wrote using python 3.5. A simplified example:

>>> from turtle import Turtle
>>> t = Turtle()
>>> t.getscreen().bye() # or manually close the turtle window
>>> t2 = Turtle()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.5/turtle.py", line 3816, in __init__
    visible=visible)
  File "/usr/lib64/python3.5/turtle.py", line 2557, in __init__
    self._update()
  File "/usr/lib64/python3.5/turtle.py", line 2660, in _update
    self._update_data()
  File "/usr/lib64/python3.5/turtle.py", line 2646, in _update_data
    self.screen._incrementudc()
  File "/usr/lib64/python3.5/turtle.py", line 1292, in _incrementudc
    raise Terminator
turtle.Terminator
>>>

This code works under 3.4, opening a new turtle window the second time Turtle() is called. Under 3.5, a blank white window opens.

This seems to be related to https://hg.python.org/cpython/rev/1628484c9408, as the only point that raises Terminator is guarded by a check for `if not TurtleScreen._RUNNING:`

----------
components: Library (Lib)
messages: 261840
nosy: Ellison Marks
priority: normal
severity: normal
status: open
title: turtle regression in 3.5
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 16 17:01:16 2016
From: report at bugs.python.org (Rob Church)
Date: Wed, 16 Mar 2016 21:01:16 +0000
Subject: [New-bugs-announce] [issue26572] urlparse does not handle passwords
 with ? in them.
Message-ID: <1458162076.53.0.59602489258.issue26572@psf.upfronthosting.co.za>


New submission from Rob Church:

>>> urlparse('http://user:pass?word at example.com/path?query')
ParseResult(scheme='http', netloc='user:pass', path='', params='', query='word at example.com/path?query', fragment='')

Expected output is:

ParseResult(scheme='http', netloc='user:pass?word at example.com', path='/path', params='', query='query', fragment='')

----------
components: Library (Lib)
messages: 261860
nosy: Rob Church
priority: normal
severity: normal
status: open
title: urlparse does not handle passwords with ? in them.
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 16 17:12:11 2016
From: report at bugs.python.org (G Young)
Date: Wed, 16 Mar 2016 21:12:11 +0000
Subject: [New-bugs-announce] [issue26573] Method Parameters can be Accepted
 as Keyword Arguments?
Message-ID: <1458162731.32.0.603859986018.issue26573@psf.upfronthosting.co.za>


New submission from G Young:

This issue arose as we were making changes to the 'pandas' library. I am not sure if this is a bug or feature, but it definitely did not cross anyone's minds when discussing the PR at hand. I have attached a code sample to illustrate the "bug" that I have run successfully on Python 2.7 and Python 3.4.

----------
components: Interpreter Core
files: bug.py
messages: 261862
nosy: G Young
priority: normal
severity: normal
status: open
title: Method Parameters can be Accepted as Keyword Arguments?
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file42178/bug.py

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

From report at bugs.python.org  Wed Mar 16 19:28:10 2016
From: report at bugs.python.org (Josh Snider)
Date: Wed, 16 Mar 2016 23:28:10 +0000
Subject: [New-bugs-announce] [issue26574] replace_interleave can be
 optimized for single character byte strings
Message-ID: <1458170890.63.0.147886169107.issue26574@psf.upfronthosting.co.za>


New submission from Josh Snider:

replace_interleave in Objects/bytesobject.c and Objects/bytearrayobject.c can be optimized for the special case where the interleaving byte string is a single character.

Here's some quick results from timeit showing that it's about three times faster for the special case.
* Before (cold start):
>>> timeit.timeit('(b"x" * 2000000).replace(b"", b".")', number=1000)
7.619218342995737
* After (cold start):
>>> timeit.timeit('(b"x" * 2000000).replace(b"", b".")', number=1000)
2.7605581780080684

For the non-special case, running timeit.timeit('(b"x" * 2000000).replace(b"", b".0")', number=10000) takes ~173 seconds on both versions.

----------
components: Library (Lib)
files: bytes.patch
keywords: patch
messages: 261870
nosy: Josh Snider
priority: normal
severity: normal
status: open
title: replace_interleave can be optimized for single character byte strings
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42179/bytes.patch

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

From report at bugs.python.org  Thu Mar 17 01:52:46 2016
From: report at bugs.python.org (David Goffredo)
Date: Thu, 17 Mar 2016 05:52:46 +0000
Subject: [New-bugs-announce] [issue26575] lambda not closed on specific
 value in comprehension
Message-ID: <1458193966.9.0.501665269138.issue26575@psf.upfronthosting.co.za>


New submission from David Goffredo:

A series of lambdas referring to a variable in a comprehension do not hold distinct values, while conventional higher order function do.

PS C:\Users\David\Desktop> python
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Caller:
...     def __init__(self, f):
...         self._f = f
...     def start(self):
...         print(self._f())
...
>>> def asFunc(boundValue):
...     def func():
...         return boundValue
...     return func
...
>>> for caller in [Caller(asFunc(x)) for x in range(5)]:
...     caller.start()
...
0
1
2
3
4
>>> for caller in [Caller(lambda: x) for x in range(5)]:
...     caller.start()
...
4
4
4
4
4
>>>

----------
messages: 261885
nosy: David Goffredo
priority: normal
severity: normal
status: open
title: lambda not closed on specific value in comprehension
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 17 02:29:58 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 17 Mar 2016 06:29:58 +0000
Subject: [New-bugs-announce] [issue26576] Tweak wording of decorator docos
Message-ID: <1458196198.66.0.0478952577579.issue26576@psf.upfronthosting.co.za>


New submission from Chris Angelico:

The official documentation declares an unambiguous equivalence which is not true in some corner cases:

    @deco
    def f(x): pass

is not quite the same as

    def f(x): pass
    f = deco(f)

as the name is never bound to the undecorated function. This is what makes @property and @prop.setter work; otherwise, the undecorated setter function would overwrite the property, and the decoration would fail. Attached patch loosens the wording slightly to "broadly equivalent"; this permits corner cases to vary from the equivalence, while still retaining its simplicity for the 99% of cases where it's correct. (Think of explaining "yield from iter" as "for x in iter: yield x" and you have a similar near-equivalence.)

Also, class decorators aren't required to return classes. Text removed saying that they do.

----------
assignee: docs at python
components: Documentation
files: deco-docos.patch
keywords: patch
messages: 261888
nosy: Rosuav, docs at python
priority: normal
severity: normal
status: open
title: Tweak wording of decorator docos
Added file: http://bugs.python.org/file42181/deco-docos.patch

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

From report at bugs.python.org  Thu Mar 17 03:40:30 2016
From: report at bugs.python.org (Ryan Fox)
Date: Thu, 17 Mar 2016 07:40:30 +0000
Subject: [New-bugs-announce] [issue26577] inspect.getclosurevars returns
 incorrect variable when using class member with the same name as other
 variable
Message-ID: <1458200430.96.0.916440482942.issue26577@psf.upfronthosting.co.za>


New submission from Ryan Fox:

If a variable 'x' exists in the global or local scope, and a function (also defined in the same scope as 'x', or lower) refers only to a member named 'x' of an object, inspect.getclosurevars will include a reference to the variable, rather than the member.

Okay, that's kind of confusing to describe, so here's a small example in code form:

import inspect

class Foo:
    x = int()

x = 1
f = Foo()
assert(f.x != x)

func = lambda: f.x == 0
assert(func())

cv = inspect.getclosurevars(func)
assert(cv.globals['f'] == f)
assert(cv.globals.get('x') != x) # <--- Assertion fails


It is expected that 'x' would not exist in cv.globals, since func does not refer to it. Also, there should be a 'f.x' included somewhere in the ClosureVariables object returned.

----------
components: Library (Lib)
messages: 261897
nosy: Ryan Fox
priority: normal
severity: normal
status: open
title: inspect.getclosurevars returns incorrect variable when using class member with the same name as other variable
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar 17 03:42:36 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 17 Mar 2016 07:42:36 +0000
Subject: [New-bugs-announce] [issue26578] Bad BaseHTTPRequestHandler
 response when using HTTP/0.9
Message-ID: <1458200556.85.0.71774056033.issue26578@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

BaseHTTPRequestHandler in http.server supports HTTP/0.9. But the response for HTTP/0.9 request is implemented wrong. 

Response of HTTP/0.9 request returns message body directly without status line and headers. But if you inherit BaseHTTPRequestHandler and set the default_request_version to "HTTP/1.x", then self.request_version can never be "HTTP/0.9" since in the https://hg.python.org/cpython/file/tip/Lib/http/server.py#l315 branch it does not set version to "HTTP/0.9" and then always sends the status line and headers back.

A trivial patch can fix this problem that set version to "HTTP/0.9" in the branch. But this will cause some failure in tests. The tests in test_httpservers use http.client.HTTPConnection to send and receive HTTP message. But since 3.4, HTTPConnection doesn't support HTTP/0.9-style simple responses. We can use it to test HTTP/0.9 connection if the server is implemented in the right way.

And since http.client.HTTPConnection has dropped the support for HTTP/0.9, is it reasonable to drop the support in http.server too?

----------
components: Library (Lib)
messages: 261898
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Bad BaseHTTPRequestHandler response when using HTTP/0.9
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar 17 04:43:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Mar 2016 08:43:06 +0000
Subject: [New-bugs-announce] [issue26579] Support pickling slots in
 subclasses of common classes
Message-ID: <1458204186.54.0.651323931278.issue26579@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Pickling and copying instances of subclasses of some basic classes pickles and copies instance attributes. Example:

>>> class BA(bytearray):
...     pass
... 
>>> b = BA(b'abc')
>>> b.x = 10
>>> c = copy.copy(b)
>>> c.x
10
>>> c = pickle.loads(pickle.dumps(b))
>>> c.x
10

But this doesn't work if attributes are saved not in instance dictionary, but in slots.

>>> class BA(bytearray):
...     __slots__ = ('x',)
... 
>>> b = BA(b'abc')
>>> b.x = 10
>>> c = copy.copy(b)
>>> c.x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: x
>>> c = pickle.loads(pickle.dumps(b))
>>> c.x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: x

Since using __slots__ is implementation detail, this failure can be considered as a bug.

Proposed patch adds support of pickling and copying slots in subclasses of all classes that already support pickling and copying non-slot attributes. It is backward compatible, classes with slots can be unpickled on older Python versions without slots. Affected classes: bytearray, set, frozenset, weakref.WeakSet, collections.OrderedDict, collections.deque, datetime.tzinfo.

The patch adds the copyreg._getstate() function for Python classes and exposes the _PyObject_GetState() function for extension classes. An alternative (and simpler for end user) solution would be to add default implementation as object.__getstate__(). But this is not easy to reject non-pickleable classes (issue22995) in this case, since __getstate__ is looked up as instance attribute, not as other special methods.

----------
components: Extension Modules, Library (Lib)
files: copyreg_getstate.patch
keywords: patch
messages: 261903
nosy: alexandre.vassalotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Support pickling slots in subclasses of common classes
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42183/copyreg_getstate.patch

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

From report at bugs.python.org  Thu Mar 17 07:52:24 2016
From: report at bugs.python.org (Alex Walters)
Date: Thu, 17 Mar 2016 11:52:24 +0000
Subject: [New-bugs-announce] [issue26580] Documentation for ftplib still
 references ftpmirror.py
Message-ID: <1458215544.62.0.0104806566658.issue26580@psf.upfronthosting.co.za>


New submission from Alex Walters:

in #23130 ftpmirror.py was removed from the python source distribution.  The documentation still references this, and sends people looking for the file (ostensibly as an example of how to use ftplib).

----------
assignee: docs at python
components: Documentation
messages: 261908
nosy: docs at python, tritium
priority: normal
severity: normal
status: open
title: Documentation for ftplib still references ftpmirror.py
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/issue26580>
_______________________________________

From report at bugs.python.org  Thu Mar 17 08:00:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Mar 2016 12:00:36 +0000
Subject: [New-bugs-announce] [issue26581] Double coding cookie
Message-ID: <1458216036.14.0.237579161127.issue26581@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When Python source file contains double coding cookies on different lines, the first wins. When it contains double coding cookies on the same line, the last wins.

PEP 263 was sufficiently vague about this. Now this is clarified (22490711c870). The first coding cookie should always win.

Proposed patch fixes Python tokenizer, the tokenize module, and other places. Tests are taken from issue25643.

----------
components: Interpreter Core, Library (Lib)
files: tokenize_double_coding.patch
keywords: patch
messages: 261909
nosy: gvanrossum, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Double coding cookie
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42185/tokenize_double_coding.patch

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

From report at bugs.python.org  Thu Mar 17 10:45:53 2016
From: report at bugs.python.org (awilfox)
Date: Thu, 17 Mar 2016 14:45:53 +0000
Subject: [New-bugs-announce] [issue26582] asyncio documentation links to
 wrong CancelledError
Message-ID: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za>


New submission from awilfox:

In the 3.5 and 3.6a0 documentation for asyncio, "CancelledError" is linked to the concurrent.futures.CancelledError.  This led me to try catching that exception and finding that it did not work correctly at all.  Only after searching for asyncio example code and seeing how other people caught asyncio.CancelledError did I realise the issue.

The fact asyncio.CancelledError even exists isn't actually documented, and I believe that is why the :exc: reference is linking to the wrong module.

----------
assignee: docs at python
components: Documentation
messages: 261911
nosy: awilfox, docs at python
priority: normal
severity: normal
status: open
title: asyncio documentation links to wrong CancelledError
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar 17 13:16:47 2016
From: report at bugs.python.org (Peter Inglesby)
Date: Thu, 17 Mar 2016 17:16:47 +0000
Subject: [New-bugs-announce] [issue26583] test_timestamp_overflow fails
Message-ID: <1458235007.87.0.738177495403.issue26583@psf.upfronthosting.co.za>


New submission from Peter Inglesby:

I get the following test failure against changeset 100576 on OSX 10.9.5:

$ ./python.exe -m test test_import
[1/1] test_import
test test_import failed -- Traceback (most recent call last):
  File "/Users/peteringlesby/src/cpython/Lib/test/test_import/__init__.py", line 301, in test_timestamp_overflow
    os.stat(compiled)
FileNotFoundError: [Errno 2] No such file or directory: '__pycache__/@test_68937_tmp.cpython-36.pyc'

1 test failed:
    test_import

----------
messages: 261919
nosy: inglesp
priority: normal
severity: normal
status: open
title: test_timestamp_overflow fails
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar 17 14:20:00 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 17 Mar 2016 18:20:00 +0000
Subject: [New-bugs-announce] [issue26584] pyclbr module needs to be more
 flexible on loader support
Message-ID: <1458238800.08.0.676127110581.issue26584@psf.upfronthosting.co.za>


New submission from Eric Snow:

(see issue26569)

The pyclbr module is showing its age (born 1995).  It assumes there are only 2 module types (builtin and source-based), particularly in readmodule() and readmodule_ex().  Really it should be source-based and "everything else".

For instance, it does not handle namespace packages correctly, since the spec.loader is set to None there.  It also doesn't handle frozen modules (e.g. "./python Lib/pyclbr.py _frozen_importlib").  This is likewise a problem for other/custom loaders that don't match the expectations of pyclbr.

Here are some things that should be done:

* replace custom introspection code with newer tools like importlib.util.module_from_spec()
* special-case namespace modules (since their spec.loader is None); this is probably a moot point if module_from_spec() gets used
* ignore more than just builtins; explicitly check for importlib.abc.SourceLoader?
* make use of similar tools in the inspect module?

----------
components: Library (Lib)
messages: 261924
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: pyclbr module needs to be more flexible on loader support
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar 17 23:18:06 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 18 Mar 2016 03:18:06 +0000
Subject: [New-bugs-announce] [issue26585] Use html.escape to replace
 _quote_html in http.server
Message-ID: <1458271086.94.0.0961534377342.issue26585@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

In http.server, _quote_html is used to escape content for BaseHTTPServer. The function has already been implemented by html.escape.

----------
components: Library (Lib)
files: _quote_html_to_html_escape.patch
keywords: patch
messages: 261943
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Use html.escape to replace _quote_html in http.server
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42195/_quote_html_to_html_escape.patch

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

From report at bugs.python.org  Fri Mar 18 00:06:16 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 18 Mar 2016 04:06:16 +0000
Subject: [New-bugs-announce] [issue26586] Simple enhancement to
 BaseHTTPRequestHandler
Message-ID: <1458273976.86.0.666454727881.issue26586@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

This patch propose several simple enhancement to BaseHTTPRequestHandler. It removes some redundant code and add handler for too many headers.

----------
components: Library (Lib)
files: simple_enhancement.patch
keywords: patch
messages: 261946
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Simple enhancement to BaseHTTPRequestHandler
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42196/simple_enhancement.patch

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

From report at bugs.python.org  Fri Mar 18 06:23:00 2016
From: report at bugs.python.org (Wolfgang Langner)
Date: Fri, 18 Mar 2016 10:23:00 +0000
Subject: [New-bugs-announce] [issue26587] Possible duplicate entries in
 sys.path if .pth files are used with zip's
Message-ID: <1458296580.88.0.236395091392.issue26587@psf.upfronthosting.co.za>


New submission from Wolfgang Langner:

In site.py there is the internal function _init_pathinfo() This function builds a set of path entries from sys.path. This is used to avoid duplicate entries in sys.path.
But this function has a check if it is a directory with os.path.isdir(...). All this is fine as long as someone has a .zip file in sys.path or a zipfile subpath. Then the path entry is not part of the set. With this duplicate detection with none directories does not work.

The fix is as simple as removing the os.path.isdir(...) line and fixing the indent. Also the docstring should be modified.

Detected by using this function in a project reusing addsitedir(...) functionality to add another path with .pth processing.

----------
components: Library (Lib)
messages: 261958
nosy: tds333
priority: normal
severity: normal
status: open
title: Possible duplicate entries in sys.path if .pth files are used with zip's
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Mar 18 17:39:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Mar 2016 21:39:27 +0000
Subject: [New-bugs-announce] [issue26588] _tracemalloc: add support for
 multiple address spaces (domains)
Message-ID: <1458337167.06.0.908004959718.issue26588@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The tracemalloc module uses a hashtable: pointer (void*) => trace. Some embedded devices use multiple address spaces. Each GPU also has its own address space. CUDA, OpenCL and OpenGL should also be seen as different address spaces.

In the issue #26530, it was proposed (required?) to support multiple addresses spaces to be able to use tracemalloc in numpy.

Attached patch enhances tracemalloc to use (pointer: void*, domain: unsigned int) as key in the hashtable. A (pointer, domain) key is stored in a hashtable entry.

In the patch, the domain is hardcoded to 0, but the issue #26530 will add new C functions to track/untrack memory blocks, and this new functions will have a domain parameter.

The patch changes how a key is passed to the hashtable API: pass a *pointer* to a key rather than directly the key value. Because of that, the patch is quite long.

The patch also removes the unused function _Py_hashtable_hash_int().

_Py_HASHTABLE_ENTRY_DATA() macro now requires the hashtable to get the key size, since the offset of data now depends on the key size.

----------
components: Extension Modules
files: tracemalloc.patch
keywords: patch
messages: 261997
nosy: haypo, njs, pitrou
priority: normal
severity: normal
status: open
title: _tracemalloc: add support for multiple address spaces (domains)
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42207/tracemalloc.patch

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

From report at bugs.python.org  Fri Mar 18 18:23:16 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Mar 2016 22:23:16 +0000
Subject: [New-bugs-announce] [issue26589] Add HTTP Response code 451
Message-ID: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

https://tools.ietf.org/html/rfc7725

----------
components: Library (Lib)
files: code451.diff
keywords: patch
messages: 262000
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Add HTTP Response code 451
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42208/code451.diff

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

From report at bugs.python.org  Fri Mar 18 21:31:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Mar 2016 01:31:15 +0000
Subject: [New-bugs-announce] [issue26590] socket destructor: implement
 finalizer
Message-ID: <1458351075.41.0.994766438444.issue26590@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PEP 442 helped to make object finalization safer, but it's just an API, it's not widely used in the Python core yet. io.FileIO has a nice implementation, but socket.socket and os.scandir don't.

I noticed this while working on the issue #26567 which indirectly resurected a destroyed socket (in test_socket).

As I workaround, I reverted my change on socket destructor, but I'm interested to enhance socket destructor to be able to use the new tracemalloc feature of the warnings module.

----------
messages: 262014
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: socket destructor: implement finalizer
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Mar 19 03:48:40 2016
From: report at bugs.python.org (jason crockett)
Date: Sat, 19 Mar 2016 07:48:40 +0000
Subject: [New-bugs-announce] [issue26591] datetime datetime.time to
 datetime.time comparison does nothing
Message-ID: <1458373720.99.0.780228236927.issue26591@psf.upfronthosting.co.za>


New submission from jason crockett:

if datetime.time(#blah) > datetime.time(#blah):
      [a]                        [b]

does nothing.. it doesnt raise an error. it doesnt run the if function even though the printout of variables compared says it should.

22:15:00 [a]
16:00:00 [b]
True
22:20:00
16:00:00
True
22:25:00
16:00:00

----------
components: Extension Modules
messages: 262027
nosy: jason crockett
priority: normal
severity: normal
status: open
title: datetime datetime.time to datetime.time comparison does nothing
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 19 09:34:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Mar 2016 13:34:14 +0000
Subject: [New-bugs-announce] [issue26592] _warnings.warn_explicit() should
 try to import the warnings module
Message-ID: <1458394454.81.0.10940568277.issue26592@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #26567 enhanced the warnings module to pass the destroyed object on ResourceWarning. The implementation to log the traceback where the object was allocated is non trivial, so I chose to only implement it in Python.

Problem: _warnings.warn_explicit() is lazy, it tries to get the warnings module from sys.modules, but it uses its own logger if the warnings is not imported yet.

As a consequence, the traceback where the object was allocated is only logged if tracemalloc is tracing Python memory allocations *and* if the warnings module is already imported.

I suggest to modify _warnings.warn_explicit() to import the warnings if it's not imported yet.

There are maybe issues to import a module during Python finalization? A comprise is to not try to import when Python finalization has started.

Example:
---
#import warnings
import tracemalloc
tracemalloc.start(10)
f = open("/etc/issue")
f = None
---

Current output:
---
x.py:5: ResourceWarning: unclosed file <_io.TextIOWrapper name='/etc/issue' mode='r' encoding='UTF-8'>
  f = None
---

Output if you uncomment the "import warnings":
---
x.py:5: ResourceWarning: unclosed file <_io.TextIOWrapper name='/etc/issue' mode='r' encoding='UTF-8'>
  f = None
Object allocated at (most recent call first):
  File "x.py", lineno 4
    f = open("/etc/issue")
---

Attached patch tries to import warnings if source object is set but not after the Pythin finalization has started.

----------
files: warnings_import.patch
keywords: patch
messages: 262049
nosy: haypo
priority: normal
severity: normal
status: open
title: _warnings.warn_explicit() should try to import the warnings module
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42217/warnings_import.patch

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

From report at bugs.python.org  Sun Mar 20 03:26:33 2016
From: report at bugs.python.org (Andrew Szeto)
Date: Sun, 20 Mar 2016 07:26:33 +0000
Subject: [New-bugs-announce] [issue26593] silly typo in logging cookbook
Message-ID: <1458458793.09.0.189282246745.issue26593@psf.upfronthosting.co.za>


New submission from Andrew Szeto:

In all versions of https://docs.python.org/3/howto/logging-cookbook.html, there is a very silly typo. It bothered me, and I wanted to get a taste of the patching workflow for contribution to Python, so I figured I'd write a patch.

----------
assignee: docs at python
components: Documentation
files: doc-logging-cookbook-capitalization.patch
keywords: patch
messages: 262060
nosy: Andrew Szeto, docs at python
priority: normal
severity: normal
status: open
title: silly typo in logging cookbook
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42219/doc-logging-cookbook-capitalization.patch

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

From report at bugs.python.org  Sun Mar 20 08:38:56 2016
From: report at bugs.python.org (Erwin Berkouwer)
Date: Sun, 20 Mar 2016 12:38:56 +0000
Subject: [New-bugs-announce] [issue26594] Tutorial example IndentationError?
Message-ID: <1458477536.83.0.48504738422.issue26594@psf.upfronthosting.co.za>


New submission from Erwin Berkouwer:

being totally new to Python, I tried actually doing the examples from the beginners guide (real RTFM ;-)

however I fail at the first example, with an error message that I don't understand. please clarify. attached file is screenprint from documentation, below what's on my screen (note I keyed in the example, no copy/paste, but I think correctly)

Also adding spaces or a tab doesn't get rid of the error.


C:\Users\erwin>python
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> the_world_is_flat = True
>>> if the_world_is_flat:
... print("be careful not to fall off!")
  File "<stdin>", line 2
    print("be careful not to fall off!")
        ^
IndentationError: expected an indented block

----------
assignee: docs at python
components: Documentation
files: IndentationError.jpg
messages: 262072
nosy: Erwin Berkouwer, docs at python
priority: normal
severity: normal
status: open
title: Tutorial example IndentationError?
versions: Python 3.5
Added file: http://bugs.python.org/file42223/IndentationError.jpg

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

From report at bugs.python.org  Sun Mar 20 10:14:22 2016
From: report at bugs.python.org (Emin Ghuliev)
Date: Sun, 20 Mar 2016 14:14:22 +0000
Subject: [New-bugs-announce] [issue26595] Segfault on Pointer operation
Message-ID: <1458483262.43.0.687206003965.issue26595@psf.upfronthosting.co.za>


New submission from Emin Ghuliev:

I'm trying use a pointer on python script but when executing the following code getting error. (Segmentation fault)


dmr at debian:~$ python test.py
Segmentation fault


self.mem  = c_char_p(mem)

pointer(self.binning())[0] = 0x41414141


output: 
[----------------------------------registers-----------------------------------]
EAX: 0x0 
EBX: 0xb7aee000 --> 0x21e4c 
ECX: 0x1 
EDX: 0x41414141 ('AAAA')
ESI: 0x41414141 ('AAAA')
EDI: 0x41414141 ('AAAA')
EBP: 0xb7b0eb3c --> 0xc ('\x0c')
ESP: 0xbfffeb74 --> 0x0 
EIP: 0xb7dfc4b6 (<__strlen_sse2_bsf+22>:	movdqu xmm1,XMMWORD PTR [edi])
EFLAGS: 0x10287 (CARRY PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0xb7dfc4ad <__strlen_sse2_bsf+13>:	pxor   xmm0,xmm0
   0xb7dfc4b1 <__strlen_sse2_bsf+17>:	cmp    ecx,0x30
   0xb7dfc4b4 <__strlen_sse2_bsf+20>:	ja     0xb7dfc4cd <__strlen_sse2_bsf+45>
=> 0xb7dfc4b6 <__strlen_sse2_bsf+22>:	movdqu xmm1,XMMWORD PTR [edi]
   0xb7dfc4ba <__strlen_sse2_bsf+26>:	pcmpeqb xmm0,xmm1
   0xb7dfc4be <__strlen_sse2_bsf+30>:	pmovmskb edx,xmm0
   0xb7dfc4c2 <__strlen_sse2_bsf+34>:	test   edx,edx
   0xb7dfc4c4 <__strlen_sse2_bsf+36>:	jne    0xb7dfc539 <__strlen_sse2_bsf+153>
[------------------------------------stack-------------------------------------]


BUG on ctypes module 

.//source/cfield.c:1328

static PyObject *
z_get(void *ptr, unsigned size)
{
        /* XXX What about invalid pointers ??? */
        if (*(void **)ptr) {
#if defined(MS_WIN32) && !defined(_WIN32_WCE)
                if (IsBadStringPtrA(*(char **)ptr, -1)) {
                        PyErr_Format(PyExc_ValueError,
                                     "invalid string pointer %p",
                                     *(char **)ptr);
                        return NULL;
                }
#endif
                return PyString_FromString(*(char **)ptr); < === passing pointer as argument
        } else {
                Py_INCREF(Py_None);
                return Py_None;
        }
}
./Objects/stringobject.c:
PyObject *
PyString_FromString(const char *str = this value assigned to 0x41414141 address)
{
	register size_t size;
	register PyStringObject *op;

	assert(str != NULL);
	size = strlen(str); <==== argument address 0x41414141

----------
files: alloc.py
messages: 262077
nosy: Emin Ghuliev
priority: normal
severity: normal
status: open
title: Segfault on Pointer operation
Added file: http://bugs.python.org/file42224/alloc.py

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

From report at bugs.python.org  Sun Mar 20 19:33:48 2016
From: report at bugs.python.org (Jose)
Date: Sun, 20 Mar 2016 23:33:48 +0000
Subject: [New-bugs-announce] [issue26596] numpy.all np.all .all
Message-ID: <1458516828.41.0.109347994463.issue26596@psf.upfronthosting.co.za>


New submission from Jose:

the numpy.all function does not work.
I created 
A = np.random.random((10,1))
np.all(A)<1 gives me False, which is wrong!
and
B = 2 * A
np.all(B)<2 gives me True, which is correct!

also np.sum(A) < 10, gives me True, which is correct!

----------
components: Macintosh
files: Screen Shot 2016-03-20 at 4.33.22 PM.png
messages: 262093
nosy: JoseLight, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: numpy.all np.all .all
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42226/Screen Shot 2016-03-20 at 4.33.22 PM.png

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

From report at bugs.python.org  Sun Mar 20 20:44:32 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 21 Mar 2016 00:44:32 +0000
Subject: [New-bugs-announce] [issue26597] Document how to cite Python
Message-ID: <1458521072.31.0.998709728719.issue26597@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

Add either a FAQ or a new page under "Meta Information" in the documentation for how to formally cite Python in scientific papers or other academic situations.

See thread on Python-Ideas here for justification and further discussion:

https://mail.python.org/pipermail/python-ideas/2016-March/038816.html

----------
assignee: docs at python
components: Documentation
messages: 262096
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Document how to cite Python
type: enhancement

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

From report at bugs.python.org  Mon Mar 21 01:05:16 2016
From: report at bugs.python.org (Simon)
Date: Mon, 21 Mar 2016 05:05:16 +0000
Subject: [New-bugs-announce] [issue26598] Embbedable zip does not import
 modules in (zip)subdirectory
Message-ID: <1458536716.69.0.0292011453311.issue26598@psf.upfronthosting.co.za>


New submission from Simon:

I downloaded the Embeddable zip file from the Python site, (https://www.python.org/downloads/release/python-351/) and rand the code below.

When I run the code below certain modules are not imported while others are imported fine.
The modules that are not imported seem to be the ones sub-directories within the zip file.

(omitted obvious code, error checking and some cleanup)

...
    int main()
    {
      // ... 
      Py_SetProgramName(L"AAAAA"); 
      Py_SetPath(L"path\\to\\python35.zip"); // embeddable from the python site. 
      Py_Initialize(); 
      PyThreadState *mainstate = PyThreadState_Get(); 
      PyInterpreterState* mainInterpreterState = mainstate->interp; 
      
      PyObject *main_module = PyImport_AddModule("__main__"); 
      PyObject *main_dict = PyModule_GetDict(main_module); 
      PyObject *local_dic = PyDict_New(); 
    
      const char* s = "import ctypes\n"; 
      PyObject * PyRes = PyRun_String(s, Py_file_input, main_dict, local_dic); 
      PyObject* ex = PyErr_Occurred(); 
      if (NULL != ex) 
      { 
        //  didn't work, import error. 
      } 
    }

The exact same code above manages to import other modules as long as they are located inside the root of the zip file.

modules like json/ctypes and so on are not imported as they are in a sub directory.

----------
messages: 262101
nosy: SimonG, amaury.forgeotdarc, belopolsky, meador.inge, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embbedable zip does not import modules in (zip)subdirectory
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 21 03:41:09 2016
From: report at bugs.python.org (=?utf-8?b?SMawbmcgTmd1eeG7hW4gVmnhu4d0?=)
Date: Mon, 21 Mar 2016 07:41:09 +0000
Subject: [New-bugs-announce] [issue26599] segfault at 24 error 6 in python
Message-ID: <1458546069.08.0.503097736938.issue26599@psf.upfronthosting.co.za>


New submission from H?ng Nguy?n Vi?t:

I'm running Python 2.7.6-8ubuntu0.2 amd64 on Ubuntu 14.04 with kernel 3.13.0-52-generic and got this segfault errors every time I ran /usr/local/sentry/bin/sentry cleanup from sentry 7.4.1 (https://github.com/getsentry/sentry/tree/7.4.1)

[22209647.263243] /usr/local/sent[11702]: segfault at 24 ip 00000000005377c7 sp 00007ffc05c8f930 error 6 in python[400000+2bc000]
[22295939.402502] /usr/local/sent[390]: segfault at 24 ip 00000000005377c7 sp 00007ffdd3e66ca0 error 6 in python[400000+2bc000]
[22296013.421469] /usr/local/sent[891]: segfault at 24 ip 0000000000558077 sp 00007fffc16e5e50 error 6 in python[400000+2bc000]
[22296046.492933] /usr/local/sent[1059]: segfault at 24 ip 00000000005377c7 sp 00007ffc84414130 error 6 in python[400000+2bc000]
[22296379.961611] /usr/local/sent[2512]: segfault at 24 ip 00000000005377c7 sp 00007ffca4920410 error 6 in python[400000+2bc000]
[22297323.455115] /usr/local/sent[7184]: segfault at 24 ip 00000000005377c7 sp 00007fff61f88d50 error 6 in python[400000+2bc000]
[22297362.031536] /usr/local/sent[7377]: segfault at 24 ip 00000000005377c7 sp 00007ffc99085470 error 6 in python[400000+2bc000]
[22297587.731566] /usr/local/sent[8287]: segfault at 24 ip 00000000004e265f sp 00007ffd70af3eb0 error 6 in python[400000+2bc000]
[22298739.800342] /usr/local/sent[27513]: segfault at 24 ip 00000000005377c7 sp 00007ffcaf9f2050 error 6 in python[400000+2bc000]

This happened every time I ran /usr/local/sentry/bin/sentry cleanup from sentry 7.4.1

----------
components: Interpreter Core
messages: 262102
nosy: hvnsweeting
priority: normal
severity: normal
status: open
title: segfault at 24 error 6 in python
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar 21 04:13:06 2016
From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Skonieczny_=28Uosiu=29?=)
Date: Mon, 21 Mar 2016 08:13:06 +0000
Subject: [New-bugs-announce] [issue26600] MagickMock __str__ sometimes
 returns MagickMock instead of str
Message-ID: <1458547986.83.0.630762686391.issue26600@psf.upfronthosting.co.za>


New submission from Stanis?aw Skonieczny (Uosiu):

This bug results in raising TypeError: __str__ returned non-string (type MagicMock)
Following program can reproduce it:

```
from threading import Thread
from mock.mock import MagicMock


def main():
    mocks = [MagicMock() for _ in range(1000)]

    def in_thread():
        for m in mocks:
            str(m)

    threads = [Thread(target=in_thread) for _ in range(10)]
    for thread in threads:
        thread.start()
    for thread in threads:
        thread.join()


if __name__ == '__main__':
    main()
```

For me it rasies few times:

```
Exception in thread Thread-6:
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/threading.py", line 923, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.5/threading.py", line 871, in run
    self._target(*self._args, **self._kwargs)
  File "../misc/magic_mock_str_bug.py", line 11, in in_thread
    str(m)
TypeError: __str__ returned non-string (type MagicMock)
```

----------
components: Library (Lib)
messages: 262104
nosy: Stanis?aw Skonieczny (Uosiu)
priority: normal
severity: normal
status: open
title: MagickMock __str__ sometimes returns MagickMock instead of str
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/issue26600>
_______________________________________

From report at bugs.python.org  Mon Mar 21 06:51:54 2016
From: report at bugs.python.org (Marcos Dione)
Date: Mon, 21 Mar 2016 10:51:54 +0000
Subject: [New-bugs-announce] [issue26601] Use new madvise()'s MADV_FREE on
 the private heap
Message-ID: <1458557514.95.0.774301964914.issue26601@psf.upfronthosting.co.za>


New submission from Marcos Dione:

Linux kernel's new madvise() MADV_FREE[1] could be used in the memory allocator to signal unused parts of the private heap as such, allowing the kernel use those pages for resolving lowmem pressure situations. From a LWN article[2]:

[...] Rather than reclaiming the pages immediately, this operation marks them for "lazy freeing" at some future point. Should the kernel run low on memory, these pages will be among the first reclaimed for other uses; should the application try to use such a page after it has been reclaimed, the kernel will give it a new, zero-filled page. But if memory is not tight, pages marked with MADV_FREE will remain in place; a future access to those pages will clear the "lazy free" bit and use the memory that was there before the MADV_FREE call. 

[...] MADV_FREE appears to be aimed at user-space memory allocator implementations. When an application frees a set of pages, the allocator will use an MADV_FREE call to tell the kernel that the contents of those pages no longer matter. Should the application quickly allocate more memory in the same address range, it will use the same pages, thus avoiding much of the overhead of freeing the old pages and allocating and zeroing the new ones. In short, MADV_FREE is meant as a way to say "I don't care about the data in this address range, but I may reuse the address range itself in the near future." 

Also note that this feature already exists in BSD kernels.

--
[1] http://kernelnewbies.org/Linux_4.5#head-42578a3e087d5bcc2940954a38ce794fe2cd642c

[2] https://lwn.net/Articles/590991/

----------
components: Interpreter Core
messages: 262117
nosy: StyXman
priority: normal
severity: normal
status: open
title: Use new madvise()'s MADV_FREE on the private heap
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Mar 21 08:11:34 2016
From: report at bugs.python.org (Daniel Stone)
Date: Mon, 21 Mar 2016 12:11:34 +0000
Subject: [New-bugs-announce] [issue26602] argparse doc introduction is
 inappropriately targeted
Message-ID: <1458562294.77.0.347454712136.issue26602@psf.upfronthosting.co.za>


New submission from Daniel Stone:

The argparse documentation starts off, after a couple of sentences, by spending several paragraphs (and a couple of sentences) explaining this gem:
import argparse

parser = argparse.ArgumentParser(description='Process some integers.')
parser.add_argument('integers', metavar='N', type=int, nargs='+',
                   help='an integer for the accumulator')
parser.add_argument('--sum', dest='accumulate', action='store_const',
                   const=sum, default=max,
                   help='sum the integers (default: find the max)')

args = parser.parse_args()
print(args.accumulate(args.integers))


While it is undoubtedly impressive, that a sidebar had to be inserted suggesting people in fact refer to other documentation, suggests it may be inappropriate. As an introduction, it is not particularly approachable (especially if you don't catch the nuance of assigning functions to accumulate), and is probably not going to serve the immediate needs of a lot of the audience: the people who click on the first hit for 'python argparse'.

I would suggest relegating this example elsewhere in the documentation, with a much more straightforward/realistic example to lead the documentation.

----------
assignee: docs at python
components: Documentation
messages: 262121
nosy: Daniel Stone, docs at python
priority: normal
severity: normal
status: open
title: argparse doc introduction is inappropriately targeted

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

From report at bugs.python.org  Mon Mar 21 12:07:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Mar 2016 16:07:26 +0000
Subject: [New-bugs-announce] [issue26603] os.scandir: implement finalizer
 (for ResourceWarning)
Message-ID: <1458576446.66.0.754431143479.issue26603@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch implements a finalizer for os.scandir() iterator type. The patch also calls the new PyErr_ResourceWarning() function to be able to display in the warning where the iterator was created (allocated) when tracemalloc is enabled.

While it makes sense to pass an "open" socket to the logger of the ResourceWarning warning for sockets (issue #26590), maybe we can close the ScandirIterator *before* calling the logger?

Example:
---
import os
f = os.scandir('.')
f = None
---

Output:
---
$ ./python -X tracemalloc -Wd example.py 
example.py:3: ResourceWarning: unclosed scandir iterator <posix.ScandirIterator object at 0x7f21cdb15280>
  f = None
Object allocated at (most recent call first):
  File "example.py", lineno 2
    f = os.scandir('.')
---

See also the issue #26590 "socket destructor: implement finalizer".

----------
messages: 262136
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: os.scandir: implement finalizer (for ResourceWarning)
versions: Python 3.6

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

From report at bugs.python.org  Mon Mar 21 12:18:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Mar 2016 16:18:33 +0000
Subject: [New-bugs-announce] [issue26604] Add optional source parameter to
 warnings.warn()
Message-ID: <1458577113.4.0.161652506992.issue26604@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Follow-up of the issue #26567 which added PyErr_ResourceWarning() (C API), attached patch adds a new source parameter to the warnings.warn() function (Python API).

source is the destroyed object which emits a ResourceWarning. The source is used to show the traceback where the object was created (allocated) when tracemalloc is used.

The patch also changes _pyio, asyncio and asyncore modules to set the source parameter.

Note: tempfile doesn't set source because it uses a class method:

    @classmethod
    def _cleanup(cls, name, warn_message):
        _shutil.rmtree(name)
        _warnings.warn(warn_message, ResourceWarning)

----------
files: warnings_warn_source.patch
keywords: patch
messages: 262137
nosy: haypo
priority: normal
severity: normal
status: open
title: Add optional source parameter to warnings.warn()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42236/warnings_warn_source.patch

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

From report at bugs.python.org  Mon Mar 21 13:00:15 2016
From: report at bugs.python.org (nickeubank)
Date: Mon, 21 Mar 2016 17:00:15 +0000
Subject: [New-bugs-announce] [issue26605] Feature request: string method
 `to_file`
Message-ID: <1458579615.34.0.816469803879.issue26605@psf.upfronthosting.co.za>


New submission from nickeubank:

As a social scientists trying to help other social scientists move from language like R, Stata, and Matlab into Python, one of the behaviors I've found unnecessarily difficult to explain is the "file.open()/file.close()" idiom (or, alternatively, context managers). In normal operating systems, and many high level languages, saving is a one-step operation. 

I understand there are situations where an open file handle is useful, but it seems a simple `to_file` method on strings (essentially wrapping a context-manager) would be really nice, as it would save users from learning this idiom. 

Any chance it's feasible? Sadly, I have no real C skills so can't implement myself. :(

----------
components: IO
messages: 262141
nosy: nickeubank
priority: normal
severity: normal
status: open
title: Feature request: string method `to_file`
type: enhancement

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

From report at bugs.python.org  Mon Mar 21 18:17:06 2016
From: report at bugs.python.org (=?utf-8?b?SsSBbmlzIMWgbGFwacWGxaE=?=)
Date: Mon, 21 Mar 2016 22:17:06 +0000
Subject: [New-bugs-announce] [issue26606] logging.baseConfig is missing the
 encoding parameter
Message-ID: <1458598626.88.0.490041392552.issue26606@psf.upfronthosting.co.za>


New submission from J?nis ?lapi??:

Hi!
Log files are only saved using the system default encoding.
On Windows, this means that the current ANSI code page is used. This may lead to a disaster (exceptions may be thrown due to unmappable characters) if you want to log particular text strings in a foreign language, e.g. those read from a source file in the UTF-8 or UTF-16 encoding, and such strings contain characters not available in your ANSI code page.
I guess this issue does not affect Linux or Mac OSX as they already use the UTF-8 encoding for their system locales.

Actually, the logging module already has the built-in functionality for setting a particular encoding for output files. However, it was not added as a parameter of the baseConfig function (in __init__.py).

I added a patch file with suggested amendments.

I already tested writing logs with those changes applied and files are now saved in the specified encoding which differs from the Windows current ANSI page. For example:
logging.basicConfig(filename=log_path, filemode='w', encoding='utf-8', format='%(message)s', level=logging.INFO)

----------
components: Library (Lib)
files: __init__.py.patch
keywords: patch
messages: 262150
nosy: janis.slapins
priority: normal
severity: normal
status: open
title: logging.baseConfig is missing the encoding parameter
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file42238/__init__.py.patch

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

From report at bugs.python.org  Mon Mar 21 20:57:28 2016
From: report at bugs.python.org (Mansour Moufid)
Date: Tue, 22 Mar 2016 00:57:28 +0000
Subject: [New-bugs-announce] [issue26607] Rename a parameter in the function
 PyFile_FromFile
Message-ID: <1458608248.15.0.411185943215.issue26607@psf.upfronthosting.co.za>


New submission from Mansour Moufid:

Hi,

The last parameter of the function PyFile_FromFile is named 'close', but is a pointer to a function with the prototype of the 'fclose' function in libc. The mismatch causes confusion for some static analysis tools.

This patch renames the parameter to 'fclose'. Note that everywhere else PyFile_FromFile is called, that argument is always named fclose or pclose (or NULL), this was the one exception.

Thanks for your time.

----------
files: 0001-PyFile_FromFile-Rename-close-parameter-to-fclose.patch
keywords: patch
messages: 262156
nosy: Mansour Moufid
priority: normal
severity: normal
status: open
title: Rename a parameter in the function PyFile_FromFile
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file42239/0001-PyFile_FromFile-Rename-close-parameter-to-fclose.patch

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

From report at bugs.python.org  Tue Mar 22 02:56:38 2016
From: report at bugs.python.org (Mateusz)
Date: Tue, 22 Mar 2016 06:56:38 +0000
Subject: [New-bugs-announce] [issue26608] RLock undocumented behavior in
 case of multiple acquire
Message-ID: <1458629798.26.0.210968234517.issue26608@psf.upfronthosting.co.za>


New submission from Mateusz:

The number of acquisitions must be the same as the number of releases or else lock will not be released for other threads leading to deadlock. This is not mentioned in documentation. 

First acquisition returns boolean and further acquisitions return 1. This is also not mentioned in documentation.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 262165
nosy: docs at python, smbrd
priority: normal
severity: normal
status: open
title: RLock undocumented behavior in case of multiple acquire
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 22 04:56:20 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 22 Mar 2016 08:56:20 +0000
Subject: [New-bugs-announce] [issue26609] Wrong request target in
 test_httpservers.py
Message-ID: <1458636980.12.0.779581831419.issue26609@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

When requesting a resource from an origin server, the request-target in request line should always starts with a back slash. But in SimpleHTTPServerTestCase in test_httpservers.py, almost all the requests are sent without the back slash though the handler handles it well. The request lines are like 'GET tmpXXXXX HTTP/1.1'. I add the back slashes.

Maybe in SimpleHTTPRequestHandler, we should reject such invalid request-targets and then return BAD_REQUEST. And then issue2254 won't happen.

----------
components: Library (Lib)
files: request_target_in_test_httpservers.patch
keywords: patch
messages: 262171
nosy: martin.panter, xiang.zhang
priority: normal
severity: normal
status: open
title: Wrong request target in test_httpservers.py
versions: Python 3.6
Added file: http://bugs.python.org/file42243/request_target_in_test_httpservers.patch

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

From report at bugs.python.org  Tue Mar 22 06:52:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Mar 2016 10:52:26 +0000
Subject: [New-bugs-announce] [issue26610] test_venv.test_with_pip() fails
 when ctypes is missing
Message-ID: <1458643946.17.0.878468383793.issue26610@psf.upfronthosting.co.za>


New submission from STINNER Victor:

pip/pep425tags.py requires ctypes, but it's not available on the OpenIndiana buildbot. I suggest to skip the test if ctypes is missing.

I don't know if it's possible to modify pip to make ctypes optional again.

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/10407/steps/test/logs/stdio

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_venv.py", line 364, in test_with_pip
    with_pip=True)
subprocess.CalledProcessError: Command '['/tmp/tmpl3s6nv31/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_venv.py", line 370, in test_with_pip
    self.fail(msg.format(exc, details))
AssertionError: Command '['/tmp/tmpl3s6nv31/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

**Subprocess Output**
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 184, in _run_module_as_main
    "__main__", mod_spec)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ensurepip/__main__.py", line 4, in <module>
    ensurepip._main()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 209, in _main
    default_pip=args.default_pip,
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 116, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 40, in _run_pip
    import pip
  File "/tmp/tmpbfnwxnn2/pip-8.1.1-py2.py3-none-any.whl/pip/__init__.py", line 16, in <module>
  File "/tmp/tmpbfnwxnn2/pip-8.1.1-py2.py3-none-any.whl/pip/vcs/subversion.py", line 9, in <module>
  File "/tmp/tmpbfnwxnn2/pip-8.1.1-py2.py3-none-any.whl/pip/index.py", line 30, in <module>
  File "/tmp/tmpbfnwxnn2/pip-8.1.1-py2.py3-none-any.whl/pip/wheel.py", line 32, in <module>
  File "/tmp/tmpbfnwxnn2/pip-8.1.1-py2.py3-none-any.whl/pip/pep425tags.py", line 9, in <module>
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: No module named '_ctypes'

----------
messages: 262173
nosy: dstufft, haypo
priority: normal
severity: normal
status: open
title: test_venv.test_with_pip() fails when ctypes is missing
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar 22 09:38:21 2016
From: report at bugs.python.org (Chris Mitchell)
Date: Tue, 22 Mar 2016 13:38:21 +0000
Subject: [New-bugs-announce] [issue26611] assertRaises callableObj cannot be
 used as a keyword with args
Message-ID: <1458653901.28.0.305409918599.issue26611@psf.upfronthosting.co.za>


New submission from Chris Mitchell:

assertRaises has callableObj listed as a keyword, though it is not possible to use it as a keyword when the callableObj takes arguments. 

The function definition is:
    def assertRaises(self, excClass, callableObj=None, *args, **kwargs):

Therefore, using it with a keyword such as:

    self.assertRaises(Exception, callableObj=my_function, args_to_function)

will fail due to passing arguments after a keyword.

----------
components: Tests
messages: 262183
nosy: Chris Mitchell
priority: normal
severity: normal
status: open
title: assertRaises callableObj cannot be used as a keyword with args
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 22 20:47:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Mar 2016 00:47:46 +0000
Subject: [New-bugs-announce] [issue26612] test_ssl: use context manager
 (with) to fix ResourceWarning
Message-ID: <1458694066.07.0.537208093993.issue26612@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modifies Lib/test/test_ssl.py to use "with socket:" instead of "try: ... finally: socket.close()" or similar patterns.

Our PPC64 AIX 3.x buildbot has a broken ssl module. A lot of tests logs ResourceWarning on unclosed sockets, because errors occur before the test closes a socket.

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4714/steps/test/logs/stdio

test_connect_ex_error (test.test_ssl.NetworkedTests) ... ok
test_connect_with_context (test.test_ssl.NetworkedTests) ... FAIL
/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py:628: ResourceWarning: unclosed <ssl.SSLSocket fd=7, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('140.211.15.154', 60379), raddr=('23.253.148.168', 443)>
  outcome.errors.clear()

----------
files: test_ssl_with.patch
keywords: patch
messages: 262222
nosy: haypo
priority: normal
severity: normal
status: open
title: test_ssl: use context manager (with) to fix ResourceWarning
versions: Python 3.6
Added file: http://bugs.python.org/file42245/test_ssl_with.patch

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

From report at bugs.python.org  Tue Mar 22 20:56:24 2016
From: report at bugs.python.org (Stubz)
Date: Wed, 23 Mar 2016 00:56:24 +0000
Subject: [New-bugs-announce] [issue26613] Descriptor HowTo Guide - Typo
Message-ID: <1458694584.31.0.177347934352.issue26613@psf.upfronthosting.co.za>


New submission from Stubz:

The last line has a typo ... Dict.fromkeys -> dict.fromkeys

I am a newbie, but that was just a pain in the ass ...

Worked my way thru this How to and spent an hour+ trying to sort a circular argument error...

Was this intentional ?
In as much as it was a pain in the ass, I think I got the concept sorted ...


https://docs.python.org/3.5/howto/descriptor.html

Static Methods and Class Methods

This behavior is useful whenever the function only needs to have a class reference and does not care about any underlying data. One use for classmethods is to create alternate class constructors. In Python 2.3, the classmethod dict.fromkeys() creates a new dictionary from a list of keys. The pure Python equivalent is:

class Dict(object):
    . . .
    def fromkeys(klass, iterable, value=None):
        "Emulate dict_fromkeys() in Objects/dictobject.c"
        d = klass()
        for key in iterable:
            d[key] = value
        return d
    fromkeys = classmethod(fromkeys)

Now a new dictionary of unique keys can be constructed like this:

>>>
Dict.fromkeys('abracadabra')

----------
assignee: docs at python
components: Documentation
messages: 262223
nosy: docs at python, stubzpub
priority: normal
severity: normal
status: open
title: Descriptor HowTo Guide - Typo
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 22 23:04:00 2016
From: report at bugs.python.org (nickeubank)
Date: Wed, 23 Mar 2016 03:04:00 +0000
Subject: [New-bugs-announce] [issue26614] False/0 and True/1 collision when
 used as dict keys?
Message-ID: <1458702240.3.0.550475924064.issue26614@psf.upfronthosting.co.za>


New submission from nickeubank:

Found an odd behavior I'd never known about today, not sure if it's a bug or known. Python 3.4.4 (anaconda)

True, False, 0, 1 can all be used as dictionary keys.

But

Apparently True and 1 hash to the same item and False and 0 hash to the same item, so they can easily overwrite (which I spent a while banging my head over today). In other words:

In[1]:
    d = {True: 'a', False: 'b'}
    d[0] = 'z'
    d[False]

Out[1]:
    'z'

----------
messages: 262232
nosy: nickeubank
priority: normal
severity: normal
status: open
title: False/0 and True/1 collision when used as dict keys?
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar 22 23:35:41 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 23 Mar 2016 03:35:41 +0000
Subject: [New-bugs-announce] [issue26615] Missing entry in
 WRAPPER_ASSIGNMENTS in update_wrapper's doc
Message-ID: <1458704141.94.0.68234227835.issue26615@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

WRAPPER_ASSIGNMENTS now contains __qualname__ but the documentation doesn't mention it.

----------
assignee: docs at python
components: Documentation
files: functools_doc.patch
keywords: patch
messages: 262237
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Missing entry in WRAPPER_ASSIGNMENTS in update_wrapper's doc
versions: Python 3.6
Added file: http://bugs.python.org/file42247/functools_doc.patch

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

From report at bugs.python.org  Wed Mar 23 01:25:06 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Mar 2016 05:25:06 +0000
Subject: [New-bugs-announce] [issue26616] A bug in datetime.astimezone()
 method
Message-ID: <1458710706.19.0.994284495334.issue26616@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

With TZ=America/New_York,

>>> from datetime import *
>>> u = datetime(2015, 11, 1, 5, tzinfo=timezone.utc)
>>> t = u.astimezone()
>>> print(t)
2015-11-01 01:00:00-04:00
>>> print(t.astimezone())
2015-11-01 00:00:00-05:00

which is wrong - the second call to astimezone() should not change the timezone.  Note that pure python code does not have this bug.  (Try setiing sys.module['_datetime'] = None before running the code above.)

----------
components: Extension Modules
messages: 262239
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: A bug in datetime.astimezone() method
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Mar 23 02:08:59 2016
From: report at bugs.python.org (Guo, Jiahua)
Date: Wed, 23 Mar 2016 06:08:59 +0000
Subject: [New-bugs-announce] [issue26617] Assertion failed in gc with
 __del__ and weakref
Message-ID: <1458713339.87.0.171873505456.issue26617@psf.upfronthosting.co.za>


New submission from Guo, Jiahua:

$ python3.5-dbg crash.py
python3.5-dbg: ../Modules/gcmodule.c:364: update_refs: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.


$ python3.5-dbg crash-multithread.py
python3.5-dbg: ../Modules/gcmodule.c:364: update_refs: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.


============ crash.py ==========
import weakref
import gc


def callback(o):
    gc.collect()


class C:
    def __del__(self):
        pass

def main():
    c = C()
    cref = weakref.ref(c, callback)
    del c


main()


============ crash-multithread.py ==========
import threading
import weakref
import gc


ei = threading.Event()
eo = threading.Event()


def gc_worker():
    ei.wait()
    gc.collect()
    eo.set()


def callback(o):
    ei.set()
    eo.wait()


class C:
    def __del__(self):
        pass


def main():
    t = threading.Thread(target=gc_worker)
    t.start()
    c = C()
    cref = weakref.ref(c, callback)
    del c
    t.join()


main()

----------
components: Interpreter Core
messages: 262242
nosy: Guo, Jiahua
priority: normal
severity: normal
status: open
title: Assertion failed in gc with __del__ and weakref
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 23 06:43:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Mar 2016 10:43:52 +0000
Subject: [New-bugs-announce] [issue26618] _overlapped extension module of
 asyncio uses deprecated WSAStringToAddressA() function
Message-ID: <1458729832.02.0.462446337559.issue26618@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The code should be updated to use WSAStringToAddressW().

https://msdn.microsoft.com/en-us/library/windows/desktop/ms742214%28v=vs.85%29.aspx

Compilation warnings:

    20>..\Modules\overlapped.c(980): warning C4996: 'WSAStringToAddressA': Use WSAStringToAddressW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings [D:\buildarea\3.x.bolen-windows8\build\PCbuild\_overlapped.vcxproj]
    20>..\Modules\overlapped.c(991): warning C4996: 'WSAStringToAddressA': Use WSAStringToAddressW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings [D:\buildarea\3.x.bolen-windows8\build\PCbuild\_overlapped.vcxproj]

----------
components: Windows, asyncio
messages: 262256
nosy: gvanrossum, haypo, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: _overlapped extension module of asyncio uses deprecated WSAStringToAddressA() function
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Mar 23 06:47:42 2016
From: report at bugs.python.org (Steve Morris)
Date: Wed, 23 Mar 2016 10:47:42 +0000
Subject: [New-bugs-announce] [issue26619] 3.5.1 install fails on Windows
 Server 2008 R2 64-bit
Message-ID: <1458730062.68.0.427600390263.issue26619@psf.upfronthosting.co.za>


New submission from Steve Morris:

Setup fails with "Windows 7 Service Pack 1 required"

----------
components: Installation
files: Python 3.5.1 (64-bit)_20160323125008.log
messages: 262257
nosy: sdmorris
priority: normal
severity: normal
status: open
title: 3.5.1 install fails on Windows Server 2008 R2 64-bit
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42256/Python 3.5.1 (64-bit)_20160323125008.log

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

From report at bugs.python.org  Wed Mar 23 06:59:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Mar 2016 10:59:05 +0000
Subject: [New-bugs-announce] [issue26620] Fix ResourceWarning warnings in
 test_urllib2_localnet
Message-ID: <1458730745.01.0.796601838932.issue26620@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch fixes 3 ResourceWarning warnings in Lib/test/test_urllib2_localnet.py.

See also issue #26612 (test_ssl).

Example of warning logged by "./python -X tracemalloc=25  -m test -v test_urllib2_localnet ":
---
/home/haypo/prog/python/default/Lib/test/support/__init__.py:1444: ResourceWarning: unclosed <socket.socket [closed] fd=6, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6>
  gc.collect()
Object allocated at (most recent call first):
  File "/home/haypo/prog/python/default/Lib/socket.py", lineno 697
    sock = socket(af, socktype, proto)
  File "/home/haypo/prog/python/default/Lib/http/client.py", lineno 898
    (self.host,self.port), self.timeout, self.source_address)
  File "/home/haypo/prog/python/default/Lib/http/client.py", lineno 926
    self.connect()
  File "/home/haypo/prog/python/default/Lib/http/client.py", lineno 983
    self.send(msg)
  File "/home/haypo/prog/python/default/Lib/http/client.py", lineno 1151
    self._send_output(message_body)
  File "/home/haypo/prog/python/default/Lib/http/client.py", lineno 1200
    self.endheaders(body)
  File "/home/haypo/prog/python/default/Lib/http/client.py", lineno 1155
    self._send_request(method, url, body, headers)
  File "/home/haypo/prog/python/default/Lib/urllib/request.py", lineno 1303
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/home/haypo/prog/python/default/Lib/urllib/request.py", lineno 1331
    return self.do_open(http.client.HTTPConnection, req)
  File "/home/haypo/prog/python/default/Lib/urllib/request.py", lineno 503
    result = func(*args)
  File "/home/haypo/prog/python/default/Lib/urllib/request.py", lineno 543
    '_open', req)
  File "/home/haypo/prog/python/default/Lib/urllib/request.py", lineno 525
    response = self._open(req, data)
  File "/home/haypo/prog/python/default/Lib/urllib/request.py", lineno 222
    return opener.open(url, data, timeout)
  File "/home/haypo/prog/python/default/Lib/test/test_urllib2_localnet.py", lineno 595
    urllib.request.urlopen(req)
  (...)
---

----------
components: Tests
messages: 262258
nosy: haypo, martin.panter
priority: normal
severity: normal
status: open
title: Fix ResourceWarning warnings in test_urllib2_localnet
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar 23 08:42:43 2016
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 23 Mar 2016 12:42:43 +0000
Subject: [New-bugs-announce] [issue26621] test_decimal fails with
 libmpdecimal 2.4.2
Message-ID: <1458736963.71.0.573230549815.issue26621@psf.upfronthosting.co.za>


New submission from Matthias Klose:

test_decimal fails with libmpdecimal 2.4.2

that's because Lib/_pydecimal.py hardcodes

__libmpdec_version__ = "2.4.1" # compatible libmpdec version

----------
components: Extension Modules
messages: 262260
nosy: doko, skrah
priority: normal
severity: normal
status: open
title: test_decimal fails with libmpdecimal 2.4.2
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Mar 23 09:24:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Mar 2016 13:24:47 +0000
Subject: [New-bugs-announce] [issue26622] test_winreg now logs "Windows
 exception: code 0x06ba" on Python 3.6
Message-ID: <1458739487.96.0.253649845996.issue26622@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #23848 (change b114dbbe2d31) enhanced the faulthandler module to log Windows exceptions with the Python traceback. It uses AddVectoredExceptionHandler(1, callback) to register the callback.

Problem: test_winreg now logs a lot of "Windows exception: code 0x06ba" messages followed by traceback. It's error RPC_S_SERVER_UNAVAILABLE (1722): "The RPC server is unavailable". It doesn't seem like a fatal error, so I'm not sure that it's worth to log it.

Is it possible to check if an exception is a fatal error or not?

Or should we explicitly ignore *this* specific error?

Note: faulthandler must be enabled manually.

Example of trace:
http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/1885/steps/test/logs/stdio
----
Windows exception: code 0x06ba

Current thread 0x00000500 (most recent call first):
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\test_winreg.py", line 305 in test_dynamic_key
  File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\case.py", line 600 in run
  File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\case.py", line 648 in __call__
  File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\runner.py", line 176 in run
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\support\__init__.py", line 1802 in _run_suite
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\support\__init__.py", line 1836 in run_unittest
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\test_winreg.py", line 479 in test_main
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\libregrtest\runtest.py", line 162 in runtest_inner
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\libregrtest\runtest.py", line 115 in runtest
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\libregrtest\main.py", line 306 in run_tests_sequential
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\libregrtest\main.py", line 367 in run_tests
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\libregrtest\main.py", line 405 in main
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\libregrtest\main.py", line 446 in main
  File "D:\buildarea\3.x.bolen-windows8\build\lib\test\libregrtest\main.py", line 468 in main_in_temp_cwd
  File "D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py", line 39 in <module>
----

----------
components: Tests, Windows
messages: 262263
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_winreg now logs "Windows exception: code 0x06ba" on Python 3.6
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar 23 10:48:20 2016
From: report at bugs.python.org (Mahmoud Lababidi)
Date: Wed, 23 Mar 2016 14:48:20 +0000
Subject: [New-bugs-announce] [issue26623] JSON encode: more informative error
Message-ID: <1458744500.18.0.912653699585.issue26623@psf.upfronthosting.co.za>


New submission from Mahmoud Lababidi:

The json.dumps()/encode functionality will raise an Error when an object that cannot be json-encoded is encountered. The current Error message only shows the Object itself. I would like to enhance the error message by also providing the Type. This is useful when numpy.int objects are passed in, but not clear that they are numpy objects.

----------
components: Library (Lib)
messages: 262272
nosy: Mahmoud Lababidi
priority: normal
severity: normal
status: open
title: JSON encode: more informative error
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar 23 11:44:31 2016
From: report at bugs.python.org (Jeremy Kloth)
Date: Wed, 23 Mar 2016 15:44:31 +0000
Subject: [New-bugs-announce] [issue26624] Windows hangs in call to CRT
 setlocale()
Message-ID: <1458747871.12.0.710719467032.issue26624@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

My Windows BuildBot (http://buildbot.python.org/all/buildslaves/kloth-win64) is hanging in calls to the CRT function setlocale() as determined by attaching to the hung test process in Visual Studio.

This has been happening occasionally (every tenth+ build) for quite some time, but not to the frequency as of late (every fourth build or so).

I would debug further, however my Visual Studio debugging-fu is not up to this challenge it seems.

Pertinent details of the buildbot:
- Windows 7 SP1 64-bit on a quad-core processor
- Running buildbot as a service
- Tests run using '-j4'
- SSD used for storage

Order of the tests do not seem to matter as re-running the test suite using the random seed that hung will pass when run from a console on the buildbot.

Locale-using functions in the CRT have internally locking which is what I believe is the cause of the deadlock, but cannot determine exactly as this is where my debugging knowledge runs out.

Help to diagnose further is greatly appreciated!

----------
components: Interpreter Core, Windows
messages: 262276
nosy: eryksun, jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows hangs in call to CRT setlocale()
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Mar 23 12:28:34 2016
From: report at bugs.python.org (Rian Hunter)
Date: Wed, 23 Mar 2016 16:28:34 +0000
Subject: [New-bugs-announce] [issue26625] SELECT-initiated transactions can
 cause "database is locked" in sqlite
Message-ID: <1458750514.03.0.475841204409.issue26625@psf.upfronthosting.co.za>


New submission from Rian Hunter:

When a transaction starts with a SELECT statement this can invoke a "database is locked" error if the SELECT statement is not exhausted or explicitly closed.

This can lead to subtle "database is locked" bugs, even when a large timeout is set on the connection. Many, many people are affected by this bug (search the web for "python sqlite database is locked").

The attached code demonstrates this bug and possible (unintuitive) fixes. The best workaround is to "explicitly" start a transaction in these cases by issuing a dummy DML statement. This seems very clumsy.

My proposed fix is to implicitly open a transaction before all non-DDL statements (including SELECT statements), not just DML statements.

If there won't be a fix soon, then at least the documentation should note this quirky behavior.

----------
components: Library (Lib)
files: unintuitive_sqlite_behavior.py
messages: 262282
nosy: rhunter
priority: normal
severity: normal
status: open
title: SELECT-initiated transactions can cause "database is locked" in sqlite
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42259/unintuitive_sqlite_behavior.py

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

From report at bugs.python.org  Wed Mar 23 12:58:02 2016
From: report at bugs.python.org (ink)
Date: Wed, 23 Mar 2016 16:58:02 +0000
Subject: [New-bugs-announce] [issue26626] test_dbm_gnu
Message-ID: <1458752282.36.0.8486326367.issue26626@psf.upfronthosting.co.za>


New submission from ink:

Hello, I was running post-build tests after building 3.5.1 when test_dbm_gnu hanged on an error. The same happens with 3.4.4 so it's not version relevant. Furthermore, this happens on an NFS mounted storage but not on our Lustre volume. Most of the time it just hangs on OSError. We probably don't need dbm but the issue seems to be directory related and directories cannot be handled properly there could be other implications.

The build process was usual
./configure --prefix=/apps/python/3.5.1 --enable-shared --with-threads
make
make test

Thank you for any advice


By the way, on its own, the test runs fine

LD_LIBRARY_PATH=/apps/python/src/Python-3.5.1 ./python  ./Lib/test/test_dbm_gnu.py
.....
----------------------------------------------------------------------
Ran 5 tests in 0.026s

OK

but not as part of the regression tests


[114/397/2] test_dbm_gnu
Warning -- files was modified by test_dbm_gnu
Traceback (most recent call last):
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/support/__init__.py", line 899, in temp_dir
    yield path
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/support/__init__.py", line 948, in temp_cwd
    yield cwd_dir
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/regrtest.py", line 1591, in main_in_temp_cwd
    main()
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/regrtest.py", line 554, in main
    sys.exit(0)
SystemExit: 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/regrtest.py", line 1616, in <module>
    main_in_temp_cwd()
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/regrtest.py", line 1591, in main_in_temp_cwd
    main()
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/support/__init__.py", line 948, in temp_cwd
    yield cwd_dir
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/support/__init__.py", line 902, in temp_dir
    shutil.rmtree(path)
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/shutil.py", line 474, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/shutil.py", line 432, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/shutil.py", line 430, in _rmtree_safe_fd
    os.unlink(name, dir_fd=topfd)
OSError: [Errno 16] Device or resource busy: '.nfs00000000027813d70000000c'

Traceback (most recent call last):
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/regrtest.py", line 1591, in main_in_temp_cwd
    main()
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/test/regrtest.py", line 756, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_dbm_gnu: Exit code 1

^CException ignored in: <module 'threading' from '/opt/gridware/apps/python/src/Python-3.5.1/Lib/threading.py'>
Traceback (most recent call last):
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/threading.py", line 1288, in _shutdown
    t.join()
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/threading.py", line 1054, in join
    self._wait_for_tstate_lock()
  File "/opt/gridware/apps/python/src/Python-3.5.1/Lib/threading.py", line 1070, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt

----------
components: Tests
messages: 262288
nosy: ink
priority: normal
severity: normal
status: open
title: test_dbm_gnu
type: crash
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 23 14:00:45 2016
From: report at bugs.python.org (Tadhg McDonald-Jensen)
Date: Wed, 23 Mar 2016 18:00:45 +0000
Subject: [New-bugs-announce] [issue26627] IDLE incorrectly labeling error as
 internal
Message-ID: <1458756045.86.0.656079576242.issue26627@psf.upfronthosting.co.za>


New submission from Tadhg McDonald-Jensen:

(I apologize if I'm doing something wrong)

When using a file named run.py in idle, any errors raised from the module makes IDLE show a traceback like this:

Traceback (most recent call last):
** IDLE Internal Exception: 
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/idlelib/run.py", line 351, in runcode
    exec(code, self.locals)
  File "/Users/Tadhg/Documents/run.py", line 1, in <module>
    raise ValueError
ValueError

I looked into idlelib.run and think the culprit is the way print_exception tries to exclude internal files, specifically line 180 in vs 2.7 and line 206 in vs3.5

            exclude = ("run.py", "rpc.py", "threading.py", "queue.py",
                       "RemoteDebugger.py", "bdb.py")

this excludes paths with these names anywhere in the path (later in cleanup_traceback) instead of getting the absolute paths of these modules.

----------
components: IDLE
files: run.py
messages: 262293
nosy: Tadhg McDonald-Jensen
priority: normal
severity: normal
status: open
title: IDLE incorrectly labeling error as internal
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file42261/run.py

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

From report at bugs.python.org  Wed Mar 23 16:52:16 2016
From: report at bugs.python.org (Thomas)
Date: Wed, 23 Mar 2016 20:52:16 +0000
Subject: [New-bugs-announce] [issue26628] Segfault in cffi with ctypes.union
 argument
Message-ID: <1458766336.13.0.0388960184699.issue26628@psf.upfronthosting.co.za>


New submission from Thomas:

Passing ctypes.Union types as arguments crashes python.

Attached is a minimal example to reproduce. Due to undefined behavior, you may have to increase the union _fields_ to reproduce. I tested with 3.5.1 and 2.7.11.

It seems that cffi treats the union as a normal struct. In classify_argument, it loops through the type->elements. The byte_offset increases for each union element until pos exceeds enum x86_64_reg_class classes[MAX_CLASSES], causing an invalid write here:

size_t pos = byte_offset / 8;
classes[i + pos] = merge_classes (subclasses[i], classes[i + pos]);

I am quite scared considering the lack of any index checks in this code. At this point I'm not yet sure whether this is a bug in ctypes or libffi.

#0  classify_argument (type=0xce41b8, classes=0x7fffffffb4e0, byte_offset=8) at Python-3.5.1/Modules/_ctypes/libffi/src/x86/ffi64.c:248
#1  0x00007ffff6bc6409 in examine_argument (type=0xce41b8, classes=0x7fffffffb4e0, in_return=false, pngpr=0x7fffffffb4dc, pnsse=0x7fffffffb4d8)
    at Python-3.5.1/Modules/_ctypes/libffi/src/x86/ffi64.c:318
#2  0x00007ffff6bc68ce in ffi_call (cif=0x7fffffffb590, fn=0x7ffff751d5a0, rvalue=0x7fffffffb660, avalue=0x7fffffffb640) at Python-3.5.1/Modules/_ctypes/libffi/src/x86/ffi64.c:462
#3  0x00007ffff6bb589e in _call_function_pointer (flags=4353, pProc=0x7ffff751d5a0, avalues=0x7fffffffb640, atypes=0x7fffffffb620, restype=0xcdd488, resmem=0x7fffffffb660, argcount=1)
    at Python-3.5.1/Modules/_ctypes/callproc.c:811
#4  0x00007ffff6bb6593 in _ctypes_callproc (pProc=0x7ffff751d5a0, argtuple=0xc8b3e8, flags=4353, argtypes=0xcb2098, restype=0xcdcd38, checker=0x0)
    at Python-3.5.1/Modules/_ctypes/callproc.c:1149
#5  0x00007ffff6baf84f in PyCFuncPtr_call (self=0xcf3708, inargs=0xc8b3e8, kwds=0x0) at Python-3.5.1/Modules/_ctypes/_ctypes.c:3869
#6  0x000000000043b66a in PyObject_Call (func=0xcf3708, arg=0xc8b3e8, kw=0x0) at ../../Python-3.5.1/Objects/abstract.c:2165

----------
components: ctypes
files: unioncrash.py
messages: 262307
nosy: tilsche
priority: normal
severity: normal
status: open
title: Segfault in cffi with ctypes.union argument
type: crash
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file42263/unioncrash.py

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

From report at bugs.python.org  Wed Mar 23 16:54:27 2016
From: report at bugs.python.org (Buraddin Ibn-Karlo)
Date: Wed, 23 Mar 2016 20:54:27 +0000
Subject: [New-bugs-announce] [issue26629] Need an ability to build standard
 DLLs with distutils
Message-ID: <1458766467.89.0.930968148514.issue26629@psf.upfronthosting.co.za>


New submission from Buraddin Ibn-Karlo:

I want to make a a dynamic library to run its function with ctypes.

Also I want to build the library from sources with distutils (the C++ sources are distributed with my Python code).

But alas! Our distutils fails, if the library doesn't have initialization function (something like init_<module_name>). Even if the module does not need any initialization.

I did a quick and dirty solution: added a dummy function:
    void init_<module_name>(){}

It somehow works, but I don't think that it is a good idea.

Cannot you add the possibility to tell distutils, that this extention module is just a simple DLL, that will be used via ctypes (or somehow else) and it does not need any extra init script?

Also, cannot you add an extra section to ctypes documentation? With a description how to build such extensions via distutils?

----------
assignee: docs at python
components: Build, Documentation, Extension Modules, Windows, ctypes
messages: 262308
nosy: Buraddin Ibn-Karlo, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Need an ability to build standard DLLs with distutils
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 23 18:06:25 2016
From: report at bugs.python.org (Jason Erickson)
Date: Wed, 23 Mar 2016 22:06:25 +0000
Subject: [New-bugs-announce] [issue26630] Windows EXE extension installers
 not finding 32bit Python 3.5 installation
Message-ID: <1458770785.37.0.707130037196.issue26630@psf.upfronthosting.co.za>


New submission from Jason Erickson:

On both 64 and 32 bit Windows OSes, the 32bit version of Python 3.5 is unable to install extensions created with the command:
setup.py bdist_wininst


To reproduce, install the 32bit version of Python 3.5 and run the .exe installation for an extension, such as:
http://www.stickpeople.com/projects/python/win-psycopg/2.6.1/psycopg2-2.6.1.win32-py3.5.exe
https://bintray.com/artifact/download/pycurl/pycurl/pycurl-7.43.0.win32-py3.5.exe

Clicking 'Next', the message "Python version 3.5 required, which was not found in the registry." will be displayed.

Temporarily renaming the registry key (For 64bit Windows, under HKCU or HKLM):
SOFTWARE\WOW6432Node\Python\PythonCore\3.5-32
to:
SOFTWARE\WOW6432Node\Python\PythonCore\3.5

Allows the extensions to be installed.


This indicates this is because 32bit Python 3.5 now uses the '3.5-32' as the string for the registry key whereas the bdist_wininst 'stub' is still expecting just the version, '3.5'.

----------
components: Distutils
messages: 262312
nosy: dstufft, eric.araujo, jerickso
priority: normal
severity: normal
status: open
title: Windows EXE extension installers not finding 32bit Python 3.5 installation
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 23 18:23:18 2016
From: report at bugs.python.org (J Osell)
Date: Wed, 23 Mar 2016 22:23:18 +0000
Subject: [New-bugs-announce] [issue26631] Unable to install Python 3.5.1 on
 Windows 10 - Error 0x80070643: Failed to install MSI package.
Message-ID: <1458771798.71.0.333968276616.issue26631@psf.upfronthosting.co.za>


New submission from J Osell:

Unable to install Python 3.5.1 on Windows 10 - Error 0x80070643: Failed to install MSI package.

----------
components: Installation
files: Python 3.5.1 (64-bit)_20160323181333.log
messages: 262313
nosy: oselljr
priority: normal
severity: normal
status: open
title: Unable to install Python 3.5.1 on Windows 10 - Error 0x80070643: Failed to install MSI package.
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42264/Python 3.5.1 (64-bit)_20160323181333.log

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

From report at bugs.python.org  Wed Mar 23 22:33:17 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 24 Mar 2016 02:33:17 +0000
Subject: [New-bugs-announce] [issue26632] __all__ decorator
Message-ID: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

This is probably terrible, but given how difficult it is to keep __all__'s up to date, maybe something like this can be useful.  I literally whipped this up in about 5 minutes, so sit back and watch the bikeshedding!

import sys

def public(thing):
    if isinstance(thing, str):
        mdict = sys._getframe(1).f_globals
        name = thing
    else:
        mdict = sys.modules[thing.__module__].__dict__
        name = thing.__name__
    dunder_all = mdict.setdefault('__all__', [])
    dunder_all.append(name)
    return thing


Then:

@public
def baz(a, b):
    return a + b

@public
def buz(c, d):
    return c / d

def qux(e, f):
    return e * f

class zup:
    pass

@public
class zap:
    pass

public('CONST1')
CONST1 = 3

CONST2 = 4

public('CONST3')
CONST3 = 5

Normally for any callable with an __name__, you can just decorate it with @public to add it to __all__.  Of course that doesn't worth with things like constants, thus the str argument.  But of course that also requires sys._getframe() so blech.

----------
messages: 262319
nosy: barry
priority: normal
severity: normal
status: open
title: __all__ decorator
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar 23 23:17:15 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 24 Mar 2016 03:17:15 +0000
Subject: [New-bugs-announce] [issue26633] multiprocessing behavior combining
 daemon with non-daemon children inconsistent with threading
Message-ID: <1458789435.04.0.43504353002.issue26633@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Unclear if this is just unclear docs, or incorrect behavior.

Per this Stack Overflow question ( https://stackoverflow.com/questions/36191447/why-doesnt-the-daemon-program-exit-without-join ), you get some rather odd behavior when you have both daemon and non-daemon child processes. In the case described, the following steps occur:

1. A daemon Process is launched which prints a message, waits two seconds, then prints a second message
2. The main process sleeps one second
3. A non-daemon process is launched which behaves the same as the daemon process, but sleeps six seconds before the second message.
4. The main process completes

The expected behavior (to my mind and the questioner on SO) is that since there is a non-daemon process running, the "process family" should stay alive until the non-daemon process finishes, which gives the daemon process time to wake up and print its second message (five seconds before the non-daemon process wakes to finish its "work"). But in fact, the atexit function used for cleanup in multiprocessing first calls .terminate() on all daemon children before join-ing all children. So the moment the main process completes, it immediately terminates the daemon child, even though the "process family" is still alive.

This seems counter-intuitive; in the threading case, which multiprocessing is supposed to emulate, all non-daemon threads are equivalent, so no daemon threads are cleaned until the last non-daemon thread exits. To match the threading behavior, it seems like the cleanup code should first join all the non-daemon children, then terminate the daemon children, then join the daemon children.

This would change the code here (
https://hg.python.org/cpython/file/3.5/Lib/multiprocessing/util.py#l303 ) from:

            for p in active_children():
                if p.daemon:
                    info('calling terminate() for daemon %s', p.name)
                    p._popen.terminate()

            for p in active_children():
                info('calling join() for process %s', p.name)
                p.join()

to:

            # Wait on non-daemons first
            for p in active_children():
                info('calling join() for process %s', p.name)
                if not p.daemon:
                    p.join()

            # Terminate and clean up daemons now that non-daemons done
            for p in active_children():
                if p.daemon:
                    info('calling terminate() for daemon %s', p.name)
                    p._popen.terminate()
                    info('calling join() for process %s', p.name)
                    p.join()


I've attached repro code to demonstrate; using multiprocessing, the daemon never prints its exiting message, while switching to multiprocessing.dummy (backed by threading) correctly prints the exit message.

----------
components: Library (Lib)
files: testmpdaemon.py
messages: 262324
nosy: josh.r
priority: normal
severity: normal
status: open
title: multiprocessing behavior combining daemon with non-daemon children inconsistent with threading
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42265/testmpdaemon.py

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

From report at bugs.python.org  Thu Mar 24 00:09:36 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 24 Mar 2016 04:09:36 +0000
Subject: [New-bugs-announce] [issue26634] recursive_repr forgets to override
 __qualname__ of wrapper
Message-ID: <1458792576.69.0.965727650976.issue26634@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

In reprlib.recursive_repr, it seems __qualname__ is forgotten. Giving the example in reprlib document, it gives a strange result 'recursive_repr.<locals>.decorating_function.<locals>.wrapper' of Mylist.__repr__.__qualname__.

I simply add the assignment of __qualname__. But I doubt the treatment of __module__, __doc__, __name__, __qualname__ will raise AttributeError when they don't exist in user_function. Is this the desired behaviour or we'd better treat them like functools.update_wrapper, catch and then ignore the error.

----------
components: Library (Lib)
files: qualname_of_recursive_repr_in_reprlib.patch
keywords: patch
messages: 262326
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: recursive_repr forgets to override __qualname__ of wrapper
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42266/qualname_of_recursive_repr_in_reprlib.patch

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

From report at bugs.python.org  Thu Mar 24 08:45:38 2016
From: report at bugs.python.org (Itay Grudev)
Date: Thu, 24 Mar 2016 12:45:38 +0000
Subject: [New-bugs-announce] [issue26635] Python default date does not match
 Unix time
Message-ID: <1458823538.48.0.621744004031.issue26635@psf.upfronthosting.co.za>


New submission from Itay Grudev:

When parsing a time only string like:

```
datetime.datetime.strptime('13:48:25', '%H:%M:%S')
```

This produces:

```
datetime.datetime(1900, 1, 1, 13, 48, 25)
```

Not that the year is `1900` which just doesn't make sense. This will produce `-1` when you attempt to get it's UNIX timestamp. And while that sounds weird it is very useful.

The default year should be 1970. And this will resolve the issue.

----------
messages: 262337
nosy: Itay Grudev
priority: normal
severity: normal
status: open
title: Python default date does not match Unix time
type: behavior

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

From report at bugs.python.org  Thu Mar 24 10:35:24 2016
From: report at bugs.python.org (Denis)
Date: Thu, 24 Mar 2016 14:35:24 +0000
Subject: [New-bugs-announce] [issue26636] SystemError while running tests:
 extra exception raised
Message-ID: <1458830124.86.0.833063009282.issue26636@psf.upfronthosting.co.za>


New submission from Denis:

Looks like related to Issue23571
Probably same issue as in Django, but in other Python module.

While compiling python-module-crypto:

===================================================================== 
ERROR: test_getStrongPrime_randfunc_bogus (Crypto.SelfTest.Util.test_number.FastmathTests) 
Test that when getStrongPrime is called, an exception is raised if randfunc returns something bogus. 
---------------------------------------------------------------------- 
TypeError: randfunc must return a string of random bytes 

During handling of the above exception, another exception occurred: 

SystemError: PyEval_EvalFrameEx returned a result with an error set 

During handling of the above exception, another exception occurred: 

Traceback (most recent call last): 
?File "build/lib.linux-i686-3.5/Crypto/SelfTest/Util/test_number.py", line 322, in test_getStrongPrime_randfunc_bogus 
???self.assertRaises(TypeError, number._fastmath.getStrongPrime, 512, randfunc=randfunc) 
?File "/usr/lib/python3.5/unittest/case.py", line 765, in assertRaises 
???return context.handle('assertRaises', args, kwargs) 
?File "/usr/lib/python3.5/unittest/case.py", line 214, in handle 
???callable_obj(*args, **kwargs) 
SystemError: PyEval_EvalFrameEx returned a result with an error set 

====================================================================== 
ERROR: test_getStrongPrime_randfunc_exception (Crypto.SelfTest.Util.test_number.FastmathTests) 
Test that when getStrongPrime is called, an exception raised in randfunc is propagated. 
---------------------------------------------------------------------- 
Crypto.SelfTest.Util.test_number.MyError 

During handling of the above exception, another exception occurred: 

SystemError: <class 'Crypto.SelfTest.Util.test_number.MyError'> returned a result with an error set 

During handling of the above exception, another exception occurred: 

Traceback (most recent call last): 
?File "build/lib.linux-i686-3.5/Crypto/SelfTest/Util/test_number.py", line 308, in test_getStrongPrime_randfunc_exception 
???self.assertRaises(MyError, number._fastmath.getStrongPrime, 512, randfunc=randfunc) 
?File "/usr/lib/python3.5/unittest/case.py", line 765, in assertRaises 
???return context.handle('assertRaises', args, kwargs) 
?File "/usr/lib/python3.5/unittest/case.py", line 214, in handle 
???callable_obj(*args, **kwargs) 
?File "build/lib.linux-i686-3.5/Crypto/SelfTest/Util/test_number.py", line 307, in randfunc 
???raise MyError 
SystemError: <class 'Crypto.SelfTest.Util.test_number.MyError'> returned a result with an error set 

The file that cause that exception can be found at

http://git.altlinux.org/gears/p/python-module-pycrypto.git?p=python-module-pycrypto.git;a=blob;f=lib/Crypto/SelfTest/Util/test_number.py;h=ac23e917b6e7d982a33fff0a14bec3e769500ba0;hb=86c4aa4683cd89f89c3d01a689efa525f961d340

----------
components: Interpreter Core
messages: 262349
nosy: nbr_alt
priority: normal
severity: normal
status: open
title: SystemError while running tests: extra exception raised
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 24 11:06:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Mar 2016 15:06:33 +0000
Subject: [New-bugs-announce] [issue26637] importlib: better error message
 when import fail during Python shutdown
Message-ID: <1458831993.32.0.609008052486.issue26637@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Example of script.py:
-------------------------
class Bla:
    def __del__(self):
        try:
            import xxxx
        except Exception as exc:
            print("import error: [%s] %r" % (type(exc), exc))

bla = Bla()
-------------------------

Running this example logs a strange error:
-------------------------
$ python3.5 script.py
import error: [<class 'TypeError'>] TypeError("'NoneType' object is not iterable",)
-------------------------

The error comes from importlib._bootstrap._find_spec() which tries to iterator on sys.meta_path, whereas PyImport_Cleanup() was called and this function setted sys.meta_path to None.

Attached patch enhances _find_spec() to handle this case to return None. Error with the patch:
-------------------------
$ python3.5 script.py
import error: [<class 'ImportError'>] ImportError('sys.meta_path is None, Python is likely shutting down',)
-------------------------

----------
components: Library (Lib)
files: importlib_shutdown.patch
keywords: patch
messages: 262352
nosy: brett.cannon, eric.snow, haypo
priority: normal
severity: normal
status: open
title: importlib: better error message when import fail during Python shutdown
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42275/importlib_shutdown.patch

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

From report at bugs.python.org  Fri Mar 25 00:49:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Mar 2016 04:49:40 +0000
Subject: [New-bugs-announce] [issue26638] Avoid warnings about missing CLI
 options when building documentation
Message-ID: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za>


New submission from Martin Panter:

Defeat many warnings and related fixes building documentation

* Mask various CLI options with exclamation marks (!)
* Correct link to CLI section in zipapp
* Make CLI section label in timeit less ambiguous

The following warnings from unittest remain. Ideally they should be linked to the Python CLI documentation, but this does not seem possible because the ?unittest? documentation defines its own CLI options.

Doc/library/unittest.rst:1965: WARNING: unknown option: -Wd
Doc/library/unittest.rst:1965: WARNING: unknown option: -Wa
Doc/library/unittest.rst:2051: WARNING: unknown option: -W

----------
assignee: docs at python
components: Documentation
files: doc-warnings.patch
keywords: patch
messages: 262401
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid warnings about missing CLI options when building documentation
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42282/doc-warnings.patch

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

From report at bugs.python.org  Fri Mar 25 06:50:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Mar 2016 10:50:05 +0000
Subject: [New-bugs-announce] [issue26639] Tools/i18n/pygettext.py: replace
 deprecated imp module with importlib
Message-ID: <1458903005.49.0.704638577802.issue26639@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch replaces the imp module with importlib in Tools/i18n/pygettext.py.

Please review carefully, it looks like the code getting the filename of a Python module is not tested by Lib/test/test_tools.py :-/

----------
files: pygettext_imp.patch
keywords: patch
messages: 262420
nosy: brett.cannon, eric.snow, haypo, ncoghlan
priority: normal
severity: normal
status: open
title: Tools/i18n/pygettext.py: replace deprecated imp module with importlib
versions: Python 3.6
Added file: http://bugs.python.org/file42286/pygettext_imp.patch

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

From report at bugs.python.org  Fri Mar 25 07:56:15 2016
From: report at bugs.python.org (ProgVal)
Date: Fri, 25 Mar 2016 11:56:15 +0000
Subject: [New-bugs-announce] [issue26640] xmlrpc.server imports xmlrpc.client
Message-ID: <1458906975.33.0.607385573018.issue26640@psf.upfronthosting.co.za>


New submission from ProgVal:

from xmlrpc.client import Fault, dumps, loads, gzip_encode, gzip_decode

Shouldn't these class/functions be moved to a new module, with a name like xmlrpc.common?

----------
components: Library (Lib)
messages: 262428
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: xmlrpc.server imports xmlrpc.client
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 25 08:00:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Mar 2016 12:00:35 +0000
Subject: [New-bugs-announce] [issue26641] doctest doesn't support packages
Message-ID: <1458907235.84.0.937791906936.issue26641@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PEP 420 -- Implicit Namespace Packages introduces packages which have no __init__.py file and can be made of multiple packages. It looks like doctest doesn't support them.

I would like to convert the Lib/test/ of the Python standard library into such package for the issue #26295.

I propose to use an heuristic when the package is only made of one directory (when module.__path__ only contains one entry): use this directory to lookup for requested test files.

Attached patch implements that.

----------
files: doctest_package.patch
keywords: patch
messages: 262429
nosy: brett.cannon, eric.snow, haypo, ncoghlan
priority: normal
severity: normal
status: open
title: doctest doesn't support packages
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42288/doctest_package.patch

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

From report at bugs.python.org  Fri Mar 25 09:13:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Mar 2016 13:13:17 +0000
Subject: [New-bugs-announce] [issue26642] Replace stdout and stderr with
 simple standard printers at Python exit
Message-ID: <1458911597.09.0.705997743741.issue26642@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The Python shutdown process is complex and fragile.

It was discussed in the issue #25654 to replace stdout and stderr with simple "standard printers" (implemented in C, don't depend on other Python objects or modules).

Attached patch implements this idea. The patch begins with closing standard stream objects (sys.stdin, sys.stdout, sys.stderr), and then replace stdout and stderr.

----------
files: replace_stdio.patch
keywords: patch
messages: 262436
nosy: haypo
priority: normal
severity: normal
status: open
title: Replace stdout and stderr with simple standard printers at Python exit
versions: Python 3.6
Added file: http://bugs.python.org/file42290/replace_stdio.patch

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

From report at bugs.python.org  Fri Mar 25 14:20:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Mar 2016 18:20:24 +0000
Subject: [New-bugs-announce] [issue26643] regrtest: rework
 libregrtest.save_env submodule
Message-ID: <1458930024.17.0.00462396415924.issue26643@psf.upfronthosting.co.za>


New submission from STINNER Victor:

(I pushed the change 245a16f33c4b, but Serhiy asked me to review it and discuss it. So I reverted my change and created this issue.)

I noticed many times that buildbots log "test xxx changed yyy" but this line is not enough to debug the issue. I propose to always display the old and new value to easy debugging these issues.

Sometimes, I try to reproduce the issue, but I fail to reproduce it locally. I may depend on the test execution order and the platform.

Attached patch changes:

* Replace get/restore methods with a Resource class and Resource subclasses
* Create ModuleAttr, ModuleAttrList and ModuleAttrDict helper classes
* Use __subclasses__() to get resource classes instead of using an hardcoded
  list (2 shutil resources were missinged in the list!)
* Don't define MultiprocessingProcessDangling resource if the multiprocessing module is missing
* Nicer diff for dictionaries. Useful for the big os.environ dict
* Reorder code to group resources


I chose to use classes to be able to easily customize how "Before/After" (value diff) is displayed: the new display_diff() method.

I also wrote helper classes to factorize the code.

Example:

    def get_sys_path(self):
        return id(sys.path), sys.path, sys.path[:]
    def restore_sys_path(self, saved_path):
        sys.path = saved_path[1]
        sys.path[:] = saved_path[2]

becomes

   class SysPath(ModuleAttrList):
       name = 'sys.path'

When sys.path is modified, currently Python displays the whole (id, object, object_copy) tuple which is not easily readable. With my change, it only displays object_copy (one list).

I began to write a pretty diff for ModuleAttrList, but it looks non trivial, and I'm not sure that it's worth (since lists are quite short).

----------
components: Tests
files: save_env.patch
keywords: patch
messages: 262449
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: regrtest: rework libregrtest.save_env submodule
versions: Python 3.6
Added file: http://bugs.python.org/file42293/save_env.patch

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

From report at bugs.python.org  Sat Mar 26 03:28:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 26 Mar 2016 07:28:02 +0000
Subject: [New-bugs-announce] [issue26644] SSLSocket.recv(-1) triggers
 SystemError
Message-ID: <1458977282.91.0.0462711735469.issue26644@psf.upfronthosting.co.za>


New submission from Martin Panter:

SystemError indicates an internal error that is not supposed to be triggerable from Python code. We should probably raise ValueError like plain sockets instead.

>>> s = create_connection(("python.org", 443))
>>> s.recv(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: negative buffersize in recv
>>> ss = ssl.wrap_socket(s)
>>> ss.recv(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/proj/python/cpython/Lib/ssl.py", line 910, in recv
    return self.read(buflen)
  File "/home/proj/python/cpython/Lib/ssl.py", line 787, in read
    return self._sslobj.read(len, buffer)
  File "/home/proj/python/cpython/Lib/ssl.py", line 573, in read
    v = self._sslobj.read(len or 1024)
SystemError: Negative size passed to PyBytes_FromStringAndSize

----------
components: Extension Modules
messages: 262488
nosy: martin.panter
priority: normal
severity: normal
status: open
title: SSLSocket.recv(-1) triggers SystemError
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Mar 26 08:05:01 2016
From: report at bugs.python.org (Alexey Muranov)
Date: Sat, 26 Mar 2016 12:05:01 +0000
Subject: [New-bugs-announce] [issue26645] argparse prints help messages to
 stdout instead of stderr by default
Message-ID: <1458993901.75.0.219308453251.issue26645@psf.upfronthosting.co.za>


New submission from Alexey Muranov:

I believe that printing help and usage messages to stdout is a design error.

In stdout i expect to find the output of my program, not help or diagnostic messages.  It is strange to see nothing printed on the screen (where stderr usually goes), and then to find help, usage, or *error* messages in the file where stdout was sent.  (Yes, argparse prints even error messages to stdout by default).

This issue has been discussed before because the implementation did not agree with the documentation: http://bugs.python.org/issue10728
I believe that the conclusion to adjust the documentation to the implementation was a mistake.

P.S. Compare with the direction of the output of `grep -h` or `git -h`.

----------
components: Library (Lib)
messages: 262491
nosy: Alexey Muranov
priority: normal
severity: normal
status: open
title: argparse prints help messages to stdout instead of stderr by default
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar 26 16:20:28 2016
From: report at bugs.python.org (Daniel Shaulov)
Date: Sat, 26 Mar 2016 20:20:28 +0000
Subject: [New-bugs-announce] [issue26646] Allow built-in module in package
Message-ID: <1459023628.39.0.77878937212.issue26646@psf.upfronthosting.co.za>


New submission from Daniel Shaulov:

Hi,

I was trying to build a python interpreter that has the cpp part of msgpack as a built-in module. I thought that I could just copy the msgpack folder to the Modules folder and add this 2 lines to Modules/Setup.local:

msgpack._packer msgpack/_packer.cpp
msgpack._unpacker msgpack/_unpacker.cpp

I had a few obstacles, the attached patch fixes them all.

The first - makesetup has a list of regexes to match and it has *.* after going through all known extensions to throw a "bad word" error.
I removed the check. All those things will now be assumed to be a module with a package.
Now the actual init function name is PyInit__packer and doesn't have msgpack in it, so I also added code in makesetup to use the full name as the name and only the module name for the PyInit function.


The second is that in Lib/importlib/_bootsrap.py in BuiltinImporter.find_spec there is a specific case to ignore modules that are part of a package.
Is there a reason to forbid it? I removed that check.
There were also unit tests that checked this behavior which I deleted.
I added tests that check module in package instead of them.
Changing _bootsrap.py also changes Python/importlib.h (it is the frozen importlib), I added a separate patch with that change, to not clutter the main patch.

The third - the __name__ didn't have the package prefix.
Digging around I found a comment in PyModule_Create2 that says that the shared library loader stores the full name _Py_PackageContext before loading the module, so I did the same in _imp_create_builtin that is done in _PyImport_LoadDynamicModuleWithSpec to set _Py_PackageContext and the __name__ was fixed too.

(If anyone tries to do this with msgpack and wants to see that it works - you also need to copy the msgpack directory to the Lib directory, and in __init__.py, where it catches the import error and goes to the fallback, just reraise the exception instead of letting it go to the fallback)

Do note that this does not allow for built-in packages, only build-it module in package. If we want to allow built-in packages, we will need to decide on some syntax to distinguish it in the Setup files and some way to distinguish them in PyImport_Inittab (for example - an asterix before the name of the package?)

Thanks, Daniel.

----------
components: Build, Interpreter Core
files: builtin_package.patch
keywords: patch
messages: 262495
nosy: Daniel Shaulov, brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Allow built-in module in package
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42297/builtin_package.patch

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

From report at bugs.python.org  Sat Mar 26 19:27:48 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sat, 26 Mar 2016 23:27:48 +0000
Subject: [New-bugs-announce] [issue26647] Wordcode
Message-ID: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>


New submission from Demur Rumed:

Originally started @ https://github.com/abarnert/cpython/tree/wpy

This patch is based off of https://github.com/serprex/cpython/tree/wpy

It omits importlib.h & importlib_external.h as those are generated

It omits https://github.com/serprex/cpython/blob/wpy/Python/wordcode.md

I got around to benchmarking against building on master rather than using my repo's packaged version, it's currently a 1% speed improvement (every bit counts). I'm testing on an Intel Atom 330 with Linux.  Besides the minor perf increase, it generates smaller bytecode & is simpler (peephole now handles EXTENDED_ARG since it isn't too hard to track & while loops become for loops in dis)

Previous discussion: https://mail.python.org/pipermail/python-dev/2016-February/143357.html

pdb works without changes. coverage.py doesn't seem to rely on anything this changes

I modified byteplay to target this change mostly over the course of half an hour before work: https://github.com/serprex/byteplay/blob/master/wbyteplay.py

I'd be interested to hear if this encoding simplifies things for FAT python & the recent work to cache attribute/global lookup

Remaining code issues: peepholer could allocate half the space as it does now for basic block tracking, compile.c & peephole.c repeat themselves on computing instruction size given an argument & how to spit out an instruction given an argument

Breaking change in dis: I've removed HAVE_ARGUMENT. This is to help code fail fast. It could be replaced with IGNORES_ARGUMENT or, as abarnert suggested, a range(90,256) named after the other hasXXXs 'hasarg'

----------
components: Interpreter Core
files: wpy.patch
keywords: patch
messages: 262501
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: Wordcode
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42300/wpy.patch

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

From report at bugs.python.org  Sat Mar 26 20:45:05 2016
From: report at bugs.python.org (Philip Martin)
Date: Sun, 27 Mar 2016 00:45:05 +0000
Subject: [New-bugs-announce] [issue26648] csv.reader Error message indicates
 to use deprecated
Message-ID: <1459039505.55.0.691901894808.issue26648@psf.upfronthosting.co.za>


New submission from Philip Martin:

Currently, the error message:

_csv.Error: new-line character seen in unquoted field - do you need to open the file in universal-newline mode?

is cryptic in that universal line mode has been deprecated, and will not run in Python 3.5., i.e.:
open(escape_path, "rU", encoding=ENCODING)
>>> DeprecationWarning: 'U' mode is deprecated

I think a message indicating a suggestion to open the file with newline='' to enable universal line mode is more insightful.

----------
messages: 262502
nosy: Philip Martin
priority: normal
severity: normal
status: open
title: csv.reader Error message indicates to use deprecated
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar 27 01:54:40 2016
From: report at bugs.python.org (q20611152@163.com)
Date: Sun, 27 Mar 2016 05:54:40 +0000
Subject: [New-bugs-announce] [issue26649] Fail update installation: 'utf-8'
 codec can't decode
Message-ID: <1459058080.48.0.96946977004.issue26649@psf.upfronthosting.co.za>


New submission from q20611152 at 163.com:

This error  occureed on the gns3 ;
give you the errorlog files .

----------
files: gns3-errorlog
messages: 262510
nosy: shanzhengcheng
priority: normal
severity: normal
status: open
title: Fail update installation: 'utf-8' codec can't decode
versions: Python 3.5
Added file: http://bugs.python.org/file42303/gns3-errorlog

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

From report at bugs.python.org  Sun Mar 27 05:38:56 2016
From: report at bugs.python.org (Martijn Pieters)
Date: Sun, 27 Mar 2016 09:38:56 +0000
Subject: [New-bugs-announce] [issue26650] calendar: OverflowErrors for year
 == 1 and firstweekday > 0
Message-ID: <1459071536.92.0.968744515291.issue26650@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

For anything other than calendar.Calendar(0), many methods lead to OverflowError exceptions:

>>> import calendar
>>> c = calendar.Calendar(0)
>>> list(c.itermonthdays(1, 1))
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 0, 0, 0, 0]
>>> c = calendar.Calendar(1)
>>> list(c.itermonthdays(1, 1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mjpieters/Development/Library/buildout.python/parts/opt/lib/python2.7/calendar.py", line 188, in itermonthdays
    for date in self.itermonthdates(year, month):
  File "/Users/mjpieters/Development/Library/buildout.python/parts/opt/lib/python2.7/calendar.py", line 160, in itermonthdates
    date -= datetime.timedelta(days=days)
OverflowError: date value out of range

This echoes a similar problem with year = 9999, see issue #15421

----------
components: Library (Lib)
messages: 262514
nosy: mjpieters
priority: normal
severity: normal
status: open
title: calendar: OverflowErrors for year == 1 and firstweekday > 0
type: crash
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Sun Mar 27 12:57:46 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 27 Mar 2016 16:57:46 +0000
Subject: [New-bugs-announce] [issue26651] Deprecate register_adapter() and
 register_converter() in sqlite3
Message-ID: <1459097866.18.0.37527564025.issue26651@psf.upfronthosting.co.za>


New submission from Berker Peksag:

In issue 19065:

Gerhard says:

"I'm -1 because I believe that ultimately, adapters and converters were a mistake to add to pysqlite. That's why I deprecated them in pysqlite 2.8.0."

Here is a patch (based on commit from pysqlite project [1]) to deprecate them.

[1] https://github.com/ghaering/pysqlite/commit/c819a1eacb6baa52d9743bd400907307711a7427#diff-a31e41a9e523fbbf9e60ba9a31f38efeR159

----------
components: Extension Modules
files: deprecate_adapters.diff
keywords: patch
messages: 262525
nosy: berker.peksag, ghaering
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate register_adapter() and register_converter() in sqlite3
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42309/deprecate_adapters.diff

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

From report at bugs.python.org  Sun Mar 27 23:34:16 2016
From: report at bugs.python.org (Hung-Hsuan Chen)
Date: Mon, 28 Mar 2016 03:34:16 +0000
Subject: [New-bugs-announce] [issue26652] Cannot install Python 2.7.11 on
 Windows Server 2008 R2
Message-ID: <1459136056.53.0.428865643545.issue26652@psf.upfronthosting.co.za>


New submission from Hung-Hsuan Chen:

I tried installing Python2.7.11 on a Virtual machine running Windows Server 2008 R2.  However, I cannot complete the installation.  I tried reboot the machine and re-install for a couple of times but got no luck.  Here I attach the log file of "msiexec /i python-2.7.amd64.msi /l*v python.log".  I hope someone can help me to figure this out.

Thanks!

----------
components: Installation
files: python.log
messages: 262550
nosy: Hung-Hsuan Chen
priority: normal
severity: normal
status: open
title: Cannot install Python 2.7.11 on Windows Server 2008 R2
versions: Python 2.7
Added file: http://bugs.python.org/file42314/python.log

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

From report at bugs.python.org  Mon Mar 28 00:00:48 2016
From: report at bugs.python.org (Mike Lenzen)
Date: Mon, 28 Mar 2016 04:00:48 +0000
Subject: [New-bugs-announce] [issue26653] bisect raises a TypeError when hi
 is None
Message-ID: <1459137648.89.0.2938672633.issue26653@psf.upfronthosting.co.za>


New submission from Mike Lenzen:

>>> bisect.bisect([1, 2, 3], 1, hi=None)
TypeError: 'NoneType' object cannot be interpreted as an integer

I'm assuming this is an error in the C implementation because the Python source has:

    if hi is None:
        hi = len(a)

----------
components: Library (Lib)
messages: 262551
nosy: Mike Lenzen, rhettinger
priority: normal
severity: normal
status: open
title: bisect raises a TypeError when hi is None
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 28 05:57:30 2016
From: report at bugs.python.org (iceboy)
Date: Mon, 28 Mar 2016 09:57:30 +0000
Subject: [New-bugs-announce] [issue26654] asyncio is not inspecting keyword
 arguments of functools.partial
Message-ID: <1459159050.15.0.830010057156.issue26654@psf.upfronthosting.co.za>


New submission from iceboy:

import asyncio
import functools

def foo(x): raise Exception()

loop = asyncio.get_event_loop()
loop.call_soon(functools.partial(foo, x=1))
loop.run_forever()

Current error message:
    Exception in callback foo()() at ...:4

Expected error message:
    Exception in callback foo(x=1)() at ...:4

----------
components: asyncio
messages: 262566
nosy: gvanrossum, haypo, iceboy, yselivanov
priority: normal
severity: normal
status: open
title: asyncio is not inspecting keyword arguments of functools.partial
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 28 09:24:02 2016
From: report at bugs.python.org (Udo Eberhardt)
Date: Mon, 28 Mar 2016 13:24:02 +0000
Subject: [New-bugs-announce] [issue26655] pathlib glob case sensitivity
 issue on Windows
Message-ID: <1459171442.9.0.718616645463.issue26655@psf.upfronthosting.co.za>


New submission from Udo Eberhardt:

On Windows Path.glob does not always return the file name with correct case. 

If the current directory contains a file named MixedCase.txt then the following script:

import pathlib
p = pathlib.Path('.')
print(list(p.glob('*.txt')))
print(list(p.glob('Mixedcase.txt')))

yields:
[WindowsPath('MixedCase.txt')]
[WindowsPath('mixedcase.txt')]

Problem: The result of the second call to glob should be 'MixedCase.txt' as well. I would expect that glob returns a file name exactly as it is spelled in the file system.

----------
components: Library (Lib), Windows
messages: 262570
nosy: paul.moore, steve.dower, tim.golden, udo.eberhardt, zach.ware
priority: normal
severity: normal
status: open
title: pathlib glob case sensitivity issue on Windows
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 28 11:21:24 2016
From: report at bugs.python.org (Sworddragon)
Date: Mon, 28 Mar 2016 15:21:24 +0000
Subject: [New-bugs-announce] [issue26656] Documentation for re.compile is a
 bit outdated
Message-ID: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>


New submission from Sworddragon:

The documentation for re.compile says "Compile a regular expression pattern into a regular expression object, which can be used for matching using its match() and search() methods, described below." which implies that match() and search() are the only methods for it while there are a few more. Maybe this sentence should be worded more generic or at least complete the list.

----------
assignee: docs at python
components: Documentation
messages: 262571
nosy: Sworddragon, docs at python
priority: normal
severity: normal
status: open
title: Documentation for re.compile is a bit outdated
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar 28 11:30:15 2016
From: report at bugs.python.org (Thomas)
Date: Mon, 28 Mar 2016 15:30:15 +0000
Subject: [New-bugs-announce] [issue26657] Directory traversal with
 http.server and SimpleHTTPServer on windows
Message-ID: <1459179015.77.0.509336394494.issue26657@psf.upfronthosting.co.za>


New submission from Thomas:

SimpleHTTPServer and http.server allow directory traversal on Windows.
To exploit this vulnerability, replace all ".." in URLs with "c:c:c:..".


Example:
Run
python -m http.server
and visit
127.0.0.1:8000/c:c:c:../secret_file_that_should_be_secret_but_is_not.txt


There is a warning that those modules are not secure in the module docs,
but for some reason they do not appear in the online docs:
https://docs.python.org/3/library/http.server.html
https://docs.python.org/2/library/simplehttpserver.html


It would be nice if that warning was as apparent as for example here:
https://docs.python.org/2/library/xml.etree.elementtree.html


There are a lot of other URLs that are insecure as well, which can all
be traced back to here:
https://hg.python.org/cpython/file/tip/Lib/http/server.py#l766


The splitdrive and split functions, which should make sure that the
final output is free of ".." are only called once which leads to this
control flow:
---------------------------------------------------------------
path = "c:/secret/public"
word = "c:c:c:.."

_, word = os.path.splitdrive(word) # word = "c:c:.."
_, word = os.path.split(word) # word = "c:.."
path = os.path.join(path, word) # path = "c:/secret/public\\.."
---------------------------------------------------------------


Iterating splitdrive and split seems safer:
---------------------------------------------------------------
for word in words:
    # Call split and splitdrive multiple times until
    # word does not change anymore.
    has_changed = True
    while has_changed:
        previous_word = word
        _, word = os.path.split(word)
        _, word = os.path.splitdrive(word)
        has_changed = word != previous_word
---------------------------------------------------------------






There is another weird thing which I am not quite sure about here:
https://hg.python.org/cpython/file/tip/Lib/http/server.py#l761

---------------------------------------------------------------
path = posixpath.normpath(path)
words = path.split('/')
---------------------------------------------------------------

posixpath.normpath does not do anything with backslashes and then the
path is split by forward slashes, so it may still contain backslashes.
Maybe replacing posixpath.normpath with os.path.normpath and then
splitting by os.sep would work, but I don't have enough different
operating systems to test this, so someone else should have a look.





I have attached some simple fuzzing test that tries a few weird URLs and
sees if they lead where they shouldn't.
Disclaimer: Might still contain other bugs.

----------
components: Library (Lib)
files: fuzz.py
messages: 262572
nosy: Thomas
priority: normal
severity: normal
status: open
title: Directory traversal with http.server and SimpleHTTPServer on windows
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file42315/fuzz.py

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

From report at bugs.python.org  Mon Mar 28 12:49:26 2016
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 28 Mar 2016 16:49:26 +0000
Subject: [New-bugs-announce] [issue26658] test_os fails when run on Windows
 ramdisk
Message-ID: <1459183766.58.0.185896673203.issue26658@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

The Win32JunctionTests class fails when the test suite is run on an ImDisk[1]_ virtual disk.  The junctions are created successfully, however os.stat() fails on them (winerror 123).  os.lstat() does succeed.

I'm inclined to believe that this is a bug in the ImDisk device driver, but when testDown() is run, it fails to remove the newly created junction to the test directory.  By leaving the junction in place, when the test runner completes it removes the entire temporary test directory containing the junction thus removing the Lib test directory!

I suggest that at least changing the tearDown() method to use os.path.lexists() to ensure that the junction is removed regardless of its target existing or not.


.. [1] http://www.ltr-data.se/opencode.html/#ImDisk

----------
components: Tests, Windows
files: test_os.patch
keywords: patch
messages: 262577
nosy: haypo, jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_os fails when run on Windows ramdisk
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42317/test_os.patch

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

From report at bugs.python.org  Mon Mar 28 16:07:30 2016
From: report at bugs.python.org (Kevin Modzelewski)
Date: Mon, 28 Mar 2016 20:07:30 +0000
Subject: [New-bugs-announce] [issue26659] slice() leaks memory when part of
 a cycle
Message-ID: <1459195650.62.0.697543008617.issue26659@psf.upfronthosting.co.za>


New submission from Kevin Modzelewski:

The slice type doesn't participate in GC, which means that if you happen to create a cycle involving a slice, that cycle will never get freed.  Here's an example:

def f():
    l = []
    l.append(slice(l))
# Will consume memory without bound:
while True:
    f()

This seems pretty hard to trigger accidentally, so it might not be a huge deal -- especially since it seems to have been around for a while.  (I only checked 2.7 and trunk though.)

I think this could be solved by either having the slice class participate in GC (ie add tp_traverse and tp_clear methods), or maybe doing some type-filtering during slice_new().

----------
components: Interpreter Core
messages: 262582
nosy: Kevin Modzelewski
priority: normal
severity: normal
status: open
title: slice() leaks memory when part of a cycle
type: resource usage
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Mon Mar 28 18:22:28 2016
From: report at bugs.python.org (Laurent Mazuel)
Date: Mon, 28 Mar 2016 22:22:28 +0000
Subject: [New-bugs-announce] [issue26660] tempfile.TemporaryDirectory()
 cleanup exception on Windows if readonly files created
Message-ID: <1459203748.81.0.389724870435.issue26660@psf.upfronthosting.co.za>


New submission from Laurent Mazuel:

Using tempfile.TemporaryDirectory() in Windows, creating read-only files in this temp directory leads to PermissionError during the cleanup().
This is a direct cause of this one:
https://bugs.python.org/issue19643

And the workaround which was proposed in the issue 19643 and added to the doc here:
https://docs.python.org/3/library/shutil.html?highlight=shutil#rmtree-example

is not used in the TemporaryDirectory implementation.

I don't know if the right solution is to modify the implementation to systematically delete read-only files using the cited workaround, or to add a 'remove_readonly' flag or to update the documentation to clearly says that cleanup will raise a PermissionError if the user creates a read-only file. At least documentation please :)

In my specific usecase I "git clone" in the temp directory, and the .git folder contains read-only files.

Full stacktrace:
Traceback (most recent call last):
  File "C:\mycode.py", line 149, in build_libraries
    update(generated_path, dest_folder)
  File "C:\Program Files\Python35\lib\tempfile.py", line 807, in __exit__
    self.cleanup()
  File "C:\Program Files\Python35\lib\tempfile.py", line 811, in cleanup
    _shutil.rmtree(self.name)
  File "C:\Program Files\Python35\lib\shutil.py", line 488, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\Program Files\Python35\lib\shutil.py", line 378, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\Program Files\Python35\lib\shutil.py", line 378, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\Program Files\Python35\lib\shutil.py", line 378, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\Program Files\Python35\lib\shutil.py", line 378, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\Program Files\Python35\lib\shutil.py", line 383, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "C:\Program Files\Python35\lib\shutil.py", line 381, in _rmtree_unsafe
    os.unlink(fullname)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\me\\AppData\\Local\\Temp\\tmpk62cp34t\\readonly.file'

----------
components: Library (Lib)
messages: 262584
nosy: Laurent.Mazuel
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory() cleanup exception on Windows if readonly files created
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 29 06:09:12 2016
From: report at bugs.python.org (Robert Kuska)
Date: Tue, 29 Mar 2016 10:09:12 +0000
Subject: [New-bugs-announce] [issue26661] python fails to locate system
 libffi
Message-ID: <1459246152.22.0.57778057602.issue26661@psf.upfronthosting.co.za>


New submission from Robert Kuska:

Python fails to locate system version of ffi when building. We delete bundled version of ffi and build process fail with following error:

error: [Errno 2] No such file or directory: '/builddir/build/BUILD/Python-3.5.1/Modules/_ctypes/libffi'

This is caused by setup.py at 1993 checking only for '#define LIBFFI_H' within ffi.h.

Content of /usr/include/ffi.h:

> $ cat /usr/include/ffi.h
/* This file is here to prevent a file conflict on multiarch systems. */
#ifdef ffi_wrapper_h
#error "Do not define ffi_wrapper_h!"
#endif
#define ffi_wrapper_h

#if defined(__i386__)
#include "ffi-i386.h"
#elif defined(__powerpc64__)
#include "ffi-ppc64.h"
#elif defined(__powerpc__)
#include "ffi-ppc.h"
#elif defined(__s390x__)
#include "ffi-s390x.h"
#elif defined(__s390__)
#include "ffi-s390.h"
#elif defined(__x86_64__)
#include "ffi-x86_64.h"
#else
#error "The libffi-devel package is not usable with the architecture."
#endif

#undef ffi_wrapper_h

It is important to note that this content is Fedora specific. As a workaround we (Fedora) use attached patch.

Would it be plausible to accept this patch in upstream?

----------
components: Build
files: 00184-ctypes-should-build-with-libffi-multilib-wrapper.patch
keywords: patch
messages: 262598
nosy: rkuska
priority: normal
severity: normal
status: open
title: python fails to locate system libffi
type: compile error
Added file: http://bugs.python.org/file42320/00184-ctypes-should-build-with-libffi-multilib-wrapper.patch

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

From report at bugs.python.org  Tue Mar 29 06:38:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Mar 2016 10:38:22 +0000
Subject: [New-bugs-announce] [issue26662] FreeBSD: "invalid slot offset"
 error on _ssl, _curses_panel and _testmultiphase extensions
Message-ID: <1459247902.98.0.893274525942.issue26662@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I built Python 3.6 (default) on FreeBSD using:

./configure --cache-file=config_debug.cache --with-pydebug CFLAGS=-O0
make

I'm using FreeBSD current, uname -a:

FreeBSD freebsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296485: Tue Mar  8 07:04:36 UTC 2016     root at releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

It looks like "cc" is clang LLVM compiler 3.8.0.

Extract of the make output:
---
[haypo at freebsd ~/prog/python/default]$ make
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
*** WARNING: importing extension "_testmultiphase" failed with <class 'RuntimeError'>: invalid slot offset
*** WARNING: importing extension "_ssl" failed with <class 'RuntimeError'>: invalid slot offset
*** WARNING: importing extension "_curses_panel" failed with <class 'RuntimeError'>: invalid slot offset
---

----------
messages: 262600
nosy: haypo
priority: normal
severity: normal
status: open
title: FreeBSD: "invalid slot offset" error on _ssl, _curses_panel and _testmultiphase extensions
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar 29 06:54:15 2016
From: report at bugs.python.org (Robert Smallshire)
Date: Tue, 29 Mar 2016 10:54:15 +0000
Subject: [New-bugs-announce] [issue26663] asyncio
 _UnixWritePipeTransport._close abandons unflushed writes
Message-ID: <1459248855.31.0.82334593717.issue26663@psf.upfronthosting.co.za>


New submission from Robert Smallshire:

Note: This report is based on a close reading of the asyncio code, rather than having experienced defective behaviour in test or production.

The documentation for BaseTransport.close() states: "Close the transport. If the transport has a buffer for outgoing data, buffered data will be flushed asynchronously."

The _UnixWritePipeTransport._close method, which is called by close() contains this code in Python 3.5.1

    def _close(self, exc=None):
        self._closing = True
        if self._buffer:
            self._loop.remove_writer(self._fileno)
        self._buffer.clear()
        self._loop.remove_reader(self._fileno)
        self._loop.call_soon(self._call_connection_lost, exc)

In this context, _buffer is a list of bytes objects comprising yet-to-be-written data. Note that close() removes the writer if _buffer is *not* empty, so the buffered data will never be written.  I believe this conditional should be inverted, so the writer is removed only if the buffer is *empty*. So:

        if not self._buffer:
            self._loop.remove_writer(self._fileno)

Arguably though, a more robust and easier to read test would be to call get_write_buffer_size(), like this:

        if self.get_write_buffer_size() == 0:
            self._loop.remove_writer(self._fileno)

Note that in the event that the writer is not removed by _close(), the writer will
remove itself when the buffer does eventually become empty.

Assuming my analysis is correct, and a fix is made to close(), then abort() will also need to be modified to *not* flush buffered writes, as the documentation for abort() states "Close the transport immediately, without waiting for pending operations to complete. Buffered data will be lost."

----------
components: asyncio
messages: 262601
nosy: Robert Smallshire, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio _UnixWritePipeTransport._close abandons unflushed writes
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar 29 08:46:25 2016
From: report at bugs.python.org (=?utf-8?b?6YSt5pmv5paH?=)
Date: Tue, 29 Mar 2016 12:46:25 +0000
Subject: [New-bugs-announce] [issue26664] find a bug in activate.fish of
 venv of cpython3.6
Message-ID: <1459255585.37.0.253753371111.issue26664@psf.upfronthosting.co.za>


New submission from ???:

I use venv module to make a virtual environment in cpython3.6.
After it, I try to activate it with fish, but it give me an error, like the screenshot. 
I open the activate.fish and remove the $ sign in line 58 and 59, then the activate file works. 
I open the activate.fish of py3.5 venv, there isn't a $ sign in line 58 and 59, too. 
However, there is a bug issue which add the $ in front of the prompt. 
I'm not sure how this happen, but I think there should not be a $ there.

----------
files: screenshot.png
messages: 262609
nosy: ???
priority: normal
severity: normal
status: open
title: find a bug in activate.fish of venv of cpython3.6
Added file: http://bugs.python.org/file42321/screenshot.png

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

From report at bugs.python.org  Tue Mar 29 10:24:46 2016
From: report at bugs.python.org (Axel Luttgens)
Date: Tue, 29 Mar 2016 14:24:46 +0000
Subject: [New-bugs-announce] [issue26665] pip is not bootstrapped by default
Message-ID: <1459261486.77.0.745706792357.issue26665@psf.upfronthosting.co.za>


New submission from Axel Luttgens:

Relevant page:

????https://docs.python.org/2/library/ensurepip.html

One may read:

????In most cases, end users of Python shouldn?t need to invoke
????this module directly (as pip should be bootstrapped by default),
????but it may be needed if installing pip was skipped when
????installing Python (or when creating a virtual environment) or
????after explicitly uninstalling pip.

As far as I correctly read the configure file that comes with the 2.7.11 tarball, the default is to behave as if --with-ensurepip=no had been passed.

As a result, that sentence fragment:

????(as pip should be bootstrapped by default)

may appear somewhat ambiguous for those compiling Python themselves.

Perhaps could this one avoid some head scratching:

????(as packagers are expected to have bootstrapped pip)

HTH,
Axel

----------
assignee: docs at python
components: Documentation
messages: 262610
nosy: Axel, docs at python
priority: normal
severity: normal
status: open
title: pip is not bootstrapped by default
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar 29 11:28:41 2016
From: report at bugs.python.org (Zack Weinberg)
Date: Tue, 29 Mar 2016 15:28:41 +0000
Subject: [New-bugs-announce] [issue26666] File object hook to modify
 select(ors) event mask
Message-ID: <1459265321.27.0.359178089762.issue26666@psf.upfronthosting.co.za>


New submission from Zack Weinberg:

This is pretty esoteric, please bear with me.  I'm attempting to enhance a transparent-SOCKS module (https://github.com/Anorov/PySocks) to support non-blocking connect().  This means, you should be able to do this:

    socks.set_default_proxy(socks.SOCKS5, "localhost")
    s = socks.socksocket(socket.AF_INET, socket.SOCK_STREAM)
    s.setblocking(False)
    err = s.connect_ex(address)
    if err == errno.EINPROGRESS:
       select.select([], [s], []) # returns when connection completes

Note the position of s in the select() arguments: the documented behavior of non-blocking connect(), at the operating system level, is that the socket will become *writable* when the connection resolves (whether successfully or not).  However, in this case, under the hood, the socket is *already connected* -- to the proxy server -- after socksocket() returns.  When connect_ex() returns EINPROGRESS, the thing we're really waiting for is a SOCKS-protocol reply message, i.e. the socket needs to become *readable* before the application can continue.  An application that used the above code (with a hypothetical version of PySocks where this was supported) would get woken up immediately, since the initial SOCKS client->server message doesn't even come close to filling up the TCP send buffer.

There's no practical way to hide this divergence with the current library.  What would be needed, I think, is a pair of new special methods on filelikes, which rewrite the set of events to listen for and the set of events to report.  Hypothetical, for my use case:

    def __preselect__(self, events):
        if not self._connecting: return events
        return selectors.EVENT_READ

    def __postselect__(self, events):
        if not self._connecting: return events
        return selectors.EVENT_WRITE

(I'm using the high-level selectors.EVENT_* constants for illustration.  This needs to happen in the low-level select-module methods, because callers can't be expected to use selectors.)

There are a bunch of awkward corner cases to worry about with this, and I'm not even sure the feature is worth it, but I thought I'd write up the problem and see what other people think.

----------
components: IO
messages: 262612
nosy: zwol
priority: normal
severity: normal
status: open
title: File object hook to modify select(ors) event mask
type: enhancement

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

From report at bugs.python.org  Tue Mar 29 14:22:54 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Mar 2016 18:22:54 +0000
Subject: [New-bugs-announce] [issue26667] Update importlib to accept
 pathlib.Path objects
Message-ID: <1459275774.9.0.416740988554.issue26667@psf.upfronthosting.co.za>


New submission from Brett Cannon:

We should go through importlib and update the various APIs to accept pathlib.Path objects and not just str.

----------
messages: 262618
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update importlib to accept pathlib.Path objects
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar 29 21:14:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Mar 2016 01:14:28 +0000
Subject: [New-bugs-announce] [issue26668] Remove
 Lib/test/test_importlib/regrtest.py?
Message-ID: <1459300468.22.0.543956048142.issue26668@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Docstring of the file:

"""Run Python's standard test suite using importlib.__import__.

Tests known to fail because of assumptions that importlib (properly)
invalidates are automatically skipped if the entire test suite is run.
Otherwise all command-line options valid for test.regrtest are also valid for
this script.

"""

Since Python 3 now uses importlib by default for __import__, I think that the file became useless and can be removed.

----------
messages: 262641
nosy: brett.cannon, eric.snow, haypo
priority: normal
severity: normal
status: open
title: Remove Lib/test/test_importlib/regrtest.py?
versions: Python 3.6

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

From report at bugs.python.org  Wed Mar 30 03:17:23 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 30 Mar 2016 07:17:23 +0000
Subject: [New-bugs-announce] [issue26669] time.localtime(float("NaN")) does
 not raise a ValueError on all platforms
Message-ID: <1459322243.53.0.921219428076.issue26669@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

time.localtime(float("NaN")) raises a ValueError on x86_64 using the few compilers I have tested it with. (this makes sense)

>>> time.localtime(float("NaN"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: (75, 'Value too large for defined data type')

On an arm and arm64 system, it does not and treats NaN as 0. (nonsense!)

>>> time.localtime(float("NaN"))
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)

The root of this problem appears to be the (potentially questionable? I'll ask a C compiler person...) code in Python/pytime.c's (3.x) Modules/timemodule.c's (2.7) double to time_t conversion function.

I'm not sure what it does is supposed to be well defined behavior with NaN...

The easy fix is to add:

#include <math.h>

and

add || isnan(x) || isinf(x) to the check that raises a ValueError in

https://hg.python.org/cpython/file/4c903ceeb4d1/Python/pytime.c#l149 (3.x)
https://hg.python.org/cpython/file/2.7/Modules/timemodule.c#l102 (2.7)

Along with a relevant assertRaises(ValueError) unittest for NaN, inf and -inf in test_time.py.

----------
components: Extension Modules, Interpreter Core
messages: 262653
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: time.localtime(float("NaN")) does not raise a ValueError on all platforms
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Mar 30 04:20:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Mar 2016 08:20:14 +0000
Subject: [New-bugs-announce] [issue26670] Add a developer mode: -X dev
 command line option
Message-ID: <1459326014.81.0.126746862215.issue26670@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch implements the idea proposed on the python-ideas mailing list:
https://mail.python.org/pipermail/python-ideas/2016-March/039314.html

The patch is a proof-of-concept. The code still contains FIXME.

----------
files: dev_mode.patch
keywords: patch
messages: 262655
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a developer mode: -X dev command line option
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42326/dev_mode.patch

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

From report at bugs.python.org  Wed Mar 30 05:31:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Mar 2016 09:31:14 +0000
Subject: [New-bugs-announce] [issue26671] Clean up path_converter in
 posixmodule.c
Message-ID: <1459330274.5.0.616265410958.issue26671@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

path_converter in Modules/posixmodule.c sequentially tries to convert an argument to str, bytes, and int. If previous conversion is failed, it clears the error and tries with type. This can hide some errors (such as MemoryError) and even cause using unexpected conversion.

Proposed patch cleans up path_converter. In addition it avoids copying the content of instances of string subclass.

----------
assignee: serhiy.storchaka
components: Extension Modules
files: path_converter_cleanup.patch
keywords: patch
messages: 262657
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Clean up path_converter in posixmodule.c
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42327/path_converter_cleanup.patch

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

From report at bugs.python.org  Wed Mar 30 07:19:11 2016
From: report at bugs.python.org (Axel Luttgens)
Date: Wed, 30 Mar 2016 11:19:11 +0000
Subject: [New-bugs-announce] [issue26672] regrtest missing in the module name
Message-ID: <1459336751.45.0.914074281653.issue26672@psf.upfronthosting.co.za>


New submission from Axel Luttgens:

Relevant page:

????https://docs.python.org/2/library/test.html

One may read (section 25.5.2):

????Specifying all as the value for the -u option enables all
????possible resources: python -m test -uall.

I guess this should be:

????Specifying all as the value for the -u option enables all
????possible resources: python -m test.regrtest -uall.

HTH,
Axel

----------
assignee: docs at python
components: Documentation
messages: 262661
nosy: Axel, docs at python
priority: normal
severity: normal
status: open
title: regrtest missing in the module name
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar 30 11:32:00 2016
From: report at bugs.python.org (wysaard)
Date: Wed, 30 Mar 2016 15:32:00 +0000
Subject: [New-bugs-announce] [issue26673] Tkinter error when opening IDLE
 configuration menu
Message-ID: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>


New submission from wysaard:

I'm using Python 3.5.1 on Arch Linux. I've restalled the python package which provides IDLE, and the tkinter package which is used by IDLE, but to no effect.

My problem is this: When in the menu at the top in IDLE, I click on Options -> Configure IDLE, the menu will stop responding, and nothing happens after that.

Doing this when I run IDLE in a terminal provides the following error on clicking `Configure IDLE`:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.5/tkinter/__init__.py", line 1549, in __call__
    return self.func(*args)
  File "/usr/lib/python3.5/idlelib/EditorWindow.py", line 516, in config_dialog
    configDialog.ConfigDialog(self.top,'Settings')
  File "/usr/lib/python3.5/idlelib/configDialog.py", line 74, in __init__
    self.LoadConfigs()
  File "/usr/lib/python3.5/idlelib/configDialog.py", line 1086, in LoadConfigs
    self.LoadFontCfg()
  File "/usr/lib/python3.5/idlelib/configDialog.py", line 988, in LoadFontCfg
    self.SetFontSample()
  File "/usr/lib/python3.5/idlelib/configDialog.py", line 866, in SetFontSample
    self.labelFontSample.config(font=newFont)
  File "/usr/lib/python3.5/tkinter/__init__.py", line 1330, in configure
    return self._configure('configure', cnf, kw)
  File "/usr/lib/python3.5/tkinter/__init__.py", line 1321, in _configure
    self.tk.call(_flatten((self._w, cmd)) + self._options(cnf))
_tkinter.TclError: expected integer but got ""

I have no idea what to do here.

----------
components: IDLE
messages: 262670
nosy: wysaard
priority: normal
severity: normal
status: open
title: Tkinter error when opening IDLE configuration menu
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 30 19:51:15 2016
From: report at bugs.python.org (Eitaro Kuwabara)
Date: Wed, 30 Mar 2016 23:51:15 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMjY2NzRdIOOAkHR5cG/jgJEg?=
 =?utf-8?q?Japanese_Documentation?=
Message-ID: <1459381875.82.0.77228452533.issue26674@psf.upfronthosting.co.za>


New submission from Eitaro Kuwabara:

I found a tiny typo in Japanese Documentation(Python3.5.1)

http://docs.python.jp/3/library/pathlib.html#general-properties

???????????????????????????????????????????????????????????Path ?????????????????Path ?????????????????????? ???? ??????????????
?????????

----------
messages: 262681
nosy: Eitaro Kuwabara
priority: normal
severity: normal
status: open
title: ?typo? Japanese Documentation
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar 30 22:49:57 2016
From: report at bugs.python.org (Swaprava Nath)
Date: Thu, 31 Mar 2016 02:49:57 +0000
Subject: [New-bugs-announce] [issue26675] Appending to a large list flushes
 old entries
Message-ID: <1459392597.63.0.301580588543.issue26675@psf.upfronthosting.co.za>


New submission from Swaprava Nath:

I'm storing several variables in a list after a computation in a for loop. I'm bundling the variables in a tuple and appending this tuple to a list. So, the structure should be:

iter 1: list = [tuple1]
iter 2: list = [tuple1, tuple2]
iter 3: list = [tuple1, tuple2, tuple3] etc.

and the tuple has dissimilar objects. Surprisingly, I see that the list grows until a point and then suddenly all old entries are flushed out and new tuple_n is the only entry

iter n: list = [tuple_n]

Is this a bug? Or is there a cap on the size of the list?

----------
files: knapsack.py
messages: 262683
nosy: Swaprava Nath
priority: normal
severity: normal
status: open
title: Appending to a large list flushes old entries
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42330/knapsack.py

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

From report at bugs.python.org  Thu Mar 31 03:14:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 31 Mar 2016 07:14:53 +0000
Subject: [New-bugs-announce] [issue26676] Add missing XMLPullParser to
 ElementTree.__all__
Message-ID: <1459408493.0.0.169001428442.issue26676@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium at yahoo.com.au>:


----------
components: XML
files: elementtree-all.patch
keywords: patch
nosy: martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Add missing XMLPullParser to ElementTree.__all__
versions: Python 3.6
Added file: http://bugs.python.org/file42332/elementtree-all.patch

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

From report at bugs.python.org  Thu Mar 31 11:49:21 2016
From: report at bugs.python.org (Florian Dold)
Date: Thu, 31 Mar 2016 15:49:21 +0000
Subject: [New-bugs-announce] [issue26677] pyvenv: activate.fish breaks $PATH
 for bash scripts
Message-ID: <1459439361.75.0.379052301641.issue26677@psf.upfronthosting.co.za>


New submission from Florian Dold:

When sourcing the activate script from bash, $PATH is restored from 
$_OLD_VIRTUAL_PATH.  If bash was invoked from fish (e.g. when running a shell script), and a virtualenv was activated from fish via activate.fish, the 
$_OLD_VIRTUAL_PATH will contain path separated by the ascii record separator char (chr(30)), since this is how the fish shell stores arrays.

But the activate script for bash will then set $PATH to $_OLD_VIRTUAL_PATH, which breaks most bash scripts.

Instead the activate scripts should differentiate between

$_OLD_BASH_VIRTUAL_PATH
and
$_OLD_FISH_VIRTUAL_PATH

or the activate.fish should take care to replace chr(30) with colons before it sets $_OLD_VIRTUAL_PATH.


bash$ pyvenv my-venv
bash$ fish
fish$ . my-venv/bin/activate.fish
fish$ bash
bash$ . my-venv/bin/activate
# $PATH is now broken, since it contains record separators instead of colons to separate paths

----------
components: Library (Lib)
messages: 262696
nosy: Florian.Dold
priority: normal
severity: normal
status: open
title: pyvenv: activate.fish breaks $PATH for bash scripts
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 31 13:36:39 2016
From: report at bugs.python.org (Andy Maier)
Date: Thu, 31 Mar 2016 17:36:39 +0000
Subject: [New-bugs-announce] [issue26678] Incorrect linking to elements in
 datetime package
Message-ID: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za>


New submission from Andy Maier:

Hi, I did search for these in the open bugs, but did not find any matching bug.

I have a project that revealed that some of its InterSphinx links to existing classes/types or methods to not resolve their targets, or to resolve to a target that is not the right one (IMO).

This issue here describes everything I found in the datetime package.

Line numbers in this issue apply to the datetime.rst file as of commit 96a98bcaac70 (https://hg.python.org/cpython/file/96a98bcaac70/Doc/library/datetime.rst).

* class datetime.tzinfo:

  An intersphinx link to it gets resolved but targets the short description of the class in the intro (line 106 of datetime.rst), and I did not find a way to target the full description (line 1552), which is really what this should be resolved to (IMO).

  I suspect that this has to do with the fact that this class has only one anchor on its short description on line 106, while companion classes such as datetime.datetime have two anchors (lines 91 and 681) where the last one wins (and happens to be the long description). However, see the next item.

* class datetime.timezone:

  Same issue as for class datetime.tzinfo; links get resolved but land on the short intro. However, this time there are two anchors (lines 113 and 1795). So maybe my suspicion above is rather speculation...

* method datetime.tzinfo.utcoffset:

  An intersphinx link to it does not get resolved. On line 1579 in datetime.rst, there is a `.. method:: tzinfo.utcoffset(dt)` but at least these intersphinx links did not get resolved:

      :func:`py:tzinfo.utcoffset`
      :func:`py:datetime.tzinfo.utcoffset`

  Do method anchors need the anchor for their defining class close by to work? Which because if the first issue above, would be the short version of it, way above. (Again speculation)

* Same for method datetime.tzinfo.dst

----------
assignee: docs at python
components: Documentation
messages: 262698
nosy: andymaier, docs at python
priority: normal
severity: normal
status: open
title: Incorrect linking to elements in datetime package
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Mar 31 15:33:42 2016
From: report at bugs.python.org (Robert Bachmann)
Date: Thu, 31 Mar 2016 19:33:42 +0000
Subject: [New-bugs-announce] [issue26679] curses: Descripton of KEY_NPAGE
 and KEY_PPAGE inverted
Message-ID: <1459452822.7.0.402599297468.issue26679@psf.upfronthosting.co.za>


New submission from Robert Bachmann:

The table on <https://docs.python.org/3/library/curses.html>
lists:
__________________________
Page Up 	KEY_NPAGE
Page Down 	KEY_PPAGE
__________________________

it should be vice versa.

----------
assignee: docs at python
components: Documentation
files: curses.patch
keywords: patch
messages: 262701
nosy: Robert Bachmann, docs at python
priority: normal
severity: normal
status: open
title: curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42334/curses.patch

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

From report at bugs.python.org  Thu Mar 31 15:34:24 2016
From: report at bugs.python.org (Robert Smallshire)
Date: Thu, 31 Mar 2016 19:34:24 +0000
Subject: [New-bugs-announce] [issue26680] Incorporating float.is_integer
 into the numeric tower and Decimal
Message-ID: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za>


New submission from Robert Smallshire:

When the useful float.is_integer method was added the opportunity was missed to incorporate this method into the numeric tower defined in numbers.py. This increased the API distance between different number types, making them less substitutable than previously, leading to what might be considered to be absurd behaviour:

  >>> a = 5.0
  >>> b = 5
  >>> a.is_integer()
  True
  >>> b.is_integer()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  AttributeError: 'int' object has no attribute 'is_integer'

The first attached patch modifies Python to:

 1) Implement int.is_integer() to always return True
 2) Add Real.is_integer() as an abstract method in numbers.py
 3) Provide a default implementation in Rational.is_integer() in numbers.py
 4) Adds tests for is_integer() for int and Fraction.
 5) Documentation changes commensurate with above.

Although the Decimal type deliberately lies outside the numeric tower for reasons not relevant here, the principle of least surprise suggests that it too should support is_integer().  In fact, the implementation already contains just such a function, although it is not exposed to Python.  The second patch implements is_integer() for both the pure Python and C implementations of Decimal, again with commensurate tests and documentation changes.

I hope these changes can be implemented to reduce the degree of surprise encountered when working with different number types in Python.

----------
components: Library (Lib)
files: is_integer_numeric_tower.patch
keywords: patch
messages: 262702
nosy: Robert Smallshire2
priority: normal
severity: normal
status: open
title: Incorporating float.is_integer into the numeric tower and Decimal
type: enhancement
Added file: http://bugs.python.org/file42335/is_integer_numeric_tower.patch

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

From report at bugs.python.org  Thu Mar 31 19:21:14 2016
From: report at bugs.python.org (Matthias welp)
Date: Thu, 31 Mar 2016 23:21:14 +0000
Subject: [New-bugs-announce] [issue26681] decorators for attributes
Message-ID: <1459466474.52.0.905793421704.issue26681@psf.upfronthosting.co.za>


New submission from Matthias welp:

This is a suggestion, and not final. 

The current ways to define the getter and setter methods for an attribute are 
these two: 

    @property
    def name():
        """ Docstring """
        pass
    
    @name.setter
    def name(value):
        pass
    
    @name.deleter
    def name(value):
        pass

and

    name = property(getter, setter, deleter, docstring)

Of the two ways you can create a property, only the second one allows you to 
use your method definition multiple times, as seen here:

    value = property(getter, setter, deleter)
    value_2 = property(getter, setter, deleter)

but this has the drawback that it can only use defined method. You can go 
around by defining a wrapper method, but even then you will have to put the 
value of your attribute inside the parenthesis of your behaviour definition, 
or put another assignation statement into your file. To prevent this, I propose 
the addition of decorators to attributes, which would behave like the 
decorators on functions:

    class Decorator(object):
        def __init__(self, ref):
            self.val = ref
    
        def __get__(self):
            return self.val
            
        def __set__(self, val):
            self.val = val
    
        def __del__(self):
            del self.val
    
    @Decorator
    val = value
    
    @Decorator
    val_2 = value_2

This should behave just like decorators on functions, but then with the 
functionality of attributes. In the proposed __init__ method ref would be the 
attribute after the evaluation of its declaration, similar to function 
decorators.

The main benefit of this would be that the definition of attributes that behave 
in a similar way (get-, set- and delete-behaviour is the same) you only have to 
define one decorator for multiple attributes and you can change the behaviour 
of your attributes in a more intuitive way. 

The current alternatives are these:

    class Decorator(object):
        def __init__(self, ref):
            self.val = ref
    
        def __get__(self):
            return self.val
            
        def __set__(self, val):
            self.val = val

        def __del__(self):
            del self.val

    @Decorator
    def val():
        pass
    
    @Decorator
    def val_2():
        pass

and

    def decorate(value):
        _value = value
        def get():
            return _value
        def set(value):
            _value = value
        def del():
            del _value
        return property(get, set, del)

    @decorate
    def val():
        pass
    
    val_2 = decorate(1)
    
    val_3 = decorate()
    val_3 = 20

I think it is weird that to create an attribute that is decorated, I need to 
create a function, or need to explicitely call the decorator. This is why the 
decorators were added for functions, I think it might as well be added for 
attributes.

----------
components: Interpreter Core
messages: 262710
nosy: Matthias welp
priority: normal
severity: normal
status: open
title: decorators for attributes
type: enhancement

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

From report at bugs.python.org  Thu Mar 31 20:28:21 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Apr 2016 00:28:21 +0000
Subject: [New-bugs-announce] [issue26682] Ttk Notebook tabs do not show with
 1-2 char names
Message-ID: <1459470501.64.0.00235900367072.issue26682@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

>From https://stackoverflow.com/questions/36336010/cannot-see-all-tabs-in-ttk-notebook

import tkinter as tk
from tkinter.ttk import Frame, Notebook

root = tk.Tk()
nb = Notebook(root, width=320, height=240)
nb.pack(fill='both', expand=1)
page0 = Frame(nb)
page1 = Frame(nb)
page2 = Frame(nb)
page3 = Frame(nb)
page4 = Frame(nb)
nb.add(page0, text="0")
nb.add(page1, text="1")
nb.add(page2, text="2")
nb.add(page3, text="3")
nb.add(page4, text="4")

Only tabs 0 and 1 show.  Add a space before or after the number and 2 & 3 show.  Add 6 spaces after 4 and '4 ' shows.  Appears to work OK with 3 chars, with first and third non-blank.

I presume this is a ttk bug.  http://www.tcl.tk/man/tcl8.6/TkCmd/ttk_notebook.htm#M14 just says 'a string'.  I plan to close this as 3rd party in a few days, but I wanted to document the defacto spec here on the tracker.

----------
components: Tkinter
messages: 262712
nosy: serhiy.storchaka, terry.reedy, wordtech
priority: normal
severity: normal
status: open
title: Ttk Notebook tabs do not show with 1-2 char names
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar 31 21:31:32 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Apr 2016 01:31:32 +0000
Subject: [New-bugs-announce] [issue26683] Questionable terminology for
 describing what locals() does
Message-ID: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The docs for locals() say that inside a function that local variables and free variables are included:  https://docs.python.org/3/library/functions.html#locals

Elsewhere we use the terms "cell variables" or "nonlocals".   Mathematically, the word "free" means unbound, so that isn't applicable here and isn't the usual way of describing variables in the enclosing scope.

>>> def f(x):
        def g(y):
            z = x + y
            print(locals())
        return g

>>> f(10)(20)
{'x': 10, 'y': 20, 'z': 30}

Also, I'm not sure why "x" and "y" are included in the definition for locals().  That seems strange given that "x" and "y" are not local to "g" and that "x += 1" would fail with an UnboundLocalError.

----------
assignee: docs at python
components: Documentation
messages: 262713
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Questionable terminology for describing what locals() does
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Mar 31 23:04:49 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 01 Apr 2016 03:04:49 +0000
Subject: [New-bugs-announce] [issue26684] pathlib.Path.with_name() and
 .with_suffix do not allow combining with an empty Path
Message-ID: <1459479889.57.0.867705716846.issue26684@psf.upfronthosting.co.za>


New submission from Ethan Furman:

The methods .with_name() and .with_suffix() of pathlib.Path (and friends) do not allow a name or suffix to be added to a path alone -- I get ValueError(... has an empty name...).

This is the documented behavior, but it seems incredibly user-unfriendly.

----------
messages: 262717
nosy: ethan.furman, pitrou
priority: normal
severity: normal
status: open
title: pathlib.Path.with_name() and .with_suffix do not allow combining with an empty Path
type: behavior
versions: Python 3.5, Python 3.6

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