From report at bugs.python.org  Fri Jan  1 02:45:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Jan 2016 07:45:03 +0000
Subject: [New-bugs-announce] [issue25985] Use sys.version_info instead of
 sys.version
Message-ID: <1451634303.31.0.471991642776.issue25985@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch replaces all occurrences of sys.version[:3] with '%d.%d' % sys.version_info[:2]. The former doesn't work with non-one-digit versions (such as 3.10 and 10.1).

----------
components: Distutils, Library (Lib)
files: use_version_info.patch
keywords: patch
messages: 257279
nosy: dstufft, eric.araujo, lemburg, serhiy.storchaka, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Use sys.version_info instead of sys.version
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file41463/use_version_info.patch

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

From report at bugs.python.org  Fri Jan  1 15:48:20 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Jan 2016 20:48:20 +0000
Subject: [New-bugs-announce] [issue25986] Collections.deque maxlen: added in
 2.6 or 2.7?
Message-ID: <1451681300.68.0.792062287695.issue25986@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://docs.python.org/2.6/library/collections.html#collections.deque has this line "Changed in version 2.6: Added maxlen parameter."

https://docs.python.org/2.7/library/collections.html#collections.deque kept the sentence above and added this entry after the list of methods.

Deque objects also provide one read-only attribute:
maxlen
    Maximum size of a deque or None if unbounded.
    New in version 2.7.

Which is it?

----------
messages: 257299
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Collections.deque maxlen: added in 2.6 or 2.7?
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  1 17:00:33 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Fri, 01 Jan 2016 22:00:33 +0000
Subject: [New-bugs-announce] [issue25987] collections.abc.Reversible
Message-ID: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

This came up as a side issue in the -ideas discussion on deprecating the old-style sequence protocol that came out of Guido's suggestion on https://github.com/ambv/typehinting/issues/170 (http://article.gmane.org/gmane.comp.python.ideas/37599):

> I also think it's fine to introduce Reversible as another ABC and carefully fit it into the existing hierarchy. It should be a one-trick pony and be another base class for Sequence; it should not have a default implementation. (But this has been beaten to death in other threads -- it's time to just file an issue with a patch.)

I'll file a patch this weekend. But in case there's anything to bikeshed, here are the details:

* Reversible is a subclass of Iterable.
 * It has a single abstract method, __reversed__, with no default implementation.
 * Its subclass hook that checks for __reversed__ existing and not being None.
* Sequence is a subclass of Reversible, Sized, and Container rather than directly of Iterable, Sized, and Container.

Builtins tuple and list, and any subclasses of them, will be Reversible because they register with Sequence or MutableSequence. Subclasses of collections.abc.Sequence will be Reversible (and should be, as they inherit Sequence.__reversed__). Custom old-style sequences will not be Reversible, even though reversed works on them.

Builtins dict, set, and frozenset, and any subclasses of them, will not be Reversible (unless they add a __reversed__ method, as OrderedDict does). Subclasses of collections.abc.Mapping will not be Reversible (and should not be, as, assuming #25864 goes through, they inherit Mapping.__reversed__=None) (unless they add a __reversed__ method, as most third-party sorted-dict types do).

I'll include tests for all of those things.

I believe this is all exactly parallel with collections.abc.Iterable, and will make collections.abc.Reversible compatible with typing.Reversible[...] in exactly the same way collections.abc.Iterable is compatible with typing.Iterable[...].

Alternatives: We could make Reversible independent of Iterable. Alternatively, we could make it subclass both Iterable and Sized instead of just Iterable. But I think this is the simplest place to slot it in.

----------
components: Library (Lib)
messages: 257310
nosy: abarnert
priority: normal
severity: normal
status: open
title: collections.abc.Reversible
type: enhancement

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

From report at bugs.python.org  Fri Jan  1 17:18:59 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Fri, 01 Jan 2016 22:18:59 +0000
Subject: [New-bugs-announce] [issue25988] collections.abc.Indexable
Message-ID: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

In an -ideas thread, Guido suggested (http://article.gmane.org/gmane.comp.python.ideas/37599):

> If we want some way to turn something that just defines __getitem__ and __len__ into a proper sequence, it should just be made to inherit from Sequence, which supplies the default __iter__ and __reversed__. (Registration is *not* good enough here.) If we really want a way to turn something that just supports __getitem__ into an Iterable maybe we can provide an additional ABC for that purpose; let's call it a HalfSequence until we've come up with a better name. (We can't use Iterable for this because Iterable should not reference __getitem__.)

Later in the thread, Nick Coghlan suggested (http://article.gmane.org/gmane.comp.python.ideas/37614):

> Perhaps collections.abc.Indexable would work? Invariant:

>     for idx, val in enumerate(container):
>         assert container[idx] is val

> That is, while enumerate() accepts any iterable, Indexable containers
have the additional property that the contained values can be looked
up by their enumeration index. Mappings (even ordered ones) don't
qualify, since they offer a key:value lookup, but enumerating them
produces an index:key relationship.

So, in particular:

* Indexable is a subclass of Iterable.
* Sequence is a subclass of Indexable, Sized, and Container instead of Iterable, Sized, and Container. (Or, if #25987 also goes through, of Reversible, Indexable, Sized, and Container.)
* The abstract method __getitem__ and the concrete __iter__ implementation get moved up from Sequence to Indexable.
* Indexable does _not_ have a subclass hook (to avoid making every Mapping, generic type, etc. accidentally Indexable).

This means that you can write this (borrowing an example from Steven D'Aprano in http://article.gmane.org/gmane.comp.python.ideas/23369/):

    class Squares(collections.abc.Indexable):
        def __getitem__(self, index):
            return index**2

Because this no longer depends on the old-style sequence protocol, testing it with ABCs will work as expected.

For related issues, see #25987, #25864, #25958, and https://github.com/ambv/typehinting/issues/170

----------
components: Library (Lib)
messages: 257311
nosy: abarnert
priority: normal
severity: normal
status: open
title: collections.abc.Indexable
type: enhancement

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

From report at bugs.python.org  Fri Jan  1 18:46:57 2016
From: report at bugs.python.org (Vincent Davis)
Date: Fri, 01 Jan 2016 23:46:57 +0000
Subject: [New-bugs-announce] [issue25989] documentation version switcher is
 broken fro 2.6, 3.2, 3.3
Message-ID: <1451692017.71.0.123733949867.issue25989@psf.upfronthosting.co.za>


New submission from Vincent Davis:

>From the documentation pages for python 2.7 and 3.4, 3.5, 3.6 it is possible to select another python version in the breadcrumb at the top left of the page. This is not available for python 2.6, 3.2 and  3.3.

See related issue which is closed.
https://bugs.python.org/issue25113

I posted this on pythondotorg but I guess this is a cpython issue not a website issue. https://github.com/python/pythondotorg/issues/868

Berker Peksag response to the report
"The version switcher is activated via a versionswitcher option in Doc/Makefile in CPython codebase. Docs are generated daily by using that Makefile, but 2.6, 3.2 and 3.3 are in security-fix-only mode (which means they won't even get documentation fixes) so the daily build script skips generating docs for those versions."

----------
assignee: docs at python
components: Documentation
messages: 257317
nosy: Vincentdavis, docs at python
priority: normal
severity: normal
status: open
title: documentation version switcher is broken fro 2.6, 3.2, 3.3
type: behavior

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

From report at bugs.python.org  Fri Jan  1 21:15:52 2016
From: report at bugs.python.org (Steve Litt)
Date: Sat, 02 Jan 2016 02:15:52 +0000
Subject: [New-bugs-announce] [issue25990] Pydoc fails on Python file with
 nonlocal
Message-ID: <1451700952.99.0.532162073876.issue25990@psf.upfronthosting.co.za>


New submission from Steve Litt:

Latest pydoc on Void linux 64 bit, I have no idea how to capture the version. Source file can be either Python 3.4 or 2.7, same result.

ERROR MESSAGE:

[slitt at mydesk ~]$ pydoc pydoc_fail
problem in ./pydoc_fail.py - <type 'exceptions.SyntaxError'>: invalid syntax (pydoc_fail.py, line 6)

[slitt at mydesk ~]$

----------
files: pydoc_fail.py
hgrepos: 328
messages: 257321
nosy: stevelitt
priority: normal
severity: normal
status: open
title: Pydoc fails on Python file with nonlocal
type: crash
Added file: http://bugs.python.org/file41468/pydoc_fail.py

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

From report at bugs.python.org  Fri Jan  1 23:28:53 2016
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sat, 02 Jan 2016 04:28:53 +0000
Subject: [New-bugs-announce] [issue25991] readline example eventually
 consumes all memory
Message-ID: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen:

The Example in the readline documentation (section 6.7 of the Library Reference) shows how to save your readline history in a file, and restore it each time you start Python.

The problem with the Example is that it does not include a call to readline.set_history_length and the default is -1 (infinite).

As a Python developer, I start Python quite a lot and had a .python_history file that was 850M bytes.  Just starting Python was causing my system to thrash before the first prompt (>>>) even appeared.

I suggest adding the following line to the example to avoid this:

readline.set_history_length(1000)

I'm not sure how far back this goes in terms of earlier versions of Python, but probably quite far.

----------
assignee: docs at python
components: Documentation
messages: 257325
nosy: dangyogi, docs at python
priority: normal
severity: normal
status: open
title: readline example eventually consumes all memory
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan  2 00:50:06 2016
From: report at bugs.python.org (Bryce Miller)
Date: Sat, 02 Jan 2016 05:50:06 +0000
Subject: [New-bugs-announce] [issue25992] test_gdb fails
Message-ID: <1451713806.34.0.803842118103.issue25992@psf.upfronthosting.co.za>


New submission from Bryce Miller:

test_gdb fails for me on OSX

Steps I did to duplicate: 
Checked out fresh '2.7' branch from https://github.com/python/cpython.git
>From the new cypthon dir ran: 
./configure
make
make test
./Lib/test/regrtest.py -v test_gdb

Attached the full verbose output. 

I am looking at Issue23137 and the output messages look different than mine, so I'm posting this as a separate issue. Perhaps it is duplicate. 

34 tracebacks included in attachment, but below is a sample for reference: 

======================================================================
FAIL: test_NULL_instance_dict (test.test_gdb.PrettyPrintTests)
Ensure that a PyInstanceObject with with a NULL in_dict is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_gdb.py", line 521, in test_NULL_instance_dict
    exptype='Foo')
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_gdb.py", line 459, in assertSane
    cmds_after_breakpoint=cmds_after_breakpoint)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_gdb.py", line 239, in get_gdb_repr
    import_site=import_site)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_gdb.py", line 224, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ['Unable to find Mach task por... != []

First list contains 4 additional elements.
First extra element 0:
Unable to find Mach task port for process-id 53220: (os/kern) failure (0x5).

----------
components: Tests
files: regrtest_test_gdb.log
hgrepos: 329
messages: 257326
nosy: Bryce Miller
priority: normal
severity: normal
status: open
title: test_gdb fails
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41471/regrtest_test_gdb.log

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

From report at bugs.python.org  Sat Jan  2 03:49:38 2016
From: report at bugs.python.org (Xiongzhi Gao)
Date: Sat, 02 Jan 2016 08:49:38 +0000
Subject: [New-bugs-announce] [issue25993] Crashed when call time.time()
 after using _mm_xor_si64
Message-ID: <1451724578.62.0.704000687465.issue25993@psf.upfronthosting.co.za>


New submission from Xiongzhi Gao:

The version of windows is Windows 7 Service Pack 1.
The version of Python is 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32.
The version of compiler in visual studio 10 is 16.00.40219.01 for 80x86.

I try to use SWIG to port a function that use _mm_xor_si64 like this:

packed_sse.i

> %module packed_sse
> %{
> extern long long _packed_mm_xor_si64(long long m1, long long m2);
> %}
> extern long long _packed_mm_xor_si64(long long m1, long long m2);

packed_sse.c

> #include <mmintrin.h>
> 
> __inline __m64 int64_to_m64 (const long long i) {
>     union {
>         long long i;
>         __m64 v;
>     } u;
>     u.i = i;
>     return u.v;
> }
> 
> __inline long long m64_to_int64 (const __m64 v) {
>     union {
>         long long i;
>         __m64 v;
>     } u;
>     u.v = v;
>     return u.i;
> }
> 
> long long _packed_mm_xor_si64(long long m1, long long m2) {
>     __m64 m64_m1 = int64_to_m64(m1), m64_m2 = int64_to_m64(m2);
>     __m64 m64_result = _mm_xor_si64(m64_m1, m64_m2);
>     return m64_to_int64(m64_result);

I use swig and compiler to port C to Python.
    
I try to test like this, it works:

test_swig.py

> # -*- coding: utf-8 -*-
> # !/bin/env python2
> 
> import random
> 
> import packed_sse
> 
> 
> if __name__ == "__main__":
>     for i in range(100000):
>         a, b = random.getrandbits(20), random.getrandbits(20)
>         _ = packed_sse._packed_mm_xor_si64(
>             a, b
>         )
>         assert a ^ b == _        

But when I try to profile the function like this, the output of first `print time.time() - _beg` is `nan` and Python crashed when run into second `print time.time() - _beg`:
    
profile_swig.py

> # -*- coding: utf-8 -*-
> # !/bin/env python2
> 
> import random
> import time
> 
> import packed_sse
> 
> 
> if __name__ == "__main__":
>     _beg = time.time()
>     for i in range(100000):
>         _ = packed_sse._packed_mm_xor_si64(
>             random.getrandbits(20), random.getrandbits(20)
>         )
>     print time.time() - _beg  # First
>     _beg = time.time()
>     for i in range(100000):
>         _ = random.getrandbits(20) ^ random.getrandbits(20)
>     print time.time() - _beg  # Second

I try to use `gdb` on MingGW to debug it, it said:
    
> (gdb) stop
> (gdb) c
> Continuing.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 7172.0xadc]
> 0x534fbe6c in python27!_Py_dg_dtoa () from C:\Windows\system32\python27.dll

----------
components: Windows
messages: 257337
nosy: Xiongzhi Gao, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Crashed when call time.time() after using _mm_xor_si64
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan  2 12:48:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Jan 2016 17:48:16 +0000
Subject: [New-bugs-announce] [issue25994] File descriptor leaks in
 os.scandir()
Message-ID: <1451756896.24.0.122789607597.issue25994@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

os.scandir() opens a file descriptor and closes it only in its destructor. This can causes file descriptor leaks in Python implementations without reference counting and if the scandir iterator becomes a part of reference loop or long living object. Since the number of open file descriptors is limited, this can leads to problems.

We need to add the close() method to the scandir iterator (as in files and generators). It would be useful also to make it a context manager.

In 3.5 we have to add a warning about this behavior.

----------
components: Extension Modules
messages: 257351
nosy: benhoyt, haypo, serhiy.storchaka
priority: high
severity: normal
status: open
title: File descriptor leaks in os.scandir()
type: resource usage
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jan  2 12:57:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Jan 2016 17:57:05 +0000
Subject: [New-bugs-announce] [issue25995] os.walk() consumes a lot of file
 descriptors
Message-ID: <1451757425.39.0.0524932176307.issue25995@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since 3.5 os.walk() consumes a lot of file descriptors. Its number equals to the deep of directories tree. Since the number of file descriptors is limited, this can cause problems.

This was the main reason for rejecting fwalk-based implementation of os.walk() (issue15200).

----------
components: Library (Lib)
messages: 257352
nosy: benhoyt, haypo, larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: os.walk() consumes a lot of file descriptors
type: resource usage
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jan  2 13:10:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Jan 2016 18:10:38 +0000
Subject: [New-bugs-announce] [issue25996] Add support of file descriptor in
 os.scandir()
Message-ID: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now os.scandir() on Unix is implemented using opendir()/readdir()/closedir(). It accepts bytes and str pathname. But most functions in the os module that accept a pathname, accept also an open file descriptor. It is possible to implement this feature in scandir() with using fdopendir() instead of opendir(). This would allow to add a support of the dir_fd parameter in scandir(). And that would allow to implement os.fwalk() with scandir() and make more efficient implementation of os.walk() (because we no longer need to walk long path for deep directories, see issue15200).

----------
components: Extension Modules
messages: 257353
nosy: benhoyt, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add support of file descriptor in os.scandir()
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Jan  2 14:53:25 2016
From: report at bugs.python.org (Patrik Dufresne)
Date: Sat, 02 Jan 2016 19:53:25 +0000
Subject: [New-bugs-announce] [issue25997] Tarfile.add with bytes path is
 failling
Message-ID: <1451764405.28.0.333419880033.issue25997@psf.upfronthosting.co.za>


New submission from Patrik Dufresne:

With python 3.4, Tarfile doesn't properly support adding a files with bytes path. Only unicode is supported. It's failing with exception similar to:

    tar.add(os.path.join(dirpath, filename), filename)
  File "/usr/lib/python3.4/tarfile.py", line 1907, in add
    tarinfo = self.gettarinfo(name, arcname)
  File "/usr/lib/python3.4/tarfile.py", line 1767, in gettarinfo
    arcname = arcname.replace(os.sep, "/")
TypeError: expected bytes, bytearray or buffer compatible object

It uses os.sep, and u"/". Instead, it should use something like posixpath.py:_get_sep(path).

----------
components: Unicode
messages: 257355
nosy: Patrik Dufresne, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Tarfile.add with bytes path is failling
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan  2 17:30:43 2016
From: report at bugs.python.org (Lasse Schuirmann)
Date: Sat, 02 Jan 2016 22:30:43 +0000
Subject: [New-bugs-announce] [issue25998] doctest crashes when accessing
 __wrapped__ fails other than AttributeError
Message-ID: <1451773843.64.0.986014558431.issue25998@psf.upfronthosting.co.za>


New submission from Lasse Schuirmann:

You can see this when importing the Flask `request` object in a file that is doctested. The `request` object will throw a RuntimeError when one tries to access any attribute. Doctest tries to `inspect.unwrap` all objects in the file in order to find out if they're doctestable functions - and apparently only catches the `AttributeError` exception. Thus it crashes :)

----------
components: Tests
files: shell
messages: 257378
nosy: Lasse Schuirmann
priority: normal
severity: normal
status: open
title: doctest crashes when accessing __wrapped__ fails other than AttributeError
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file41477/shell

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

From report at bugs.python.org  Sun Jan  3 06:45:05 2016
From: report at bugs.python.org (SonokoMizuki)
Date: Sun, 03 Jan 2016 11:45:05 +0000
Subject: [New-bugs-announce] [issue25999] Add support of native number in
 bin()
Message-ID: <1451821505.72.0.958245773106.issue25999@psf.upfronthosting.co.za>


New submission from SonokoMizuki:

Add support of negative number in bin().
Currently, bin(-5) returns '-0b101', It is not intuitive.
I think bin() should return two's complement.

I suggest new bin().
New second argument is bit size.
if first argument is negative number and bit size is given, bin() will return two's complement.

example)
>>> bin(12)
'0b1100'
>>> bin(-12)
'-0b1100'
>>> bin(-12,8)
'0b11110100'
>>> bin(-12,3) # if not enough bit size, bin will return value as usual.
'-0b100'

----------
components: Argument Clinic
messages: 257408
nosy: larry, mizuki
priority: normal
severity: normal
status: open
title: Add support of native number in bin()
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/issue25999>
_______________________________________

From report at bugs.python.org  Sun Jan  3 08:50:57 2016
From: report at bugs.python.org (William Bowling)
Date: Sun, 03 Jan 2016 13:50:57 +0000
Subject: [New-bugs-announce] [issue26000] Crash in Tokenizer -
 Heap-use-after-free
Message-ID: <1451829057.23.0.675213101615.issue26000@psf.upfronthosting.co.za>


New submission from William Bowling:

Similar to https://bugs.python.org/issue25388 the following causes a crash on 3.5.1 and the latest 3.5 branch:

./python -c 'with open("vuln.py", "wb") as f: f.write(b"\x61\x73\x00\x0a\x79\x6e\x63\x5c\x0a\xef")'
./python vuln.py


Python 3.5.1+ (default, Jan  4 2016, 00:05:40) 
=================================================================
==24400==ERROR: AddressSanitizer: heap-use-after-free on address 0xf270f100 at pc 0x080ad09e bp 0xffef5ee8 sp 0xffef5ac0
READ of size 2 at 0xf270f100 thread T0
    #0 0x80ad09d in strncpy (/home/will/python/cpython/python+0x80ad09d)
    #1 0x8589b56 in parsetok /home/will/python/cpython/Parser/parsetok.c:235:13
    #2 0x858b301 in PyParser_ParseFileObject /home/will/python/cpython/Parser/parsetok.c:134:12
    #3 0x8439e0b in PyParser_ASTFromFileObject /home/will/python/cpython/Python/pythonrun.c:1150:15
    #4 0x843aa37 in PyRun_FileExFlags /home/will/python/cpython/Python/pythonrun.c:916:11
    #5 0x8438a98 in PyRun_SimpleFileExFlags /home/will/python/cpython/Python/pythonrun.c:396:13
    #6 0x84382a6 in PyRun_AnyFileExFlags /home/will/python/cpython/Python/pythonrun.c:80:16
    #7 0x813f194 in run_file /home/will/python/cpython/Modules/main.c:318:11
    #8 0x813f194 in Py_Main /home/will/python/cpython/Modules/main.c:768
    #9 0x8138070 in main /home/will/python/cpython/./Programs/python.c:69:11
    #10 0xf7558496 in __libc_start_main (/usr/lib32/libc.so.6+0x18496)
    #11 0x80715b7 in _start (/home/will/python/cpython/python+0x80715b7)

0xf270f100 is located 0 bytes inside of 8194-byte region [0xf270f100,0xf2711102)
freed by thread T0 here:
    #0 0x810c2a4 in __interceptor_cfree.localalias.1 (/home/will/python/cpython/python+0x810c2a4)
    #1 0x8139560 in _PyMem_RawFree /home/will/python/cpython/Objects/obmalloc.c:90:5
    #2 0x813852b in PyMem_Free /home/will/python/cpython/Objects/obmalloc.c:349:5
    #3 0x8596b05 in error_ret /home/will/python/cpython/Parser/tokenizer.c:198:9
    #4 0x8596b05 in decoding_fgets /home/will/python/cpython/Parser/tokenizer.c:636
    #5 0x8594df0 in tok_nextc /home/will/python/cpython/Parser/tokenizer.c:1016:21
    #6 0x858ebba in tok_get /home/will/python/cpython/Parser/tokenizer.c:1457:13
    #7 0x858fc79 in tok_get /home/will/python/cpython/Parser/tokenizer.c:1524:34
    #8 0x858e1da in PyTokenizer_Get /home/will/python/cpython/Parser/tokenizer.c:1804:18
    #9 0x85899a7 in parsetok /home/will/python/cpython/Parser/parsetok.c:208:16
    #10 0x858b301 in PyParser_ParseFileObject /home/will/python/cpython/Parser/parsetok.c:134:12
    #11 0x8439e0b in PyParser_ASTFromFileObject /home/will/python/cpython/Python/pythonrun.c:1150:15
    #12 0x843aa37 in PyRun_FileExFlags /home/will/python/cpython/Python/pythonrun.c:916:11
    #13 0x8438a98 in PyRun_SimpleFileExFlags /home/will/python/cpython/Python/pythonrun.c:396:13
    #14 0x84382a6 in PyRun_AnyFileExFlags /home/will/python/cpython/Python/pythonrun.c:80:16
    #15 0x813f194 in run_file /home/will/python/cpython/Modules/main.c:318:11
    #16 0x813f194 in Py_Main /home/will/python/cpython/Modules/main.c:768
    #17 0x8138070 in main /home/will/python/cpython/./Programs/python.c:69:11
    #18 0xf7558496 in __libc_start_main (/usr/lib32/libc.so.6+0x18496)

previously allocated by thread T0 here:
    #0 0x810c784 in realloc (/home/will/python/cpython/python+0x810c784)
    #1 0x8139541 in _PyMem_RawRealloc /home/will/python/cpython/Objects/obmalloc.c:84:12
    #2 0x8138506 in PyMem_Realloc /home/will/python/cpython/Objects/obmalloc.c:343:12
    #3 0x8594f1c in tok_nextc /home/will/python/cpython/Parser/tokenizer.c:1058:31
    #4 0x858e4c9 in tok_get /home/will/python/cpython/Parser/tokenizer.c:1354:17
    #5 0x858e1da in PyTokenizer_Get /home/will/python/cpython/Parser/tokenizer.c:1804:18
    #6 0x85899a7 in parsetok /home/will/python/cpython/Parser/parsetok.c:208:16
    #7 0x858b301 in PyParser_ParseFileObject /home/will/python/cpython/Parser/parsetok.c:134:12
    #8 0x8439e0b in PyParser_ASTFromFileObject /home/will/python/cpython/Python/pythonrun.c:1150:15
    #9 0x843aa37 in PyRun_FileExFlags /home/will/python/cpython/Python/pythonrun.c:916:11
    #10 0x8438a98 in PyRun_SimpleFileExFlags /home/will/python/cpython/Python/pythonrun.c:396:13
    #11 0x84382a6 in PyRun_AnyFileExFlags /home/will/python/cpython/Python/pythonrun.c:80:16
    #12 0x813f194 in run_file /home/will/python/cpython/Modules/main.c:318:11
    #13 0x813f194 in Py_Main /home/will/python/cpython/Modules/main.c:768
    #14 0x8138070 in main /home/will/python/cpython/./Programs/python.c:69:11
    #15 0xf7558496 in __libc_start_main (/usr/lib32/libc.so.6+0x18496)

SUMMARY: AddressSanitizer: heap-use-after-free (/home/will/python/cpython/python+0x80ad09d) in strncpy
Shadow bytes around the buggy address:
  0x3e4e1dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e4e1de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e4e1df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e4e1e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e4e1e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x3e4e1e20:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x3e4e1e30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x3e4e1e40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x3e4e1e50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x3e4e1e60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x3e4e1e70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==24400==ABORTING

----------
components: Interpreter Core
messages: 257417
nosy: William Bowling
priority: normal
severity: normal
status: open
title: Crash in Tokenizer - Heap-use-after-free
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sun Jan  3 08:56:15 2016
From: report at bugs.python.org (Dimitri Papadopoulos Orfanos)
Date: Sun, 03 Jan 2016 13:56:15 +0000
Subject: [New-bugs-announce] [issue26001] Tutorial: write() does not expect
 string in binary mode
Message-ID: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za>


New submission from Dimitri Papadopoulos Orfanos:

About section "7.2.1. Methods of File Objects" of the tutorial:


1. Method read() is documented as follows:
reads some quantity of data and returns it as a string or bytes object.

Indeed read() returns a string in text mode and bytes in binary mode. For the sake of clarity, I suggest changing to:

reads some quantity of data and returns it as a string (in text mode) or bytes object (in binary mode).

This might seem long-winded but I believe it would help those moving from Python 2 to Python 3.


2. Method write() is documented as follows:

To write something other than a string, it needs to be converted to a string first

While this is correct in text mode, it is wrong in binary mode. May I suggest:

To write something other than a string (in text mode) or bytes object (in binary mode), it needs to be converted first

----------
assignee: docs at python
components: Documentation
messages: 257418
nosy: Dimitri Papadopoulos Orfanos, docs at python
priority: normal
severity: normal
status: open
title: Tutorial: write() does not expect string in binary mode
versions: Python 3.5

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

From report at bugs.python.org  Sun Jan  3 09:21:58 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Sun, 03 Jan 2016 14:21:58 +0000
Subject: [New-bugs-announce] [issue26002] make statistics.median_grouped
 more efficient
Message-ID: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za>


New submission from Upendra Kumar:

statistics.median_grouped currently uses cf=data.index(x) to find the leftmost position of x in data ( line number 445 ). Here, data.index() has linear time complexity, which may not be good for long lists.

But, here since the list 'data' is sorted beforehand, we can use binary search ( bisect_left() ) to find the leftmost occurrence of 'x' in 'data'. 

Similarly, for counting number of occurrence of 'x' in data after sorting, we can find the position of rightmost occurrence of 'x' in data[l1....len(data)], where l1 is position of leftmost occurrence of 'x' (line number 447 )

----------
components: Library (Lib)
files: median_grouped.patch
keywords: patch
messages: 257419
nosy: upendra-k14
priority: normal
severity: normal
status: open
title: make statistics.median_grouped more efficient
type: performance
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41484/median_grouped.patch

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

From report at bugs.python.org  Sun Jan  3 14:04:26 2016
From: report at bugs.python.org (tzickel)
Date: Sun, 03 Jan 2016 19:04:26 +0000
Subject: [New-bugs-announce] [issue26003] Issues with PyEval_InitThreads and
 PyGILState_Ensure
Message-ID: <1451847866.91.0.926666566382.issue26003@psf.upfronthosting.co.za>


New submission from tzickel:

A few issues regarding threads:
A. (Python 2 & 3) The documentation (https://docs.python.org/3/c-api/init.html) about initializing the GIL/Threading system does not specify that calling PyEval_InitThreads actually binds the calling thread as the main_thread in the ceval.c, meaning that the thread will be in charge till the process goes down for handling Py_AddPendingCall calls, and if it ends/dies, they won't be handled anymore.

This ceval.c's main_thread is different BTW from the one in signalmodule.c which is bound to the thread that called Py_InitializeEx.

Maybe there is sense for both main_thread to be the same one and initialized in the same time ? (even without a GIL existing)

B. (Python 3) Besides the bad documentation regarding this, python 3.4 added issue #19576 which actually hides the call for PyEval_InitThreads inside PyGILState_Ensure. Without careful care and knowledge by the programmer, this might cause for a short lived thread created in C to actually bind the ceval.c's main_thread and when the thread dies main_thread will never be changed again.

The reason this is important is beforehand, the programmer needed to think about PyEval_InitThreads now it's hidden and not even mentioned in the documentation.

C. (Python 2 & 3) In PyEval_InitThreads documentation it's written "It is not safe to call this function when it is unknown which thread (if any) currently has the global interpreter lock." Thus it should be mentioned that PyGILState_Ensure is now calling it in the documentation ?

Also I believe the reason this quote exists is because a potential race condition between thread A which might be running code in PyEval_EvalFrameEx (before PyEval_InitThreads is called, and thus is not GIL aware), and thread B which calls PyEval_InitThreads then calls PyGILState_Ensure, then running Python code, while thread A is still running python code as well. I think it should be explained more clearly in the documentation the implications (race condition).

I think there might be a way to make an PyEval_InitThreads variant which can overcome this race condition. Basically it involves using Py_AddPendingCall to a C function which calls PyEval_InitThreads, and notifies the calling command/thread when it's done. This way we can be sure that the GIL is taken by one thread, and all the others are blocked. (maybe a signal should be sent as well, in case the main_thread is blocked on an I/O operation).

D. (Python 2) If the main_thread finishes it's job, while other python threads are still alive, signal handling isn't processed anymore (Example will be added as a file).

----------
components: Interpreter Core
files: signalexample.py
messages: 257425
nosy: tzickel
priority: normal
severity: normal
status: open
title: Issues with PyEval_InitThreads and PyGILState_Ensure
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file41485/signalexample.py

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

From report at bugs.python.org  Mon Jan  4 03:45:06 2016
From: report at bugs.python.org (Debashish Maity)
Date: Mon, 04 Jan 2016 08:45:06 +0000
Subject: [New-bugs-announce] [issue26004] pip install lifetimes - throwing
 error and unable to install packages
Message-ID: <1451897106.72.0.251427221401.issue26004@psf.upfronthosting.co.za>


New submission from Debashish Maity:

Not able to install "lifetimes" package using pip script.
Need urgent help.

Followed the following links for help, but still no success
http://blog.ionelmc.ro/2014/12/21/compiling-python-extensions-on-windows/
http://stackoverflow.com/questions/26473854/python-pip-has-issues-with-path-for-ms-visual-studio-2010-express-for-64-bit-ins/26513378#26513378

----------
components: Windows
files: log.txt
messages: 257445
nosy: dudestc, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pip install lifetimes - throwing error and unable to install packages
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file41489/log.txt

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

From report at bugs.python.org  Mon Jan  4 03:54:10 2016
From: report at bugs.python.org (Richard Clifford)
Date: Mon, 04 Jan 2016 08:54:10 +0000
Subject: [New-bugs-announce] [issue26005] Denial of Service in
 SimpleHTTPServer and BaseHTTPServer
Message-ID: <1451897650.58.0.64883073344.issue26005@psf.upfronthosting.co.za>


New submission from Richard Clifford:

The issue comes when there is a malformed HTTP request not ending in a new line, it causes the server to hang, not timeout and causes a DoS.

The request that I sent to the server was as follows:
const char *headers = "GET / HTTP/1.1\r\nHost: localhost:8000\r\n";

Which should have been:
const char *headers = "GET / HTTP/1.1\r\nHost: localhost:8000\r\n\r\n";

This causes a the application to await the second set of new-line sequences and hang until they are received which prevents any further connections from being made. 

I have just tested this against the latest versions of the library and I can supply a proof of concept code if that would be useful - just let me know.

A recommended fix would be to ensure that all HTTP requests are received in full and in the correct manor prior to being parsed.

----------
components: Extension Modules
files: basehttpdos.c
messages: 257446
nosy: Richard Clifford
priority: normal
severity: normal
status: open
title: Denial of Service in SimpleHTTPServer and BaseHTTPServer
type: security
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/file41490/basehttpdos.c

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

From report at bugs.python.org  Mon Jan  4 07:06:49 2016
From: report at bugs.python.org (Artur Korobeynyk)
Date: Mon, 04 Jan 2016 12:06:49 +0000
Subject: [New-bugs-announce] [issue26006] 32 bits python ctypes creates 64
 bits process from 32 bits executable
Message-ID: <1451909209.14.0.184769502954.issue26006@psf.upfronthosting.co.za>


New submission from Artur Korobeynyk:

Hi,

I have a 32 bits python on 64 bits Windows and 32 bits executable (compiled from native C).
When I do kernel32.CreateProcessA(path_to_exe, ...) python creates a process which is 64 bit (ctypes IsWow64Process returns true).
I expect it to be 32 as well. Am I wrong or that is a bug?

I attached testprog.exe but it requires testdll.dll
The sources of testprog.c:

#include <stdio.h>
#include <windows.h>

int main()
{

        Sleep(15000);
        printf("%d", testSum(5,10));
        return 0;
}

testdll.c

#include <stdio.h>

__declspec(dllexport) int __cdecl testSum(int a, int b)
{
        return(a+b);
}

compiled as:
/usr/bin/i686-pc-mingw32-gcc.exe -c testdll.c
/usr/bin/i686-pc-mingw32-gcc.exe --shared -o testdll.dll testdll.o
/usr/bin/i686-pc-mingw32-gcc.exe -o testprog testprog.c -L. -ltestdll

Process creation:
if kernel32.CreateProcessA(path_to_exe,
                                   None,
                                   None,
                                   None,
                                   None,
                                   creation_flags,
                                   None,
                                   None,
                                   byref(startupinfo),
                                   byref(process_information))

----------
components: ctypes
files: testprog.exe
messages: 257461
nosy: Artur Korobeynyk
priority: normal
severity: normal
status: open
title: 32 bits python ctypes creates 64 bits process from 32 bits executable
versions: Python 2.7
Added file: http://bugs.python.org/file41492/testprog.exe

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

From report at bugs.python.org  Mon Jan  4 11:13:13 2016
From: report at bugs.python.org (Phil Thompson)
Date: Mon, 04 Jan 2016 16:13:13 +0000
Subject: [New-bugs-announce] [issue26007] Request for Support for Embedding
 the Standard Library in an Executable
Message-ID: <1451923993.52.0.708853061063.issue26007@psf.upfronthosting.co.za>


New submission from Phil Thompson:

The use case is a packaging tool that can create a single executable for a Python application. Like similar tools it embeds frozen Python code (including the standard library) and is linked (often statically) against the interpreter library.

Executables are usually configured so that they cannot import packages from the filesystem. They can only import packages embedded in the executable. This is done directly, ie. the package is not written out to the filesystem and imported from there. This is done by a specially written importer.

The importer is installed by adding it to sys.path_hooks. However this must be done early on in the bootstrap process so that the parts of the standard library that are implemented as Python packages can be found by the installer. For example, the point at which the zipimport importer is added to sys.path_hooks is too late.

Currently a modified version of bootstrap_external.py is embedded in the executable which updates sys.path_hooks at the end of the _install() function.

What I would like is some way to avoid having to modify bootstrap_external.py to install a new importer sufficiently early in the bootstrap process to allow it to import the standard library.

----------
components: Interpreter Core
messages: 257464
nosy: philthompson10
priority: normal
severity: normal
status: open
title: Request for Support for Embedding the Standard Library in an Executable
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Jan  4 12:18:51 2016
From: report at bugs.python.org (=?utf-8?q?Antonio_=C3=81lvarez?=)
Date: Mon, 04 Jan 2016 17:18:51 +0000
Subject: [New-bugs-announce] [issue26008] Different behaviour
 platform.linux_distribution() on Python2.7 and 3.6
Message-ID: <1451927931.59.0.302771657902.issue26008@psf.upfronthosting.co.za>


New submission from Antonio ?lvarez:

Hi! I have a doubt, is this behaviour in Python2.7.11 usual, or is it a bug?

>>> import platform
>>> platform.linux_distribution()
('', '', '')

In Python3.5.1 I get

>>> import platform
>>> platform.linux_distribution()
('arch', 'Arch', 'Linux')

I work with Archlinux x86_64 with lsb-release installed. Thanks!

----------
components: Extension Modules
messages: 257471
nosy: analca3
priority: normal
severity: normal
status: open
title: Different behaviour platform.linux_distribution() on Python2.7 and 3.6
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  4 12:35:38 2016
From: report at bugs.python.org (Jason Sachs)
Date: Mon, 04 Jan 2016 17:35:38 +0000
Subject: [New-bugs-announce] [issue26009] HTMLParser lacking a few features
 to reconstruct input exactly
Message-ID: <1451928938.48.0.712719588041.issue26009@psf.upfronthosting.co.za>


New submission from Jason Sachs:

The HTMLParser class (https://docs.python.org/2/library/htmlparser.html) is lacking a few features to reconstruct input exactly. For the most part it can do this, but I found two items where it falls short (there may be others):

- There is a get_starttag_text() method but no get_endtag_text() method, which is necessary if the end tag is not in canonical form, e.g. instead of </p> it is </P> or </   P >

- The effect of the parse_bogus_comment() internal method is to call handle_comment(), so content like <! I AM BOGUS > cannot be distinguished by subclasses of HTMLParser from actual comments <!-- I AM BOGUS -->

Suggested changes:

- Add a get_endtag_text() method to return the exact endtag text
- change parse_bogus_comment to call self.handle_bogus_comment(), and define self.handle_bogus_comment() to call self.handle_comment(). This way it is backwards-compatible with existing behavior, but subclasses can redefine self.handle_bogus_comment() to do what they want.

----------
messages: 257472
nosy: jason_s
priority: normal
severity: normal
status: open
title: HTMLParser lacking a few features to reconstruct input exactly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  4 16:43:19 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 04 Jan 2016 21:43:19 +0000
Subject: [New-bugs-announce] [issue26010] document CO_* constants
Message-ID: <1451943799.55.0.170174957696.issue26010@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
assignee: docs at python
components: Documentation
keywords: needs review
nosy: docs at python, r.david.murray, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: document CO_* constants
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jan  4 18:32:19 2016
From: report at bugs.python.org (Karl Richter)
Date: Mon, 04 Jan 2016 23:32:19 +0000
Subject: [New-bugs-announce] [issue26011] Document necesities for cmp
 argument of sorted
Message-ID: <1451950339.23.0.203915233375.issue26011@psf.upfronthosting.co.za>


New submission from Karl Richter:

The docstring of `sorted` doesn't explain what can be passed to the `cmp` and `key` argument of `sorted`.

----------
assignee: docs at python
components: Documentation
messages: 257505
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: Document necesities for cmp argument of sorted
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  4 21:13:51 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Jan 2016 02:13:51 +0000
Subject: [New-bugs-announce] [issue26012] pathlib.Path().rglob() is fooled
 by symlink loops
Message-ID: <1451960031.51.0.813695149526.issue26012@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I created a symlink loop as follows:

mkdir tmp
cd tmp
ln -s ../tmp baz
cd ..

Then I tried to list it recursively using rglob():

>>> list(pathlib.Path('tmp').rglob('**/*')

This caused an infinite regress:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 1065, in rglob
    for p in selector.select_from(self):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 549, in _select_from
    for p in successor_select(starting_point, is_dir, exists, listdir):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 548, in _select_from
    for starting_point in self._iterate_directories(parent_path, is_dir, listdir):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 538, in _iterate_directories
    for p in self._iterate_directories(path, is_dir, listdir):
[...]
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 538, in _iterate_directories
    for p in self._iterate_directories(path, is_dir, listdir):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 537, in _iterate_directories
    if is_dir(path):
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 1303, in is_dir
    return S_ISDIR(self.stat().st_mode)
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 1111, in stat
    return self._accessor.stat(self)
  File "/Users/guido/src/cpython36/Lib/pathlib.py", line 371, in wrapped
    return strfunc(str(pathobj), *args)
OSError: [Errno 62] Too many levels of symbolic links: 'tmp/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz/baz'

----------
messages: 257511
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: pathlib.Path().rglob() is fooled by symlink loops
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jan  5 02:39:44 2016
From: report at bugs.python.org (Anil Kulkarni)
Date: Tue, 05 Jan 2016 07:39:44 +0000
Subject: [New-bugs-announce] [issue26013] Pickle protocol 2.0 not loading in
 python 3.5
Message-ID: <1451979584.96.0.927777070704.issue26013@psf.upfronthosting.co.za>


New submission from Anil Kulkarni:

Pickles created with python 3.4.X will not load with python 3.5.X if they include a collections.OrderedDict

To reproduce this issue, simply create a pickle of an OrderedDict on python 3.4.3 with protocol=2 and try to open it on 3.5. I have included a simple script to demonstrate this issue.


I believe this is related to this bug: https://bugs.python.org/issue18473

As to the real-world implications: The python package Celery uses protocol=2 by default when serializing with pickle, and thus a celery web running 3.5 cannot receive the results of a worker running 3.4
For celery specifically, there is a workaround by setting the PICKLE_PROTOCOL environment variable, but this is a core python issue.

P.S. This is the first bug I've filed with python so please let me know if there's something else I should be including.

Thanks!

----------
files: b.py
messages: 257524
nosy: anilredshift
priority: normal
severity: normal
status: open
title: Pickle protocol 2.0 not loading in python 3.5
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41503/b.py

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

From report at bugs.python.org  Tue Jan  5 08:04:25 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Jan 2016 13:04:25 +0000
Subject: [New-bugs-announce] [issue26014] Guide users to the newer package
 install instructions
Message-ID: <1451999065.99.0.467691766338.issue26014@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The up to date module installation docs are at:

* https://docs.python.org/2/installing/index.html
* https://docs.python.org/3/installing/index.html

However, legacy deep links still resolve to the old docs:

* https://docs.python.org/2/install/index.html
* https://docs.python.org/3/install/index.html

Those link out to packaging.python.org, the link is buried in a longish note, rather than being highlighted as a more obvious See Also link.

The top level landing page in the Python 2.7 docs also still links to the legacy docs rather than the new ones, and the "(Legacy)" notation hasn't been appended to the headings on the legacy docs the way it has in 3.x.

There's a few long hanging fruit for cleanup here:

* add See Also links to the modern docs from the legacy docs
* append the (Legacy) suffix in the 2.x docs
* fix the 2.x top level docs page to link to the new docs rather than the legacy ones
* link to the legacy docs from the distutils package docs in 2.7 (as has already been done in 3.x)

----------
assignee: docs at python
components: Documentation
messages: 257529
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Guide users to the newer package install instructions
type: enhancement

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

From report at bugs.python.org  Tue Jan  5 09:47:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Jan 2016 14:47:37 +0000
Subject: [New-bugs-announce] [issue26015] Add new tests for pickling
 iterators of mutable sequences
Message-ID: <1452005257.2.0.950563811675.issue26015@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch updates tests for iterators of mutable sequences. Now tested iterators in all four states (initial, running, empty and exhausted), and tested that unpickled iterator is linked with a sequence, not with an independed copy (as in case of dict iterators).

Note that there is a difference in the behavior of exhausted array iterator from other iterators. Perhaps this should be changed.

----------
components: Tests
files: iterators_pickle_tests.patch
keywords: patch
messages: 257530
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add new tests for pickling iterators of mutable sequences
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41507/iterators_pickle_tests.patch

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

From report at bugs.python.org  Tue Jan  5 10:05:36 2016
From: report at bugs.python.org (=?utf-8?b?7J207Iuc66eMIChFY21hWHAp?=)
Date: Tue, 05 Jan 2016 15:05:36 +0000
Subject: [New-bugs-announce] [issue26016] io.TextIOWrapper.tell() report
 65bit number when mix readline() + tell()
Message-ID: <1452006336.5.0.310653434385.issue26016@psf.upfronthosting.co.za>


New submission from ??? (EcmaXp):

I did test on 
- Python 3.5.1 on Windows 64 Bit and 32 Bit (Machine A)
- Python 3.4.4 on Windows 32 Bit (Machine A)
- Python 3.4.3+ on Ubuntu 15.10 64 Bit (Virtual Machine on Machine A)
- Python 3.4.2 on Machine B and C
- Python 3.3.5 on Windows 32 Bit (Machine A)

I did test but not produce bug. (report 8 correctly)
- Python 3.2.5 on Windows 32 Bit (Machine A)
- Python 3.1.4 on Windows 32 Bit (Machine A)
- Python 2.7.10 on Windows 64 Bit (Machine A) 

Machine A: i7-5775C with Windows 10 (build 10586.36) 64 Bit
Machine B: http://www.tutorialspoint.com/execute_python3_online.php
Machine C: https://repl.it/languages/python3

Code are here

import io
with io.TextIOWrapper(io.BytesIO(b'.\r\n...\r\n\r\n\r\n')) as fp:
    fp.readline() # '.\n'
    fp.readline() # '......\n'
    print(fp.tell()) # 18446744073709551628 = 0x10000000000000009

Not only those string produce bug, also adding more dot make produce bug sometimes.

----------
components: IO, Library (Lib)
messages: 257531
nosy: ??? (EcmaXp)
priority: normal
severity: normal
status: open
title: io.TextIOWrapper.tell() report 65bit number when mix readline() + tell()
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jan  5 12:43:16 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Jan 2016 17:43:16 +0000
Subject: [New-bugs-announce] [issue26017] Update
 https://docs.python.org/3/installing/index.html to always quote arguments
Message-ID: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you look at https://docs.python.org/3/installing/index.html it lists two commands:

python -m pip install SomePackage==1.0.4    # specific version
python -m pip install 'SomePackage>=1.0.4'  # minimum version

If you notice that beyond the change from `==` to `>=`, you will notice one quotes its argument while the other one doesn't. This is a UNIX shell thing due to what `>` means. But if you don't know how the UNIX shell works this could be easily overlooked. It would be best to simply quote both examples and avoid people messing up by leaving off the quotes.

----------
assignee: docs at python
components: Documentation
messages: 257536
nosy: alexis, brett.cannon, docs at python, dstufft, eric.araujo, lemburg, ncoghlan, paul.moore, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Update https://docs.python.org/3/installing/index.html to always quote arguments
type: enhancement

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

From report at bugs.python.org  Tue Jan  5 19:06:41 2016
From: report at bugs.python.org (Martin von Gagern)
Date: Wed, 06 Jan 2016 00:06:41 +0000
Subject: [New-bugs-announce] [issue26018] documentation of ZipFile file name
 encoding
Message-ID: <1452038801.7.0.594053315947.issue26018@psf.upfronthosting.co.za>


New submission from Martin von Gagern:

https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.write writes:

?Note: There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write(). WinZip interprets all file names as encoded in CP437, also known as DOS Latin.?

I think this is wrong in many ways. Firstly, APPNOTE.TXT used to explicitely define CP437 as the standard, and it's still the standard in the absence of general purpose bit 11 and a more specific description using the 0x0008 Extra Field. On the other hand, we do have that general purpose bit these days, so there are now not just one but two well-defined file name encodings. And thirdly, encoding the string to bytes as suggested will in fact lead to a run time error, since ZipInfo expects to do this conversion itself.

See work towards issue1734346, starting at commit 8e33f316ce14, for details on when this was addressed in the source code.

----------
assignee: docs at python
components: Documentation
messages: 257567
nosy: docs at python, gagern
priority: normal
severity: normal
status: open
title: documentation of ZipFile file name encoding
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan  5 21:05:12 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Wed, 06 Jan 2016 02:05:12 +0000
Subject: [New-bugs-announce] [issue26019] collections.abc documentation
 incomplete
Message-ID: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

Some of the modules in collections.abc have a subclass hook that implicitly registers any type that declares the right methods, like Iterator. Others do not, like Sequence. For those that do have the hook, it's not always obvious what methods are tested. And some of them test the methods for truthiness, others only for existence (although #25958 will fix that last bit).

The documentation doesn't even mention this, much less describe which ABCs are of which kind.

For someone who just wants to know how to write isinstance(arg, Iterable), that's fine. But anyone who wants to create new classes, or integrate third-party classes that weren't ABC-friendly, has to read the collections.abc module source to figure out what they want to do.

----------
assignee: docs at python
components: Documentation
messages: 257577
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: collections.abc documentation incomplete
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Jan  5 21:42:21 2016
From: report at bugs.python.org (Hamish Campbell)
Date: Wed, 06 Jan 2016 02:42:21 +0000
Subject: [New-bugs-announce] [issue26020] set_display evaluation order
 doesn't match documented behaviour
Message-ID: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za>


New submission from Hamish Campbell:

It looks like the behaviour of set displays do not match behaviour in some cases. The documentation states:

"A set display yields a new mutable set object, the contents being specified by either a sequence of expressions or a comprehension. When a comma-separated list of expressions is supplied, its elements are evaluated from left to right and added to the set object. When a comprehension is supplied, the set is constructed from the elements resulting from the comprehension."

Note the following:

   >>> foo = { True, 1 }
   >>> print(foo)
   {1}

However, if we add elements 'left to right':

   >>> foo = set()
   >>> foo.add(True)
   >>> foo.add(1)
   >>> print(foo)
   {True}

Note that similar documentation for dict displays produces the expected result.

"If a comma-separated sequence of key/datum pairs is given, they are evaluated from left to right to define the entries of the dictionary: each key object is used as a key into the dictionary to store the corresponding datum. This means that you can specify the same key multiple times in the key/datum list, and the final dictionary?s value for that key will be the last one given."

   >>> foo = {}
   >>> foo[True] = 'bar'
   >>> foo[1] = 'baz'
   >>> print(foo)
   {True: 'baz'}

Which matches the dict display construction:

   >>> foo = { True: 'bar', 1: 'baz'}
   >>> print(foo)
   {True: 'baz'}

Note that I've tagged this as a documentation bug, but it seems like the documentation might be the preferred implementation.

----------
assignee: docs at python
components: Documentation
messages: 257579
nosy: Hamish Campbell, docs at python
priority: normal
severity: normal
status: open
title: set_display evaluation order doesn't match documented behaviour
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/issue26020>
_______________________________________

From report at bugs.python.org  Wed Jan  6 04:37:23 2016
From: report at bugs.python.org (=?utf-8?q?Torsten_Z=C3=BChlsdorff?=)
Date: Wed, 06 Jan 2016 09:37:23 +0000
Subject: [New-bugs-announce] [issue26021] Missing IPv6 support for
 pypi.python.org
Message-ID: <1452073043.01.0.523357649838.issue26021@psf.upfronthosting.co.za>


New submission from Torsten Z?hlsdorff:

Hello,

i'm done some research about the impact of missing IPv6 support at the FreeBSD ports-tree, which is the list of supported software for FreeBSD.

Python and many libs written in python are supported for FreeBSD, but if you have an IPv6 only server, they are not usable at all. Currently python has the biggest impact on the ports-tree: (https://wiki.freebsd.org/IPv6PortsTODO#TOP_25_hosts_with_missing_IPv6_support)

This is because the server pypi.python.org lacks support for IPv6. There is also no AAAA record in DNS:

$ drill pypi.python.org aaaa
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 9429
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; pypi.python.org.     IN      AAAA

;; ANSWER SECTION:
pypi.python.org.        6983    IN      CNAME   prod.python.map.fastly.net.
prod.python.map.fastly.net.     5       IN      CNAME   prod.python.map.fastlylb.net.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 33 msec
;; SERVER: 192.168.0.23
;; WHEN: Wed Jan  6 10:34:12 2016
;; MSG SIZE  rcvd: 112

Please add IPv6 support to your server(s). If you need any help/feedback/tests i will gladly help you!

Thank you very much,
Torsten

----------
messages: 257592
nosy: thorny
priority: normal
severity: normal
status: open
title: Missing IPv6 support for pypi.python.org
type: enhancement

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

From report at bugs.python.org  Wed Jan  6 07:26:47 2016
From: report at bugs.python.org (Roland Eichman)
Date: Wed, 06 Jan 2016 12:26:47 +0000
Subject: [New-bugs-announce] [issue26022] string.replace('  ',
 ' ') has to be called 2 times before it works
Message-ID: <1452083207.08.0.345721672406.issue26022@psf.upfronthosting.co.za>


New submission from Roland Eichman:

Windows 10 
python 3.5
small function in a small module 
contained a string len(str1) == 5000 {approx}
str1 = str1.replace('  ',' ')
did not work
added, via copy & paste, a second identical line
str1 = str1.replace('  ',' ')
str1 = str1.replace('  ',' ')
AND IT WORKED

----------
components: Interpreter Core
messages: 257603
nosy: roland_eichman
priority: normal
severity: normal
status: open
title: string.replace('  ',' ') has to be called 2 times before it works
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan  6 08:07:55 2016
From: report at bugs.python.org (Freddy Rietdijk)
Date: Wed, 06 Jan 2016 13:07:55 +0000
Subject: [New-bugs-announce] [issue26023] Missing signatures operator module
Message-ID: <1452085675.2.0.944148741894.issue26023@psf.upfronthosting.co.za>


New submission from Freddy Rietdijk:

The operator module has no signatures for (most) of the functions defined in it.


Use case:
The multipledispatch module uses inspect.getfullargspec and therefore the functions in operator cannot be used in combination with the @dispatch decorator

----------
components: Library (Lib)
messages: 257606
nosy: Freddy Rietdijk
priority: normal
severity: normal
status: open
title: Missing signatures operator module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan  6 09:28:10 2016
From: report at bugs.python.org (Vidar Fauske)
Date: Wed, 06 Jan 2016 14:28:10 +0000
Subject: [New-bugs-announce] [issue26024] Non-ascii Windows locale names
Message-ID: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za>


New submission from Vidar Fauske:

The Norwegian locale on Windows has the honor of having the only locale name with a non-ASCII character ('Norwegian Bokm?l_Norway', see e.g. https://wiki.postgresql.org/wiki/Changes_To_Norwegian_Locale). It does not seem like python 3 is able to handle this properly, as the following code demonstrates:

>python
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_TIME, 'swedish')
'Swedish_Sweden.1252'
>>> loc_sw = locale.getlocale(locale.LC_TIME)
>>> locale.setlocale(locale.LC_TIME, 'norwegian')
'Norwegian Bokm?l_Norway.1252'
>>> loc_no = locale.getlocale(locale.LC_TIME)
>>> locale.setlocale(locale.LC_TIME, loc_sw)
'Swedish_Sweden.1252'
>>> locale.setlocale(locale.LC_TIME, loc_no)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\prog\WinPython-64bit-3.4.3.7\python-3.4.3.amd64\lib\locale.py", line 593, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting


As can be seen, this can be worked around when setting the locale manually, but if the locale has already been set to Norwegian, the value returned from getlocale is invalid when passed to setlocale.

Following the example of postgres in the link above, I suggest changing the behavior of locale.getlocale to alias 'Norwegian Bokm?l_Norway.1252' as 'Norwegian_Norway.1252', which is completely ASCII, and therefore fine.

----------
components: Unicode, Windows
messages: 257608
nosy: ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, vidartf, zach.ware
priority: normal
severity: normal
status: open
title: Non-ascii Windows locale names
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan  6 12:39:34 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Jan 2016 17:39:34 +0000
Subject: [New-bugs-announce] [issue26025] Document pathlib.Path.__truediv__()
Message-ID: <1452101974.47.0.473485918535.issue26025@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I noticed that the documentation for pathlib only mentions the overloading of __truediv__ in examples and not anywhere in the actual docs for the Path object itself.

----------
assignee: docs at python
components: Documentation
messages: 257617
nosy: brett.cannon, docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Document pathlib.Path.__truediv__()

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

From report at bugs.python.org  Wed Jan  6 13:38:14 2016
From: report at bugs.python.org (Hristo Venev)
Date: Wed, 06 Jan 2016 18:38:14 +0000
Subject: [New-bugs-announce] [issue26026] True%2==True
Message-ID: <1452105494.05.0.152464370821.issue26026@psf.upfronthosting.co.za>


New submission from Hristo Venev:

Should be 1. This comes from the (a%b=a if a<b) optimization.

Let's be consistent with all other arithmetic operations.

----------
components: Interpreter Core
messages: 257629
nosy: h.venev
priority: normal
severity: normal
status: open
title: True%2==True
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan  6 16:05:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Jan 2016 21:05:29 +0000
Subject: [New-bugs-announce] [issue26027] Support Path objects in the posix
 module
Message-ID: <1452114329.99.0.617690911804.issue26027@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

path_converter should be changed to accept objects with the "path" attribute. See issue22570 for details.

----------
assignee: serhiy.storchaka
components: Extension Modules
messages: 257642
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Support Path objects in the posix module
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Jan  6 16:33:53 2016
From: report at bugs.python.org (Hassan Mahroof)
Date: Wed, 06 Jan 2016 21:33:53 +0000
Subject: [New-bugs-announce] [issue26028] .sort() Causing Strings to Be
 Listed on the same line
Message-ID: <1452116033.54.0.131066296483.issue26028@psf.upfronthosting.co.za>


New submission from Hassan Mahroof:

I am a student @ Burnley College and we were learning how to use the .write(), .close(), .readlines() and .sort().

I have a list of names within a text file which I am trying sort, These are random names generated using my Random Mind. However, when the sorted text file is created, what seems to be under certain circumstances with my list only (or words similar, This bug did not occur within my whole class till I stumbled upon it) it seems to instead of writing each term to seperate lines, it seems to connect two of the words (in this case names) on the same line. I have tried to find a pattern in this madness however being the rookie student I am I can only seem to break things aha. I have attached the 2 files which I am using and Hopefully someone can correct this cause I am confused.

This is a list of the names:
Robertas
Hassan
Bob
Connor
Camera
Billy
Maz
Richard
Mo

----------
components: IDLE
files: SortFile2.py
messages: 257644
nosy: Hassan Mahroof
priority: normal
severity: normal
status: open
title: .sort() Causing Strings to Be Listed on the same line
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41520/SortFile2.py

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

From report at bugs.python.org  Wed Jan  6 16:44:08 2016
From: report at bugs.python.org (Julien)
Date: Wed, 06 Jan 2016 21:44:08 +0000
Subject: [New-bugs-announce] [issue26029] Broken sentence in extending
 documentation
Message-ID: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za>


New submission from Julien:

Hello,

While translating the documentation to French, I found a bug here : 

https://docs.python.org/3/extending/building.html#building-c-and-c-extensions-with-distutils

The sentence: "Normally, a package will contain of addition modules:"
Should probably be: "Normally, a package will contain additional modules:"

Bests.

----------
assignee: docs at python
components: Documentation
messages: 257645
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Broken sentence in extending documentation
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan  6 17:06:04 2016
From: report at bugs.python.org (Julien)
Date: Wed, 06 Jan 2016 22:06:04 +0000
Subject: [New-bugs-announce] [issue26030] Use PEP8 in documentation examples
Message-ID: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za>


New submission from Julien:

Hi,

Shouldn't Python use PEP8 in its examples in the documentation ? I found a lot of missing spaces around binary operators, and things like "setup (name = 'PackageName'," (found in the Distributing section, but that's just a single example) which hurt my eyes and will probably teach bad practices to newcomers reading it.

If everybody agree documentation examples should be PEP8 compliant, I'll can gladly provide some patches.

I also found http://bugs.python.org/issue23921 which is probably not merged as it's still open, and the patch don't fix my example, so there is probably some problems left.

----------
assignee: docs at python
components: Documentation
messages: 257649
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Use PEP8 in documentation examples
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan  6 17:41:29 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 06 Jan 2016 22:41:29 +0000
Subject: [New-bugs-announce] [issue26031] Add stat caching option to pathlib
Message-ID: <1452120089.84.0.0792910513701.issue26031@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

There are concerns that pathlib is inefficient because it doesn't cache stat() operations. Thus, for example this code calls stat() for each result twice (once internal to the glob, a second time to answer the is_symlink() question):

  p = pathlib.Path('/usr')
  links = [x for x in p.rglob('*') if x.is_symlink()]

I have a tentative patch (without tests). On my Mac it only gives modest speedups (between 5 and 20 percent) but things may be different on other platforms or for applications that make a lot of inquiries about the same path.

The API I am proposing is that by default nothing changes; to benefit from caching you must instantiate a StatCache() object and pass it to Path() constructor calls, e.g. Path('/usr', stat_cache=cache_object). All Path objects derived from this path object will share the cache. To force an uncached Path object you can use Path(p).

The patch is incomplete; there are no tests for the new functionality (though existing tests pass) and __eq__ should be adjusted so that Path objects using different caches always compare unequal.

Question for Antoine: Did you perhaps anticipate a design like this? Each Path instance has an _accessor slot, but there is only one accessor instance defined that is used everywhere (the global _normal_accessor). So you could have avoided a bunch of complexity in the code around setting the proper _accessor unless you were planning to use multiple accessors.

----------
files: statcache.diff
keywords: patch
messages: 257651
nosy: gvanrossum, pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: Add stat caching option to pathlib
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41521/statcache.diff

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

From report at bugs.python.org  Wed Jan  6 17:55:27 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 06 Jan 2016 22:55:27 +0000
Subject: [New-bugs-announce] [issue26032] Use scandir() to speed up pathlib
 globbing
Message-ID: <1452120927.04.0.31788168865.issue26032@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The globbing functionality in pathlib (Path.glob() and Path.rglob()) might benefit from using the new optimized os.scandir() interface. It currently just uses os.listdir(). The Path.iterdir() method might also benefit (though less so).

There's also a sideways connection with http://bugs.python.org/issue26031 (adding an optional stat cache) -- the cache could possibly keep the DirEntry objects and use their (hopefully cached) attributes. This is more speculative though (and what if the platform's DirEntry doesn't cache?)

----------
messages: 257653
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Use scandir() to speed up pathlib globbing
type: performance
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan  6 19:32:48 2016
From: report at bugs.python.org (Stefan Seefeld)
Date: Thu, 07 Jan 2016 00:32:48 +0000
Subject: [New-bugs-announce] [issue26033] distutils default compiler API is
 incomplete
Message-ID: <1452126768.68.0.403890898516.issue26033@psf.upfronthosting.co.za>


New submission from Stefan Seefeld:

I'm trying to use the distutil compiler to preprocess some header (to be used with the cffi package).
The code is

    compiler = distutils.ccompiler.new_compiler()
    compiler.add_include_dir(join(sys.prefix, 'include'))
    compiler.preprocess(source)

This raises this exception (on Linux):

  File ".../distutils/unixccompiler.py", line 88, in preprocess
    pp_args = self.preprocessor + pp_opts
TypeError: unsupported operand type(s) for +: 'NoneType' and 'list'

caused by 'set.preprocessor' to be set to None (with the preceding comment:

    # The defaults here
    # are pretty generic; they will probably have to be set by an outsider
    # (eg. using information discovered by the sysconfig about building
    # Python extensions).

Seems that code never got fully implemented.
Further, the MSVC version of the compiler (msvccompiler.py) doesn't even implement a "preprocess()" method, so this falls back to the CCompiler.preprocess() default, which does nothing !

----------
components: Distutils
messages: 257663
nosy: dstufft, eric.araujo, stefan
priority: normal
severity: normal
status: open
title: distutils default compiler API is incomplete
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Wed Jan  6 23:38:52 2016
From: report at bugs.python.org (Dan Sadowski)
Date: Thu, 07 Jan 2016 04:38:52 +0000
Subject: [New-bugs-announce] [issue26034] venv documentation out of date
Message-ID: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za>


New submission from Dan Sadowski:

The listing for the --clear option in the documentation is outdated. This is from the actual current 3.5 usage text:

  --clear               Delete the contents of the environment directory if it
                        already exists, before environment creation.

----------
assignee: docs at python
components: Documentation
messages: 257669
nosy: docs at python, dsadowski
priority: normal
severity: normal
status: open
title: venv documentation out of date
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan  6 23:47:35 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Thu, 07 Jan 2016 04:47:35 +0000
Subject: [New-bugs-announce] [issue26035] traceback.print_tb() takes `tb`,
 not `traceback` as a keyword argument
Message-ID: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za>


New submission from Nicholas Chammas:

Here is traceback.print_tb()'s signature [0]:

```
def print_tb(tb, limit=None, file=None):
```

However, its documentation reads [1]:

```
.. function:: print_tb(traceback, limit=None, file=None)
```

Did the keyword argument change recently, or was this particular doc always wrong?

[0] https://github.com/python/cpython/blob/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Lib/traceback.py#L43
[1] https://raw.githubusercontent.com/python/cpython/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Doc/library/traceback.rst

----------
assignee: docs at python
components: Documentation
messages: 257670
nosy: Nicholas Chammas, docs at python
priority: normal
severity: normal
status: open
title: traceback.print_tb() takes `tb`, not `traceback` as a keyword argument
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jan  7 07:16:23 2016
From: report at bugs.python.org (Cal Leeming)
Date: Thu, 07 Jan 2016 12:16:23 +0000
Subject: [New-bugs-announce] [issue26036] Unnecessary arguments on
 smtpd.SMTPServer
Message-ID: <1452168983.71.0.914590889995.issue26036@psf.upfronthosting.co.za>


New submission from Cal Leeming:

`smtpd.SMTPServer` takes argument `remoteaddr`, however this is only used in subclass `smtpd.DebuggingServer`.

Would anyone object to a patch which removes `remoteaddr` from `smtpd.SMTPServer.__init__` and places it into `smtpd.DebuggingServer.__init__` instead?

Naturally this would be backwards incompatible

----------
components: Library (Lib)
messages: 257684
nosy: sleepycal
priority: normal
severity: normal
status: open
title: Unnecessary arguments on smtpd.SMTPServer
type: enhancement

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

From report at bugs.python.org  Thu Jan  7 07:43:44 2016
From: report at bugs.python.org (=?utf-8?b?ZXBoIOKAiw==?=)
Date: Thu, 07 Jan 2016 12:43:44 +0000
Subject: [New-bugs-announce] [issue26037] Crash when reading
 sys.stdin.buffer in a daemon thread
Message-ID: <1452170624.64.0.0901256170606.issue26037@psf.upfronthosting.co.za>


New submission from eph ?:

I wrote a script to non-blocking reading binary data from stdin like this:


import sys, threading

def _thread():
    data = sys.stdin.buffer.readline()

thread = threading.Thread(target=_thread)
thread.daemon = True
thread.start()


and the output is like this:


Fatal Python error: could not acquire lock for <_io.BufferedReader name='<stdin>'> at interpreter shutdown, possibly due to daemon threads

Thread 0x00007faf54ebf700 (most recent call first):
  File "pipetcpadapter.py", line 8 in func
  File "/usr/lib/python3.5/threading.py", line 862 in run
  File "/usr/lib/python3.5/threading.py", line 914 in _bootstrap_inner
  File "/usr/lib/python3.5/threading.py", line 882 in _bootstrap

Current thread 0x00007faf566da700 (most recent call first):
Aborted (core dumped)

----------
components: IO
messages: 257685
nosy: eph ?
priority: normal
severity: normal
status: open
title: Crash when reading sys.stdin.buffer in a daemon thread
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan  7 08:29:43 2016
From: report at bugs.python.org (Brett Rosen)
Date: Thu, 07 Jan 2016 13:29:43 +0000
Subject: [New-bugs-announce] [issue26038] zipfile cannot handle zip files
 where the archive size for a file does not match actual contents
Message-ID: <1452173383.07.0.105152287179.issue26038@psf.upfronthosting.co.za>


New submission from Brett Rosen:

In python 2.7 it was able to handle this. It looks like this was introduced in https://github.com/python/cpython/commit/ae489fa76bb02daa636afe3bebec232e5aa9fac5 .

I'm not really sure if this should be considered a regression or not since the zip files that trigger this could be considered bad, even though unzip and older versions of zipfile.py could handle them.

I've attached a copy of a local diff I applied that worked around this issue, but I don't think it is a proper fix.

----------
components: Library (Lib)
files: changes.diff
keywords: patch
messages: 257687
nosy: Brett Rosen
priority: normal
severity: normal
status: open
title: zipfile cannot handle zip files where the archive size for a file does not match actual contents
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41523/changes.diff

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

From report at bugs.python.org  Thu Jan  7 10:10:51 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 07 Jan 2016 15:10:51 +0000
Subject: [New-bugs-announce] [issue26039] More flexibility in zipfile
 interface
Message-ID: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

I was working recently on some code writing zip files, and needed a bit more flexibility than the interface of zipfile provides. To do what I wanted, I ended up copying the entirety of ZipFile.write() into my own code with modifications. That's ugly, and to make it worse, the code I copied from the Python 3.4 stdlib didn't work properly with Python 3.5.

Specifically, I want to:

* Override the timestamp, which write() unconditionally takes from the mtime of the file.
* Do extra processing on the data (e.g. calculating a checksum) as it is read. Being able to pass a file-like object in to be read, rather than just a filename, would work for this.

I could do both by using ZipFile.writestr(), but then the entire file must be loaded into memory at once, which I would much rather avoid.

The patch attached is one proposal which would make it easier to do what I want, but it's intended as a starting point for discussion. I'm not particularly attached to the API.

- Should this be a new method, or new functionality for either the write or writestr method? I favour a new method, because the existing methods are already quite long, and I think it's nicer to break write() up into two parts like this.

- If a new method, what should it be called? I opted for writefile()

- What should its signature be? It's currently writefile(file_obj, zinfo, force_zip64=False), but I can see an argument for aligning it with writestr(zinfo_or_arcname, data, compress_type=None).

- What to do about ZIP64: the code has to decide whether to use ZIP64 format before writing, because it affects the header size, but we may not know the length before we have read it all. I've used a force_zip64 boolean parameter, and documented that people should pass it True if a file of unknown size could exceed 2 GiB.

- Are there other points where it could be made more flexible while we're thinking about this? I'd quite like to split out the code for writing a directory entry to a separate method ('writedir'?). I'd also like to allow datetime objects to be passed in for timestamps as well as the 6-tuples currently expected.

----------
components: Library (Lib)
files: zipfile-flexibility.patch
keywords: patch
messages: 257694
nosy: takluyver
priority: normal
severity: normal
status: open
title: More flexibility in zipfile interface
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41525/zipfile-flexibility.patch

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

From report at bugs.python.org  Thu Jan  7 10:41:22 2016
From: report at bugs.python.org (Jeff Allen)
Date: Thu, 07 Jan 2016 15:41:22 +0000
Subject: [New-bugs-announce] [issue26040] Improve coverage and rigour of
 test.test_math
Message-ID: <1452181282.79.0.203850145541.issue26040@psf.upfronthosting.co.za>


New submission from Jeff Allen:

In many cases, test_math does not exercise the functions defined by the math module, other than at a few values needing special handling. Where it does test a function with values representative of the domain, the accuracy demanded is often loose in one place and tight in another. By comparison, test_cmath uses more interesting values and a rational approach to accuracy.

In most implementations, math simply proxies an expertly built (and tested) platform library or firmware, so it is unlikely we are the victims of mathematical inexactitude.

We observed this as a problem in the Jython project, where failures in cmath were traced eventually to the naive (but passing) implementation of some functions in math. For Jython, we now supplement test_math with stronger tests more like those in test_cmath. So this issue is really an offer to fold that work back into the CPython test_math, to strengthen testing for all.


Coverage:
--------
In the attached program, in the coverge section, I logged the calls to selected functions from test_math to see what range of values they used. It produces results like:

sqrt
 [9.881e-324, 7.905e-323, 1.862e-309, 1e-305, 1e-150, ..., 2, 23, 1e+16, 1e+150, 1e+299]
 [-1]
 [-0.0, -inf, 0.0, inf, nan]

sin
 [1.571]
 [-1.571]
 [-0.0, -inf, 0.0, inf, nan]

exp
 []
 [-745]
 [-0.0, -inf, 0.0, inf, nan]

sinh
 []
 []
 [-0.0, -inf, 0.0, inf, nan]

The three rows here are positive, negative and "special" arguments, and "..." means I abridged the list.


Accuracy:
--------
Where functions are tested, results are expected with a maximum error of 1e-5. On sqrt(1e150), this demands bit-perfect accuracy; on sqrt(1e-150) it demands virtually nothing. 

In the attached program, in the accuracy section, I wrap most of the functions so as to fuzz their results by plus or minus 2e-6, test_math will still pass them. test_cmath uses a relative measure of error (so many ulps of the expected value), which is worth emulating.


If people think it better, coverage and accuracy can be tracked as separate issues.

----------
components: Tests
files: stat_math.py
messages: 257695
nosy: jeff.allen, mark.dickinson
priority: normal
severity: normal
status: open
title: Improve coverage and rigour of test.test_math
type: behavior
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file41526/stat_math.py

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

From report at bugs.python.org  Thu Jan  7 12:18:20 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 07 Jan 2016 17:18:20 +0000
Subject: [New-bugs-announce] [issue26041] Update deprecation messages of
 platform.dist() and platform.linux_distribution()
Message-ID: <1452187100.03.0.384540652472.issue26041@psf.upfronthosting.co.za>


New submission from Berker Peksag:

We need to remove "and will be removed in Python 3.7" from deprecation messages of platform.dist() and platform.linux_distribution() and update the relevant whatsnew entry in Doc/whatsnew/3.5.rst. 

See msg256111 in issue 1322 for details.

----------
components: Library (Lib)
keywords: easy
messages: 257704
nosy: berker.peksag
priority: normal
severity: normal
stage: needs patch
status: open
title: Update deprecation messages of platform.dist() and platform.linux_distribution()
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jan  7 12:52:21 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 Jan 2016 17:52:21 +0000
Subject: [New-bugs-announce] [issue26042] Consider dropping magic number for
 more detailed .pyc file name
Message-ID: <1452189141.27.0.112439951883.issue26042@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The reason the magic number exists in .pyc files is because back in Python 2 we only had a single .pyc file per module, which meant if you suddenly switched versions of Python you needed a way to know that the .pyc file was wrong for the running version of Python.

This is not the case in Python 3. Thanks to __pycache__ directories we have separate .pyc files per release version of Python (we also have .pyc files for each optimization level of Python). If we changed the sys.implementation.cache_tag to include the bugfix version -- and maybe even release level -- then the magic number wouldn't be necessary for users. It does make developing bytecode a little bit more difficult for core developers since they will have to clear out their .pyc files during development, but users wouldn't be affected.

Now I don't know if this is really worth the simplification it provides. I don't think it's worth the compatibility break for any code that may be reading .pyc files and I doubt there is any measurable performance benefit.  But the realization struck me and I figured I should at least write it down in case anyone else thinks of it.

----------
components: Interpreter Core
messages: 257705
nosy: brett.cannon, eric.snow, ncoghlan
priority: low
severity: normal
stage: test needed
status: open
title: Consider dropping magic number for more detailed .pyc file name
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Jan  7 13:57:09 2016
From: report at bugs.python.org (Vitaminus Maximus)
Date: Thu, 07 Jan 2016 18:57:09 +0000
Subject: [New-bugs-announce] [issue26043] ON DELETE CASCADE does not work
 when using sqlite3 library
Message-ID: <1452193029.87.0.593726838819.issue26043@psf.upfronthosting.co.za>


New submission from Vitaminus Maximus:

Let me provide a completely reproducible code, which demonstrates the issue:

    >>> import sqlite3
    >>> cnx = sqlite3.connect("mytest.db")
    >>> cnx.isolation_level = None
    >>> cursor = cnx.cursor()
    >>> cnx.execute("BEGIN")
    <sqlite3.Cursor object at 0x7f0ab0923490>
    >>> cursor.execute("CREATE TABLE test_table (id integer)")
    <sqlite3.Cursor object at 0x7f0ab0923420>
    >>> cursor.execute("CREATE UNIQUE INDEX id_primary ON test_table(id)")
    <sqlite3.Cursor object at 0x7f0ab0923420>
    >>> cursor.execute("INSERT INTO test_table (id) VALUES (1),(2),(3)")
<sqlite3.Cursor object at 0x7f0ab0923420>
    >>> cursor.execute("CREATE TABLE test_table_2(id_fk integer, txt text,  FOREIGN KEY (id_fk) REFERENCES test_table(id) ON DELETE CASCADE)")
    <sqlite3.Cursor object at 0x7f0ab0923420>
    >>> cursor.execute("INSERT INTO test_table_2 (id_fk, txt) VALUES (1,\"one\"),(2,\"two\"),(3,\"three\")")
    <sqlite3.Cursor object at 0x7f0ab0923420>
    >>> res = cursor.execute("SELECT * FROM test_table_2")
    >>> res
    <sqlite3.Cursor object at 0x7f0ab0923420>
    >>> for r in res:
    ...     print(r)
    ...
    (1, 'one')
    (2, 'two')
    (3, 'three')
    >>> cursor.execute("PRAGMA foreign_keys = ON")
    <sqlite3.Cursor object at 0x7f0ab0923420>
    >>> cursor.execute("DELETE FROM test_table WHERE id = 1")
    <sqlite3.Cursor object at 0x7f0ab0923420>
    >>> res = cursor.execute("SELECT * FROM test_table_2")
    >>> for r in res:
    ...     print(r)
    ...
    (1, 'one')
    (2, 'two')
    (3, 'three')

As you can see, even though I explicitly set isolation_level, start transaction and specify PRAGMA foreign_keys = ON, it does not work. The expected behaviour is that when I run the last SELECT command, it should return only two rows (because a "parent" raw with id = 1 was deleted). By the way, if I run these commands in pure sqlite prompt, then I get what I expect to see.

----------
components: Library (Lib)
messages: 257709
nosy: Vitaminus Maximus
priority: normal
severity: normal
status: open
title: ON DELETE CASCADE does not work when using sqlite3 library
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  7 14:28:19 2016
From: report at bugs.python.org (Joseph Fox-Rabinovitz)
Date: Thu, 07 Jan 2016 19:28:19 +0000
Subject: [New-bugs-announce] [issue26044] Name mangling overrides externally
 defined names
Message-ID: <1452194899.15.0.985986475185.issue26044@psf.upfronthosting.co.za>


New submission from Joseph Fox-Rabinovitz:

I will begin by including three code snippets that do not work to illustrate the issue. All snippets were run as python modules/scripts from the command line using "python snippet.py":

**1**

__a = 3
print(locals())
class T:
    def __init__(self):
        global __a
        self.a = __a
t1 = T()

**2**

__a = 3
print(locals())
class T:
    def __init__(self):
        self.a = __a
t2 = T()

**3**

__a = 3
print(locals())
class T:
    def __init__(self):
        m = sys.modules[__name__]
        self.a = m.__a
t3 = T()

All three snippets fail in the line assigning `self.a`. The first two produce `NameError: name '_T__a' is not defined`. The third produces `AttributeError: module '__main__' has no attribute '_T__a'`. The problem in all three cases is that name mangling supercedes any other operation to the point that it mangles elements that are explicitly stated not to belong to the class. This behavior is not intuitive or expected.

I am running `Python 3.5.1 :: Continuum Analytics, Inc.` (using the Anaconda platform) on a Red Hat 6.5 machine. I have tried the same thing on Arch Linux (also with Python 3.5.1 and anaconda) with identical results.

----------
components: Interpreter Core
messages: 257714
nosy: madphysicist
priority: normal
severity: normal
status: open
title: Name mangling overrides externally defined names
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan  7 17:27:17 2016
From: report at bugs.python.org (=?utf-8?q?Emil_Stenstr=C3=B6m?=)
Date: Thu, 07 Jan 2016 22:27:17 +0000
Subject: [New-bugs-announce] [issue26045] Improve error message for
 http.client when posting unicode string
Message-ID: <1452205637.36.0.0359255361227.issue26045@psf.upfronthosting.co.za>


New submission from Emil Stenstr?m:

This issue is in response to this thread on python-ideas: https://mail.python.org/pipermail/python-ideas/2016-January/037678.html

Note that Cory did a lot of encoding background work here:
https://mail.python.org/pipermail/python-ideas/2016-January/037680.html

---
Bug description:

When posting an unencoded unicode string directly with python-requests you get the following stacktrace:

import requests
r = requests.post("http://example.com", data="Celebrate ?") 
...
  File "../lib/python3.4/http/client.py", line 1127, in _send_request
    body = body.encode('iso-8859-1')
UnicodeEncodeError: 'latin-1' codec can't encode characters in position 14-15: ordinal not in range(256) 

This is because requests uses http.client, and http.client assumes the encoding to be latin-1 if given a unicode string. This is a very common source of bugs for beginners who assume sending in unicode would automatically encode it in utf-8, like in the libraries of many other languages.

The simplest fix here is to catch the UnicodeEncodeError and improve the error message to something that points beginners in the right direction.

Another option would be to:
- Keep encoding in latin-1 first, and if that fails try utf-8

Other possible solutions (that would be backwards incompatible) includes:
- Changing the default encoding to utf-8 instead of latin-1
- Detect an unencoded unicode string and fail without encoding it with a descriptive error message

---

Just to show that this is a problem that exists in the wild, here are a few examples that all crashes on the same line in http.client (not all going through the requests library:

- https://github.com/kennethreitz/requests/issues/2838
- https://github.com/kennethreitz/requests/issues/1822
- http://stackoverflow.com/questions/34618149/post-unicode-string-to-web-service-using-python-requests-library
- https://www.reddit.com/r/learnpython/comments/3violw/unicodeencodeerror_when_searching_ebay_with/
- https://github.com/codecov/codecov-python/issues/35
- https://github.com/google/google-api-python-client/issues/145
- https://bugs.launchpad.net/ubuntu/+source/lazr.restfulclient/+bug/1414063

----------
components: Unicode
messages: 257721
nosy: Emil Stenstr?m, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Improve error message for http.client when posting unicode string
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jan  7 19:46:20 2016
From: report at bugs.python.org (David Sterry)
Date: Fri, 08 Jan 2016 00:46:20 +0000
Subject: [New-bugs-announce] [issue26046] Typo
Message-ID: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za>


New submission from David Sterry:

In https://docs.python.org/2/library/unittest.html#basic-example the word "details" should be "detail".

----------
assignee: docs at python
components: Documentation
messages: 257731
nosy: David Sterry, docs at python
priority: normal
severity: normal
status: open
title: Typo
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  8 04:18:18 2016
From: report at bugs.python.org (Christof Hanke)
Date: Fri, 08 Jan 2016 09:18:18 +0000
Subject: [New-bugs-announce] [issue26047] argparse.ArgumentError
 documentation wrong
Message-ID: <1452244698.45.0.106083471244.issue26047@psf.upfronthosting.co.za>


New submission from Christof Hanke:

On https://docs.python.org/2/library/argparse.html (and on those of the 3.6-Version) it says at the bottom:

"""

ArgumentParser.error(message)

    This method prints a usage message including the message to the standard error and terminates the program with a status code of 2.
"""

In fact, the returned staus code is 1.

----------
assignee: docs at python
components: Documentation
messages: 257745
nosy: Christof Hanke, docs at python
priority: normal
severity: normal
status: open
title: argparse.ArgumentError documentation wrong
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/issue26047>
_______________________________________

From report at bugs.python.org  Fri Jan  8 06:58:49 2016
From: report at bugs.python.org (Divyang Patel)
Date: Fri, 08 Jan 2016 11:58:49 +0000
Subject: [New-bugs-announce] [issue26048] New user in community
Message-ID: <1452254329.64.0.275249688938.issue26048@psf.upfronthosting.co.za>


New submission from Divyang Patel:

Greetings to all!

Hi,


please Guide me to understand how to contributing python ??

----------
messages: 257752
nosy: devtechnofreak
priority: normal
severity: normal
status: open
title: New user in community
type: enhancement

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

From report at bugs.python.org  Fri Jan  8 08:36:38 2016
From: report at bugs.python.org (Sergi Almacellas Abellana)
Date: Fri, 08 Jan 2016 13:36:38 +0000
Subject: [New-bugs-announce] [issue26049] Poor performance when reading
 large xmlrpc data
Message-ID: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>


New submission from Sergi Almacellas Abellana:

By default, python xmlrpclib parser reads data by chunks of 1024 bytes [1], which leads to a lot of data concatenations when reading large data, which is very slow in python.

Increasing the chuck size from 1024 bytes to a higher value makes improve in performance. 

On the same machine, we have tested with 20MB of data and we've got the following results: 

Chucks of 1024: 1min 48.933491sec
Chucks of 10 * 1024 * 1024: 0.245282sec

We have chosen 10 * 1024 * 1024, as it is the same value used in issue792570

We have done our tests on python2.7, but same code exists for default branch [2] (and 3.x branches also [3][4][5][6]), so I belive all the versions are affected. 

I can work on a patch if you think this change is acceptable.

IMHO it's logical to allow the developer to customize the chunk size instead of using a hard coded one. 

[1] https://hg.python.org/cpython/file/2.7/Lib/xmlrpclib.py#l1479
[2] https://hg.python.org/cpython/file/default/Lib/xmlrpc/client.py#l1310
[3] https://hg.python.org/cpython/file/3.5/Lib/xmlrpc/client.py#l1310
[4] https://hg.python.org/cpython/file/3.4/Lib/xmlrpc/client.py#l1324
[5] https://hg.python.org/cpython/file/3.3/Lib/xmlrpc/client.py#l1316
[6] https://hg.python.org/cpython/file/3.2/Lib/xmlrpc/client.py#l1301

----------
components: XML
messages: 257756
nosy: pokoli
priority: normal
severity: normal
status: open
title: Poor performance when reading large xmlrpc data

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

From report at bugs.python.org  Fri Jan  8 15:37:56 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 08 Jan 2016 20:37:56 +0000
Subject: [New-bugs-announce] [issue26050] Add new StreamReader.readuntil()
 method
Message-ID: <1452285476.14.0.419432816204.issue26050@psf.upfronthosting.co.za>


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

See code discussion here:

https://github.com/python/asyncio/pull/297

----------
components: asyncio
messages: 257776
nosy: gvanrossum, haypo, mmarkk, yselivanov
priority: normal
severity: normal
status: open
title: Add new StreamReader.readuntil() method
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  8 18:21:49 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 08 Jan 2016 23:21:49 +0000
Subject: [New-bugs-announce] [issue26051] Non-data descriptors in pydoc
Message-ID: <1452295309.05.0.476253695659.issue26051@psf.upfronthosting.co.za>


New submission from Antony Lee:

Consider the following minimal example:

    class readonlyprop:
        __init__ = lambda self, func: None
        __get__ = lambda self, inst, cls=None: None

    class C:
        def bar(self):
            pass
        @readonlyprop
        def foo(self):
            pass
        def quux(self):
            pass

the output of `pydoc modname.C` is

    <... cropped ...>
    modname.C = class C(builtins.object)
    |  Methods defined here:
    |  
    |  bar(self)
    |  
    |  foo = None
    |  quux(self)
    |  
    |  ----------------------------------------------------------------------
    |  Data descriptors defined here:
    <... cropped ...>

It would be nice if
1. a newline was added after `foo = None`, and
2. foo was *also* marked as being a non-data-descriptor of class readonlyprop (basically what you'd get without invoking the __get__).

----------
assignee: docs at python
components: Documentation
messages: 257782
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Non-data descriptors in pydoc
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  8 18:30:07 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 08 Jan 2016 23:30:07 +0000
Subject: [New-bugs-announce] [issue26052] pydoc for __init__ with not
 docstring
Message-ID: <1452295807.98.0.613500169742.issue26052@psf.upfronthosting.co.za>


New submission from Antony Lee:

For a class whose __init__ has no docstring, e.g.

    class C:
        def __init__(self, arg):
            pass

pydoc outputs

    <... cropped ...>
    class C(builtins.object)
     |  Methods defined here:
     |  
     |  __init__(self, arg)
     |      Initialize self.  See help(type(self)) for accurate signature.
    <... cropped ...>

The last part "See help(type(self)) for accurate signature." could arguably be cropped as the correct signature is already displayed (I see that this is the docstring of object.__init__, it's not clear to me why it needs this sentence.).

----------
assignee: docs at python
components: Documentation
messages: 257784
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: pydoc for __init__ with not docstring
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  8 18:43:41 2016
From: report at bugs.python.org (Doug Hellmann)
Date: Fri, 08 Jan 2016 23:43:41 +0000
Subject: [New-bugs-announce] [issue26053] regression in pdb output between
 2.7 and 3.5
Message-ID: <1452296621.32.0.373600761217.issue26053@psf.upfronthosting.co.za>


New submission from Doug Hellmann:

Under python 2.7 using the "run" command within pdb and passing it arguments causes those arguments to be printed out. Under 3.5, this is no longer true.



$ python2.7 -m pdb pdb_run.py
> /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)<module>()
-> import sys
(Pdb) c
('Command-line args:', ['pdb_run.py'])
The program finished and will be restarted
> /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)<module>()
-> import sys
(Pdb) run a b c "this is a long argument"
Restarting pdb_run.py with arguments:
	a b c this is a long argument
> /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)<module>()
-> import sys



$ python3.5 -m pdb pdb_run.py
> /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)<module>()
-> import sys
(Pdb) c
Command-line args: ['pdb_run.py']
The program finished and will be restarted
> /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)<module>()
-> import sys
(Pdb) run a b c "this is a long argument"
Restarting pdb_run.py with arguments:
	pdb_run.py
> /Users/dhellmann/Dropbox/PyMOTW/Python3/pymotw-3/source/pdb/pdb_run.py(7)<module>()
-> import sys


It looks like the issue is in the pdb main loop. Under 2.7 the restart logic has:

except Restart:
    print "Restarting", mainpyfile, "with arguments:"
    print "\t" + " ".join(sys.argv[1:])


but under 3.5 that was changed to:

except Restart:
    print("Restarting", mainpyfile, "with arguments:")
    print("\t" + " ".join(args))


The do_run() method has already reset sys.argv before throwing Restart, so to print the correct arguments sys.argv[1:] should be used.

----------
files: pdb_run.py
keywords: 3.5regression
messages: 257785
nosy: doughellmann
priority: normal
severity: normal
status: open
title: regression in pdb output between 2.7 and 3.5
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41538/pdb_run.py

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

From report at bugs.python.org  Fri Jan  8 21:44:40 2016
From: report at bugs.python.org (David Jackson)
Date: Sat, 09 Jan 2016 02:44:40 +0000
Subject: [New-bugs-announce] [issue26054] Unable to run scripts: idle3 -r
 script.py
Message-ID: <1452307480.34.0.944770933211.issue26054@psf.upfronthosting.co.za>


New submission from David Jackson:

[Raspberry Jessie] Idle3(4.2]
If I open a idle3 shell (from menu) and enter >>import pandas as pd it accepts the command, but if I trying and run it from the shell>> idle3 -r script.py I get the following errors:

Traceback (most recent call last):
  File "test.py", line 1, in <module>
    import pandas as pd
  File "/home/pi/python/pandas.py", line 3, in <module>
    from pandas_datareader import data, wb
  File "/usr/local/lib/python3.4/dist-packages/pandas_datareader-0.2.1-py3.4.egg/pandas_datareader/__init__.py", line 3, in <module>
    from .data import (get_components_yahoo, get_data_famafrench, get_data_google, get_data_yahoo,
  File "/usr/local/lib/python3.4/dist-packages/pandas_datareader-0.2.1-py3.4.egg/pandas_datareader/data.py", line 7, in <module>
    from pandas_datareader.google.daily import GoogleDailyReader
  File "/usr/local/lib/python3.4/dist-packages/pandas_datareader-0.2.1-py3.4.egg/pandas_datareader/google/daily.py", line 1, in <module>
    from pandas_datareader.base import _DailyBaseReader
  File "/usr/local/lib/python3.4/dist-packages/pandas_datareader-0.2.1-py3.4.egg/pandas_datareader/base.py", line 9, in <module>
    from pandas import to_datetime
ImportError: cannot import name 'to_datetime'

----------
components: IDLE
messages: 257792
nosy: davidjackson1955
priority: normal
severity: normal
status: open
title: Unable to run scripts: idle3 -r script.py
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan  8 23:38:16 2016
From: report at bugs.python.org (YoungBoy)
Date: Sat, 09 Jan 2016 04:38:16 +0000
Subject: [New-bugs-announce] [issue26055] sys.argv[0] is the python file,
 not ""
Message-ID: <1452314296.6.0.563314730517.issue26055@psf.upfronthosting.co.za>


New submission from YoungBoy:

python tutorial 2.1.1
You can access this list by executing import sys. The length of the list is at least one; when no script and no arguments are given, sys.argv[0] is an empty string. 

but, when i try it, the sys.argv[0]is the filename,not empty string.

----------
assignee: docs at python
components: Documentation
messages: 257795
nosy: Wei, docs at python
priority: normal
severity: normal
status: open
title: sys.argv[0] is the python file, not ""
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan  9 03:22:39 2016
From: report at bugs.python.org (Amandeep Singh Sohal)
Date: Sat, 09 Jan 2016 08:22:39 +0000
Subject: [New-bugs-announce] [issue26056] installation failure
Message-ID: <1452327759.39.0.705157588806.issue26056@psf.upfronthosting.co.za>


New submission from Amandeep Singh Sohal:

when i trying to install the python 3.5.1. It gives a error "window 7 service pack 1 and all applicable updates are required to install python 3.5.1". here i am also uploading the log file of installation.

----------
components: Installation
files: Python 3.5.1 (32-bit)_20160109133257.log
messages: 257801
nosy: Amandeep Singh Sohal
priority: normal
severity: normal
status: open
title: installation failure
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file41540/Python 3.5.1 (32-bit)_20160109133257.log

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

From report at bugs.python.org  Sat Jan  9 03:41:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Jan 2016 08:41:41 +0000
Subject: [New-bugs-announce] [issue26057] Avoid nonneeded use of
 PyUnicode_FromObject()
Message-ID: <1452328901.15.0.65828251852.issue26057@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In Python 2 PyUnicode_FromObject() was used for coercing 8-bit strings to unicode by decoding them with the default encoding. But in Python 3 there is no such coercing. The effect of PyUnicode_FromObject() in Python 3 is ensuring that the argument is a string and convert an instance of str subtype to exact str. The latter often is just a waste of memory and time, since resulted string is used only for retrieving UTF-8 representation or raw data. 

Proposed patch makes following things:

1. Avoids unneeded copying of string's content.
2. Avoids raising some unneeded exceptions.
3. Gets rid of unneeded incref/decref.
4. Makes some error messages more correct or informative.
5. Converts runtime checks PyBytes_Check() for results of string encoding to asserts.

Example of performance gain:

Unpatched:
$ ./python -m timeit -s "a = 'a'*100; b = 'b'*1000" -- "a in b"
1000000 loops, best of 3: 0.404 usec per loop
$ ./python -m timeit -s "class S(str): pass" -s "a = S('a'*100); b = S('b'*1000)" -- "a in b"
1000000 loops, best of 3: 0.723 usec per loop

Patched:
$ ./python -m timeit -s "a = 'a'*100; b = 'b'*1000" -- "a in b"
1000000 loops, best of 3: 0.383 usec per loop
$ ./python -m timeit -s "class S(str): pass" -s "a = S('a'*100); b = S('b'*1000)" -- "a in b"
1000000 loops, best of 3: 0.387 usec per loop

----------
components: Interpreter Core
files: no_unicode_copy.patch
keywords: patch
messages: 257806
nosy: haypo, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid nonneeded use of PyUnicode_FromObject()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41541/no_unicode_copy.patch

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

From report at bugs.python.org  Sat Jan  9 04:30:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Jan 2016 09:30:48 +0000
Subject: [New-bugs-announce] [issue26058] Add dict.__version__ read-only
 property
Message-ID: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch implements the following PEP currently discussed on python-ideas:
https://faster-cpython.readthedocs.org/pep_dict_version.html#pep-dict-version

----------
files: dict_version.patch
keywords: patch
messages: 257809
nosy: haypo
priority: normal
severity: normal
status: open
title: Add dict.__version__ read-only property
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41542/dict_version.patch

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

From report at bugs.python.org  Sat Jan  9 04:43:43 2016
From: report at bugs.python.org (Ramin Farajpour Cami)
Date: Sat, 09 Jan 2016 09:43:43 +0000
Subject: [New-bugs-announce] [issue26059] Integer Overflow
Message-ID: <1452332623.28.0.0160182788623.issue26059@psf.upfronthosting.co.za>


New submission from Ramin Farajpour Cami:

this work on python 2.7.10 and 2.7.11 crash,

C:\Users\RaminFP>cdb -g python C:\Users\RaminFP\Desktop\1.py

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: python C:\Users\RaminFP\Desktop\1.py
Symbol search path is: srv*c:\pubsymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 1d000000 1d00a000   python.exe
ModLoad: 76fe0000 77159000   ntdll.dll
ModLoad: 76ac0000 76bb0000   C:\Windows\SysWOW64\KERNEL32.DLL
ModLoad: 74e30000 74fa6000   C:\Windows\SysWOW64\KERNELBASE.dll
ModLoad: 1e000000 1e264000   C:\Windows\SysWOW64\python27.dll
ModLoad: 71a10000 71ab3000   C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9158_none_5091b51ebcb97cdc\MSVCR90.dll
ModLoad: 748f0000 74a30000   C:\Windows\SysWOW64\USER32.dll
ModLoad: 747a0000 748ed000   C:\Windows\SysWOW64\GDI32.dll
ModLoad: 763e0000 7645b000   C:\Windows\SysWOW64\ADVAPI32.dll
ModLoad: 74bd0000 74c8e000   C:\Windows\SysWOW64\msvcrt.dll
ModLoad: 76bd0000 76c13000   C:\Windows\SysWOW64\sechost.dll
ModLoad: 76c30000 76cdc000   C:\Windows\SysWOW64\RPCRT4.dll
ModLoad: 740f0000 7410e000   C:\Windows\SysWOW64\SspiCli.dll
ModLoad: 740e0000 740ea000   C:\Windows\SysWOW64\CRYPTBASE.dll
ModLoad: 74080000 740d9000   C:\Windows\SysWOW64\bcryptPrimitives.dll
ModLoad: 74fb0000 7636f000   C:\Windows\SysWOW64\SHELL32.dll
ModLoad: 742c0000 7479d000   C:\Windows\SysWOW64\windows.storage.dll
ModLoad: 76900000 76aba000   C:\Windows\SysWOW64\combase.dll
ModLoad: 74de0000 74e24000   C:\Windows\SysWOW64\shlwapi.dll
ModLoad: 767c0000 767cc000   C:\Windows\SysWOW64\kernel.appcore.dll
ModLoad: 76d40000 76dcd000   C:\Windows\SysWOW64\shcore.dll
ModLoad: 767d0000 76814000   C:\Windows\SysWOW64\powrprof.dll
ModLoad: 76bc0000 76bcf000   C:\Windows\SysWOW64\profapi.dll
ModLoad: 76670000 7669b000   C:\Windows\SysWOW64\IMM32.DLL
ModLoad: 766a0000 767c0000   C:\Windows\SysWOW64\MSCTF.dll
(13a4.1030): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=02555630 ebx=5708ac94 ecx=00003c7a edx=00000000 esi=02546448 edi=57091000
eip=71a4ae7a esp=0028fc98 ebp=0028fca0 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
MSVCR90!memcpy+0x5a:
71a4ae7a f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
0:000> r
eax=02555630 ebx=5708ac94 ecx=00003c7a edx=00000000 esi=02546448 edi=57091000
eip=71a4ae7a esp=0028fc98 ebp=0028fca0 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
MSVCR90!memcpy+0x5a:
71a4ae7a f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
0:000> db esi
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\SysWOW64\python27.dll -
02546448  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
02546458  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
02546468  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
02546478  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
02546488  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
02546498  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
025464a8  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
025464b8  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
0:000> db edi
57091000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57091010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57091020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57091030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57091040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57091050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57091060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57091070  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000>

----------
components: ctypes
files: 1.py
messages: 257812
nosy: Ramin Farajpour Cami
priority: normal
severity: normal
status: open
title: Integer Overflow
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file41543/1.py

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

From report at bugs.python.org  Sat Jan  9 07:56:11 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Jan 2016 12:56:11 +0000
Subject: [New-bugs-announce] [issue26060] Class __dict__ iteration order
 changing due to type instance key-sharing
Message-ID: <1452344171.87.0.895462140972.issue26060@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Dave Beazley found some odd behaviour in Python 3.4.1+, where the order of the keys in a class dictionary can be changed by assigning a new value to an existing key: https://gist.github.com/dabeaz/617a5b0542d57e003433

Dave's original reproducer showed a case where iterating over class attributes replacing some of them with new values worked correctly as a class decorator on a normal instance of type, but was unreliable when the same operation was called from a metaclass __new__ or __init__ method.

Further investigation showed that it wasn't the timing of the assignment that mattered, but rather the use of a subclass of type rather than type itself as the metaclass.

Checking between 3.4.0 and 3.4.1 with hg bisect using the simpler attached script as the reproducer identified the enabling of key sharing with subclass instances in #20637 as the apparent culprit.

My current theory is that from 3.3.0 to 3.4.0, keys weren't being shared between instances of type and instances of type subclasses at all, and changing that in 3.4.1 broke a subtle assumption somewhere in type_new.

----------
files: ns_reordering_bug.py
messages: 257824
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Class __dict__ iteration order changing due to type instance key-sharing
Added file: http://bugs.python.org/file41550/ns_reordering_bug.py

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

From report at bugs.python.org  Sat Jan  9 09:12:01 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 09 Jan 2016 14:12:01 +0000
Subject: [New-bugs-announce] [issue26061] logging LogRecordFactory allow
 kwargs
Message-ID: <1452348721.62.0.0659441609169.issue26061@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

The logging LogRecord factory receives kwargs. However because _log and makeRecord functions in the Logger class don't support kwargs we can't actually pass additional positional arguments to LogRecord.

A use case for this is attached.

I had made a patch to fix this by changing _log and makeRecord to accept kwargs and pass them.

----------
components: Library (Lib)
files: usecase.py
messages: 257831
nosy: palaviv, vinay.sajip
priority: normal
severity: normal
status: open
title: logging LogRecordFactory allow kwargs
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file41553/usecase.py

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

From report at bugs.python.org  Sat Jan  9 09:25:36 2016
From: report at bugs.python.org (=?utf-8?q?Christoph_B=C3=B6ddeker?=)
Date: Sat, 09 Jan 2016 14:25:36 +0000
Subject: [New-bugs-announce] [issue26062] IPython4 bash magic ! with {} does
 not work with Python 3.5.1
Message-ID: <1452349536.45.0.55048690622.issue26062@psf.upfronthosting.co.za>


New submission from Christoph B?ddeker:

Hello, 

I found a wrong behavior with IPython 4 in combination with Python 3.5.1. 

Normally in a command like "In [2]: !echo {a}" everything inside {} is interpreted with python and inserted to executed the line with bash. After I done a upgrade tp Python 3.5.1 this wasn't working. After a downgrade (3.5.0) it was working.

In the bottom is an example, where "In [2]: !echo {a}" are the important lines.
In [2]: !echo {a}
 * Python 3.5.0 -> 3
 * Python 3.5.1 -> {a}

Best regards
Christoph 

-----------------------------------------------------------------------
$ ipython
Python 3.5.1 |Anaconda 2.4.0 (64-bit)| (default, Dec  7 2015, 11:16:01) 
Type "copyright", "credits" or "license" for more information.

IPython 4.0.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: a = 3

In [2]: !echo {a}
{a}

In [3]: 
-----------------------------------------------------------------------
conda install python=3.5.0
Fetching package metadata: ....
Solving package specifications: ................
Package plan for installation in environment /opt/anaconda3:

The following packages will be DOWNGRADED:

    python: 3.5.1-0 --> 3.5.0-1

Proceed ([y]/n)? y

Unlinking packages ...
[      COMPLETE      ]|###################################################| 100%
Linking packages ...
[      COMPLETE      ]|###################################################| 100%

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

$ ipython
Python 3.5.0 |Anaconda 2.4.0 (64-bit)| (default, Oct 19 2015, 21:57:25) 
Type "copyright", "credits" or "license" for more information.

IPython 4.0.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: a = 3

In [2]: !echo {a}
3

In [3]:

----------
messages: 257833
nosy: Christoph B?ddeker
priority: normal
severity: normal
status: open
title: IPython4 bash magic ! with {} does not work with Python 3.5.1
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan  9 09:30:37 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 09 Jan 2016 14:30:37 +0000
Subject: [New-bugs-announce] [issue26063] Update copyright in the devguide
Message-ID: <1452349837.88.0.575893993486.issue26063@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The copyright in the devguide needs to be updated for 2016.

----------
components: Devguide
messages: 257834
nosy: ezio.melotti, willingc
priority: normal
severity: normal
stage: needs patch
status: open
title: Update copyright in the devguide
type: enhancement

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

From report at bugs.python.org  Sat Jan  9 13:25:26 2016
From: report at bugs.python.org (Sagar Kar)
Date: Sat, 09 Jan 2016 18:25:26 +0000
Subject: [New-bugs-announce] [issue26064] directory is getting separated
Message-ID: <1452363926.86.0.702790160127.issue26064@psf.upfronthosting.co.za>


New submission from Sagar Kar:

In [108]: os.mkdir('newdir') # make new dir
In [140]: p = os.path.abspath('newdir')

In [141]: p
Out[141]: '/media/sagarkar10/sdrive/programing/python/SciPy/scipy-notebook/newdir'

## here 'newdir' is also a directory with a file inside

In [143]: os.path.dirname(p)
Out[143]: '/media/sagarkar10/sdrive/programing/python/SciPy/scipy-notebook'

## but os.path.dirname() dont show it under directory it treats as if its a file and till the last '/' is the directory
and also 

In [145]: os.path.basename(p)
Out[145]: 'newdir'

## basename shows it

----------
components: Extension Modules
messages: 257849
nosy: sagarkar10
priority: normal
severity: normal
status: open
title: directory is getting separated
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan  9 14:15:02 2016
From: report at bugs.python.org (Laurent Dufrechou)
Date: Sat, 09 Jan 2016 19:15:02 +0000
Subject: [New-bugs-announce] [issue26065] python embedded 3.5 amd64 crash
 when using venv
Message-ID: <1452366902.23.0.484622853391.issue26065@psf.upfronthosting.co.za>


New submission from Laurent Dufrechou:

Install python-3.5.1-embed-amd64 to c:\dev\python-3.5.1-embed-amd64
Open terminal window:
cd c:\dev\python-3.5.1-embed-amd64
python -m venv c:\dev\myenv

-> crash
Error: Command '['C:\\dev\\myenv\\Scripts\\python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 3221226505

Using debugger (VS2015) shows error:
Exception non g?r?e ? 0x00007FFDA1D05A4E (ucrtbase.dll) dans python.exe?
And stopping debugger leave this log:
C:\dev\python-3.5.1-embed-amd64>python -m venv C:\dev\python35_x64_rtquickreport
Traceback (most recent call last):
  File "runpy.py", line 170, in _run_module_as_main
  File "runpy.py", line 85, in _run_code
  File "venv\__main__.py", line 6, in <module>
  File "venv\__init__.py", line 442, in main
  File "venv\__init__.py", line 85, in create
  File "venv\__init__.py", line 257, in _setup_pip
  File "subprocess.py", line 629, in check_output
  File "subprocess.py", line 698, in run
  File "subprocess.py", line 1055, in communicate
KeyboardInterrupt

----------
components: Windows
messages: 257855
nosy: Laurent Dufrechou, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python embedded 3.5 amd64 crash when using venv
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan  9 15:41:56 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 09 Jan 2016 20:41:56 +0000
Subject: [New-bugs-announce] [issue26066] Language on the "Cryptographic
 Services" is out of date
Message-ID: <1452372116.19.0.623367169611.issue26066@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://docs.python.org/2/library/crypto.html
https://docs.python.org/3/library/crypto.html

This language has a number of issues:
- Crypto isn't just for "Hardcore cypherpunks" anymore, it's a necessary component of a great many software projects
- PyCrypto isn't maintained by A.M. Kuchling any longer
- (IMO) it's no longer the recommended library for cryptography in Python
- The page should probably also point people towards the ssl module.

----------
assignee: docs at python
components: Documentation
messages: 257857
nosy: alex, docs at python
priority: normal
severity: normal
status: open
title: Language on the "Cryptographic Services" is out of date
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jan  9 16:10:35 2016
From: report at bugs.python.org (Dinesh Wijekoon)
Date: Sat, 09 Jan 2016 21:10:35 +0000
Subject: [New-bugs-announce] [issue26067] test_shutil fails when gid name is
 missing
Message-ID: <1452373835.73.0.278108988814.issue26067@psf.upfronthosting.co.za>


New submission from Dinesh Wijekoon:

./python.exe -m test -j3 -v test_shutil

The above test fails when id name is missing. The fail message is 
group = grp.getgrgid(gid)[0]
KeyError: 'getgrgid(): gid not found: 203135016'

Following is the results from console "id" command, when the failure happens. 

uid=1336551206(athukora) gid=203135016 groups=203135016,402(com.apple.sharepoint.group.2),12(everyone),62(netaccounts),80(admin),401(com.apple.sharepoint.group.1),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),398(com.apple.access_screensharing),399(com.apple.access_ssh)

And again when I change user to sudo the "id" command returns the following and test get passed.
uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),2(kmem),3(sys),4(tty),5(operator),8(procview),9(procmod),12(everyone),20(staff),29(certusers),61(localaccounts),80(admin),401(com.apple.sharepoint.group.1),402(com.apple.sharepoint.group.2),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),398(com.apple.access_screensharing),399(com.apple.access_ssh)

PS:

We tried to debug this a bit and found the bug is possibly in Modules/grpmodule.c, may be at method grp_getgrall_impl. Adding "PyString_AsString(v);" before if command " PyList_Append(d, v) != 0" will fix the issue in test. But we have no idea how its working with this change.

----------
components: Extension Modules
messages: 257858
nosy: Dinesh Wijekoon, ezio.melotti
priority: normal
severity: normal
status: open
title: test_shutil fails when gid name is missing
versions: Python 3.6

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

From report at bugs.python.org  Sat Jan  9 16:18:18 2016
From: report at bugs.python.org (ThiefMaster)
Date: Sat, 09 Jan 2016 21:18:18 +0000
Subject: [New-bugs-announce] [issue26068] re.compile() repr end quote
 truncated
Message-ID: <1452374298.65.0.166509982693.issue26068@psf.upfronthosting.co.za>


New submission from ThiefMaster:

```
Python 3.4.3 (default, Jan  5 2016, 23:13:10)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> for n in range(198, 201):
...     print(re.compile('x' * n))
...
re.compile('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')
re.compile('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
re.compile('xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
```

The closing quote in the repr goes away once the regex exceeds a certain length. This smells like an off-by-one somewhere that results in the last character to be lost. In any case, it's pretty ugly since the repr clearly pretends to be executable Python code, which is not the case anymore with this quote missing.

----------
components: Regular Expressions
messages: 257860
nosy: ThiefMaster, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.compile() repr end quote truncated
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan  9 19:20:26 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Jan 2016 00:20:26 +0000
Subject: [New-bugs-announce] [issue26069] Remove the Deprecated API in trace
 module
Message-ID: <1452385226.89.0.6584761467.issue26069@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

A number of old methods in trace module were deprecated in issue10371. They should be removed in 3.6 release.

----------
components: Library (Lib)
messages: 257877
nosy: belopolsky, orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove the Deprecated API in trace module
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Jan  9 19:59:35 2016
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 10 Jan 2016 00:59:35 +0000
Subject: [New-bugs-announce] [issue26070] Launcher fails to find in-place
 built binaries from earlier Python versions
Message-ID: <1452387575.38.0.184373942558.issue26070@psf.upfronthosting.co.za>


New submission from Mark Hammond:

The launcher was recently updated to look in PCBuild/win32 to support the win32 binaries being built in this directory instead of the top-level PCBuild directory. However, when this new launcher tries to find a binary for, say, Python 2.7, it doesn't find an executable because it's directly in PCBuild, not one of the win32 or amd64 sub-directories.

Note this only impacts Python when it is built in the directory - it doesn't impact installed versions.

The fix I came up with is to continue looking in PCBuild if it isn't found in one of those dirs.

Vinay, what do you think?

----------
components: Windows
files: launcher.patch
keywords: patch
messages: 257878
nosy: mhammond, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: normal
severity: normal
status: open
title: Launcher fails to find in-place built binaries from earlier Python versions
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41560/launcher.patch

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

From report at bugs.python.org  Sat Jan  9 20:06:48 2016
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 10 Jan 2016 01:06:48 +0000
Subject: [New-bugs-announce] [issue26071] bdist_wininst created binaries
 fail to start and find 32bit Pythons
Message-ID: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za>


New submission from Mark Hammond:

Binaries created by bdist_wininst fail on 3.5+ for 2 reasons:

* The built binary links against the DLL version of the CRT. This means the binary will typically fail to start as the CRT DLL isn't found.

* When looking for 32bit Python versions, it fails to take the recent "-32" change for the registry key, so it tells you no Python is installed.

This patch:
* Uses the static CRT, which IIRC, was the case in previous Python versions.
* Changes directory to the directory with pythonxx.dll before attempting to loadlibrary it - this allows the loadlibrary to succeed as the CRT DLL in that directory is found.
* Appends "-32" to registry keys on 32bit builds.

With these patches I can successfully get a pywin32 build working and installing.

Steve (or anyone), what do you think?

(Note that the attached patch does *not* include a newly built wininst-14.exe, but that would obviously need to be updated before checking in.)

----------
components: Windows
files: bdist.patch
keywords: patch
messages: 257879
nosy: mhammond, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: bdist_wininst created binaries fail to start and find 32bit Pythons
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41561/bdist.patch

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

From report at bugs.python.org  Sun Jan 10 00:16:24 2016
From: report at bugs.python.org (Antony Lee)
Date: Sun, 10 Jan 2016 05:16:24 +0000
Subject: [New-bugs-announce] [issue26072] pdb fails to access variables
 closed over
Message-ID: <1452402984.12.0.000738362264887.issue26072@psf.upfronthosting.co.za>


New submission from Antony Lee:

Consider the following example:

    def f(x=1):
        def g():
            y = 2
            raise Exception
        g()

    f()

$ python -mpdb -ccontinue example.py
<... traceback ...>
> /tmp/example.py(4)g()
-> raise Exception
(Pdb) p x
##### this can be worked around using "up"
*** NameError: name 'x' is not defined
(Pdb) p y
2
(Pdb) p (lambda: y)()
##### this is more awkward to work around, e.g. (lambda *, y=y: y)()
*** NameError: name 'y' is not defined

Use case: I wan to pass a lambda to a numerical optimizer, but the optimizer fails using the default starting point.  Within pdb, I'd like to pass a different starting point but the same lambda, to see whether this helps.

----------
components: Library (Lib)
messages: 257888
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: pdb fails to access variables closed over
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Jan 10 02:49:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Jan 2016 07:49:53 +0000
Subject: [New-bugs-announce] [issue26073] Update the list of magic numbers
 in launcher
Message-ID: <1452412193.99.0.751958856998.issue26073@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a list of magic numbers in PC/launcher.c for mapping magic number to Python version. But it ends on 3.3 (and even only on 3.3a0). Proposed patch updates the list (by values taken from Lib/importlib/_bootstrap_external.py).

----------
components: Windows
files: launcher_magic_numbers.patch
keywords: patch
messages: 257896
nosy: brett.cannon, eric.snow, ncoghlan, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Update the list of magic numbers in launcher
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41564/launcher_magic_numbers.patch

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

From report at bugs.python.org  Sun Jan 10 05:52:00 2016
From: report at bugs.python.org (Blaize Rhodes)
Date: Sun, 10 Jan 2016 10:52:00 +0000
Subject: [New-bugs-announce] [issue26074] Add a method to pip..
 pip.require("package_name")
Message-ID: <1452423120.4.0.471254538905.issue26074@psf.upfronthosting.co.za>


New submission from Blaize Rhodes:

The idea is to add a method to pip that tries to import a package and if the import fails then try to download and install the package handling the UI.

Yes, you can put the package as a dependency in your pip config for 
your code.  This is intended for the case when you have a bunch of 
python tools/libs in some shared repository in your organization.
People check the code out and expect it to run but it has third party 
dependencies.  There is no install step for your code, per se.  Furthermore the people using your code don't know enough about python to install things themselves.

Proposed syntax is:

import pip
pip.require("foo")

If you search online for pip.main you'll see a whole bunch of hall-baked brittle solutions to this problem that look like this:

try:
    import foo
except ImportError:
     pip.main("install", "foo")

----------
files: require.py
messages: 257903
nosy: Blaize Rhodes
priority: normal
severity: normal
status: open
title: Add a method to pip.. pip.require("package_name")
type: enhancement
Added file: http://bugs.python.org/file41565/require.py

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

From report at bugs.python.org  Sun Jan 10 07:57:34 2016
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sun, 10 Jan 2016 12:57:34 +0000
Subject: [New-bugs-announce] [issue26075] typing.Union unifies types too
 broadly
Message-ID: <1452430654.78.0.244173734721.issue26075@psf.upfronthosting.co.za>


New submission from Alex Gr?nholm:

>>> from typing import Union, Iterable
>>> Union[str, Iterable[int]]
typing.Iterable[int]

The union loses the "str" parameter because issubclass(str, collections.abc.Iterable) returns True and the check completely disregards generics.

Guido mentioned that issubclass() support for generic types should be going away. In the mean time, maybe the subclass check in typing.GenericMeta should be modified not to do it with types from Typing, but how can we accurately identify them?

----------
components: Extension Modules
messages: 257910
nosy: alex.gronholm, gvanrossum, lukasz.langa
priority: normal
severity: normal
status: open
title: typing.Union unifies types too broadly
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Jan 10 14:00:00 2016
From: report at bugs.python.org (Oren Milman)
Date: Sun, 10 Jan 2016 19:00:00 +0000
Subject: [New-bugs-announce] [issue26076] redundant checks in tok_get in
 Parser\tokenizer.c
Message-ID: <1452452400.02.0.853203557937.issue26076@psf.upfronthosting.co.za>


New submission from Oren Milman:

In Parser\tokenizer.c, in tok_get, in the identification of a potential NUMBER token, in case the token starts with a '0', the next char of the token is retrieved, followed by two redundant checks:
if (c == '.')
    goto fraction;
if (c == 'j' || c == 'J')
    goto imaginary;

These two are redundant, because they check for the case of a token starting with '0.' or '0j', but even without them, the flow in either of these would reach the code after the /* maybe old-style octal; c is first char of it */ comment.
This code (after consuming all zeros and all decimal digits) would again perform those exact two checks, and handle them exactly the same.

My proposal is simply to remove the first two checks.

I have attached the patched tokenizer.c (the redundant checks are just commented out).

----------
components: Interpreter Core
files: tokenizer.c.withoutRedundantChecks.c
messages: 257927
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: redundant checks in tok_get in Parser\tokenizer.c
type: enhancement
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/file41572/tokenizer.c.withoutRedundantChecks.c

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

From report at bugs.python.org  Sun Jan 10 15:45:56 2016
From: report at bugs.python.org (Filip Haglund)
Date: Sun, 10 Jan 2016 20:45:56 +0000
Subject: [New-bugs-announce] [issue26077] Make slicing of immutable
 structures return a view instead of a copy
Message-ID: <1452458756.3.0.749991798075.issue26077@psf.upfronthosting.co.za>


New submission from Filip Haglund:

Slicing tuples returns a copy, which is O(n) time. This could be O(1) since tuples are immutable, by just pointing to the same data.

This probably applies to other immutable structures as well, such as strings.

----------
components: Interpreter Core
messages: 257937
nosy: Filip Haglund
priority: normal
severity: normal
status: open
title: Make slicing of immutable structures return a view instead of a copy
type: performance
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/issue26077>
_______________________________________

From report at bugs.python.org  Sun Jan 10 16:24:42 2016
From: report at bugs.python.org (Edward)
Date: Sun, 10 Jan 2016 21:24:42 +0000
Subject: [New-bugs-announce] [issue26078] Python launcher options enhancement
Message-ID: <1452461082.93.0.268338836984.issue26078@psf.upfronthosting.co.za>


New submission from Edward:

The Python launcher in Windows is a neat tool for running multiple versions of Python 2 and Python 3 at different times. It allows as options the ability to specify the latest version of either Python 2 or Python 3 defaulting to the 64-bit version if both exist, or a specific 32-bit or 64-bit version of Python 2 or Python 3. What is missing is the ability to specify the latest 32-bit version of Python 2 or Python 3. The equivalent syntax would be '-2-32' or '-3-32'. Is there some reason why this option has been disallowed ? If not I would like to see this logical enhancement to the Python launcher in Windows added to its functionality.

----------
components: Windows
messages: 257940
nosy: edienerlee, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python launcher options enhancement
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Jan 11 08:34:40 2016
From: report at bugs.python.org (Bjoern Thiel)
Date: Mon, 11 Jan 2016 13:34:40 +0000
Subject: [New-bugs-announce] [issue26079] Build with Visual Studio 2015
 using PlatformToolset=v120
Message-ID: <1452519280.93.0.432725713668.issue26079@psf.upfronthosting.co.za>


New submission from Bjoern Thiel:

Fixing the build output folder for tix-8.4.3.6.

----------
components: Build
files: build.patch
keywords: patch
messages: 257956
nosy: bjoernthiel
priority: normal
severity: normal
status: open
title: Build with Visual Studio 2015 using PlatformToolset=v120
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file41578/build.patch

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

From report at bugs.python.org  Mon Jan 11 12:09:29 2016
From: report at bugs.python.org (W. Trevor King)
Date: Mon, 11 Jan 2016 17:09:29 +0000
Subject: [New-bugs-announce] [issue26080] "abandonned" -> "abandoned" in PEP
 510's https://hg.python.org/peps/rev/b463c740990c
Message-ID: <1452532169.85.0.59348007279.issue26080@psf.upfronthosting.co.za>


New submission from W. Trevor King:

In the recently-landed [1],

  There was also the Unladen Swallow project, but it was abandonned in 2011.

Should have used ?abandoned? instead of ?abandonned?.

[1]: https://hg.python.org/peps/rev/b463c740990c
     changeset: 6155:b463c740990c
     user: Victor Stinner <victor.stinner< at >gmail.com>
     date: Sun Jan 10 14:58:17 2016 +0100
     summary: PEP 510: rationale for static optimize vs JIT compiler
     http://permalink.gmane.org/gmane.comp.python.cvs/114604

----------
assignee: docs at python
components: Documentation
messages: 257974
nosy: docs at python, labrat
priority: normal
severity: normal
status: open
title: "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c
type: enhancement

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

From report at bugs.python.org  Mon Jan 11 12:23:42 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 11 Jan 2016 17:23:42 +0000
Subject: [New-bugs-announce] [issue26081] Implement asyncio Future in C to
 improve performance
Message-ID: <1452533022.97.0.443242974791.issue26081@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Some info on this: https://github.com/python/asyncio/issues/282#issuecomment-155957235  Long story short, Future implemented in C can speedup some asyncio code up to 25%.

I'm attaching a patch with a WIP implementation.  There are some failing assertions deep in GC, which I need to track down.  'Future.remove_done_callback' still needs to be properly implemented.

----------
assignee: yselivanov
components: asyncio
files: futures.patch
keywords: patch
messages: 257984
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement asyncio Future in C to improve performance
type: performance
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41579/futures.patch

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

From report at bugs.python.org  Mon Jan 11 14:23:57 2016
From: report at bugs.python.org (Chiu-Hsiang Hsu)
Date: Mon, 11 Jan 2016 19:23:57 +0000
Subject: [New-bugs-announce] [issue26082] functools.lru_cache user specified
 cachedict support
Message-ID: <1452540237.19.0.595360503064.issue26082@psf.upfronthosting.co.za>


New submission from Chiu-Hsiang Hsu:

Currently, lru_cache will automatically construct a Python dictionary in the function as cachedict. IMHO, it will be much more flexible to let users specified their cachedict, so they can use any kind of dict-like calss as their cachedict. Thus, users can use any dictionary implementation and save result in any form they want.

for example :

use OrderedDict

.. code-block:: python

    from functools import lru_cache
    from collections import OrderedDict

    @lru_cache(maxsize=None, cache=OrderedDict())
    def func(*args, **kwargs):
        pass


save by pickle

.. code-block:: python

    import os
    import pickle
    from functools import lru_cache

    filename = "cache.pickle"
    cache = {}

    def load_cache():
        global cache
        if os.path.isfile(filename):
            with open(filename, "rb") as f:
                cache = pickle.load(f)

    def store_cache():
        with open(filename, "wb") as f:
            pickle.dump(cache, f)

    load_cache()

    @lru_cache(maxsize=None, cache=cache)
    def func(*args, **kwargs):
        pass

----------
components: Library (Lib)
files: functools.lru_cache-user-specified-cachedict.patch
keywords: patch
messages: 258001
nosy: wdv4758h
priority: normal
severity: normal
status: open
title: functools.lru_cache user specified cachedict support
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41584/functools.lru_cache-user-specified-cachedict.patch

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

From report at bugs.python.org  Mon Jan 11 15:43:15 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Mon, 11 Jan 2016 20:43:15 +0000
Subject: [New-bugs-announce] [issue26083] ValueError: insecure string pickle
 in subprocess.Popen on Python 2
Message-ID: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

Originally reported at [1] and [2].

On Mac OS X, read() on pipes may return only the first 512 bytes. The remaining bytes are not read into `data` in _execute_child(). There's a patch proposal at [3]. I didn't test it myself because I can't reproduce the broken situation.

[1] https://github.com/rg3/youtube-dl/issues/6840
[2] https://github.com/matplotlib/matplotlib/issues/5386
[3] https://github.com/matplotlib/matplotlib/issues/5386#issuecomment-161111817

----------
components: Library (Lib), Macintosh
messages: 258011
nosy: Chi Hsuan Yen, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: ValueError: insecure string pickle in subprocess.Popen on Python 2
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 11 15:48:45 2016
From: report at bugs.python.org (Tom Anderl)
Date: Mon, 11 Jan 2016 20:48:45 +0000
Subject: [New-bugs-announce] [issue26084] HTMLParser mishandles last
 attribute in self-closing tag
Message-ID: <1452545325.06.0.546064798317.issue26084@psf.upfronthosting.co.za>


New submission from Tom Anderl:

When the HTMLParser encounters a start tag element that includes:
  1. an unquoted attribute as the final attribute 
  2. an optional '/' character marking the start tag as self-closing
  3. no space between the final attribute and the '/' character

the '/' character gets attached to the attribute value and the element is interpreted as not self-closing.  This can be illustrated with the following:

===============================================================================

import HTMLParser

# Begin Monkeypatch
#import re
#HTMLParser.attrfind = re.compile(
#    r'((?<=[\'"\s/])[^\s/>][^\s/=>]*)(\s*=+\s*'
#    r'(\'[^\']*\'|"[^"]*"|(?![\'"])[^/>\s]*))?(?:\s|/(?!>))*')
# End Monkeypatch

class MyHTMLParser(HTMLParser.HTMLParser):
    def handle_starttag(self, tag, attrs):
        print('got starttag: {0} with attributes {1}'.format(tag, attrs))

    def handle_endtag(self, tag):
        print('got endtag: {0}'.format(tag))

MyHTMLParser().feed('<img height=1.0 width=2.0/>')

==============================================================================

Running the above code yields the output:

    got starttag: img with attributes [('height', '1.0'), ('width', '2.0/')]

Note the trailing '/' on the 'width' attribute.  If I uncomment the monkey patch, the script then yields:

    got starttag: img with attributes [('height', '1.0'), ('width', '2.0')]
    got endtag: img

Note that the trailing '/' is gone, and an endtag event was generated.

----------
components: Library (Lib)
messages: 258013
nosy: Tom Anderl
priority: normal
severity: normal
status: open
title: HTMLParser mishandles last attribute in self-closing tag
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 11 16:12:36 2016
From: report at bugs.python.org (fresh_nick)
Date: Mon, 11 Jan 2016 21:12:36 +0000
Subject: [New-bugs-announce] [issue26085] Tkinter spoils the input text
Message-ID: <1452546756.92.0.853539899898.issue26085@psf.upfronthosting.co.za>


New submission from fresh_nick:

Hello, I have Python 3.4.3 and Tk/Tcl 8.5 (built in Python; reported by tk.TclVersion and tk.TkVersion). When I assign printing 'This works' to a hotkey, the program prints 'This worsk'. After pressing the hotkey again, 'worsk' is replaced with 'works', but when the hotkey is pressed repeatedly, we can see 'worsk' sometimes (see the attachment).

Have a nice day.

----------
components: Tkinter
files: 2016-01-11--1452545267_1920x1080_scrot.png
messages: 258019
nosy: fresh_nick
priority: normal
severity: normal
status: open
title: Tkinter spoils the input text
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41585/2016-01-11--1452545267_1920x1080_scrot.png

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

From report at bugs.python.org  Mon Jan 11 16:35:26 2016
From: report at bugs.python.org (Hana Larsen)
Date: Mon, 11 Jan 2016 21:35:26 +0000
Subject: [New-bugs-announce] [issue26086] Bug in standardmodule os
Message-ID: <1452548126.01.0.956593686661.issue26086@psf.upfronthosting.co.za>


New submission from Hana Larsen:

I get a error in the stardard module "os" (I use Python 3.5.1 64bit for Windows 10!)
What is wrong and have someone a patch
See the "os-bug.PNG"-file.

----------
files: os-bug.PNG
messages: 258023
nosy: Johano
priority: normal
severity: normal
status: open
title: Bug in standardmodule os
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file41586/os-bug.PNG

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

From report at bugs.python.org  Mon Jan 11 23:14:31 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 12 Jan 2016 04:14:31 +0000
Subject: [New-bugs-announce] [issue26087] PEP 0373 should be updated
Message-ID: <1452572071.97.0.659652590609.issue26087@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

Current PEP 0373 lists Python 2.7.11 as a future release, and there's no information about Python 2.7.12. Please update it, thanks!

----------
assignee: docs at python
components: Documentation
messages: 258063
nosy: Chi Hsuan Yen, docs at python
priority: normal
severity: normal
status: open
title: PEP 0373 should be updated
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 12 03:14:44 2016
From: report at bugs.python.org (Hana Larsen)
Date: Tue, 12 Jan 2016 08:14:44 +0000
Subject: [New-bugs-announce] [issue26088] re
Message-ID: <5694B5F2.5000806@mail.dk>


New submission from Hana Larsen:

-- 
Hans Larsen Galgebakken S?nder 4-11A 2620 Albertslund Danmark/Danio

----------
messages: 258073
nosy: Johano
priority: normal
severity: normal
status: open
title: re

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

From report at bugs.python.org  Tue Jan 12 04:44:50 2016
From: report at bugs.python.org (Augustin Laville)
Date: Tue, 12 Jan 2016 09:44:50 +0000
Subject: [New-bugs-announce] [issue26089] Duplicated keyword in distutils
 metadata
Message-ID: <1452591890.07.0.0660802423296.issue26089@psf.upfronthosting.co.za>


New submission from Augustin Laville:

The line https://hg.python.org/cpython/file/tip/Lib/distutils/dist.py#l1016 contains the word "licence" twice.

Check only on Python, 3.5 and 3.6, may be in others versions.

----------
components: Distutils
messages: 258091
nosy: Augustin Laville, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Duplicated keyword in distutils metadata
type: resource usage
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jan 12 04:54:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Jan 2016 09:54:14 +0000
Subject: [New-bugs-announce] [issue26090] More correct string truncating in
 PyUnicode_FromFormat()
Message-ID: <1452592454.92.0.0368970992087.issue26090@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The C code often uses %.<number><format> in PyUnicode_FromFormat(). %.200s protects from unlimited output when broken pointer points on random non-null-terminated data. %.200R is used to limit the size of human-readable messages.

In all these case formatted string can look well-formed with short data, but mis-formed (not closed quote, truncated backslash escaping or ? decoded from truncated UTF-8 sequence) with long data.

I propose to make truncating in PyUnicode_FromFormat() more smart.

1. Truncated %R should keep at least one end character (the quote or ">").
2. Truncated output should include "..." or "[...]" as truncating sign.
3. \c, \OOO, \xXX, \uXXXX, and \UXXXXXXXX should not be truncated. It is better to omit these sequences at all (cut the string before them) that output them truncated.
4. Doesn't truncate UTF-8 sequence inside a character for %s.

----------
components: Interpreter Core
messages: 258092
nosy: gvanrossum, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: More correct string truncating in PyUnicode_FromFormat()
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Jan 12 12:59:25 2016
From: report at bugs.python.org (Joseph Pyott)
Date: Tue, 12 Jan 2016 17:59:25 +0000
Subject: [New-bugs-announce] [issue26091] decimal.Decimal(0)**0 throws
 decimal.InvalidOperation
Message-ID: <1452621565.71.0.961155486004.issue26091@psf.upfronthosting.co.za>


Changes by Joseph Pyott <josephpyott at windstream.net>:


----------
components: Extension Modules
files: decimal pow error.py
nosy: Pyottamus
priority: normal
severity: normal
status: open
title: decimal.Decimal(0)**0 throws decimal.InvalidOperation
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41593/decimal pow error.py

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

From report at bugs.python.org  Tue Jan 12 13:20:57 2016
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Tue, 12 Jan 2016 18:20:57 +0000
Subject: [New-bugs-announce] [issue26092] doctest should allow custom
 sys.displayhook
Message-ID: <1452622857.37.0.137754453324.issue26092@psf.upfronthosting.co.za>


New submission from Sergey B Kirpichev:

The purpose of doctest's - verify interactive examples.  But if
your users will use custom displayhook all the time (consider, as
examples CAS like SymPy or https://github.com/skirpichev/omg/) - why
you must show them examples with the builtin's displayhook?

After https://bugs.python.org/issue8048, sys.displayhook can't be
customized for doctest.  I think, that decision was wrong and we
should have a better solution.

PS: In fact, right now this issue can be workarrounded if you instead
override sys.__displayhook__ before doctest call.  But I believe
this "solution" has own problems.

----------
components: Library (Lib)
messages: 258115
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: doctest should allow custom sys.displayhook
type: behavior

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

From report at bugs.python.org  Tue Jan 12 17:33:48 2016
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 12 Jan 2016 22:33:48 +0000
Subject: [New-bugs-announce] [issue26093] __qualname__ different when
 calling generator object w/ functions.partial
Message-ID: <1452638028.1.0.595104762218.issue26093@psf.upfronthosting.co.za>


New submission from Dino Viehland:

import functools
def f():
    def g():
        yield 1
    return g

functools.partial(f())().__qualname__ != f()().__qualname__

The qualified name gets passed in via the interpreter loop with _PyEval_EvalCodeWithName calling PyGen_NewWithQualName.  If a generator object gets called from C then the qualified name gets lost.

It seems like _PyEval_EvalCodeWithName shouldn't exist and the generator code object should be able to get back to its qualified name so subtle differences like this don't happen.

----------
components: Interpreter Core
messages: 258119
nosy: dino.viehland
priority: normal
severity: normal
status: open
title: __qualname__ different when calling generator object w/ functions.partial
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan 12 19:39:59 2016
From: report at bugs.python.org (khyox)
Date: Wed, 13 Jan 2016 00:39:59 +0000
Subject: [New-bugs-announce] [issue26094] ConfigParser.get() doc to be
 updated according to the configparser.py header doc
Message-ID: <1452645599.68.0.959713633048.issue26094@psf.upfronthosting.co.za>


New submission from khyox:

For the sake of clarity, in https://docs.python.org/3.5/library/configparser.html#configparser.ConfigParser the ConfigParser.get() method doc could be properly updated with merging the information written in the header doc of the source file, as found in https://hg.python.org/cpython/file/3.5/Lib/configparser.py

Concretely, this sentence there, "Return a string value for the named option." could be considered quite relevant to be added to the doc of the method, as some packages are (incorrectly) expecting boolean values returned by the ConfigParser.get() method. The reality is that a "True" in the configuration file is returning the string "True" and not the boolean constant True.

To sum up, the suggested update would be:

    def get(self, section, option, *, raw=False, vars=None, fallback=_UNSET):
        """Returns a string value for the named option for a given section.

        If `vars' is provided, it must be a dictionary. The option is looked up
        in `vars' (if provided), `section', and in `DEFAULTSECT' in that order.
        If the key is not found and `fallback' is provided, it is used as
        a fallback value. `None' can be provided as a `fallback' value.

        If interpolation is enabled and the optional argument `raw' is False,
        all interpolations are expanded in the return values.

        Arguments `raw', `vars', and `fallback' are keyword only.

        The section DEFAULT is special.
        """
        (...)

----------
assignee: docs at python
components: Documentation
messages: 258124
nosy: docs at python, khyox
priority: normal
severity: normal
status: open
title: ConfigParser.get() doc to be updated according to the configparser.py header doc
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jan 12 21:16:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 02:16:37 +0000
Subject: [New-bugs-announce] [issue26095] Update porting HOWTO to
 special-case Python 2 code, not Python 3
Message-ID: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As pointed out by http://astrofrog.github.io/blog/2016/01/12/stop-writing-python-4-incompatible-code/, special-casing Python 3 code instead of Python 2 code when writing Python 2/3 code will lead to breakage when Python 3 comes out. There should probably be a note in the porting HOWTO mentioning that you should always special-case Python 2 code and not Python 3 code.

----------
assignee: docs at python
components: Documentation
messages: 258126
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: Update porting HOWTO to special-case Python 2 code, not Python 3

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

From report at bugs.python.org  Tue Jan 12 21:17:53 2016
From: report at bugs.python.org (JitterMan)
Date: Wed, 13 Jan 2016 02:17:53 +0000
Subject: [New-bugs-announce] [issue26096] '*' glob string matches dot files
 in pathlib
Message-ID: <1452651473.17.0.586447787765.issue26096@psf.upfronthosting.co.za>


New submission from JitterMan:

Path('.').glob('*') generates all files and directories in '.' including hidden files (those that begin with '.'). This behavior is inconsistent with the shell and with the old glob module, which only generate hidden files if the glob pattern starts with a '.'.

----------
messages: 258128
nosy: jitterman
priority: normal
severity: normal
status: open
title: '*' glob string matches dot files in pathlib
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 13 06:07:08 2016
From: report at bugs.python.org (=?utf-8?q?Nicolas_=C3=89vrard?=)
Date: Wed, 13 Jan 2016 11:07:08 +0000
Subject: [New-bugs-announce] [issue26097] 2.7 documentation about
 TextTestRunner do not specify all the arguments
Message-ID: <1452683228.39.0.232346799389.issue26097@psf.upfronthosting.co.za>


New submission from Nicolas ?vrard:

Some of the arguments although specified further in the documentation do not appear in the signature of TextTestRunner.

Here's a simple patch to include them.

----------
assignee: docs at python
components: Documentation
files: unittest_doc_bug.diff
keywords: patch
messages: 258140
nosy: docs at python, nicoe
priority: normal
severity: normal
status: open
title: 2.7 documentation about TextTestRunner do not specify all the arguments
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41600/unittest_doc_bug.diff

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

From report at bugs.python.org  Wed Jan 13 07:52:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 12:52:48 +0000
Subject: [New-bugs-announce] [issue26098] PEP 510: Specialize functions with
 guards
Message-ID: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch implements the PEP 510 "Specialize functions with guards".

Changes on the C API are described in the PEP:
https://www.python.org/dev/peps/pep-0510/#changes

Additions of the patch:

* Add func_specialize() and func_get_specialized() to _testcapi
* Add _testcapi.PyGuard: Python wrapper to the Guard C API
* Add Lib/test/test_pep510.py

----------
files: specialize.patch
keywords: patch
messages: 258141
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 510: Specialize functions with guards
versions: Python 3.6
Added file: http://bugs.python.org/file41601/specialize.patch

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

From report at bugs.python.org  Wed Jan 13 09:46:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 14:46:44 +0000
Subject: [New-bugs-announce] [issue26099] site ignores ImportError when
 running sitecustomize and usercustomize
Message-ID: <1452696404.05.0.367833198211.issue26099@psf.upfronthosting.co.za>


New submission from STINNER Victor:

If the code of sitecustomize raises an ImportError because the requested module doesn't exist, sitecustomize exception is silently ignored because site.py uses "try: import sitecustomize except ImportError: pass".

It's possible to log a warning since ImportError now has a name attribute since Python 3.3.

There is a similar issue on usercustomize.

Attached patch fixes the issue.

----------
files: site.patch
keywords: patch
messages: 258144
nosy: haypo
priority: normal
severity: normal
status: open
title: site ignores ImportError when running sitecustomize and usercustomize
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41603/site.patch

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

From report at bugs.python.org  Wed Jan 13 11:32:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:32:31 +0000
Subject: [New-bugs-announce] [issue26100] Add
 test.support.optim_args_from_interpreter_flags()
Message-ID: <1452702751.92.0.809582535795.issue26100@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds a new optim_args_from_interpreter_flags() function to the test.support module, similar to the existing args_from_interpreter_flags() function. The function creates command line arguments related to optimization. The function is required by test_compileall.py and test_inspect.py.

The patch enables test_details() test of test_inspect when -O or -OO command line options are used.

----------
files: optim_args.patch
keywords: patch
messages: 258152
nosy: haypo
priority: normal
severity: normal
status: open
title: Add test.support.optim_args_from_interpreter_flags()
versions: Python 3.6
Added file: http://bugs.python.org/file41606/optim_args.patch

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

From report at bugs.python.org  Wed Jan 13 11:40:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2016 16:40:57 +0000
Subject: [New-bugs-announce] [issue26101] Lib/test/test_compileall.py fails
 when run directly
Message-ID: <1452703257.16.0.0951114007651.issue26101@psf.upfronthosting.co.za>


New submission from STINNER Victor:

"./python Lib/test/test_compileall.py" fails on test_compile_path() because the Lib/test/ directory is in sys.path and this directory contains invalid Python scripts like Lib/test/badsyntax_pep3120.py

Attached patch fixes the issue by removing temporarely Lib/test/ from sys.path.

Note: Python 3.5 doesn't test compileall.compile_path() which fails. The new test was added by the changeset 71f071f2e074 of the issue #25768.

----------
files: test_compileall.patch
keywords: patch
messages: 258154
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: Lib/test/test_compileall.py fails when run directly
versions: Python 3.6
Added file: http://bugs.python.org/file41607/test_compileall.patch

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

From report at bugs.python.org  Wed Jan 13 14:47:51 2016
From: report at bugs.python.org (Christian Berger)
Date: Wed, 13 Jan 2016 19:47:51 +0000
Subject: [New-bugs-announce] [issue26102] access violation in PyErrFetch if
 tcur==null in PyGILState_Release
Message-ID: <1452714471.66.0.669763876009.issue26102@psf.upfronthosting.co.za>


New submission from Christian Berger:

I've been messing with PyGILState_... handling for my embedded python interpreter and came across this issue:

code in PyGILState_Release:

    PyThreadState *tcur = (PyThreadState *)PyThread_get_key_value(
                                                            autoTLSkey);
    if (tcur == NULL)
        Py_FatalError("auto-releasing thread-state, "
                      "but no thread-state for this thread");

The Py_FatalError() call will then invoke PyErr_Fetch() which won't check if PyThreadState_GET() returns a valid ptr (!= NULL):

PyErr_Fetch(PyObject **p_type, PyObject **p_value, PyObject **p_traceback)
{
    PyThreadState *tstate = PyThreadState_GET();
    *p_type = tstate->curexc_type;

----------
components: Interpreter Core
messages: 258164
nosy: cberger
priority: normal
severity: normal
status: open
title: access violation in PyErrFetch if tcur==null in PyGILState_Release
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan 13 15:56:52 2016
From: report at bugs.python.org (Aaron Hall)
Date: Wed, 13 Jan 2016 20:56:52 +0000
Subject: [New-bugs-announce] [issue26103] Contradiction in definition of
 "data descriptor" between (dotted lookup behavior/datamodel documentation)
 and (inspect lib/descriptor how-to)
Message-ID: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za>


New submission from Aaron Hall:

Based on the data-model documentation (https://docs.python.org/2/reference/datamodel.html#invoking-descriptors) and the dotted lookup behavior, the follow definitions are correct:

"If the descriptor defines __set__() and/or __delete__(), it is a data descriptor; if it defines neither, it is a non-data descriptor."

def has_data_descriptor_attrs(obj):
    return set(['__set__', '__delete__']) & set(dir(obj))

def is_data_descriptor(obj):
    return bool(has_data_descriptor_attrs(obj))


However, the inspect module has the following, which is also reflected in the descriptor how-to (https://docs.python.org/2/howto/descriptor.html#descriptor-protocol):

"If an object defines both __get__() and __set__(), it is considered a data descriptor."

def isdatadescriptor(object):
    """Return true if the object is a data descriptor.

    Data descriptors have both a __get__ and a __set__ attribute..."""
    if isclass(object) or ismethod(object) or isfunction(object):
        # mutual exclusion
        return False
    tp = type(object)
    return hasattr(tp, "__set__") and hasattr(tp, "__get__")


I'm willing to sign a contributor release and fix myself.

----------
messages: 258168
nosy: Aaron Hall
priority: normal
severity: normal
status: open
title: Contradiction in definition of "data descriptor" between (dotted lookup behavior/datamodel documentation) and (inspect lib/descriptor how-to)
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/issue26103>
_______________________________________

From report at bugs.python.org  Wed Jan 13 17:24:30 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 13 Jan 2016 22:24:30 +0000
Subject: [New-bugs-announce] [issue26104] Reference leak in
 functools.partial constructor in failure case
Message-ID: <1452723870.39.0.274687476417.issue26104@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Minor bug introduced while implementing the fix for #7830:

In the case where functools.partial is wrapping another functools.partial instance, both of them providing positional arguments, the value nargs is not freed when the tuple concatenation fails and the constructor raises an Exception/returns NULL. Only nargs has the problem (it's a slice of the args passed to the function); pargs is a borrowed reference so there is no leak there. Admittedly, the odds of failure is incredibly low, but best to fix it on principle.

Code link: https://hg.python.org/cpython/file/5a2692911a43/Modules/_functoolsmodule.c#l77

The simplest fix is to add the explicit DECREF in the error path:

        pto->args = PySequence_Concat(pargs, nargs);
        if (pto->args == NULL) {
            pto->kw = NULL;
            Py_DECREF(nargs);  // <-- New
            Py_DECREF(pto);
            return NULL;
        }

All other code paths hit a DECREF later on, no other fixes required. I'd submit a proper patch, but I'm on a new machine and I've got a lot of work to get the repos set up again.

----------
components: Extension Modules
messages: 258176
nosy: belopolsky, josh.r
priority: normal
severity: normal
status: open
title: Reference leak in functools.partial constructor in failure case
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan 13 18:15:13 2016
From: report at bugs.python.org (Connor Wolf)
Date: Wed, 13 Jan 2016 23:15:13 +0000
Subject: [New-bugs-announce] [issue26105] Python JSON module doesn't
 actually produce JSON
Message-ID: <1452726913.68.0.934947942911.issue26105@psf.upfronthosting.co.za>


New submission from Connor Wolf:

The Python library JSON library doesn't emit JSON by default.

Basically, `json.dumps(float('nan'))` produces something that kind of looks like json, but isn't (specifically, `'NaN'`). Valid JSON must be `null`.

JSON *does not allow `NaN`, `infinity`, or `-infinity`. 

`json.dump[s]` has the parameter `allow_nan`, but it's `False` by default, so basically it's not actually JSON by default.

The default for emitting JSON should actually emit JSON. `allow_nan` must be `True` by default.

----------
components: Library (Lib)
messages: 258179
nosy: Connor.Wolf
priority: normal
severity: normal
status: open
title: Python JSON module doesn't actually produce JSON
versions: Python 3.4

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

From report at bugs.python.org  Wed Jan 13 18:16:27 2016
From: report at bugs.python.org (Julien)
Date: Wed, 13 Jan 2016 23:16:27 +0000
Subject: [New-bugs-announce] [issue26106] Move licences to literal blocks
Message-ID: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>


New submission from Julien:

In the context of translating the documentation:

I'd like to move the licence texts in https://docs.python.org/3.5/license.html to literal blocks, so they won't pollute the po files with legal (untranslatable) stuff, and it's visually more appealing (as far as it's possible for a licence text).

Here is what it gives graphically when applying the patch (it's the translation, don't mind the french text): http://www.afpy.org/doc/python/3.5/license.html

I also took the liberty to drop a dangling "ACCEPT", while reformating centered "titles" to real titles and building paragraphs from licence text, hope it wasn't legal stuff / part of the licence (a line before the licence mention an "accept" button ...).

----------
assignee: docs at python
components: Documentation
files: literal-licence.patch
keywords: patch
messages: 258180
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Move licences to literal blocks
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41612/literal-licence.patch

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

From report at bugs.python.org  Thu Jan 14 04:12:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2016 09:12:43 +0000
Subject: [New-bugs-announce] [issue26107] code.co_lnotab: use signed line
 number delta to support moving instructions in an optimizer
Message-ID: <1452762763.46.0.511729382261.issue26107@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python doesn't store the original line number in the .pyc file in the bytecode. Instead, an efficient table is used to find the line number from the current in the bytecode: code.co_lnotab.

Basically, it's a list of (offset_delta, line_number_delta) pairs where offset_delta and line_number_delta are unsigned 8 bits numbers. If an offset delta is larger than 255, (offset_delta % 255, line_number_delta) and (offset_delta // 255, 0) pairs are emited. Same for line_number_delta. (In fact, more than two pairs can be created.)

The format is described in Objects/lnotab_notes.txt.

I implemented an optimizer which can generate *negative* line number. For example, the loop:

   for i in range(2):   # line 1
      print(i)          # line 2

is replaced with:

   i = 0      # line 1
   print(i)   # line 2
   i = 1      # line 1
   print(i)   # line 2

The third instruction has a negative line number delta.

I'm not the first one hitting the issue, but it's just that no one proposed a patch before. Previous projects bitten by this issue:

* issue #10399: "AST Optimization: inlining of function calls"
* issue #11549: "Build-out an AST optimizer, moving some functionality out of the peephole optimizer"

Attached patch changes the type of line number delta from unsigned 8-bit integer to *signed* 8-bit integer. If a line number delta is smaller than -128 or larger than 127, multiple pairs are created (as before).

My code in Lib/dis.py is inefficient. Maybe unpack the full lnotab than *then* skip half of the bytes? (instead of calling struct.unpack times for each byte).

The patch adds also "assert(Py_REFCNT(lnotab_obj) == 1);" to PyCode_Optimize(). The assertion never fails, but it's just to be extra safe.

The patch renames variables in PyCode_Optimize() because I was confused between "offset" and "line numbers". IMHO variables were badly named.

I changed the MAGIC_NUMBER of importlib, but it was already changed for f-string:

#     Python 3.6a0  3360 (add FORMAT_VALUE opcode #25483)

Is it worth to modify it again?

You may have to recompile Python/importlib_external.h if it's not recompiled automatically (just touch the file before running make).

Note: this issue is related to the PEP 511 (the PEP is not ready for a review, but it gives a better overview of the use cases.)

----------
files: lnotab.patch
keywords: patch
messages: 258189
nosy: brett.cannon, haypo, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: code.co_lnotab: use signed line number delta to support moving instructions in an optimizer
versions: Python 3.6
Added file: http://bugs.python.org/file41613/lnotab.patch

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

From report at bugs.python.org  Thu Jan 14 04:53:50 2016
From: report at bugs.python.org (David Heffernan)
Date: Thu, 14 Jan 2016 09:53:50 +0000
Subject: [New-bugs-announce] [issue26108] Calling PyInitialize with 2.7.11
 on Windows x64 terminates process
Message-ID: <1452765230.72.0.612722422255.issue26108@psf.upfronthosting.co.za>


New submission from David Heffernan:

Environment: 
 - Python 2.7.11 from python.org, x64.
 - Windows 10 or Windows 8.1
 - MSVC 2015

I compiled the most basic embedding example, taken from the Python docs:

#include <Python.h>

int
main(int argc, char *argv[])
{
  Py_SetProgramName(argv[0]);  /* optional but recommended */
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
                     "print 'Today is',ctime(time())\n");
  Py_Finalize();
  return 0;
}

When run the call to Py_Initialize does not return and the process is terminated.

----------
components: Windows
messages: 258194
nosy: David Heffernan, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Calling PyInitialize with 2.7.11 on Windows x64 terminates process
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 14 08:10:34 2016
From: report at bugs.python.org (John Malmberg)
Date: Thu, 14 Jan 2016 13:10:34 +0000
Subject: [New-bugs-announce] [issue26109] _Py_DumpTraceback should be
 PyAPI_FUNC
Message-ID: <1452777034.65.0.00477411953399.issue26109@psf.upfronthosting.co.za>


New submission from John Malmberg:

The _PyDumpTraceback and _Py_DumpTracebackThreads routines in traceback.h are tagged with PyAPI_DATA attributes when they should be tagged with PyAPI_FUNC.

For platforms that use those attributes, this can cause run-time issues if those methods are called.

----------
components: Interpreter Core
messages: 258199
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: _Py_DumpTraceback should be PyAPI_FUNC
versions: Python 3.6

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

From report at bugs.python.org  Thu Jan 14 12:09:07 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 Jan 2016 17:09:07 +0000
Subject: [New-bugs-announce] [issue26110] Speedup method calls 1.2x
Message-ID: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This issue supersedes issue #6033.  I decided to open a new one, since the patch is about Python 3.6 (not 2.7) and is written from scratch.

The idea is to add new opcodes to avoid instantiation of BoundMethods.  The patch only affects method calls of Python functions with positional arguments.

I'm working on the attached patch in this repo: https://github.com/1st1/cpython/tree/call_meth2

If the patch gets accepted, I'll update it with the docs etc.


Performance Improvements
------------------------

Method calls in micro-benchmarks are 1.2x faster:

### call_method ###
Avg: 0.330371 -> 0.281452: 1.17x faster

### call_method_slots ###
Avg: 0.333489 -> 0.280612: 1.19x faster

### call_method_unknown ###
Avg: 0.304949 -> 0.251623: 1.21x faster

Improvements in mini-benchmarks, such as Richards are less impressive, I'd say it's 3-7% improvement.  The full output of benchmarks/perf.py is here: https://gist.github.com/1st1/e00f11586329f68fd490

When the full benchmarks suite is run, some of them report that they were slow.  When I ran them separately several times, they all show no real slowdowns.  It's just some of them (such as nbody) are highly unstable.

It's actually possible to improve the performance another 1-3% if we fuse __PyObject_GetMethod with ceval/LOAD_METHOD code.  I've tried this here: https://github.com/1st1/cpython/tree/call_meth4, however I don't like to have so many details of object.c into ceval.c.


Changes in the Core
-------------------

Two new opcodes are added -- LOAD_METHOD and CALL_METHOD.  Whenever compiler sees a method call "obj.method(..)" with positional arguments it compiles it as follows:

  LOAD_FAST(obj)
  LOAD_METHOD(method)
  {call arguments}
  CALL_METHOD

LOAD_METHOD implementation in ceval looks up "method" on obj's type, and checks that it wasn't overridden in obj.__dict__.  Apparently, even with the __dict__ check this is still faster then creating a BoundMethod instance etc.  

If the method is found and not overridden, LOAD_METHOD pushes the resolved method object, and 'obj'.  If the method was overridden, the resolved method object and NULL are pushed to the stack.

CALL_METHOD then looks at the two stack values after call arguments.  If the first one isn't NULL, it means that we have a method call.


Why CALL_METHOD?
----------------

It's actually possible to hack CALL_FUNCTION to support LOAD_METHOD.  I've tried this approach in https://github.com/1st1/cpython/tree/call_meth3.  It looks like that adding extra checks in CALL_FUNCTION have negative impact on many benchmarks.  It's really easier to add another opcode.


Why only pure-Python methods?
-----------------------------

LOAD_METHOD atm works only with methods defined in pure Python.  C methods, such as `list.append` are still wrapped into a descriptor, that creates a PyCFunction object on each attribute access.  I've tried to do that in https://github.com/1st1/cpython/tree/call_cmeth.  It does impact C method calls in a positive way, although my implementation is very hacky.  It still uses LOAD_METHOD and CALL_METHOD opcodes, so my idea is to consider merging this patch first, and then introduce the necessary refactoring of PyCFunction and MethodDesctiptors in a separate issue.


Why only calls with positional arguments?
-----------------------------------------

As showed in "Why CALL_METHOD?", making CALL_FUNCTION to work with LOAD_METHOD slows it down.  For keyword and var-arg calls we have three more opcodes -- CALL_FUNCTION_VAR, CALL_FUNCTION_KW, and CALL_FUNCTION_VAR_KW.  I suspect that making them work with LOAD_METHOD would slow them down too, which will probably require us to add three (!) more opcodes for LOAD_METHOD.

And these kind of calls require much more overhead anyways, I don't expect them to be as optimizable as positional arg calls.

----------
assignee: yselivanov
components: Interpreter Core
files: call_method_1.patch
keywords: patch
messages: 258204
nosy: benjamin.peterson, brett.cannon, gvanrossum, haypo, ncoghlan, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Speedup method calls 1.2x
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41614/call_method_1.patch

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

From report at bugs.python.org  Thu Jan 14 13:45:10 2016
From: report at bugs.python.org (Remy Roy)
Date: Thu, 14 Jan 2016 18:45:10 +0000
Subject: [New-bugs-announce] [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator
 is exhausted
Message-ID: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>


New submission from Remy Roy:

On Windows, os.scandir will keep a handle on the directory being scanned until the iterator is exhausted. This behavior can cause various problems if try to use some filesystem calls like os.chmod or os.remove on the directory while the handle is still being kept.

There are some use cases where the iterator is not going to be exhausted like looking for a specific entry in a directory and breaking from the loop prematurely.

This behavior should at least be documented.  Alternatively, it might be interesting to provide a way prematurely end the scan without having to exhaust it and close the handle.

As a workaround, you can force the exhaustion after you are done with the iterator with something like:

for entry in iterator:
    pass

This is going to affect os.walk as well since it uses os.scandir .

The original github issue can be found on https://github.com/benhoyt/scandir/issues/58 .

----------
components: Windows
messages: 258212
nosy: paul.moore, remyroy, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: On Windows, os.scandir will keep a handle on the directory until the iterator is exhausted
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 14 14:29:52 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 19:29:52 +0000
Subject: [New-bugs-announce] [issue26112] Error on example using "dialect"
 parameter. have to be: "dialect=dialect"
Message-ID: <1452799792.3.0.65685555924.issue26112@psf.upfronthosting.co.za>


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

with open('example.csv') as csvfile:
    dialect = csv.Sniffer().sniff(csvfile.read(1024))
    csvfile.seek(0)
    reader = csv.reader(csvfile, dialect)
    # ... process CSV file contents here ...
--

have to be:
    ...
    reader = csv.reader(csvfile, dialect=dialect)
     # ... process CSV file contents here ...

It's here:
https://docs.python.org/3.4/library/csv.html

----------
assignee: docs at python
components: Documentation
messages: 258214
nosy: docs at python, ?????? ?????????
priority: normal
severity: normal
status: open
title: Error on example using "dialect" parameter. have to be: "dialect=dialect"
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 14 15:16:18 2016
From: report at bugs.python.org (JitterMan)
Date: Thu, 14 Jan 2016 20:16:18 +0000
Subject: [New-bugs-announce] [issue26113] pathlib p.match('') should return
 False rather than raising exception
Message-ID: <1452802578.55.0.628676824088.issue26113@psf.upfronthosting.co.za>


New submission from JitterMan:

One can use '*' as an 'accept all' pattern to match(). It would be nice to also use '' as a 'reject all' pattern. These 'accept all' and 'reject all' rules are useful as defaults. Currently passing '' to match() causes an exception. While it is easy enough to catch the exception, the need to constrains the way match() must be called and makes the calling code needlessly complicated and fussy.

----------
files: example.py
messages: 258216
nosy: jitterman
priority: normal
severity: normal
status: open
title: pathlib p.match('') should return False rather than raising exception
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file41615/example.py

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

From report at bugs.python.org  Thu Jan 14 15:35:41 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2016 20:35:41 +0000
Subject: [New-bugs-announce] [issue26114] Rewrite math.erf() and math.erfc()
 from scratch
Message-ID: <1452803741.39.0.631242355329.issue26114@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you look Modules/mathmodule.c you will notice there is a comment that goes with erf() and erfc() stating that the algorithms were taken from a book entitled 'Numerical Recipes'. Unfortunately that book has a license dictating that any information from the book is only allowed for non-commercial use; commercial use requires negotiating a license (http://numerical.recipes/aboutNR3license.html). That's bad for anyone who has a commercial distribution of Python as that's a special requirement they have to follow.

It would be best to do a clean room implementation of both math.erf() and math.erfc() that does not use information from 'Numerical Recipes' in order to not be violating that license. That way Python can be sold commercially without having to negotiate a separate license just for those two functions.

Unfortunately this code exists since at least Python 2.7, so I have flagged all Python releases as needing the eventual clean room implementation applied to it (although Python 3.2 goes out of security maintenance next month so I don't know how critical it is to fix that far back).

----------
components: Library (Lib)
messages: 258218
nosy: benjamin.peterson, brett.cannon, eric.smith, georg.brandl, larry, lemburg, mark.dickinson, stutzbach
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Rewrite math.erf() and math.erfc() from scratch
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/issue26114>
_______________________________________

From report at bugs.python.org  Thu Jan 14 16:20:32 2016
From: report at bugs.python.org (JitterMan)
Date: Thu, 14 Jan 2016 21:20:32 +0000
Subject: [New-bugs-announce] [issue26115] pathlib.glob('**') returns only
 directories
Message-ID: <1452806432.12.0.827592335617.issue26115@psf.upfronthosting.co.za>


New submission from JitterMan:

The title says it all.

The shell version of '*' and '**' return both directories and files.
Path('.').glob('*') returns both directories and files, but Path('.').glob('**') returns only directories. That seems wrong to me.

----------
messages: 258223
nosy: jitterman
priority: normal
severity: normal
status: open
title: pathlib.glob('**') returns only directories
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 14 16:50:32 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 21:50:32 +0000
Subject: [New-bugs-announce] [issue26116] CSV-module. The example code don't
 work. Have to be: reader = csv.reader(csvfile, dialect=dialect)
Message-ID: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>


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

with open('example.csv') as csvfile:
    dialect = csv.Sniffer().sniff(csvfile.read(1024))
    csvfile.seek(0)
    reader = csv.reader(csvfile, dialect)
    # ... process CSV file contents here ...
--

have to be:
    ...
    reader = csv.reader(csvfile, dialect=dialect)
     # ... process CSV file contents here ...

It's here:
https://docs.python.org/3.4/library/csv.html

----------
assignee: docs at python
components: Documentation
messages: 258227
nosy: Vasyl Kolomiets, docs at python
priority: normal
severity: normal
status: open
title: CSV-module. The example code don't work.    Have to be: reader = csv.reader(csvfile, dialect=dialect)
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 14 17:10:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 22:10:22 +0000
Subject: [New-bugs-announce] [issue26117] Close directory descriptor in
 scandir iterator on error
Message-ID: <1452809422.76.0.117373240485.issue26117@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since scandir iterator has no close method, the most safe way to avoid file descriptors leaks when use os.scandir() is accumulating yielded results into a list before processing them:

    entries = list(os.scandir(path))

But this doesn't save us from all leaks. If an error happened during yielding next entry, opened file descriptor left open.

Proposed patch makes scandir to close the file descriptor not only when an iteration is exhausted, but when any error (expected OSError or MemoryError) is raised.

This is needed to fix possible leaks in os.walk() in 3.5 (see also issue25995).

----------
components: Extension Modules
files: scandir_closedir_on_error.patch
keywords: patch
messages: 258232
nosy: benhoyt, gvanrossum, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Close directory descriptor in scandir iterator on error
type: resource usage
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41616/scandir_closedir_on_error.patch

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

From report at bugs.python.org  Thu Jan 14 17:47:44 2016
From: report at bugs.python.org (poostenr)
Date: Thu, 14 Jan 2016 22:47:44 +0000
Subject: [New-bugs-announce] [issue26118] String performance issue using
 single quotes
Message-ID: <1452811664.45.0.761474192648.issue26118@psf.upfronthosting.co.za>


New submission from poostenr:

There appears to be a significant performance issue between the following two statements. Unable to explain performance impact.

s = "{0},".format(columnvalue)   # fast
s = "'{0}',".format(columnvalue) # ~30x slower

So far, no luck trying to find other statements to improve performance, such as:
s = "\'{0}\',".format(columnvalue)
s = "'" + "%s" %(columnvalue) + "'"+","
s = "{0}{1}{2},".format("'",columnvalue,"'")

----------
components: Windows
messages: 258243
nosy: paul.moore, poostenr, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: String performance issue using single quotes
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 14 22:54:11 2016
From: report at bugs.python.org (Paul Hammant)
Date: Fri, 15 Jan 2016 03:54:11 +0000
Subject: [New-bugs-announce] [issue26119] Windows Installer can sometimes
 silently fail pip stage
Message-ID: <1452830051.37.0.928414799264.issue26119@psf.upfronthosting.co.za>


New submission from Paul Hammant:

It NEEDS to communicate more as to why it is rolling back the pip install (progress bar goes backwards, install fails).

Reasons can be:

1. older/wrong versions of Python listed in the PATH - eg c:\Python27 encountered when c:\Python34 is being installed. User should redo PATH env-var.

2. PYTHONPATH similarly set to the wrong thing. User should delete PYTHONPATH env-vars.

3. Incompatible Python installed. User should uninstall other Python's first.

The windows install does not have to silently fail on the pip piece. It can do more to inform them end-user, and not drive them off to stackoverflow.

----------
components: Windows
messages: 258266
nosy: Paul Hammant, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Installer can sometimes silently fail pip stage
versions: Python 3.5

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

From report at bugs.python.org  Fri Jan 15 01:31:40 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 15 Jan 2016 06:31:40 +0000
Subject: [New-bugs-announce] [issue26120] pydoc: move __future__ imports out
 of the DATA block
Message-ID: <1452839500.03.0.307183465285.issue26120@psf.upfronthosting.co.za>


New submission from Antony Lee:

Currently, for a module that uses __future__ imports, the DATA section of `pydoc foo` contains these imports interspersed with the "real" data from the module.

Even though it is fully-featured _Feature objects that are imported, it probably makes sense to move them out of this section.

----------
assignee: docs at python
components: Documentation
messages: 258272
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: pydoc: move __future__ imports out of the DATA block
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan 15 06:42:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 11:42:15 +0000
Subject: [New-bugs-announce] [issue26121] Use C99 functions in math if
 available
Message-ID: <1452858135.55.0.233335376493.issue26121@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently the math module uses own implementation of some mathematical functions that are in C99 standard, but not in C89 standard: tgamma, lgamma, erf, erfc. Proposed patch makes it to use functions from standard C library if they are available. They are faster and presumably more accurate.

Here are microbenchmark results (time in microseconds):

                  0.1     1      3     10     30
erf unpatched:   0.506  0.655  0.509  0.548  0.239
erf patched:     0.129  0.252  0.357  0.253  0.253

erfc unpatched:  0.508  0.646  0.532  0.522  0.251
erfc patched:    0.129  0.239  0.373  0.371  0.307

                    0.1    1.5     3     10     10.5
gamma unpatched:   0.369  0.279  0.273  0.274  0.457
gamma patched:     0.24   0.23   0.412  0.741  0.682

lgamma unpatched:  0.351  0.338  0.478  0.627  0.52
lgamma patched:    0.217  0.155  0.37   0.372  0.247

If some libm implementations are pretty bad, they can be disabled by undefining corresponding HAVE_XXX macros.

----------
components: Extension Modules
files: math_libc_funcs.patch
keywords: patch
messages: 258288
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use C99 functions in math if available
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41623/math_libc_funcs.patch

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

From report at bugs.python.org  Fri Jan 15 07:48:14 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 Jan 2016 12:48:14 +0000
Subject: [New-bugs-announce] [issue26122] Isolated mode doesn't ignore
 PYTHONHASHSEED
Message-ID: <1452862094.75.0.964095204421.issue26122@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

While working on the draft PEP 432 implementation, I noticed that -I isn't special cased for early processing the same way that -E is: https://hg.python.org/cpython/file/tip/Modules/main.c#l265

This means that when isolated mode is used to turn off environment variable access, PYTHONHASHSEED may still be read while configuring hash randomisation.

----------
assignee: christian.heimes
messages: 258290
nosy: christian.heimes, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Isolated mode doesn't ignore PYTHONHASHSEED
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan 15 08:10:03 2016
From: report at bugs.python.org (Sebastian Rittau)
Date: Fri, 15 Jan 2016 13:10:03 +0000
Subject: [New-bugs-announce] [issue26123] http.client status code constants
 incompatible with Python 3.4
Message-ID: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>


New submission from Sebastian Rittau:

The HTTP status code constants in Python 3.5 http.client are not compatible with the constants in Python 3.4, since the str() behaviour is different. This breaks code: 

srittau at moby:~$ python3.5
Python 3.5.1+ (default, Jan 13 2016, 15:09:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import http.client
>>> str(http.client.OK)
'HTTPStatus.OK'

vs:

rittau at moby:~$ python3.4
Python 3.4.4 (default, Jan  5 2016, 15:35:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import http.client
>>> str(http.client.OK)
'200'

----------
components: Library (Lib)
messages: 258291
nosy: srittau
priority: normal
severity: normal
status: open
title: http.client status code constants incompatible with Python 3.4
versions: Python 3.5

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

From report at bugs.python.org  Fri Jan 15 08:14:41 2016
From: report at bugs.python.org (Charles Daffern)
Date: Fri, 15 Jan 2016 13:14:41 +0000
Subject: [New-bugs-announce] [issue26124] shlex.quote and pipes.quote do not
 quote shell keywords
Message-ID: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>


New submission from Charles Daffern:

The shlex.quote and pipes.quote functions do not quote shell keywords.

Example shell keywords: done, time, coproc, while

Presumably the intent of the quote functions is to prevent the resulting string from altering the syntax of the script it is inserted into, which is why I think these need to be quoted.

We can't possibly know every shell keyword, so the only sensible thing to do here is to quote everything.

----------
components: Extension Modules
messages: 258292
nosy: Charles Daffern
priority: normal
severity: normal
status: open
title: shlex.quote and pipes.quote do not quote shell keywords
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/issue26124>
_______________________________________

From report at bugs.python.org  Fri Jan 15 08:52:59 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Fri, 15 Jan 2016 13:52:59 +0000
Subject: [New-bugs-announce] [issue26125] Incorrect error message in the
 module asyncio.selector_events.
Message-ID: <1452865979.87.0.840611229209.issue26125@psf.upfronthosting.co.za>


New submission from Carlo Beccarini:

Incorrect error message in the module asyncio.selector_events for the methods:
_SelectorSocketTransport.write
_SelectorSslTransport.write
_SelectorDatagramTransport.sendto.

The previous error was raising a Tuple:
TypeError: ('data argument must be byte-ish (%r)', <class 'str'>)

Patched:
TypeError: data argument must be a bytes-like object, not 'str'

----------
components: asyncio
files: patch.diff
keywords: patch
messages: 258294
nosy: Paradisee, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Incorrect error message in the module asyncio.selector_events.
versions: Python 3.4
Added file: http://bugs.python.org/file41624/patch.diff

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

From report at bugs.python.org  Fri Jan 15 13:04:50 2016
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 15 Jan 2016 18:04:50 +0000
Subject: [New-bugs-announce] [issue26126] Possible subtle bug when
 normalizing and str.translate()ing
Message-ID: <1452881090.74.0.501338365474.issue26126@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

I am using Python 3.4.3 on Xubuntu 14.04 LTS 64-bit.

I have a program that when run repeatedly sometimes what I expect, and sometimes does not:

$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
BUG ('The aenid oevre', '!=', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')
$ ~/tmp/normbug.py 
BUG ('The aenid oevre', '!=', 'The AEnid oevre')
$ ~/tmp/normbug.py 
BUG ('The aenid oevre', '!=', 'The AEnid oevre')
$ ~/tmp/normbug.py 
OK ('The AEnid oevre', '==', 'The AEnid oevre')

As you can see, sometimes the left (actual) is case-folded, and sometimes it isn't which is surprising given the code (which is attached).

Of course this could be a mistake on my part; maybe I've misunderstood how the unicode normalizing works.

----------
files: normbug.py
messages: 258314
nosy: mark
priority: normal
severity: normal
status: open
title: Possible subtle bug when normalizing and str.translate()ing
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41627/normbug.py

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

From report at bugs.python.org  Fri Jan 15 13:56:51 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 15 Jan 2016 18:56:51 +0000
Subject: [New-bugs-announce] [issue26127] Broken link in docs for tokenize
Message-ID: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docs for `tokenize.detect_encoding` state `Use open() to open Python source files: it uses detect_encoding() to detect the file encoding.`

Unfortunately, clicking on `open` redirects to the builtin `open` function, not to `tokenize.open` as it should.

----------
assignee: docs at python
components: Documentation
messages: 258319
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Broken link in docs for tokenize
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan 15 14:45:19 2016
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 15 Jan 2016 19:45:19 +0000
Subject: [New-bugs-announce] [issue26128] Let the subprocess.STARTUPINFO
 constructor take arguments
Message-ID: <1452887119.07.0.716350004713.issue26128@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Right now when you want to use `subprocess.STARTUPINFO`, you need to do something like this: 

    si = subprocess.STARTUPINFO()
    si.dwFlags = subprocess.STARTF_USESTDHANDLES
    subprocess.Popen(['whatever'], startupinfo=si)

It would be much nicer to do this: 

    subprocess.Popen(
        ['whatever'],
        startupinfo=subprocess.STARTUPINFO(
            subprocess.STARTF_USESTDHANDLES
        )
    )

So I suggest that the `STARTUPINFO` constructor take an optional argument that sets the flags on it.

----------
components: Library (Lib), Windows
messages: 258324
nosy: cool-RR, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Let the subprocess.STARTUPINFO constructor take arguments
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Jan 15 14:48:25 2016
From: report at bugs.python.org (Simon Fraser)
Date: Fri, 15 Jan 2016 19:48:25 +0000
Subject: [New-bugs-announce] [issue26129] Difference in behaviour with
 grp.getgrgid and pwd.getpwuid
Message-ID: <1452887305.34.0.0492943983639.issue26129@psf.upfronthosting.co.za>


New submission from Simon Fraser:

grp.getgrgid is capable of accepting a string:

from grp import getgrgid
print(getgrgid('0'))

However, pwd.getpwuid can't do the same:

from pwd import getpwuid
print(getpwuid('0'))

Traceback (most recent call last):
  File "getpwuid_test.py", line 2, in <module>
    print(getpwuid('0'))
TypeError: an integer is required

This seems to be because inside Modules/pwdmodule.c, getpwuid uses PyNumber_ParseTuple with a converter that uses PyNumber_Index to get a Python integer, and that raises an exception on failure.

However, in Modules/grpmodule.c, grp_getgrgid uses PyNumber_Long (Or PyNumber_Int for an old enough Python) as a conversion first, and as the documentation says at https://docs.python.org/3/c-api/number.html, this is the equivalent of running int(o), which can convert a string to an integer. Only then is it given to PyNumber_Index, by way of a helper function _Py_Gid_Converter

Should these have different behaviours? Is there a reason for the difference?

The behaviour of getgrgid seems more helpful, and it's odd that it doesn't apply to both functions. Is this undesirable behaviour in getgrgid or getpwuid?

----------
components: Library (Lib)
messages: 258325
nosy: SimonFr
priority: normal
severity: normal
status: open
title: Difference in behaviour with grp.getgrgid and pwd.getpwuid
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Jan 15 15:36:48 2016
From: report at bugs.python.org (Oren Milman)
Date: Fri, 15 Jan 2016 20:36:48 +0000
Subject: [New-bugs-announce] [issue26130] redundant local copy of a char
 pointer in classify in Parser\parser.c
Message-ID: <1452890208.24.0.32779562482.issue26130@psf.upfronthosting.co.za>


New submission from Oren Milman:

In Parser\parser.c in classify, the 'str' parameter is assigned into the local variable 's'. However, 'str' is not used anywhere else in the function, which makes 's' redundant.

My proposal is to simply remove 's', and just use 'str' instead.

The diff is attached.

I played a little with the interpreter, and everything worked as usual.
In addition, I run 'python -m test' (on my 64-bit Windows 10) before and after applying the patch, and got the same output:
354 tests OK.
1 test altered the execution environment:
    test_subprocess
45 tests skipped:
    test_bz2 test_crypt test_curses test_dbm_gnu test_dbm_ndbm
    test_devpoll test_epoll test_fcntl test_fork1 test_gdb test_grp
    test_idle test_ioctl test_kqueue test_lzma test_nis test_openpty
    test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd
    test_readline test_resource test_smtpnet test_socketserver
    test_spwd test_sqlite test_ssl test_syslog test_tcl
    test_threadsignals test_timeout test_tix test_tk test_ttk_guionly
    test_ttk_textonly test_urllib2net test_urllibnet test_wait3
    test_wait4 test_winsound test_xmlrpc_net test_zipfile64

----------
components: Interpreter Core
files: patchDiff.txt
messages: 258326
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: redundant local copy of a char pointer in classify in Parser\parser.c
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41629/patchDiff.txt

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

From report at bugs.python.org  Fri Jan 15 16:44:04 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2016 21:44:04 +0000
Subject: [New-bugs-announce] [issue26131] Raise ImportWarning when
 loader.load_module() is used
Message-ID: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Since loader.load_module() is documented as deprecated, we should consider raising an ImportWarning when it is used. That way when Python 2.7 support ends we can either remove it or have one more release where the various ImportWarnings turn into DeprecationWarnings and we finally clean up the import semantics to only be spec-based.

----------
components: Interpreter Core
messages: 258333
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Raise ImportWarning when loader.load_module() is used
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Jan 16 09:12:42 2016
From: report at bugs.python.org (David Rader)
Date: Sat, 16 Jan 2016 14:12:42 +0000
Subject: [New-bugs-announce] [issue26132] 2.7.11 Windows Installer issues on
 Win2008R2
Message-ID: <1452953562.0.0.729045756058.issue26132@psf.upfronthosting.co.za>


New submission from David Rader:

Problem 1:
The .manifest information for the VC runtime dll's has been changed in the recent versions of the 2.7.x 64-bit installers for Windows. Python fails to run on a clean Win2008R2 install after running the Python installer to install "Just for me". The installation succeeds if "Install for all users" is selected.

After install completes, trying to run python results in:
The application has failed to start because it's side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

The event viewer log shows:
Activation context generation failed for "C:\Python27\python.exe".Error in manifest or policy file "C:\Python27\Microsoft.VC90.CRT.MANIFEST" on line 4. Component identity found in manifest does not match the identity of the component requested. Reference is Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8". Definition is Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.1". Please use sxstrace.exe for detailed diagnosis.

This means that that VC2008 SP1 dll and manifest are included in the installer, but the Python.exe is compiled against VC2008 (_not_ SP1).
Replacing the installed manifest and VC90 with one pulled from an older distribution with the correct 9.0.21022.8 version enables python to run.

Problem 2:
The compiled DLLs in the DLLs folder incorrectly have the VC manifest included in them as well. This breaks the side-by-side look up, since the VC90 dll is not in the DLLs folder. So if you try to import socket, you get an error message like:
Traceback (most recent call last):
  File "hub\scripts\pgc.py", line 9, in <module>
    import socket
  File "C:\Python27\lib\socket.py", line 47, in <module>
    import _socket
ImportError: DLL load failed: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

Previous versions of Python for windows have had this problem but it was corrected. It looks like it has crept back in.

----------
components: Installation
messages: 258387
nosy: David Rader, benjamin.peterson, loewis
priority: normal
severity: normal
status: open
title: 2.7.11 Windows Installer issues on Win2008R2
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan 16 14:06:06 2016
From: report at bugs.python.org (Alex Brandt)
Date: Sat, 16 Jan 2016 19:06:06 +0000
Subject: [New-bugs-announce] [issue26133] TypeError: signal handler must be
 signal.SIG_IGN, signal.SIG_DFL,
 or a callable object in <bound method BaseEventLoop.__del__ of
 <_UnixSelectorEventLoop running=False closed=True debug=False>>
Message-ID: <1452971166.69.0.340450798134.issue26133@psf.upfronthosting.co.za>


New submission from Alex Brandt:

When using the suggested practice of setting a stop loop signal handler with:

loop.add_signal_handler(signal.SIGTERM, loop.stop)

The following stack trace is given when the signal runs:

ligament_1 | Exception ignored in: <bound method BaseEventLoop.__del__ of <_UnixSelectorEventLoop running=False closed=True debug=False>>
ligament_1 | Traceback (most recent call last):
ligament_1 |   File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in __del__
ligament_1 |   File "/usr/lib/python3.5/asyncio/unix_events.py", line 58, in close
ligament_1 |   File "/usr/lib/python3.5/asyncio/unix_events.py", line 139, in remove_signal_handler
ligament_1 |   File "/usr/lib/python3.5/signal.py", line 47, in signal
ligament_1 | TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object

Since this happens during shutdown of the application I wouldn't consider this a high priority bug but it is quite annoying.  I've also not investigated if this interrupts the loop stopping procedure yet.

----------
components: asyncio
messages: 258401
nosy: Alex Brandt, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object in <bound method BaseEventLoop.__del__ of <_UnixSelectorEventLoop running=False closed=True debug=False>>
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan 16 18:39:30 2016
From: report at bugs.python.org (guesommer)
Date: Sat, 16 Jan 2016 23:39:30 +0000
Subject: [New-bugs-announce] [issue26134] urllib2.HTTPBasicPriorAuthHandler
 does not work with DigestAuthentication
Message-ID: <1452987570.59.0.951573135537.issue26134@psf.upfronthosting.co.za>


New submission from guesommer:

My first bug reported here, so might not be perfectly following the rules :)

Similar to issue 19494 ("Add urllib2.HTTPBasicPriorAuthHandler for use with APIs that don't return 401 errors") - but related to digest authentication. 

The sending of the auth header at all times works when using basic authentication, but not with digest authentication (verified with wireshark).

IMHO it should be the same behaviour with digest authentication - I think the change needs to applied there as well.

example code to check:
password_mgr = urllib.request.HTTPPasswordMgrWithPriorAuth()
password_mgr.add_password(None , 'http://www.example.org", "supercow","blablabla",is_authenticated=True)
auth_handler = urllib.request.HTTPDigestAuthHandler(password_mgr)
opener = urllib.request.build_opener(auth_handler)
urllib.request.install_opener(opener)

----------
components: Library (Lib)
messages: 258435
nosy: guesommer
priority: normal
severity: normal
status: open
title: urllib2.HTTPBasicPriorAuthHandler does not work with DigestAuthentication
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan 16 20:08:48 2016
From: report at bugs.python.org (Cameron Conn)
Date: Sun, 17 Jan 2016 01:08:48 +0000
Subject: [New-bugs-announce] [issue26135] Documentation Recommends
 Deprecated `imp` Module
Message-ID: <1452992928.86.0.18217536546.issue26135@psf.upfronthosting.co.za>


New submission from Cameron Conn:

The documentation detailing modules recommends using the deprecated `imp` module in section 6.1. Instead, it should recommend `importlib`, which `imp` was deprecated in favor of in Python 3.4.

The portion of the documentation that says this is in the gray aside box at the bottom of Section 6.1 immediately before Section 6.1.1.

These are the pages that have this issue:
Python 3.4: https://docs.python.org/3.4/tutorial/modules.html#more-on-modules
Python 3.5: https://docs.python.org/3.5/tutorial/modules.html#more-on-modules
Python 3.6: https://docs.python.org/3.6/tutorial/modules.html#more-on-modules

----------
assignee: docs at python
components: Documentation
messages: 258438
nosy: camconn, docs at python
priority: normal
severity: normal
status: open
title: Documentation Recommends Deprecated `imp` Module
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jan 16 22:31:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 Jan 2016 03:31:19 +0000
Subject: [New-bugs-announce] [issue26136] DeprecationWarning for PEP 479
 (generator_stop)
Message-ID: <1453001479.54.0.173509242949.issue26136@psf.upfronthosting.co.za>


New submission from Martin Panter:

PEP 479 says ?Python 3.6: Non-silent deprecation warning? if ?StopIteration bubbles out of a generator not under __future__ import?. Currently I see a PendingDeprecationWarning in this case; I guess this should be changed to DeprecationWarning in the 3.6 branch.

----------
components: Interpreter Core
messages: 258448
nosy: martin.panter
priority: normal
severity: normal
stage: needs patch
status: open
title: DeprecationWarning for PEP 479 (generator_stop)
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Jan 17 04:44:12 2016
From: report at bugs.python.org (Alexander Riccio)
Date: Sun, 17 Jan 2016 09:44:12 +0000
Subject: [New-bugs-announce] [issue26137] [idea] use the Microsoft
 Antimalware Scan Interface
Message-ID: <1453023852.0.0.39090079449.issue26137@psf.upfronthosting.co.za>


New submission from Alexander Riccio:

I'm really not sure what it'd look like, or how it'd work, but CPython should take advantage of Microsoft's Antimalware Scan Interface, which is new to Windows 10. It's designed for applications like interpreters, which can execute u trusted code that may not be visible to antimalware.

----------
components: Interpreter Core, Windows
messages: 258455
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [idea] use the Microsoft Antimalware Scan Interface
type: enhancement

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

From report at bugs.python.org  Sun Jan 17 06:26:01 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2016 11:26:01 +0000
Subject: [New-bugs-announce] [issue26138] Disable /W4 warning (non-standard
 dllimport behavior)
Message-ID: <1453029961.05.0.06139396524.issue26138@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
nosy: skrah
priority: normal
severity: normal
status: open
title: Disable /W4 warning (non-standard dllimport behavior)

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

From report at bugs.python.org  Sun Jan 17 06:27:07 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2016 11:27:07 +0000
Subject: [New-bugs-announce] [issue26139] libmpdec: disable /W4 warning
 (non-standard dllimport behavior)
Message-ID: <1453030027.6.0.790177544356.issue26139@psf.upfronthosting.co.za>


New submission from Stefan Krah:

See: #25878

----------
assignee: skrah
components: Extension Modules
messages: 258461
nosy: skrah
priority: normal
severity: normal
status: open
title: libmpdec: disable /W4 warning (non-standard dllimport behavior)
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Sun Jan 17 06:42:52 2016
From: report at bugs.python.org (Hiroyuki Takagi)
Date: Sun, 17 Jan 2016 11:42:52 +0000
Subject: [New-bugs-announce] [issue26140] inspect.iscoroutinefunction raises
 TypeError when checks Mock of function or coroutinefunction
Message-ID: <1453030972.84.0.0646105171888.issue26140@psf.upfronthosting.co.za>


New submission from Hiroyuki Takagi:

inspect.iscoroutinefunction and asyncio.iscoroutinefunction with patch of issue25599 (https://bugs.python.org/issue25599) raise TypeError when used to check Mock object which mocks function or coroutinefunction.

How to reproduce:

- For the mock of function

>>> from unittest.mock import Mock
>>> import inspect
>>> def a():...
... 
>>> inspect.iscoroutinefunction(Mock(a))

Expected: False
Actual: 
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File ".../cpython/Lib/inspect.py", line 187, in iscoroutinefunction
        object.__code__.co_flags & CO_COROUTINE)
    TypeError: unsupported operand type(s) for &: 'Mock' and 'int'


- For the mock of coroutine-function

>>> async def b():...
... 
>>> inspect.iscoroutinefunction(Mock(b))

Expected: True
Actual:
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File ".../cpython/Lib/inspect.py", line 187, in iscoroutinefunction
        object.__code__.co_flags & CO_COROUTINE)
    TypeError: unsupported operand type(s) for &: 'Mock' and 'int'


Without the patch of issue25599, asyncio.iscoroutinefunction does not raise error and returns Mock object. But I don't think it is expected behavior, as discussed in that issue.

I wrote a patch to solve this problem.

----------
components: asyncio
files: mock.patch
keywords: patch
messages: 258464
nosy: gvanrossum, haypo, miyakogi, yselivanov
priority: normal
severity: normal
status: open
title: inspect.iscoroutinefunction raises TypeError when checks Mock of function or coroutinefunction
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41638/mock.patch

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

From report at bugs.python.org  Sun Jan 17 11:55:40 2016
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 17 Jan 2016 16:55:40 +0000
Subject: [New-bugs-announce] [issue26141] typing module documentation
 incomplete
Message-ID: <1453049740.68.0.762293537242.issue26141@psf.upfronthosting.co.za>


New submission from Ben Darnell:

The typing module docs at https://docs.python.org/3/library/typing.html do not include everything that is documented in the PEP (https://www.python.org/dev/peps/pep-0484/#the-typing-module). Specifically, `AnyStr` is mentioned but not defined, the `@overload` decorator is missing, and so are the new-to-3.5 types Awaitable, AsyncIterable, AsyncIterator.

----------
assignee: docs at python
components: Documentation
messages: 258475
nosy: Ben.Darnell, docs at python
priority: normal
severity: normal
status: open
title: typing module documentation incomplete
versions: Python 3.5

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

From report at bugs.python.org  Sun Jan 17 18:37:34 2016
From: report at bugs.python.org (Jim Nasby)
Date: Sun, 17 Jan 2016 23:37:34 +0000
Subject: [New-bugs-announce] [issue26142] Formatting bug on
 https://docs.python.org/2.7/c-api/intro.html
Message-ID: <1453073854.16.0.698165135506.issue26142@psf.upfronthosting.co.za>


New submission from Jim Nasby:

The code for the set_all() example has a formatting bug:

            return -1;
    }
        Py_DECREF(index);
    }

it should be

            return -1;
        }
        Py_DECREF(index);
    }

----------
assignee: docs at python
components: Documentation
messages: 258486
nosy: Jim Nasby, docs at python
priority: normal
severity: normal
status: open
title: Formatting bug on https://docs.python.org/2.7/c-api/intro.html
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 17 23:05:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jan 2016 04:05:50 +0000
Subject: [New-bugs-announce] [issue26143] Ensure that IDLE's stdlib imports
 are from the stdlib
Message-ID: <1453089950.28.0.356846327087.issue26143@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In the past few months, there has been an increase "IDLE fails to start" reports that are apparently due to shadowing of stdlib modules by user modules in the same directly as as user code.  For instance, a beginner creates turtle.py and then writes "import turtle" in the same file or another in the same directory.

Note that only Python-coded modules can be shadowed. Imports of builtin modules that are not accelerators for a .py module are handled internally and do not involve sys.path.  (If turtle were builtin, turtle.py would not interfere with 'import turtle.) In particular, sys is builtin and 'import sys' is guaranteed to work and give access to sys.path.

CPython avoids shadowing of the stdlib in its own imports.  Perhaps it does not add '', standing for the current working directory, to the front of sys.path until after its imports are done.  A self-contained application can avoid the problem by properly naming its own modules.  An application like IDLE that runs user code needs to protect itself from user files.  It does not now.

IDLE normally runs with two processes. I believe shadowing is more a problem for the user process that executes user code, with the working directory set to that of the user code.  (I believe that this is one reason why user code must be saved, to a particular directory, before it is run.)  Since, with one exception, all imports in run.py are done before running user code, I believe a sufficient fix would be temporarily delete '' while run.py does its own imports.

By default, the IDLE gui process should not have a problem.  The working directory is that of python.exe, which initially has no conflicting files.  To guard against user additions, '' could be permanently removed.  However, for option -n single-process mode, it would have to be restored (a reason for wanting to remove that mode).  I am not sure of the effect of all the other options.  At present, I believe, all imports are done at startup.  So the same idea used for the user process might work, at least for the present.

Automated tests would be nice.  I might want to some day 
limit initial imports to the minimum needed to show the initial window (or windows), so IDLE might start faster.  But they are not trivial.  And there is the time factor. A single cold start of IDLE takes as long (about 4 seconds on my machine) as the average test file in the test suite.

----------
messages: 258496
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Ensure that IDLE's stdlib imports are from the stdlib
type: behavior

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

From report at bugs.python.org  Mon Jan 18 00:27:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 Jan 2016 05:27:40 +0000
Subject: [New-bugs-announce] [issue26144] test_pkg test_4 and/or test_7
 sometimes fail
Message-ID: <1453094860.75.0.307197769475.issue26144@psf.upfronthosting.co.za>


New submission from Martin Panter:

It doesn?t always fail, and sometimes only one or the other test fails. Also, it seems to depend on the way the tests are run. I have never seen it fail with ?python -m test -v?. Two commands where it does often fail for me:

./python -m test -w test_pkg
./python -m unittest -v test.test_pkg

Here is the output when both tests fail:

test_1 (test.test_pkg.TestPkg) ... ok
test_2 (test.test_pkg.TestPkg) ... ok
test_3 (test.test_pkg.TestPkg) ... ok
test_4 (test.test_pkg.TestPkg) ... ERROR
test_5 (test.test_pkg.TestPkg) ... ok
test_6 (test.test_pkg.TestPkg) ... ok
test_7 (test.test_pkg.TestPkg) ... FAIL
test_8 (test.test_pkg.TestPkg) ... ok

======================================================================
ERROR: test_4 (test.test_pkg.TestPkg)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 180, in test_4
    self.run_code(s)
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 69, in run_code
    exec(textwrap.dedent(code), globals(), {"self": self})
  File "<string>", line 2, in <module>
  File "/tmp/tmprhpx80bw/t4.py", line 1, in <module>
RuntimeError: Shouldnt load t4.py

======================================================================
FAIL: test_7 (test.test_pkg.TestPkg)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 260, in test_7
    '__name__', '__package__', '__path__', '__spec__'])
AssertionError: Lists differ: ['__c[34 chars]__loader__', '__name__', '__package__', '__spec__'] != ['__c[34 chars]__loader__', '__name__', '__package__', '__path__', '__spec__']

First differing element 6:
__spec__
__path__

Second list contains 1 additional elements.
First extra element 7:
__spec__

  ['__cached__',
   '__doc__',
   '__file__',
   '__loader__',
   '__name__',
   '__package__',
+  '__path__',
   '__spec__']

----------------------------------------------------------------------
Ran 8 tests in 0.038s

FAILED (failures=1, errors=1)

----------
components: Tests
messages: 258500
nosy: martin.panter
priority: normal
severity: normal
status: open
title: test_pkg test_4 and/or test_7 sometimes fail
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jan 18 04:10:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 09:10:57 +0000
Subject: [New-bugs-announce] [issue26145] PEP 511: Add
 sys.set_code_transformers()
Message-ID: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch implements the largest part of the PEP 511:

* add sys.get_code_transformers() and sys.set_code_transformers()
* add sys.implementation.optim_tag
* add -o command line option setting sys.implementation.optim_tag
* modify importlib to use sys.implementation.optim_tag to build .pyc filenames
* modify importlib to raise an ImportError when the .pyc file is missing, the .py is available, and the optimizer tag created from code transformers is different than the current sys.implementation.optim_tag
* add Lib/test/test_pep511.py: test changes especially bytecode and AST transformers
* add a PeepholeOptimizer object created by default for sys.set_code_transformers()
* skip the peephole optimizer when -o noopt is used
* add sys field to the PyInterpreterState structure: used by _PySys_GetCodeTransformers() to get code transformers
* update unit tests to use the optimizer to create the .pyc filename

An optimizer tag must contain characters: '.', '-', directory separators or NUL character.

Brett Canon proposed to not include the optimizer tag in .pyc filenames if it is "opt" to limit backward incompatible changes.

Note: The PEP 511 is under discussion on python-ideas. The patch implements the first version of the PEP, sent to python-ideas, so it doesn't include proposed changes like changing code_transformer() prototype to "def code_transformer(self, code, context)".

See also the issue #26100: add test.support.optim_args_from_interpreter_flags().

----------
files: transformers.patch
keywords: patch
messages: 258509
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: PEP 511: Add sys.set_code_transformers()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41643/transformers.patch

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

From report at bugs.python.org  Mon Jan 18 12:04:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jan 2016 17:04:51 +0000
Subject: [New-bugs-announce] [issue26146] PEP 511: Add ast.Constant to allow
 AST optimizer to emit constants
Message-ID: <1453136691.51.0.69393755181.issue26146@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, the Python parser emits ast.Tuple AST nodes which are compiled to multiple LOAD_xxx instructions followed a final BUILD_TUPLE instruction. The Python peephole optimizer detect LOAD_CONST x n + BUILD_TUPLE instructions to replace it directly with a tuple constant.

IHMO it's better to implement this optimization early at the AST level in an AST optimizer. The PEP 511 proposes to add a new ast.Constant AST node for that.

With this new AST node, the AST optimizer can emit tuple constants, but also any kind of constant like frozenset. For example, it's also possible to optimize "x in {1, 2}" to "x in frozenset({1, 2})" where frozenset({1, 2}) is a constant (don't call frozenset type at runtime). (Again, this optimization is already implemented in the peephole optimizer, it's just an example.)

Attached patch adds the new ast.Constant type but update also code consuming AST to handle this new kind of node:

* add the node: Parser/Python.asdl, Parser/asdl.py, Parser/asdl_c.py
* generated changes: Include/asdl.h, Include/Python-ast.h, Python/Python-ast.c
* accept the node kind: Python/symtable.c, Python/ast.c
* accept Constant instead of Num or Str: Lib/ast.py, Python/future.c, Tools/parser/unparse.py
* emit constants to bytecode: Python/compile.c

I didn't change the compiler to emit directly ast.Constant nodes to reduce the impact on the backward compatibility. This change can be done. An AST optimizer is responsible to convert NameConstant (False, True, None), Num (int, float, complex), Str, Bytes, Tuple to Constant. Example with fatoptimizer:
https://github.com/haypo/fatoptimizer/blob/2d794f511fe23ccde320725c6d12ce5ce8ffbdfe/fatoptimizer/convert_const.py

ast.Constant also simplifies AST optimizers: no need to check each time if a node is constant or not.

Adding a new kind of node was already proposed in the old issue #11549: the patch adds ast.Lit (it was proposed to rename it to ast.Literal).

----------
files: constant.patch
keywords: patch
messages: 258528
nosy: benjamin.peterson, brett.cannon, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PEP 511: Add ast.Constant to allow AST optimizer to emit constants
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41647/constant.patch

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

From report at bugs.python.org  Mon Jan 18 13:21:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 18:21:49 +0000
Subject: [New-bugs-announce] [issue26147] Encoding errors in xmlrpc
Message-ID: <1453141309.77.0.0400539753207.issue26147@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes issue with sending non-encodable string via XML RPC. This issue caused raising an exception or even hanging.

----------
components: Library (Lib), XML
files: xmlrpc_escape_nonencodable-3.x.patch
keywords: patch
messages: 258537
nosy: loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Encoding errors in xmlrpc
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41648/xmlrpc_escape_nonencodable-3.x.patch

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

From report at bugs.python.org  Mon Jan 18 15:09:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Jan 2016 20:09:48 +0000
Subject: [New-bugs-announce] [issue26148] String literals are not interned
 if in a tuple
Message-ID: <1453147788.86.0.284579420871.issue26148@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Usually string literals are interned. But not if they are a part of constant tuple.

>>> def abc(): pass
... 
>>> x = 'abc'
>>> x is abc.__name__
True
>>> x = ('abc',)
>>> x[0] is abc.__name__
False

This makes effect on namedtuples (issue25981). May make effect on __slots__ or other uses of constant tuples since searching a value in a tuple when values are not identical is a little slower that when they are identical.

----------
components: Interpreter Core
messages: 258542
nosy: benjamin.peterson, brett.cannon, georg.brandl, haypo, ncoghlan, rhettinger, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: String literals are not interned if in a tuple

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

From report at bugs.python.org  Mon Jan 18 16:48:48 2016
From: report at bugs.python.org (John Hagen)
Date: Mon, 18 Jan 2016 21:48:48 +0000
Subject: [New-bugs-announce] [issue26149] Suggest PyCharm Community as an
 editor for Unix platforms
Message-ID: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>


New submission from John Hagen:

The Python documentation recommends editors that can be used on Unix:
https://docs.python.org/3.5/using/unix.html#editors

If the intent is to advertise very excellent IDEs (as Geany and Komodo Edit are listed), I suggest that PyCharm Community Edition (https://www.jetbrains.com/pycharm/download/) be added to the list.

It is free, has a very powerful static analyzer, comes with PEP8 checking installed by default, supports type hinting, ... (https://www.jetbrains.com/pycharm/features/)

----------
assignee: docs at python
components: Documentation
messages: 258551
nosy: John Hagen, docs at python
priority: normal
severity: normal
status: open
title: Suggest PyCharm Community as an editor for Unix platforms
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/issue26149>
_______________________________________

From report at bugs.python.org  Tue Jan 19 06:06:38 2016
From: report at bugs.python.org (=?utf-8?b?0JLQu9Cw0LTQuNGB0LvQsNCyINCQ0LvQtdC60YHQsNC90LTRgNC+0LLQuNGH?=)
Date: Tue, 19 Jan 2016 11:06:38 +0000
Subject: [New-bugs-announce] [issue26150] SequenceMatcher's algorithm is not
 correct
Message-ID: <1453201598.83.0.994407990741.issue26150@psf.upfronthosting.co.za>


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

For strings 'aaaaaa', 'aabaaa' SequenceMatcher's algorithm finds only common substring 'aaa', while well-known classic LCS algorithm: http://www.geeksforgeeks.org/printing-longest-common-subsequence/ finds 'aa' and 'aaa'.

Is it the price for "best case time is linear", as mentioned in difflib's documentation? Are there any other reasons not to implement classic LCS algorith (e.g. memory limits?)? If no, maybe it will be usefull to create subclass StrictSequenceMatcher?

----------
messages: 258582
nosy: ????????? ?????????????
priority: normal
severity: normal
status: open
title: SequenceMatcher's algorithm is not correct
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan 19 06:52:04 2016
From: report at bugs.python.org (Johnny Wezel)
Date: Tue, 19 Jan 2016 11:52:04 +0000
Subject: [New-bugs-announce] [issue26151] str(bytes) does __repr__() instead
 of __str__()
Message-ID: <1453204324.06.0.936189522154.issue26151@psf.upfronthosting.co.za>


New submission from Johnny Wezel:

str(b'xxx') returns "b'xxx'" instead of 'xxx'

----------
components: Interpreter Core, Unicode
messages: 258583
nosy: ezio.melotti, haypo, jwezel
priority: normal
severity: normal
status: open
title: str(bytes) does __repr__() instead of __str__()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan 19 07:01:37 2016
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 19 Jan 2016 12:01:37 +0000
Subject: [New-bugs-announce] [issue26152] A non-breaking space in a source
Message-ID: <1453204897.88.0.969876573405.issue26152@psf.upfronthosting.co.za>


New submission from Adam Barto?:

Consider the following code:
>>> 1,?2
  File "<stdin>", line 1
    1,?2
       ^
SyntaxError: invalid character in identifier

The error is due to the fact, that the space before "2" is actually a non-breaking space. The error message and the position of the caret is misleading.

The tokenize module gives an ERRORTOKEN at the position of the space, so shouldn't the massage be more like "invalid syntax" with the correct position or even something more appropriate?

----------
components: Interpreter Core, Unicode
messages: 258584
nosy: Drekin, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: A non-breaking space in a source
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Jan 19 07:14:30 2016
From: report at bugs.python.org (Min RK)
Date: Tue, 19 Jan 2016 12:14:30 +0000
Subject: [New-bugs-announce] [issue26153] PyImport_GetModuleDict: no module
 dictionary! when `__del__` triggers a warning
Message-ID: <1453205670.9.0.210259286868.issue26153@psf.upfronthosting.co.za>


New submission from Min RK:

PyImport_GetModuleDict: no module dictionary! can be raised during interpreter shutdown if a `__del__` method results in a warning. This only happens on Python 3.5.

The prompting case is IPython 4.0.2 and traitlets 4.1.0. An IPython ExtensionManager calls `self.shell.on_trait_change` during its `__del__` to unregister a listener. That `on_trait_change` method is deprecated, and tries to display a DeprecationWarning. The call to `warnings.warn results in:

    Fatal Python error: PyImport_GetModuleDict: no module dictionary!

There appear to be races involved, because the crash happens with inconsistent frequency, sometimes quite rarely.

I've tried to put together a simple minimal test case, but I cannot reproduce the crash outside of IPython. I can, however, reproduce inconsistent behavior where a UserWarning displayed during `__del__` sometimes fails with

    ImportError: import of 'linecache' halted; None in sys.modules

and sometimes the exact same code succeeds, showing the error:

    ~/dev/tmp/del-warn/a.py:9: DeprecationWarning: I don't cleanup anymore
      self.b.cleanup()

and sometimes it shows the warning but not the frame

    ~/dev/tmp/del-warn/a.py:9: DeprecationWarning: I don't cleanup anymore

----------
components: Interpreter Core
messages: 258586
nosy: minrk
priority: normal
severity: normal
status: open
title: PyImport_GetModuleDict: no module dictionary! when `__del__` triggers a warning
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan 19 07:30:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 12:30:33 +0000
Subject: [New-bugs-announce] [issue26154] Add private
 _PyThreadState_FastGet() to get the current thread state
Message-ID: <1453206633.27.0.0623775421981.issue26154@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #25150 modified pystate.h to hide _PyThreadState_Current. Sadly, this change broke the vmprof project:
https://mail.python.org/pipermail/python-dev/2016-January/142767.html

Attached patches adds a new private _PyThreadState_FastGet() function to get the current thread state but don't call Py_FatalError() if it is NULL.

The patch also uses replace direct access to _PyThreadState_Current with _PyThreadState_FastGet(), except inside ceval.c and pystate.c.

Calling Py_FatalError() to handle errors is not really a great API... Bad that's a different story, I don't want to break anything here.

I want to add the private function to Python 3.5.2 because I consider that the removal of the _PyThreadState_Current symbol is a regression introduced in Python 3.5.1.

We have no rule for the Python private API, it can change *anytime*.

----------
files: pythreadstate_fastget.patch
keywords: patch
messages: 258587
nosy: haypo, larry
priority: normal
severity: normal
status: open
title: Add private _PyThreadState_FastGet() to get the current thread state
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41660/pythreadstate_fastget.patch

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

From report at bugs.python.org  Tue Jan 19 09:26:47 2016
From: report at bugs.python.org (TarotRedhand)
Date: Tue, 19 Jan 2016 14:26:47 +0000
Subject: [New-bugs-announce] [issue26155] 3.5.1 installer issue on Win 7 32
 bit
Message-ID: <1453213607.65.0.0758375238655.issue26155@psf.upfronthosting.co.za>


New submission from TarotRedhand:

This is not in the Python Core but in the installer for version 3.5.1 on windows 32 bit. It occurs with the custom install option. I gave a verified new location for python to be installed to but it installed in MyDocuments anyway.

----------
components: Installation
messages: 258595
nosy: TarotRedhand
priority: normal
severity: normal
status: open
title: 3.5.1 installer issue on Win 7 32 bit
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan 19 09:41:26 2016
From: report at bugs.python.org (=?utf-8?q?Chema_Cort=C3=A9s?=)
Date: Tue, 19 Jan 2016 14:41:26 +0000
Subject: [New-bugs-announce] [issue26156] Bad name into power operator syntax
Message-ID: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>


New submission from Chema Cort?s:

The documentation erroneously changes "primary" for "away" in the power operator syntax:

https://docs.python.org/3.6/reference/expressions.html#the-power-operator
https://docs.python.org/3.5/reference/expressions.html#the-power-operator

----------
assignee: docs at python
components: Documentation
messages: 258596
nosy: Chema Cort?s, docs at python
priority: normal
severity: normal
status: open
title: Bad name into power operator syntax
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jan 19 10:16:28 2016
From: report at bugs.python.org (Frank Millman)
Date: Tue, 19 Jan 2016 15:16:28 +0000
Subject: [New-bugs-announce] [issue26157] Typo in asyncio documentation
Message-ID: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>


New submission from Frank Millman:

18.5.1.15. Server

close()

"The sockets that represent existing incoming client connections are leaved open."

I think this should say 'are left open'.

----------
assignee: docs at python
components: Documentation
messages: 258599
nosy: docs at python, frankmillman
priority: normal
severity: normal
status: open
title: Typo in asyncio documentation
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jan 19 10:19:44 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 15:19:44 +0000
Subject: [New-bugs-announce] [issue26158] File truncate() not defaulting to
 current position as documented
Message-ID: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>


New submission from Fornax:

io.IOBase.truncate() documentation says:
"Resize the stream to the given size in bytes (or the current position if size is not specified). The current stream position isn?t changed. This resizing can extend or reduce the current file size. In case of extension, the contents of the new file area depend on the platform (on most systems, additional bytes are zero-filled). The new file size is returned."

However:
>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.readline()
'ABCDE\n'
>>> f.tell()
6                   # As expected, current position is 6 after the readline
>>> f.truncate()
32                  # ?!

Verified that the document does not get truncated to 6 bytes as expected. Adding an explicit f.seek(6) before the truncate causes it to work properly (truncate to 6). It also works as expected using a StringIO rather than a file, or in Python 2 (used 2.7.9).

Tested in 3.4.3/Windows, 3.4.1/Linux, 3.5.1/Linux.

----------
components: IO
messages: 258600
nosy: fornax
priority: normal
severity: normal
status: open
title: File truncate() not defaulting to current position as documented
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jan 19 11:14:58 2016
From: report at bugs.python.org (Bradley McLean)
Date: Tue, 19 Jan 2016 16:14:58 +0000
Subject: [New-bugs-announce] [issue26159] Unsafe to
 BaseEventLoop.set_debug(False) when PYTHONASYNCIODEBUG=1
Message-ID: <1453220098.77.0.244617474798.issue26159@psf.upfronthosting.co.za>


New submission from Bradley McLean:

Leads to spurious RuntimeWarning: coroutine  was never awaited messages, when @asyncio.coroutine methods call async def methods.  Likely because decorators ran before set_debug set False, and are assuming it won't change.

----------
components: asyncio
messages: 258607
nosy: Bradley McLean, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Unsafe to BaseEventLoop.set_debug(False) when PYTHONASYNCIODEBUG=1
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan 20 02:02:32 2016
From: report at bugs.python.org (Kevin Norris)
Date: Wed, 20 Jan 2016 07:02:32 +0000
Subject: [New-bugs-announce] [issue26160] Tutorial incorrectly claims that
 (explicit) relative imports don't work in the main module
Message-ID: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>


New submission from Kevin Norris:

The tutorial contains this statement:

Note that relative imports are based on the name of the current module. Since the name of the main module is always "__main__", modules intended for use as the main module of a Python application must always use absolute imports.

See <https://docs.python.org/3/tutorial/modules.html#intra-package-references>.  The wording is slightly different in the 2.7 version of the tutorial to account for the existence of implicit relative imports, but it clearly states that explicit relative imports suffer from this limitation.

As of PEP 366, this is no longer true.  You can do (explicit) relative imports in the main module just fine (though with some minor caveats w.r.t. using the -m flag vs. specifying the .py file directly).  PEP 366 has a Python-Version of 2.6, 3.0, so every sufficiently recent version of the tutorial is wrong.

It's probably not a good idea to get too far into those caveats in the tutorial.  I'd suggest wording like this:

Note that relative imports are based on the name of the current package.  If Python is invoked with the -m switch, it can determine the package name automatically, but if it is invoked directly as ``python file.py``, relative imports will not work because Python doesn't know what package file.py belongs to.

It might be worth mentioning __package__ here, too, but we don't want to get too far down the rabbit hole of trivia (e.g. PEP 366 discusses sys.path manipulation, and for that you probably want to use __file__ instead of hard-coding the path, and then you have to talk about zipimports, and then, and then, and then...!).

(For the record, is the 2.7 tutorial still under active support?  Is it okay to report bugs in it?)

----------
assignee: docs at python
components: Documentation
messages: 258650
nosy: Kevin.Norris, docs at python
priority: normal
severity: normal
status: open
title: Tutorial incorrectly claims that (explicit) relative imports don't work in the main module
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/issue26160>
_______________________________________

From report at bugs.python.org  Wed Jan 20 05:57:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 10:57:13 +0000
Subject: [New-bugs-announce] [issue26161] Use Py_uintptr_t instead of void*
 for atomic pointers
Message-ID: <1453287433.06.0.917991277181.issue26161@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch fixes compiler warnings on atomic pointers.

Python has 4 implementations of atomic types:

* <stdatomic.h>
* GCC 4.7+ builtin atomic operations
* GCC x86 and x86_64 assembler
* volatile

The type of atomic pointers changes depending on the implementation. Attached patch changes the _Py_atomic_address to use atomic_uintptr_t (<stdatomic.h>) or Py_uintptr_t type internally.

The patchs also adds GET_TSTATE(), SET_TSTATE() and GET_INTERP_STATE() macros in pystate.c to make the code more readable.

This issue is a follow up of the issue #22038 which added support for <stdatomic.h> in Python/pyatomic.h. See also issues #23644 (compilation issue with g++), #25150 (compilation issue with OpenMP) and #26154 (add _PyThreadState_UncheckedGet()).

I would be "nice" to backport this change to Python 3.5.2 to fix the compiler warning, but I'm not 100% confident that my patch works on all compilers and all platforms. Maybe it's better to "experiment" it only in Python 3.6.

Note: I copied the nosy list of the issue #22038 since this one is a follow up.

----------
components: Interpreter Core
files: atomic_pointer.patch
keywords: patch
messages: 258661
nosy: Arfrever, John.Malmberg, Vitor.de.Lima, fijall, gustavotemple, haypo, koobs, lbianc, neologix
priority: normal
severity: normal
status: open
title: Use Py_uintptr_t instead of void* for atomic pointers
versions: Python 3.6
Added file: http://bugs.python.org/file41667/atomic_pointer.patch

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

From report at bugs.python.org  Wed Jan 20 06:28:44 2016
From: report at bugs.python.org (Ali Razmjoo)
Date: Wed, 20 Jan 2016 11:28:44 +0000
Subject: [New-bugs-announce] [issue26162] thread error
Message-ID: <1453289324.96.0.367077041612.issue26162@psf.upfronthosting.co.za>


New submission from Ali Razmjoo:

Hello,

I've got a problem while using threading in python 2.7.10 windows.
I copied errors in here https://gist.github.com/Ali-Razmjoo/d503171d338c6381f94f

with 845 threads,870 and 1000. there isn't any problem or error with 840-830 threads!

----------
messages: 258667
nosy: Ali Razmjoo
priority: normal
severity: normal
status: open
title: thread error
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 20 07:37:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 12:37:44 +0000
Subject: [New-bugs-announce] [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
Message-ID: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The buildbot "x86 Ubuntu Shared 3.x" build 12691 failed, the previous builds succeeded. Changes:

* f97da0952a2ebe08f2e5999c7473c776c59f3a16 (issue #25982)
* 775b74e0e103f816382a0fc009b6ac51ea956750 (issue #26107)

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/12691/steps/test/logs/stdio

======================================================================
FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_set.py", line 736, in test_hash_effectiveness
    self.assertGreater(4*u, t)
AssertionError: 192 not greater than 256

======================================================================
FAIL: test_hash_effectiveness (test.test_set.TestFrozenSetSubclass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_set.py", line 736, in test_hash_effectiveness
    self.assertGreater(4*u, t)
AssertionError: 192 not greater than 256

----------
components: Tests
keywords: buildbot
messages: 258674
nosy: haypo
priority: normal
severity: normal
status: open
title: FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)
versions: Python 3.6

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

From report at bugs.python.org  Wed Jan 20 07:39:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 12:39:00 +0000
Subject: [New-bugs-announce] [issue26164] test_with_pip() of test_venv fails
 on Windows buildbots
Message-ID: <1453293540.51.0.991113408845.issue26164@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Windows7%203.5/builds/591/steps/test/logs/stdio

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.5.bolen-windows7\build\lib\test\test_venv.py", line 379, in test_with_pip
    self.assertEqual(err, "")
AssertionError: "d:\\temp\\tmpcyw9drz0\\lib\\site-package[323 chars]\r\n" != ''
- d:\temp\tmpcyw9drz0\lib\site-packages\pip\pep425tags.py:89: RuntimeWarning: Config variable 'Py_DEBUG' is unset, Python ABI tag may be incorrect
-   warn=(impl == 'cp')):
- d:\temp\tmpcyw9drz0\lib\site-packages\pip\pep425tags.py:93: RuntimeWarning: Config variable 'WITH_PYMALLOC' is unset, Python ABI tag may be incorrect
-   warn=(impl == 'cp')):

----------
messages: 258675
nosy: dstufft, haypo
priority: normal
severity: normal
status: open
title: test_with_pip() of test_venv fails on Windows buildbots
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan 20 12:36:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jan 2016 17:36:12 +0000
Subject: [New-bugs-announce] [issue26165] devguide: table summarizing status
 of Python branches
Message-ID: <1453311372.86.0.442915333055.issue26165@psf.upfronthosting.co.za>


New submission from STINNER Victor:

A frequent question is to get the status of a Python branch: is it still maintained? when does the support stop?

Attached patch adds a short table giving the current status of Python branches between 2.6 and 3.6 (default).

I sorted branches by their status, nor by their value, to show immediatly that 2.7 is still at the top :-)

For the future end-of-life, I took the year of the last binary release and I added 5 years. Is that right?

----------
components: Devguide
files: branch_status.patch
keywords: patch
messages: 258696
nosy: ezio.melotti, haypo, willingc
priority: normal
severity: normal
status: open
title: devguide: table summarizing status of Python branches
Added file: http://bugs.python.org/file41672/branch_status.patch

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

From report at bugs.python.org  Wed Jan 20 12:49:43 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 17:49:43 +0000
Subject: [New-bugs-announce] [issue26166] zlib compressor/decompressor
 objects should support copy protocol
Message-ID: <1453312183.38.0.668863762812.issue26166@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

zlib.compressobj and zlib.decompressobj objects (actually zlib.Compress and zlib.Decompress, the other names are the function constructors I guess?) have a .copy() method, but don't implement `__copy__` or `__deepcopy__`. This leads to the mildly silly result that a copyable object can't be copied using the common copy protocol.

I see two solutions:

1. Implement `__copy__` and `__deepcopy__` directly for the zlib objects
2. Have the copy module include them in _copy_dispatch mapped to the existing _copy_with_copy_method (and use a similar approach for _deepcopy_dispatch, since AFAICT this isn't a case where deep copying differs from shallow copying)

The former makes for more C code in CPython, and would require matching updates in the zlib used by all alternate CPython interpreters, but is probably faster and introduces no new cross-module dependencies.

The latter would make zlib an import dependency of copy (or vice versa, if zlib messed with copy's internals on import), but involves only a trivial amount of new Python code and wouldn't require any changes by alternate Python implementations that used the core copy module (when they update to the new copy, they get the support for free).

----------
components: Extension Modules, Library (Lib)
messages: 258700
nosy: josh.r
priority: normal
severity: normal
status: open
title: zlib compressor/decompressor objects should support copy protocol
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan 20 13:07:38 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Jan 2016 18:07:38 +0000
Subject: [New-bugs-announce] [issue26167] Improve copy.copy speed for
 built-in types
Message-ID: <1453313258.69.0.822432262864.issue26167@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

copy.copy uses a relatively high overhead approach to copying list, set and dict, using:

    def _copy_with_constructor(x):
        return type(x)(x)

This is despite the fact that all three types implement a .copy() method, and there is already a defined method:

    def _copy_with_copy_method(x):
        return x.copy()

that (in %timeit tests) runs with substantially less overhead, in percentage terms; for empty lists, sets and dicts, calling _copy_with_constructor or _copy_with_copy_method directly on them, the times on my machine (Python 3.5.0, Linux x86-64) are:

empty list: 281 ns (constructor), 137 ns (method)
empty set: 275 ns (constructor), 175 ns (method)
empty dict: 372 ns (constructor), 211 ns (method)

The method costs could be trimmed further if _copy_with_copy_method was changed from a Python implementation to using operator.methodcaller, e.g.

    try:
        # If we have _operator, avoids cost of importing Python code; it's part of core modules in CPython, already loaded for free
        from _operator import methodcaller  
    except ImportError:
        from operator import methodcaller

    _copy_with_copy_method = methodcaller('copy')

This doesn't save a whole lot more (shaves another 9-17 ns off the times for the Python version of _copy_with_copy_method), but it's nice in that it avoids reinventing the wheel in the copy module. Combining the two changes (to use methodcaller for _copy_with_copy_method and to have list, set and dict use _copy_with_copy_method) means we can get rid of both Python defined functions in favor of a single use of operator.methodcaller used by all types that previously used either of them.

Obviously not a high priority fix, but I noticed this while trying to figure out a way to fix zlib's lack of support in the copy module ( #26166 which apparently duplicates #25007 ) and how to work around it.

----------
components: Library (Lib)
messages: 258704
nosy: josh.r
priority: normal
severity: normal
status: open
title: Improve copy.copy speed for built-in types
type: performance
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan 20 13:26:25 2016
From: report at bugs.python.org (squidevil)
Date: Wed, 20 Jan 2016 18:26:25 +0000
Subject: [New-bugs-announce] [issue26168] Py_BuildValue may leak 'N'
 arguments on PyTuple_New failure
Message-ID: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>


New submission from squidevil:

Expected behavior:
  Calling Py_BuildValue with a 'N' argument should take ownership of the N object, and on failure (returns NULL), call Py_DECREF() on any N argument.  The documentation explicitly says that this is the intended usage:
    "N": Same as "O", except it doesn't increment the reference count on the object. Useful when the object is created by a call to an object constructor in the argument list.

Actual behavior:
  N objects appear to be abandoned/leaked in some cases.

Example: PyBuildValue("iN", 0, obj);

* calls _Py_BuildValue_SizeT via macro
* calls va_build_value (in modsupport.c)
* calls do_mktuple [0]
* [0] first calls v = PyTuple_New(n=2). If this fails, it returns NULL, leaking obj.
* if [0] creates the tuple v, then it goes on to populate the values in the tuple.
* [0] calls do_mkvalue() to create the "i=0" object.  If this fails, obj is never Py_DECREF()'ed.

Many other leaks are possible, as long as at least one allocation occurs prior to the processing of the N arguments.

----------
components: Interpreter Core
messages: 258708
nosy: squidevil
priority: normal
severity: normal
status: open
title: Py_BuildValue may leak 'N' arguments on PyTuple_New failure
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 20 16:14:07 2016
From: report at bugs.python.org (Soufiane BOUSSALI)
Date: Wed, 20 Jan 2016 21:14:07 +0000
Subject: [New-bugs-announce] [issue26169] Buffer OverFlow
Message-ID: <1453324447.34.0.636986980752.issue26169@psf.upfronthosting.co.za>


Changes by Soufiane BOUSSALI <soufiane.boussali at efet.ac.ma>:


----------
components: IDLE
files: poc.py
nosy: Soufiane BOUSSALI
priority: normal
severity: normal
status: open
title: Buffer OverFlow
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file41673/poc.py

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

From report at bugs.python.org  Wed Jan 20 19:57:37 2016
From: report at bugs.python.org (Vinyl Darkscratch-Kazotetsu)
Date: Thu, 21 Jan 2016 00:57:37 +0000
Subject: [New-bugs-announce] [issue26170] pip Crash on Unpacking in
 get_platform() line 119
Message-ID: <1453337857.76.0.99047592718.issue26170@psf.upfronthosting.co.za>


New submission from Vinyl Darkscratch-Kazotetsu:

Since upgrading to pip 8.0, I get a crash whenever I try to run it.  It fails to unpack to major, minor, and micro for the release, saying there's only two values.

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/bin/pip", line 7, in <module>
    from pip import main
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/__init__.py", line 15, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/vcs/subversion.py", line 9, in <module>
    from pip.index import Link
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/index.py", line 29, in <module>
    from pip.wheel import Wheel, wheel_ext
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/wheel.py", line 32, in <module>
    from pip import pep425tags
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py", line 214, in <module>
    supported_tags = get_supported()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py", line 162, in get_supported
    arch = get_platform()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/pep425tags.py", line 119, in get_platform
    major, minor, micro = release.split('.')
ValueError: need more than 2 values to unpack

----------
components: Macintosh
messages: 258726
nosy: Vinyl Darkscratch-Kazotetsu, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: pip Crash on Unpacking in get_platform() line 119
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 20 22:52:33 2016
From: report at bugs.python.org (Insu Yun)
Date: Thu, 21 Jan 2016 03:52:33 +0000
Subject: [New-bugs-announce] [issue26171] heap overflow in zipimporter module
Message-ID: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za>


New submission from Insu Yun:

in zipimport.c
  1116     bytes_size = compress == 0 ? data_size : data_size + 1;
  1117     if (bytes_size == 0)
  1118         bytes_size++;
  1119     raw_data = PyBytes_FromStringAndSize((char *)NULL, bytes_size);

If compress != 0, then bytes_size = data_size + 1
data_size is not sanitized, so if data_size = -1, then it overflows and becomes 0.
In that case bytes_size becomes 1 and python allocates small heap, but after that in fread, it overflows heap.

----------
files: crash.py
messages: 258733
nosy: Insu Yun
priority: normal
severity: normal
status: open
title: heap overflow in zipimporter module
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file41677/crash.py

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

From report at bugs.python.org  Thu Jan 21 00:48:23 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 21 Jan 2016 05:48:23 +0000
Subject: [New-bugs-announce] [issue26172] iBook can't open ePub
Message-ID: <1453355303.75.0.605572221579.issue26172@psf.upfronthosting.co.za>


New submission from INADA Naoki:

Script cannot run in iBook is included in ePub.
Attached patch resolves the issue.

----------
assignee: docs at python
components: Documentation
files: epub.patch
keywords: patch
messages: 258734
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: iBook can't open ePub
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41678/epub.patch

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

From report at bugs.python.org  Thu Jan 21 05:46:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 21 Jan 2016 10:46:23 +0000
Subject: [New-bugs-announce] [issue26173] test_ssl.bad_cert_test() exception
 handling
Message-ID: <1453373183.85.0.754157160572.issue26173@psf.upfronthosting.co.za>


New submission from Martin Panter:

In bad_cert_test(), there are two OSError exception handler; one masking the other. In Python 3, I think we should remove the second (dead) handler. In Python 2, maybe the first OSError handler should catch socket.error instead.

Originally, in r80534, socket.error was caught and ignored, with the vague explanation ?socket.error can really happen here?. Then revision 9297974604ff added an IOError handler, presumably to catch ENOENT for test_nonexisting_cert().

Later, in revisions 50d19c2fac82 and 9297974604ff, socket.error and IOError were both changed to OSError. I guess in Python 3 we should just catch all OSError exceptions and remove the second handler that only wants ENOENT.

In Python 2, there was a large backport of SSL functionality in revision 221a1f9155e2 (Issue 21308). It seems to have brought too much of the OSError alias changes with it. This is probably the cause of the following 2.7 builtbot failure:

http://buildbot.python.org/all/builders/x86%20XP-4%202.7/builds/3580/steps/test/logs/stdio
======================================================================
ERROR: test_nonexisting_cert (test.test_ssl.ThreadedTests)
Connecting with a non-existing cert file
----------------------------------------------------------------------
Traceback (most recent call last):
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_ssl.py", line 2153, in test_nonexisting_cert
    "wrongcert.pem"))
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_ssl.py", line 1889, in bad_cert_test
    s.connect((HOST, server.port))
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\ssl.py", line 844, in connect
    self._real_connect(addr, False)
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\ssl.py", line 835, in _real_connect
    self.do_handshake()
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\ssl.py", line 808, in do_handshake
    self._sslobj.do_handshake()
error: [Errno 10054] An existing connection was forcibly closed by the remote host

Errno 10054 is apparently ECONNRESET.

----------
components: Tests
keywords: buildbot
messages: 258754
nosy: martin.panter
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl.bad_cert_test() exception handling
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jan 21 10:48:20 2016
From: report at bugs.python.org (Jan Pokorny)
Date: Thu, 21 Jan 2016 15:48:20 +0000
Subject: [New-bugs-announce] [issue26174] Exception alias cause destruction
 of existing variable
Message-ID: <1453391300.18.0.241912144859.issue26174@psf.upfronthosting.co.za>


New submission from Jan Pokorny:

Encountered a weird behavior when working with variable with the same name as exception's alias.

Observed behavior:

- In case variable with the same name (e.g. 'e') already exists when any 'except Error as e' block is executed, the 'e' variable is removed after exception handling finishes (NameError: name 'e' is not defined)

- Happens only in Python 3
- Code reproducing the issue included

Expected behavior:

- Variable is kept in its pre-exception state

Proposed solution:

- Store colliding variable into temporary variable, restore it afterwards

----------
components: Interpreter Core
files: schrodinger.py
messages: 258757
nosy: japokorn
priority: normal
severity: normal
status: open
title: Exception alias cause destruction of existing variable
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file41683/schrodinger.py

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

From report at bugs.python.org  Thu Jan 21 16:54:34 2016
From: report at bugs.python.org (Gary Fernie)
Date: Thu, 21 Jan 2016 21:54:34 +0000
Subject: [New-bugs-announce] [issue26175] Fully implement IOBase abstract on
 SpooledTemporaryFile
Message-ID: <1453413274.25.0.536987988375.issue26175@psf.upfronthosting.co.za>


New submission from Gary Fernie:

SpooledTemporaryFile does not fully satisfy the abstract for IOBase.
Namely, `seekable`, `readable`, and `writable` are missing.

This was discovered when seeking a SpooledTemporaryFile-backed lzma file.
You may quickly repro this:
`lzma.open(SpooledTemporaryFile()).seek(0)`

----------
files: fix-SpooledTemporaryFile-IOBase-abstract.patch
keywords: patch
messages: 258769
nosy: Gary Fernie
priority: normal
severity: normal
status: open
title: Fully implement IOBase abstract on SpooledTemporaryFile
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/file41685/fix-SpooledTemporaryFile-IOBase-abstract.patch

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

From report at bugs.python.org  Thu Jan 21 20:58:36 2016
From: report at bugs.python.org (Srujan Chaitanya)
Date: Fri, 22 Jan 2016 01:58:36 +0000
Subject: [New-bugs-announce] [issue26176] EmailMessage example doesn't work
Message-ID: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>


New submission from Srujan Chaitanya:

Example provided in 19.1.14.1. Examples using the Provisional API
at https://docs.python.org/3.4/library/email-examples.html?highlight=email%20example

Doesn't work. This could be a EmailMessage class issue also?

----------
assignee: docs at python
components: Documentation
messages: 258781
nosy: Srujan Chaitanya, docs at python
priority: normal
severity: normal
status: open
title: EmailMessage example doesn't work
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 22 01:51:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jan 2016 06:51:29 +0000
Subject: [New-bugs-announce] [issue26177] tkinter: Canvas().keys returns
 empty strings.
Message-ID: <1453445489.52.0.0197706093826.issue26177@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

tkinter wraps tk widgets as option-value mappings with subscripting and .keys().  The latter does not work for Canvas (subscripting does).  First tested with 3.5.1, Win 10. First Text versus Canvas contrast below was confirmed with 2.7.11.

>>> import tkinter as tk
>>> tk.Text().keys()
['autoseparators', 'background', 'bd', 'bg', 'blockcursor', 'tabstyle', 
...
'takefocus', 'undo', 'width', 'wrap', 'xscrollcommand', 'yscrollcommand']
>>> tk.Canvas().keys()
['', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '']

Explanation: Widget classes inherit keys from Misc via BaseWidget and Widget.  Misc.keys calls into tk.

    def keys(self):
        """Return a list of all resource names of this widget."""
        return [x[0][1:] for x in
                self.tk.splitlist(self.tk.call(self._w, 'configure'))]

The call returns different types for Text and Canvas.

>>> self = tk.Text()
>>> self.tk.call(self._w, 'configure')  # tuple of tuples
(('-autoseparators', 'autoSeparators', 'AutoSeparators', 1, 1),
 ('-background', 'background', 'Background', <border object: 'SystemWindow'>, 'SystemWindow'), <etc>)
>>> self = tk.Canvas()
>>> self.tk.call(self._w, 'configure')  # tcl list as single string
'{-background background Background SystemButtonFace SystemButtonFace} {-bd borderWidth} {-bg background} {-borderwidth borderWidth BorderWidth 0 0} ...'

This difference between widgets seems odd.  A bug in tcl/tk/_tkinter?

tk.splitlist appears to return the Text tuple of tuples as is.  It splits the Canvas string into a tuple of strings

('-background background Background SystemButtonFace SystemButtonFace', '-bd borderWidth', ... )

but does not split the inner strings.  As a consequence, x[0] is the first character of each string ('{' as it turns out, though not relevant) and the slice [1:] of a single char string is always ''.

Possible remedy: tk.split also leaves tuple of tuples alone *and* splits the inner strings to a tuple.

>>> self.tk.split(self.tk.call(self._w, 'configure'))
(('-background', 'background', 'Background', 'SystemButtonFace', 'red'), ('-bd', 'borderWidth'), ...)

So a fix (if the different returns are not changed) is to change 'splitlines' to 'split'.  With this change, keys (extracted as a function) gives the expected list.

>>> keys(tk.Canvas())
['background', 'bd', ..., 'yscrollincrement']

A test for Canvas().keys should be added somewhere.

----------
messages: 258789
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: tkinter: Canvas().keys returns empty strings.
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan 22 08:35:34 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Fri, 22 Jan 2016 13:35:34 +0000
Subject: [New-bugs-announce] [issue26178] Python C-API: __all__ Creator
Message-ID: <1453469734.25.0.137084363575.issue26178@psf.upfronthosting.co.za>


New submission from Devyn Johnson:

When creating Python modules via th C-API, it would be wonderful if there were an easier and more efficient way of creating an "__all__" for the module. In my opinion, an API function should be made; i.e., something like PyALL("FUNC1", "FUNC2", ...)


Currently, I use something like the below code.

"""
PyObject *create_all(void);

PyObject *create_all(void) {  // Create __all__
#define _ALLSTRING "[ssssss"
#define _ENDSTRING "]"
    return Py_BuildValue(
        _ALLSTRING
#if defined(ENV64BIT) && (defined(__x86_64__) || defined(__x86_64))
        "sss"
#ifdef __BMI2__
        "ssss"
#endif
#endif
        _ENDSTRING,
        // STRING CONVERSIONS
        "lowercasestr",
        "uppercasestr",
        // FIND AND REPLACE/REMOVE
        "strreplace",
        "strreplace_once",
        "rmgravequote",
        // ASSEMBLY-RELATED COMMANDS
#if defined(ENV64BIT) && (defined(__x86_64__) || defined(__x86_64))
        "rdtsc",
        "get_vendor_id",
        "get_cpu_stepping",
#ifdef __BMI2__
        "is_fpu_aval",
        "is_avx_aval",
        "is_fma_aval",
        "is_aes_aval",
#endif
#endif
        "nop"
    );
}

// Some code excluded

MODINIT {  // Initialize module
    PyObject *m;
    m = PyModule_Create(&module);
    PyModule_AddObject(m, "__all__", create_all());
    PyModule_AddStringConstant(m, "__author__", __author__);
    PyModule_AddStringConstant(m, "__version__", __version__);
    if (m == NULL)
        return NULL;
    return m;
}
"""

----------
components: Interpreter Core
messages: 258804
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python C-API: __all__ Creator
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Jan 22 09:06:20 2016
From: report at bugs.python.org (Devyn Johnson)
Date: Fri, 22 Jan 2016 14:06:20 +0000
Subject: [New-bugs-announce] [issue26179] Python C-API "unused-parameter"
 warnings
Message-ID: <1453471580.75.0.72814531944.issue26179@psf.upfronthosting.co.za>


New submission from Devyn Johnson:

When compiling Python C-API extensions with "-Wextra", warnings like 

warning: unused parameter ?self? [-Wunused-parameter]

appear for code (like below). It seems like a minor issue for a warning to appear when "PyObject *self, PyObject *args" is required. Is there an underlying issue in the API?

static PyObject *mathfunc_ismersenneprime(PyObject *self, PyObject *args) {
    sllint num;
    ASSERT_LONGLONG_ARG(num);
    if (num < (sllint)0) ERR_POSITIVE_INT;
    returnbool(islonglongmersenneprime(num));
}

----------
components: Interpreter Core
messages: 258809
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python C-API "unused-parameter" warnings
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Jan 22 10:24:46 2016
From: report at bugs.python.org (Milan Zamazal)
Date: Fri, 22 Jan 2016 15:24:46 +0000
Subject: [New-bugs-announce] [issue26180]
 multiprocessing.util._afterfork_registry leak in threaded environment
Message-ID: <1453476286.88.0.329468896089.issue26180@psf.upfronthosting.co.za>


New submission from Milan Zamazal:

When calling multiprocessing.managers.BaseManager repeatedly from a client, each time from a new thread, new entry with (already existent) multiprocessing.util.ForkAwareLocal instance is inserted as a value into multiprocessing.util._afterfork_registry dictionary on each of the calls.  So the dictionary grows on each client call and may grow so indefinitely, causing memory leak if nothing else.

The attached file demonstrates the problem (Python 2.7 version, it's reproducible on 3.4 as well after 2->3 adjustments).  Just run it and look at the output.  The printed dictionary contains 10 entries holding the same ForkAwareLocal instance although there should be probably just one such entry there.

----------
components: Library (Lib)
files: bug.py
messages: 258816
nosy: mzamazal
priority: normal
severity: normal
status: open
title: multiprocessing.util._afterfork_registry leak in threaded environment
type: resource usage
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file41690/bug.py

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

From report at bugs.python.org  Fri Jan 22 11:35:32 2016
From: report at bugs.python.org (Alex)
Date: Fri, 22 Jan 2016 16:35:32 +0000
Subject: [New-bugs-announce] [issue26181] argparse can't handle positional
 argument after list (help message is wrong)
Message-ID: <1453480532.52.0.987369969347.issue26181@psf.upfronthosting.co.za>


New submission from Alex:

This code is meant to take a filename and a list of integers as arguments.  The filename is required, the integers are optional:

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('filename')
parser.add_argument('-L', metavar='integer', type=int, nargs='+')
args = parser.parse_args()
print(args)  # see what we got

It produces the following help message:
usage: demo.py [-h] [-L integer [integer ...]] filename

However, the filename argument does not work if it's given in that position (after the list of ints).  Instead, it tries to use filename as another list element:

$ python demo.py -L 1 2 3 test.txt
usage: demo.py [-h] [-L integer [integer ...]] filename
demo.py: error: argument -L: invalid int value: 'test.txt'

Changing the order of the arguments works as intended:

$ python demo.py test.txt -L 1 2 3 
Namespace(L=[1, 2, 3], filename='test.txt')

Probably the simplest fix would be to amend the help message to show the positional argument before the list:

usage: demo.py [-h] filename [-L integer [integer ...]]

----------
components: Library (Lib)
messages: 258823
nosy: atpage
priority: normal
severity: normal
status: open
title: argparse can't handle positional argument after list (help message is wrong)
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Jan 22 14:06:06 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 22 Jan 2016 19:06:06 +0000
Subject: [New-bugs-announce] [issue26182] Deprecation warnings for the
 future async and await keywords
Message-ID: <1453489566.62.0.462459552998.issue26182@psf.upfronthosting.co.za>


New submission from Marco Buttu:

I saw that async and await will become keywords in Python 3.7 :

https://www.python.org/dev/peps/pep-0492/#deprecation-plans

I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I noticed that assigning to async or await does not issue any deprecation warning: 

$ python -Wd -c "import sys; print(sys.version); async = 33"
3.5.1 (default, Jan 21 2016, 19:59:28)
[GCC 4.8.4]

$ python -Wd -c "import sys; print(sys.version); async = 33"
3.6.0a0 (default:4b434a4770a9, Jan 12 2016, 13:01:29)
[GCC 4.8.4]

----------
components: Interpreter Core
messages: 258833
nosy: marco.buttu
priority: normal
severity: normal
status: open
title: Deprecation warnings for the future async and await keywords
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan 22 16:05:11 2016
From: report at bugs.python.org (Roger Cook)
Date: Fri, 22 Jan 2016 21:05:11 +0000
Subject: [New-bugs-announce] [issue26183] 2.7.11 won't clean install on
 Windows 10 x64
Message-ID: <1453496711.72.0.869603030432.issue26183@psf.upfronthosting.co.za>


New submission from Roger Cook:

The Windows installer stops the installation and backs out on a clean system. Here is the relevant section of the log file (msiexec /i python-2.7.11.amd64.msi /l*v):

MSI (s) (14:90) [15:13:32:577]: Executing op: ActionStart(Name=RemovePip,,)
Action 15:13:32: RemovePip. 
MSI (s) (14:90) [15:13:32:578]: Executing op: CustomActionSchedule(Action=RemovePip,ActionType=3090,Source=C:\Python27\python.exe,Target=-B -m ensurepip._uninstall,)
MSI (s) (14:90) [15:13:32:579]: Note: 1: 1721 2: RemovePip 3: C:\Python27\python.exe 4: -B -m ensurepip._uninstall 
MSI (s) (14:90) [15:13:32:579]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RemovePip, location: C:\Python27\python.exe, command: -B -m ensurepip._uninstall 
MSI (s) (14:90) [15:13:37:027]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (14:90) [15:13:37:027]: Product: Python 2.7.10 (64-bit) -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RemovePip, location: C:\Python27\python.exe, command: -B -m ensurepip._uninstall 

Action ended 15:13:37: InstallFinalize. Return value 3.

--- end log ---

It appears that the installer tries to call the Python executable before it has been put in place. This fails, and the installer backs out.

Workaround: Install 2.7.10, then install 2.7.11 over it.

----------
components: Installation
messages: 258836
nosy: Roger Cook
priority: normal
severity: normal
status: open
title: 2.7.11 won't clean install on Windows 10 x64
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 22 17:31:00 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Jan 2016 22:31:00 +0000
Subject: [New-bugs-announce] [issue26184] raise an error when
 create_module() is not defined by exec_module() is for loaders
Message-ID: <1453501860.77.0.669534801782.issue26184@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As explained in https://docs.python.org/3/reference/import.html#loaders, as of Python 3.6 an error is to be raised when a loader defines exec_module() but not create_module(). Probably should raise a TypeError.

----------
components: Interpreter Core
messages: 258840
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: raise an error when create_module() is not defined by exec_module() is for loaders
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Jan 23 05:41:53 2016
From: report at bugs.python.org (Matthew Zipay)
Date: Sat, 23 Jan 2016 10:41:53 +0000
Subject: [New-bugs-announce] [issue26185] zipfile.ZipInfo slots can raise
 unexpected AttributeError
Message-ID: <1453545713.56.0.930101536202.issue26185@psf.upfronthosting.co.za>


New submission from Matthew Zipay:

The zipfile.ZipInfo.__init__ method permits several of ZipInfo's slot attributes to go uninitialized unless the object is obtained from ZipFile.getinfo() or ZipFile.infolist().

As a result, accessing those attributes (header_offset, CRC, compress_size, or file_size) or attempting to repr() a ZipInfo object can fail unexpectedly with AttributeError. (I say "unexpectedly" because ZipInfo.__init__ and its attributes are public/documented, so the attributes ought to be properly initialized regardless of how the object gets created.)

A simple test to illustrate:

>>> import zipfile
>>> zinfo = zipfile.ZipInfo()
>>> repr(zinfo)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "********/cpython/Lib/zipfile.py", line 376, in __repr__
    result.append(' file_size=%r' % self.file_size)
AttributeError: file_size

(If you assign zinfo.file_size = None, it next fails on compress_size.)

This problem has been noted before - see issues 3039 and 22217 - but has not been resolved.

Patch including tests is attached.

----------
components: Library (Lib)
files: zipfile.ZipInfo.patch
keywords: patch
messages: 258859
nosy: Matthew Zipay
priority: normal
severity: normal
status: open
title: zipfile.ZipInfo slots can raise unexpected AttributeError
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41698/zipfile.ZipInfo.patch

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

From report at bugs.python.org  Sat Jan 23 14:28:00 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Jan 2016 19:28:00 +0000
Subject: [New-bugs-announce] [issue26186] LazyLoader rejecting use of
 SourceFileLoader
Message-ID: <1453577280.26.0.226746274701.issue26186@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It was privately reported to me that importlib.util.LazyLoader rejects using importlib.machinery.SourceFileLoader (or at least _frozen_importlib.SourceFileLoader). At least a test should be added for LazyLoader to make sure it will happily accept importlib.machinery.SourceFileLoader, and if it rejects the one from _frozen_importlib, tweak the test to accept loaders from there as well.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 258873
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: LazyLoader rejecting use of SourceFileLoader
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jan 23 14:34:32 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 23 Jan 2016 19:34:32 +0000
Subject: [New-bugs-announce] [issue26187] sqlite3 trace callback prints
 duplicate line
Message-ID: <1453577672.38.0.77226221379.issue26187@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

I am running the following script:

------------------------------------------
>>> import sqlite3
>>> import os
>>> import time
>>> con1 = sqlite3.connect("/tmp/test.db")
>>> con2 = sqlite3.connect("/tmp/test.db")
>>> con1.set_trace_callback(print)
>>> cur = con1.cursor()
>>> cur.execute("create table test(a)")
create table test(a)
<sqlite3.Cursor object at 0x7fb488ddf260>
>>> con2.execute("create table test2(a)")
<sqlite3.Cursor object at 0x7fb488ddf2d0>
>>> cur.execute("insert into test(a) values(1)")
BEGIN 
insert into test(a) values(1)
insert into test(a) values(1)
<sqlite3.Cursor object at 0x7fb488ddf260>
>>> for a in con1.execute("select * from test"):
...     print("result:", a)
... 
select * from test
result: (1,)
-------------------------------------------

As you can see i get duplicate traceback print of the "insert into test(a) values(1)" line. The duplicate print has no effect on the actual db.

I have tested this both on python 3.4.3 and 3.6.0a0 on ubuntu14.04

----------
components: Extension Modules
messages: 258874
nosy: ghaering, palaviv
priority: normal
severity: normal
status: open
title: sqlite3 trace callback prints duplicate line
type: behavior
versions: Python 3.4, Python 3.6

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

From report at bugs.python.org  Sat Jan 23 21:06:03 2016
From: report at bugs.python.org (Nicholas Chammas)
Date: Sun, 24 Jan 2016 02:06:03 +0000
Subject: [New-bugs-announce] [issue26188] Provide more helpful error message
 when `await` is called inside non-`async` method
Message-ID: <1453601163.58.0.356009781594.issue26188@psf.upfronthosting.co.za>


New submission from Nicholas Chammas:

Here is the user interaction:

```python
$ python3
Python 3.5.1 (default, Dec  7 2015, 21:59:10) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def oh_hai():
...     await something()
  File "<stdin>", line 2
    await something()
                  ^
SyntaxError: invalid syntax
```

It would be helpful if Python could tell the user something more specific about _why_ the syntax is invalid. Is that possible?

For example, in the case above, an error message along the following lines would be much more helpful:

```
SyntaxError: Cannot call `await` inside non-`async` method.
```

Without a hint like this, it's too easy to miss the obvious and waste time eye-balling the code, like I did. :-)

----------
components: Interpreter Core
messages: 258879
nosy: Nicholas Chammas
priority: normal
severity: normal
status: open
title: Provide more helpful error message when `await` is called inside non-`async` method
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jan 23 21:29:02 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 24 Jan 2016 02:29:02 +0000
Subject: [New-bugs-announce] [issue26189] Non-interactive interpreter
 returns control to cmd.exe early
Message-ID: <1453602542.98.0.731550634512.issue26189@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

When running python.exe from windows console non-interactively, cmd.exe prompt appears immediately after starting:

C:\>python -c "import time; time.sleep(2); print 'bla-bla-bla'"

C:\>bla-bla-bla
<cursor here>

Not only this prevents from cmd to setting ERRORLEVEL to the return code, this makes it impossible to run scripts that expect input from console because Python and cmd get input lines in turns (I typed both inputs 2 times in the following example):

C:\>python -c "s=raw_input('1st:'); print s; s=raw_input('2nd:'); print s"

C:\>1st:abcdef
'abcdef' is not recognized as an internal or external command,
operable program or batch file.

C:\>abcdef
abcdef
2nd:123456
'123456' is not recognized as an internal or external command,
operable program or batch file.

C:\>123456
123456
<cursor here>

----------
components: IO
messages: 258880
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: Non-interactive interpreter returns control to cmd.exe early
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 24 05:42:56 2016
From: report at bugs.python.org (=?utf-8?q?Maximilian_K=C3=B6hl?=)
Date: Sun, 24 Jan 2016 10:42:56 +0000
Subject: [New-bugs-announce] [issue26190] GC memory leak using weak and
 cyclic references
Message-ID: <1453632176.06.0.994495814039.issue26190@psf.upfronthosting.co.za>


New submission from Maximilian K?hl:

In the attached code the object initially bind to `a` is never garbage collected although there are no references left. The finalizer of `b` is executed and the weak reference to it becomes dead however the garbage collector does not free the object itself and it could be resurrected with `gc.get_objects()`.

Output:
gc: collecting generation 2...
gc: objects in each generation: 27 0 5795
gc: collectable <B 0x7f158796a320>
gc: collectable <dict 0x7f15879e3088>
finalize: b <__main__.A object at 0x7f158796acc0>
gc: done, 3 unreachable, 0 uncollectable, 0.0005s elapsed
gc: collecting generation 2...
gc: objects in each generation: 1 0 5812
gc: done, 0.0005s elapsed
gc: collecting generation 2...
gc: objects in each generation: 1 0 5812
gc: done, 0.0005s elapsed
[...]

----------
components: Interpreter Core
files: gc_test_code.py
messages: 258886
nosy: koehlma
priority: normal
severity: normal
status: open
title: GC memory leak using weak and cyclic references
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file41704/gc_test_code.py

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

From report at bugs.python.org  Sun Jan 24 10:05:08 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Sun, 24 Jan 2016 15:05:08 +0000
Subject: [New-bugs-announce] [issue26191] pip on Windows doesn't honor Case
Message-ID: <1453647908.67.0.442004366007.issue26191@psf.upfronthosting.co.za>


New submission from Anders Rundgren:

pip install Crypto

Terminates correctly and the package is there as well.
Unfortunately the directory is named "crypto" rather than "Crypto" so when I perform

>>>import Crypto

the interpreter fails.

>>>import crypto 

seems to work but is incompatible over platforms.

If this is a problem with pycrypto or pip is beyond my knowledge of python.

----------
components: Installation
messages: 258887
nosy: anders.rundgren.net at gmail.com
priority: normal
severity: normal
status: open
title: pip on Windows doesn't honor Case
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Sun Jan 24 10:49:55 2016
From: report at bugs.python.org (=?utf-8?q?=C6=A6OB_COASTN?=)
Date: Sun, 24 Jan 2016 15:49:55 +0000
Subject: [New-bugs-announce] [issue26192] python3 k1om dissociation
 permanence: libffi
Message-ID: <1453650595.09.0.833212655161.issue26192@psf.upfronthosting.co.za>


New submission from ?OB COASTN:

initial patch attached for Python-3.4.4
This patch requires rework.

I am willing to implement the __MIC__ or __KNC__ into a new patch if this is in fact the route forward that seems optimal.

Thanks,
Rob


> Enabling the build system for Intel MIC k1om is non-trivial using
> Python-3.4.4
> Using Python2 for the k1om is very popular, but I require Python3
> support on k1om.
>
> The first requirement to complete this build involved the download and
> extraction of pre-built MPSS RPM's.
> Then built required host python bins using GCC.
> Lastly, build MIC bins using ICC.
> The exacts are appended to the end of this message.
>
> I would like to discuss a few change requirements that trial and error
> has revealed.
>
> 1.) libffi requires the University OF Cantabria patch because the k1om
> is not binary compatible with x86_64. [attached]
>
> These libffi changes could be implemented using the __MIC__ or __KNC__
> macros.
> *see https://software.intel.com/en-us/node/514528

----------
files: 0001-k1om-libffi.patch
keywords: patch
messages: 258888
nosy: ?OB COASTN
priority: normal
severity: normal
status: open
title: python3 k1om dissociation permanence: libffi
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41705/0001-k1om-libffi.patch

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

From report at bugs.python.org  Sun Jan 24 11:09:57 2016
From: report at bugs.python.org (=?utf-8?q?=C6=A6OB_COASTN?=)
Date: Sun, 24 Jan 2016 16:09:57 +0000
Subject: [New-bugs-announce] [issue26193] python3 k1om dissociation
 permanence: readelf
Message-ID: <1453651797.54.0.364540683305.issue26193@psf.upfronthosting.co.za>


New submission from ?OB COASTN:

> 2.) ./configure script halts during failure to locate readelf for the host.
>
> I simply commented out these lines in the ./configure file:
>  #if test "$cross_compiling" = yes; then
>     #case "$READELF" in
>     #readelf|:)
>     #as_fn_error $? "readelf for the host is required for cross
> builds" "$LINENO" 5
>     #;;
>     #esac
> #fi
>
> Ideally, ./configure would support ICC and k1om.
> Am I missing something in the configure/make commands below?
> Is it possible to bypass the readelf requirement when cross-compiling for
> k1om?
>
> Additionally, are any of the command line parameters below unnecessary?
> PKG_CONFIG_LIBDIR
> PKG_CONFIG_PATH
> PYTHON_FOR_BUILD
> _PYTHON_HOST_PLATFORM
> HOSTPGEN
> HOSTARCH
> BUILDARCH
>
>
> Thanks,
> Rob
>
>
>
>
> #copy/unpack the k1om bins tarball
> cd /home/
> wget mpss-3.4.6-k1om.tar
> tar xvf mpss-3.4.6-k1om.tar
> cd /home/mpss-3.4.6/k1om/
> for rpm in *.rpm; do rpm2cpio $rpm | cpio -idm; done
>
> #vars
> PythonVersion=Python-3.4.4
> k1om_rpm=/home/mpss-3.4.6/k1om/
> INSTALLPREFIX=/home/Python/release/$PythonVersion-mic
> SRC=/home/Python/$PythonVersion
>
> echo "Compiling host Python"
> cd $SRC && make distclean
> cd $SRC && ./configure
> cd $SRC && make python Parser/pgen
> rm -f $SRC/hostpython
> mv $SRC/python $SRC/hostpython
> rm -f $SRC/Parser/hostpgen
> mv $SRC/Parser/pgen $SRC/Parser/hostpgen
> cd $SRC && make distclean
>
> echo "Configuring Python for MIC..."
> cd $SRC && CONFIG_SITE=config.site \
> ./configure \
> CC="icc -mmic" \
> CFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \
> CXX="icpc -mmic" \
> CPPFLAGS="-I$k1om_rpm/include -I$k1om_rpm/usr/include -wd10006" \
> PKG_CONFIG_LIBDIR="$k1om_rpm/usr/lib64/pkgconfig" \
> PKG_CONFIG_PATH="$k1om_rpm/usr/lib64/pkgconfig" \
> --host=x86_64-k1om-linux \
> --build=x86_64-linux-gnu \
> --with-cxx-main="icpc -mmic" \
> --disable-ipv6
> echo "done"
>
> echo "Compiling Python for MIC..."
> cd $SRC && make \
> PYTHON_FOR_BUILD=./hostpython \
> _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \
> HOSTPGEN=./Parser/hostpgen \
> HOSTARCH=x86_64-k1om-linux \
> BUILDARCH=x86_64-linux-gnu \
> EXTRA_CFLAGS="-fp-model precise -shared -fPIC" \
> LDFLAGS="-L$k1om_rpm/lib64 -L$k1om_rpm/usr/lib64"
> echo "done"
>
> echo "Installing Python for MIC"
> mkdir -p $INSTALLPREFIX
> cd $SRC && make install \
> PYTHON_FOR_BUILD=./hostpython \
> _PYTHON_HOST_PLATFORM=x86_64-k1om-linux \
> prefix=$INSTALLPREFIX
> echo "done"

----------
components: Cross-Build
messages: 258889
nosy: ?OB COASTN
priority: normal
severity: normal
status: open
title: python3 k1om dissociation permanence: readelf
type: compile error
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/issue26193>
_______________________________________

From report at bugs.python.org  Sun Jan 24 12:47:04 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Jan 2016 17:47:04 +0000
Subject: [New-bugs-announce] [issue26194] Undefined behavior for
 deque.insert() when len(d) == maxlen
Message-ID: <1453657624.63.0.880277863791.issue26194@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The behavior of deque.insert() in a bounded deque is a bit odd:

>>> from collections import deque
>>> d = deque(range(20), maxlen=10)
>>> d
deque([10, 11, 12, 13, 14, 15, 16, 17, 18, 19], maxlen=10)
>>> d.insert(3, 'New')
>>> d
deque([19, 10, 11, 'New', 13, 14, 15, 16, 17, 18], maxlen=10)
#       ^   ^        ^--- The 12 got replaced
#       |   \--- The elements before the insertion point got rotated
#       \--- The final element got rotated to first position

With append/appendleft/extend/extendleft, the intended and useful behavior for maxlen is to pop from the opposite end.  But for deque.insert(), the best and most useful behavior invariants are less obvious.

Ideally, the effect of d.insert(0, item) would be the same as d.appendleft(item), and the effect of d.insert(len(d), item) would be the same as d.append(item).  

Also, d.insert(i, newitem) should have the post-condition:

  assert d[i] == newitem if i < len(d) else d[-1] == newitem

Having decided where to put the newitem, the question turns to deciding which element should be popped-off to maintain the size invariant.

I'm thinking that it should always be the rightmost element that gets popped, so that items before the inserted element never get moved.  This matches what insert() does for unbounded deques, making it the least surprising choice.

----------
assignee: rhettinger
components: Extension Modules
messages: 258893
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Undefined behavior for deque.insert() when len(d) == maxlen
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Jan 24 21:54:44 2016
From: report at bugs.python.org (Alex Robinson)
Date: Mon, 25 Jan 2016 02:54:44 +0000
Subject: [New-bugs-announce] [issue26195] Windows frozen .exe
 multiprocessing.Queue access is denied exception
Message-ID: <1453690484.95.0.111987955887.issue26195@psf.upfronthosting.co.za>


New submission from Alex Robinson:

A pyinstaller 3.0 frozen .exe Python 2.7.10 program under Windows 7 that uses a multiprocessing.Queue to send things to a multiprocessing.Process leads to the process getting access-is-denied exceptions on every q.get() call.

And, when the program can't exit. Or leaves a dangling process for every Process.

An unsatisfying fix for this is to put the following code somewhere in the program:

"""
    Do what must be done to make multiprocessing work in .exe files.

    This involves monkey patching multiprocessing.forking under Windows
    so when the a program using a multiprocessing.Process exits,
    there won't be processes left running.

    Hint from   http://stackoverflow.com/questions/33764448/pathos-multiprocessing-pipe-and-queue-on-windows

    .           The bottom line is we get "access is denied" when trying
    .           to get from the multiprocessing.Queue when we're an .exe file.

    .           So, in multiprocessing.forking.duplicate(),
    .           we change 'inheritable' to default to True
    .           from the normal code's False.

"""

import  sys
import  multiprocessing
import  multiprocessing.forking


#
#
#
#
def duplicate(handle, target_process = None, inheritable = True) :
    return(multiprocessing.forking.kludge_to_fix_dangling_processes(handle, target_process, inheritable))

if  (not hasattr(multiprocessing.forking, 'kludge_to_fix_dangling_processes')) and (sys.platform == 'win32') :
    multiprocessing.forking.kludge_to_fix_dangling_processes    = multiprocessing.forking.duplicate
    multiprocessing.forking.duplicate                           = duplicate

----------
components: Library (Lib)
messages: 258895
nosy: alex_python_org
priority: normal
severity: normal
status: open
title: Windows frozen .exe multiprocessing.Queue access is denied exception
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 25 06:25:35 2016
From: report at bugs.python.org (Charles Daffern)
Date: Mon, 25 Jan 2016 11:25:35 +0000
Subject: [New-bugs-announce] [issue26196] Argparse breaks when a switch is
 given an argument beginning with a dash
Message-ID: <1453721135.68.0.519114761572.issue26196@psf.upfronthosting.co.za>


New submission from Charles Daffern:

Example code demonstrating the problem:

# {{{
import argparse

def try_args(*args):
    parser = argparse.ArgumentParser()
    parser.add_argument("-a")
    print("Trying:", args)
    try:
        print(parser.parse_args(args))
    except SystemExit:
        print("FAILED!")

try_args("-a", "-")  # Works fine
try_args("-a", "-a")  # Breaks
try_args("-a", "--")  # Breaks
try_args("-a", "--things--")  # Breaks
# }}}

This behaviour is contrary to optparse:

# {{{
import optparse

def try_args(*args):
    parser = optparse.OptionParser()
    parser.add_option("-a")
    print("Trying:", args)
    try:
        print(parser.parse_args(list(args)))
    except SystemExit:
        print("FAILED!")

try_args("-a", "-")  # Works
try_args("-a", "-a")  # Works
try_args("-a", "--")  # Works
try_args("-a", "--things--")  # Works
# }}}

It is also contrary to many other utilities, including python itself:

# {{{
$ python -c -c
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'c' is not defined
$ printf 'hello\nworld\n-- pick me\netc\n' | grep -e --
-- pick me
$ gawk -f --
gawk: fatal: can't open source file `--' for reading (No such file or directory)
$ vim -u --
E282: Cannot read from "--"
Press ENTER or type command to continue
$ man -M --asdf man
No manual entry for man
$ less -b --sdfkds
Number is required after -b (--buffers)
Missing filename ("less --help" for help)
$ perl -e --fasd
Can't modify constant item in predecrement (--) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
# }}}

I first encountered this problem when using a text scrolling utility someone had written in python, and tried to pass "--" as the text separator. The program just bailed out, and it turned out that it wasn't the author's fault but a problem in argparse itself.

----------
components: Library (Lib)
messages: 258897
nosy: Charles Daffern
priority: normal
severity: normal
status: open
title: Argparse breaks when a switch is given an argument beginning with a dash
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Jan 25 07:57:17 2016
From: report at bugs.python.org (Francesco Pelizza)
Date: Mon, 25 Jan 2016 12:57:17 +0000
Subject: [New-bugs-announce] [issue26197] arange from numpy function has
 some limits....I propose a python function that overcome
Message-ID: <1453726637.54.0.637888159754.issue26197@psf.upfronthosting.co.za>


New submission from Francesco Pelizza:

arange from numpy is a function to generate list of floats from a start to an end number with a defined float number.

The "arange" function works fine for some cases, but in my case where I have to generate numbers that constitute parameters in a Quantum Mechanical calculation, numbers can be missing or be more than what I want, since many time each number is calculated in a couple of days or more. I need to avoid extra numbers or missing numbers to avoid loss of data. And sometimes the script will pass to a cycle function wrong numbers for start and stop, or the same number as starting and ending point, but I can not avoid this because they are numbers coming from Quantum World, and I need a function that sort out anything on its own because is inserted in for loops and things like that.

Also arange function does not take the "stop" number as the last number of the list, but it will terminate before, so to have the last wanted number in the list you have to use the formulae  arange(start,stop+inc,inc) or arange(start,stop+n,inc) where n allows is bigger than zero.

Some cases that give me problems are the following:
Defective lists of numbers:
1) arange(1,10+0.0000001,0.00000001) some numbers are missing
2) arange(1,10+0.0000001,1) generate float without any decimal after the point
3) arange(1,10,0.0000001) some numbers are missing
4) ...other combination gives problems

Empty lists of numbers:
1) arange(1,10,-1)
2) arange(1,-10,1)
3) arange(1,1,1)
4) arange(1,1,0.5)
5) arange(1,-10,0.005)
6) so on....

I made a python function that goes across any of these problems, taking account of using the absolute value of the given incremental step number.

Numbers can be float or integers, any exception of number ordering is kept under control to generate anyway at least a list of one number, if the stop number is bigger than the starting one, they get switched to generate anyway a list of numbers. And it can go down until 14 decimal places of incremental steps without generating wrong numbers due to the binary conversion of floats!
Some use of this function are eventually weird or really exotic, but in using python as a code to deal with computation without crashing for silly numbers ordering from the quantum world, is essential.

Do you agree with the improvements I put in this function called "CYCLE" can be of help?

I would like to share it with the community.

Here attached the function I made

----------
components: Library (Lib)
files: CYCLE.py
messages: 258899
nosy: Francesco Pelizza
priority: normal
severity: normal
status: open
title: arange from numpy function has some limits....I propose a python function that overcome
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41707/CYCLE.py

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

From report at bugs.python.org  Mon Jan 25 11:13:08 2016
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 25 Jan 2016 16:13:08 +0000
Subject: [New-bugs-announce] [issue26198] PyArg_ParseTuple with format "et#"
 and "es#" detects overflow by raising TypeError instead of ValueError
Message-ID: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i?:

The documentation for the "es#" format (and the "et#" that derives from it) documents the possibility of providing an already allocated buffer. Buffer overflow is detected and handled as follows: "If the buffer is not large enough, a ValueError will be set."

However, the actual behavior is to raise a TypeError. Inspecting the code in getargs.c reveals that convertsimple() handles buffer overflow by returning a formatted message to its caller, convertitem(). Calls to convertitem() that return an error call seterror() to set the error, and seterror() unconditionally sets the PyExc_TypeError.

This is not a big issue in practice, and since the behavior is not new, it might be best to simply update the documentation to match the existing practice instead of changing the behavior and risking breaking working code.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 258905
nosy: docs at python, hniksic
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple with format "et#" and "es#" detects overflow by raising TypeError instead of ValueError
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Jan 25 11:20:52 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Mon, 25 Jan 2016 16:20:52 +0000
Subject: [New-bugs-announce] [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
Message-ID: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>


New submission from Raphael Das Gupta:

On

* https://docs.python.org/3.3/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.4/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.5/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.6/library/unittest.mock-examples.html#more-complex-argument-matching

the link to hamcrest.library.integration.match_equality documentation at the very end of the page is broken.

(Earlier versions didn't have this documentation page.)

----------
assignee: docs at python
components: Documentation
hgrepos: 332
messages: 258906
nosy: das-g, docs at python
priority: normal
severity: normal
status: open
title: fix broken link to hamcrest.library.integration.match_equality in unittest.mock "getting started" documentation
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jan 25 13:03:44 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2016 18:03:44 +0000
Subject: [New-bugs-announce] [issue26200] SETREF adds unnecessary work in
 some cases
Message-ID: <1453745024.51.0.674954872761.issue26200@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Application of the SETREF macro was not code neutral in a number of cases.  The SETREF macro always uses Py_XDECREF where the original code correctly used a faster and lighter Py_DECREF.

There should be an XSETREF variant and more care should be taken when applying these macros wholesale to the entire code base.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 258913
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: SETREF adds unnecessary work in some cases
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Mon Jan 25 14:25:40 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2016 19:25:40 +0000
Subject: [New-bugs-announce] [issue26201] Faster type checking in
 listobject.c
Message-ID: <1453749940.01.0.185085396815.issue26201@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

A number of fine-grained methods in Objects/listobject.c use PyList_Check().  They include PyList_Size, PyList_GetItem, PyList_SetItem, PyList_Insert, and PyList_Append.

The PyList_Check() works by making two sequentially dependent memory fetches:

    movq    8(%rdi), %rax
    testb   $2, 171(%rax)
    je  L1645

This patch proposes a fast path for the common case of an exact match, using PyList_CheckExact() as an early-out before the PyList_Check() test:

    leaq    _PyList_Type(%rip), %rdx # parallelizable
    movq    8(%rdi), %rax            # only 1 memory access
    cmpq    %rdx, %rax               # macro-fusion  
    je  L1604                        # early-out
    testb   $2, 171(%rax)            # fallback to 2nd memory access
    je  L1604

This technique won't help outside of Objects/listobject.c because the initial LEA instruction becomes a MOV for the global offset table, nullifying the advantage.

----------
assignee: serhiy.storchaka
components: Interpreter Core
files: list_check_fastpath.diff
keywords: patch
messages: 258918
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster type checking in listobject.c
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41713/list_check_fastpath.diff

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

From report at bugs.python.org  Mon Jan 25 15:53:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Jan 2016 20:53:06 +0000
Subject: [New-bugs-announce] [issue26202] The range() object is deepcopied
 as atomic
Message-ID: <1453755186.26.0.578500471201.issue26202@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The range() object is immutable, but is not atomic, and copy.deepcopy() shouldn't return it unchanged.

>>> class I(int): pass  # mutable index
... 
>>> import copy
>>> r = range(I(10))
>>> r2 = copy.deepcopy(r)
>>> r.stop.attr = 'spam'
>>> r2.stop.attr
'spam'

This is Python 3 only issue because in 2.7 the xrange() object doesn't exposes start/stop/step attributes.

Proposed patch fixes the copy module.

----------
components: Library (Lib)
files: deepcopy_range.patch
keywords: patch
messages: 258921
nosy: alexandre.vassalotti, fdrake, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: The range() object is deepcopied as atomic
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41714/deepcopy_range.patch

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

From report at bugs.python.org  Mon Jan 25 16:06:30 2016
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Caron?=)
Date: Mon, 25 Jan 2016 21:06:30 +0000
Subject: [New-bugs-announce] [issue26203] nesting venv in virtualenv
 segfaults
Message-ID: <1453755990.33.0.69898482015.issue26203@psf.upfronthosting.co.za>


New submission from Andr? Caron:

When trying to create a new virtual environment using Python 3.5's venv package from a virtual environment created by the popular 3rd-party virtualenv  package, I get a segfault.

Nested virtual environments work fine both with venv and virtualenv, but using one inside the other doesn't work.  This suggests a subtle incompatibility between the two implementations.

I'm not sure whether compatibility between the implementations is a goal or not at the moment, but there is extensive tooling that uses the 3rd party virtualenv implementation.  For example, I run tests with Tox, which uses virtualenv.  I cannot test any package that uses the standard venv because everything crashes.  As a result of this, I will avoid moving to the standard implementation.

I put up some sample scripts up on GitHub to show how to reproduce the issue.  I hope they can help explain the issue.

https://github.com/AndreLouisCaron/nested-venv-bug

Cheers,

Andr?

----------
components: Library (Lib)
messages: 258923
nosy: Andr? Caron
priority: normal
severity: normal
status: open
title: nesting venv in virtualenv segfaults
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Mon Jan 25 20:00:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 01:00:40 +0000
Subject: [New-bugs-announce] [issue26204] compiler: don't emit LOAD_CONST
 instructions for constant expressions?
Message-ID: <1453770040.66.0.71475007122.issue26204@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The bytecode compilers ignores ast.Str and ast.Num nodes:

----------------------------
>>> def func():
...     123
...     "test"
... 
>>> import dis; dis.dis(func)
  3           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE
----------------------------

But other ast nodes which are constant are not ignored:

----------------------------
>>> def func2():
...     b'bytes'
...     (1, 2)
... 
>>> import dis; dis.dis(func2)
  2           0 LOAD_CONST               1 (b'bytes')
              3 POP_TOP

  3           4 LOAD_CONST               4 ((1, 2))
              7 POP_TOP
              8 LOAD_CONST               0 (None)
             11 RETURN_VALUE
----------------------------

I don't understand the point of loading a constant and then unload it (POP_TOP).


Attached patch changes the compiler to not emit LOAD_CONST+POP_TOP anymore.


My patch only affects constants. Example with the patch:
----------------------------
>>> def f():
...  x
... 
>>> import dis
>>> dis.dis(f)
  2           0 LOAD_GLOBAL              0 (x)
              3 POP_TOP
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE
----------------------------

The compiler still emits "LOAD_GLOBAL x" for the instruction "x".

Ignoring the Python instruction "x" would change the Python semantics, because the function would not raise a NameError anymore if x is not defined.

Note: I noticed this inefficient bytecode while working on the issue #26146 (add ast.Constant).

----------
components: Interpreter Core
files: compiler.patch
keywords: patch
messages: 258939
nosy: haypo, yselivanov
priority: normal
severity: normal
status: open
title: compiler: don't emit LOAD_CONST instructions for constant expressions?
versions: Python 3.6
Added file: http://bugs.python.org/file41716/compiler.patch

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

From report at bugs.python.org  Mon Jan 25 21:16:27 2016
From: report at bugs.python.org (Roscoe R.Higgins)
Date: Tue, 26 Jan 2016 02:16:27 +0000
Subject: [New-bugs-announce] [issue26205] Inconsistency concerning nested
 scopes
Message-ID: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>


New submission from Roscoe R.Higgins:

In chapter 9. Classes of the Python3.5 documentation it says: 

"At any time during execution, there are at least three nested scopes whose namespaces are directly accessible:",

followed by a list containing 4 items.
Further down a middle scope is mentioned (although mentioned by name). This was confusing for a while.

----------
assignee: docs at python
components: Documentation
messages: 258941
nosy: Roscoe R. Higgins, docs at python
priority: normal
severity: normal
status: open
title: Inconsistency concerning nested scopes
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan 26 08:02:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 13:02:10 +0000
Subject: [New-bugs-announce] [issue26206] test_socket.testRecvmsgPeek()
 timeout on "AMD64 Debian root 3.x" buildbot
Message-ID: <1453813330.04.0.627005992155.issue26206@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The bug started between build 3071 and 3072:
* http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3071
* http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3072

Maybe it's an issue on the buildbot, not on the code directly?

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/3142/steps/test/logs/stdio

[300/400] test_socket
Timeout (1:00:00)!
Thread 0x00002b16599dab20 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 1920 in doRecvmsg
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 2376 in testRecvmsgPeek
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 600 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 648 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/runner.py", line 176 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1780 in _run_suite
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1814 in run_unittest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_socket.py", line 5345 in test_main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/runtest.py", line 162 in runtest_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/runtest.py", line 115 in runtest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 295 in run_tests_sequential
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 356 in run_tests
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 392 in main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 433 in main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/libregrtest/main.py", line 455 in main_in_temp_cwd
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/__main__.py", line 3 in <module>
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 85 in _run_code
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 184 in _run_module_as_main
make: *** [buildbottest] Error 1

----------
components: Tests
keywords: buildbot
messages: 258952
nosy: haypo
priority: normal
severity: normal
status: open
title: test_socket.testRecvmsgPeek() timeout on "AMD64 Debian root 3.x" buildbot
versions: Python 3.6

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

From report at bugs.python.org  Tue Jan 26 08:09:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jan 2016 13:09:42 +0000
Subject: [New-bugs-announce] [issue26207] test_distutils fails on "AMD64
 Windows7 SP1 3.x" buildbot
Message-ID: <1453813782.88.0.185045860262.issue26207@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like the buildbot started to fail with the build http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7166/

The change 37dc870175be43cdcb6920cc642a99fc10cd4bb4 of issue #25850 changed Lib/distutils/_msvccompiler.py: "Use cross-compilation by default for 64-bit Windows.". It's an interesting suspect.

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7214/steps/test/logs/stdio

test test_distutils failed

======================================================================
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", line 480, in link
    self.spawn([self.linker] + ld_args)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", line 503, in spawn
    return super().spawn(cmd)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\spawn.py", line 38, in spawn
    _spawn_nt(cmd, search_path, dry_run=dry_run)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\spawn.py", line 81, in _spawn_nt
    "command %r failed with exit status %d" % (cmd, rc))
distutils.errors.DistutilsExecError: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1101

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\tests\test_install.py", line 215, in test_record_extensions
    cmd.run()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\install.py", line 539, in run
    self.run_command('build')
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build.py", line 135, in run
    self.run_command(cmd_name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py", line 338, in run
    self.build_extensions()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py", line 447, in build_extensions
    self._build_extensions_serial()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py", line 472, in _build_extensions_serial
    self.build_extension(ext)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\command\build_ext.py", line 557, in build_extension
    target_lang=language)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\ccompiler.py", line 717, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\distutils\_msvccompiler.py", line 483, in link
    raise LinkError(msg)
distutils.errors.LinkError: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1101

----------
components: Tests, Windows
keywords: buildbot
messages: 258954
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_distutils fails on "AMD64 Windows7 SP1 3.x" buildbot

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

From report at bugs.python.org  Tue Jan 26 12:46:59 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 26 Jan 2016 17:46:59 +0000
Subject: [New-bugs-announce] [issue26208] decimal C module's exceptions
 don't match the Python version
Message-ID: <1453830419.58.0.782557332566.issue26208@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

Exceptions from the decimal module are quite unfriendly:

    >>> Decimal(42) / Decimal(0)
    ...
    decimal.DivisionByZero: [<class 'decimal.DivisionByZero'>]

    >>> huge = Decimal('9' * 99)
    >>> huge.quantize(Decimal('0.1'))
    ...
    decimal.InvalidOperation: [<class 'decimal.InvalidOperation'>]


compared to the pure Python implementation:

    decimal.DivisionByZero: x / 0

    decimal.InvalidOperation: quantize result has too many digits for current context


If I'm reading http://bugs.python.org/issue21227 right, the exception argument is a of signals, and indicates the complete set of signals raised by the operation. However, this is (AFAICS) not documented, and not portable (since it's not present in the Python version).

I believe this behavior should be
- either dropped in favor of friendlier error messages (or possibly moved to a more internal attribute of the exception, and documented as an optional CPython feature),
- or documented, and implemented in _pydecimal as well.

Which of those actions would be right seems to be a question of whether the exception argument is part of the API.

----------
components: Library (Lib)
messages: 258965
nosy: encukou, skrah
priority: normal
severity: normal
status: open
title: decimal C module's exceptions don't match the Python version

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

From report at bugs.python.org  Tue Jan 26 15:34:38 2016
From: report at bugs.python.org (Lorenzo Ancora)
Date: Tue, 26 Jan 2016 20:34:38 +0000
Subject: [New-bugs-announce] [issue26209] TypeError in smtpd module with
 string arguments
Message-ID: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>


New submission from Lorenzo Ancora:

smtpd.PureProxy(localaddr="host1", remoteaddr="host2")

...produces the error:

[...] smtpd.py", line 657, in __init__
    gai_results = socket.getaddrinfo(*localaddr, type=socket.SOCK_STREAM)
TypeError: getaddrinfo() got multiple values for argument 'type'

The module only works with:

smtpd.PureProxy(localaddr=("host1", 25), remoteaddr=("host2", 25))

The documentation does not specify the format of the INPUT parameters, only the CLI syntax with hostnames as "host:port" strings.
The underlying library should convert them to tuples or at least the documentation should be completed.

----------
components: Library (Lib)
messages: 258971
nosy: lorenzo.ancora
priority: normal
severity: normal
status: open
title: TypeError in smtpd module with string arguments
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan 26 16:10:08 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Tue, 26 Jan 2016 21:10:08 +0000
Subject: [New-bugs-announce] [issue26210] `HTMLParser.handle_data` may be
 invoked although `HTMLParser.reset` was invoked
Message-ID: <1453842608.52.0.40675264133.issue26210@psf.upfronthosting.co.za>


New submission from Yannick Duch?ne:

`HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked. This occurs at least when `HTMLParser.reset` was invoked during `HTMLParser.handle_endtag`.

According to the documentation, `HTMLParser.reset` discard all data, so it should immediately stop the parser.

Additionally as an aside, it's strange `HTMLParser.reset` is invoked during object creation as it's invoking a method on an object which is potentially not entirely initialized (that matters with derived classes).

----------
components: Library (Lib)
messages: 258973
nosy: Hibou57
priority: normal
severity: normal
status: open
title: `HTMLParser.handle_data` may be invoked although `HTMLParser.reset` was invoked
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan 26 16:47:17 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Tue, 26 Jan 2016 21:47:17 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue26211=5D_HTMLParser=3A_?=
 =?utf-8?q?=E2=80=9CAssertionError=3A_we_should_not_get_here!=E2=80=9D?=
Message-ID: <1453844837.54.0.120197785601.issue26211@psf.upfronthosting.co.za>


New submission from Yannick Duch?ne:

Using HTMLParser on the attached file, I got this:

      File "/usr/lib/python3.5/html/parser.py", line 111, in feed
        self.goahead(0)
      File "/usr/lib/python3.5/html/parser.py", line 171, in goahead
        k = self.parse_starttag(i)
      File "/usr/lib/python3.5/html/parser.py", line 303, in parse_starttag
        endpos = self.check_for_whole_start_tag(i)
      File "/usr/lib/python3.5/html/parser.py", line 383, in check_for_whole_start_tag
        raise AssertionError("we should not get here!")
    AssertionError: we should not get here!

The file purposely contains an error, as I was to check the behaviour of my application in the case of this error???I finally triggered one in the library :-P

----------
components: Library (Lib)
files: sample.html
messages: 258975
nosy: Hibou57
priority: normal
severity: normal
status: open
title: HTMLParser: ?AssertionError: we should not get here!?
versions: Python 3.5
Added file: http://bugs.python.org/file41721/sample.html

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

From report at bugs.python.org  Tue Jan 26 18:40:33 2016
From: report at bugs.python.org (R. Jones)
Date: Tue, 26 Jan 2016 23:40:33 +0000
Subject: [New-bugs-announce] [issue26212] Python with ncurses6.0 will not
 load _curses module.
Message-ID: <1453851633.31.0.356555678785.issue26212@psf.upfronthosting.co.za>


New submission from R. Jones:

I am trying to compile Python-2.7.10.  This is being done as a user, not root and I don't have access to /usr/local other than to avoid all the broken stuff in it.

My local is /appl/local

I am installing Python in /appl/local/python-2.7.10

I have ncursest as part of my /appl/local, but python keeps wanting to link with /usr/ccs/lib/libcurses.so.  UGH.
"ncursest" was built instead of "ncurses" because I used "--with-pthread" and "--enable-reentrant"


I rebuilt ncurses without those two flags but with --with-termlib which built libtinfo.so.  When compiling the _curses module, I get this error:

*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.10-sun4u.32bit-2.7/_curses.so: symbol _unctrl: referenced symbol not found

In this case I can see unctrl is in tinfo...but no matter what I do, I cannot get it to add -ltinfo to the link line.

$ nm -s libtinfo.so | grep unctrl
0001d4f8 T unctrl
00039170 r unctrl_blob.5682
00039070 r unctrl_c1.5681
0001d30c T unctrl_sp
00039572 r unctrl_table.5680


So my next attempt was to make a private copy of ncurses for Python without --with-termlib, but had to add --enable-termcap and install it in /appl/local/python-2.7.10/lib

$ ls -al /appl/local/python-2.7.10/lib
total 15584
drwxr-xr-x   4 gfp-ip   gfp-ip      1024 Jan 26 16:45 .
drwxr-xr-x   6 gfp-ip   gfp-ip        96 Jan 26 15:31 ..
-rw-r--r--   1 gfp-ip   gfp-ip    120560 Jan 26 15:32 libform.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1055 Jan 26 15:32 libform.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        16 Jan 26 15:32 libform.so -> libform.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        16 Jan 26 15:32 libform.so.6 -> libform.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip     95604 Jan 26 15:32 libform.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip     61908 Jan 26 15:32 libmenu.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1055 Jan 26 15:32 libmenu.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        16 Jan 26 15:32 libmenu.so -> libmenu.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        16 Jan 26 15:32 libmenu.so.6 -> libmenu.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip     48060 Jan 26 15:32 libmenu.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip    174364 Jan 26 15:32 libncurses++.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1295 Jan 26 15:32 libncurses++.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        21 Jan 26 15:32 libncurses++.so -> libncurses++.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        21 Jan 26 15:32 libncurses++.so.6 -> libncurses++.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip    114812 Jan 26 15:32 libncurses++.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip    628332 Jan 26 15:31 libncurses.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1019 Jan 26 15:31 libncurses.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        19 Jan 26 15:31 libncurses.so -> libncurses.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        19 Jan 26 15:31 libncurses.so.6 -> libncurses.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip    478356 Jan 26 15:31 libncurses.so.6.0.0
-rw-r--r--   1 gfp-ip   gfp-ip     26324 Jan 26 15:31 libpanel.a
-rwxr-xr-x   1 gfp-ip   gfp-ip      1062 Jan 26 15:31 libpanel.la
lrwxrwxrwx   1 gfp-ip   gfp-ip        17 Jan 26 15:31 libpanel.so -> libpanel.so.6.0.0
lrwxrwxrwx   1 gfp-ip   gfp-ip        17 Jan 26 15:31 libpanel.so.6 -> libpanel.so.6.0.0
-rwxr-xr-x   1 gfp-ip   gfp-ip     23652 Jan 26 15:31 libpanel.so.6.0.0

$ nm /appl/local/python-2.7.10/lib/libncurses.so | grep unctrl
0004acac T unctrl
00067540 r unctrl_blob.5717
00067440 r unctrl_c1.5716
0004aac0 T unctrl_sp
00067942 r unctrl_table.5715

So ONCE again, compiling Python module _curses with the new lib:
Script started on Tue Jan 26 19:36:55 2016
$ make
running build
running build_ext
building dbm using ndbm
building '_curses' extension
gcc -fPIC -fno-strict-aliasing -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/appl/local/python-2.7.10/include -I/appl/local/include -I/usr/local/include -I/appl/logs/local_build/src/python.org/Python-2.7.10/Include -I/appl/logs/local_build/src/python.org/Python-2.7.10 -c /appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c -o build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.o
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c: In function 'PyCursesWindow_ChgAt':
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c:713:9: warning: implicit declaration of function 'mvwchgat' [-Wimplicit-function-declaration]
/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.c:717:9: warning: implicit declaration of function 'wchgat' [-Wimplicit-function-declaration]
gcc -shared -L/appl/local/python-2.7.10/lib -Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses -R/appl/local/python-2.7.10/lib -L/appl/local/lib -L/appl/local/python-2.7.10/lib -Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses -R/appl/local/python-2.7.10/lib -L/appl/local/lib -fno-strict-aliasing -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_cursesmodule.o -L/appl/local/python-2.7.10/lib -L/appl/local/lib -L/usr/local/lib -L. -Wl,-R/appl/local/python-2.7.10/lib -lncurses -lpython2.7 -o build/lib.solaris-2.10-sun4u.32bit-2.7/_curses.so

*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.10-sun4u.32bit-2.7/_curses.so: symbol _unctrl: referenced symbol not found

building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/appl/local/python-2.7.10/include -I/appl/local/include -I/usr/local/include -I/appl/logs/local_build/src/python.org/Python-2.7.10/Include -I/appl/logs/local_build/src/python.org/Python-2.7.10 -c /appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_curses_panel.c -o build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_curses_panel.o
gcc -shared -L/appl/local/python-2.7.10/lib -Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses -R/appl/local/python-2.7.10/lib -L/appl/local/lib -L/appl/local/python-2.7.10/lib -Wl,-rpath,/appl/local/python-2.7.10/lib -lncurses -R/appl/local/python-2.7.10/lib -L/appl/local/lib -fno-strict-aliasing -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/appl/local/python-2.7.10/include -I/appl/local/include -DNCURSES_OPAQUE=0 -DNCURSES_REENTRANT=0 build/temp.solaris-2.10-sun4u.32bit-2.7/appl/logs/local_build/src/python.org/Python-2.7.10/Modules/_curses_panel.o -L/appl/local/python-2.7.10/lib -L/appl/local/lib -L/usr/local/lib -L. -Wl,-R/appl/local/python-2.7.10/lib -lpanel -lncurses -lpython2.7 -o build/lib.solaris-2.10-sun4u.32bit-2.7/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             bsddb185           linuxaudiodev   
ossaudiodev                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_curses            _curses_panel

Here is LDD output for the built python:
$ ldd python
        libncurses.so.6 =>       /appl/local/python-2.7.10/lib/libncurses.so.6
        libpython2.7.so.1.0 =>   /appl/local/python-2.7.10/lib/libpython2.7.so.1.0
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        librt.so.1 =>    /lib/librt.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libm.so.2 =>     /lib/libm.so.2
        libc.so.1 =>     /lib/libc.so.1
        libgcc_s.so.1 =>         /appl/local/lib/libgcc_s.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libmd.so.1 =>    /lib/libmd.so.1
        libscf.so.1 =>   /lib/libscf.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        /platform/SUNW,Netra-T12/lib/libc_psr.so.1
        /platform/SUNW,Netra-T12/lib/libmd_psr.so.1

$ nm /appl/local/python-2.7.10/lib/libncurses.so.6 | grep unctrl
0004acac T unctrl
00067540 r unctrl_blob.5717
00067440 r unctrl_c1.5716
0004aac0 T unctrl_sp
00067942 r unctrl_table.5715


Unfortunately I see this in /usr/ccs/lib/libcurses.so
$ nm /usr/ccs/lib/libcurses.so | grep unctrl
0003d5e8 D _unctrl
0000cb00 T unctrl


I don't see any reference to unctrl except this: 
./Modules/_cursesmodule.c:        knp = unctrl(rtn);
./Modules/_cursesmodule.c:    return PyString_FromString(unctrl(ch));
./Modules/_cursesmodule.c:    {"unctrl",              (PyCFunction)PyCurses_UnCtrl, METH_VARARGS},

none of which is referencing _unctrl

so it seems that python can never work with ncurses6...even though it seems there is support for it in the code.

Any help?

----------
components: Extension Modules
messages: 258984
nosy: jonesrw
priority: normal
severity: normal
status: open
title: Python with ncurses6.0 will not load _curses module.
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 26 18:40:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 23:40:45 +0000
Subject: [New-bugs-announce] [issue26213] Document BUILD_LIST_UNPACK &
 BUILD_TUPLE_UNPACK
Message-ID: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Turns out the BUILD_TUPLE_UNPACK and BUILD_LIST_UNPACK opcodes are undocumented in the dis module.

----------
assignee: docs at python
components: Documentation
messages: 258985
nosy: benjamin.peterson, brett.cannon, docs at python
priority: low
severity: normal
stage: needs patch
status: open
title: Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK
versions: Python 3.6

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

From report at bugs.python.org  Wed Jan 27 03:08:41 2016
From: report at bugs.python.org (Tuomas Salo)
Date: Wed, 27 Jan 2016 08:08:41 +0000
Subject: [New-bugs-announce] [issue26214] textwrap should minimize breaks
Message-ID: <1453882121.55.0.184610339904.issue26214@psf.upfronthosting.co.za>


New submission from Tuomas Salo:

This code:

    import textwrap
    textwrap.wrap("123 123 1234567", width=5)

currently* produces this output:

    ['123', '123 1', '23456', '7']

I would expect the textwrap module to only break words when absolutely necessary. That is, I would have expected it to produce one break less:

    ['123', '123', '12345', '67']

This is of course a matter of taste - the current implementation produces more efficiently filled lines.

(* I only have access to Python 2.7 and 3.4)

----------
messages: 258999
nosy: Tuomas Salo
priority: normal
severity: normal
status: open
title: textwrap should minimize breaks
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Jan 27 06:08:47 2016
From: report at bugs.python.org (yuriy_levchenko)
Date: Wed, 27 Jan 2016 11:08:47 +0000
Subject: [New-bugs-announce] [issue26215] remove gc from CPython
Message-ID: <1453892927.49.0.620193472963.issue26215@psf.upfronthosting.co.za>


New submission from yuriy_levchenko:

I permanently use gc.disable() but CPython create object with GC_Head.
it's use big memory.
I suggest add define to a few file that remove use GC_Head and allocate extra memory.

----------
messages: 259013
nosy: yuriy_levchenko
priority: normal
severity: normal
status: open
title: remove gc from CPython
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 27 08:36:20 2016
From: report at bugs.python.org (allensll)
Date: Wed, 27 Jan 2016 13:36:20 +0000
Subject: [New-bugs-announce] [issue26216] run runtktests.py error when test
 tkinter
Message-ID: <1453901780.17.0.263140202656.issue26216@psf.upfronthosting.co.za>


New submission from allensll:

When I run the following:
python ...\Python35\Lib\tkinter\test\runtktests.py
Error:
SystemError: Parent module 'tkinter.test' not loaded, cannot perform relative import
When I add "import tkinter.test" into runtktests.py,it's working.

----------
components: Tkinter
messages: 259021
nosy: allensll
priority: normal
severity: normal
status: open
title: run runtktests.py error when test tkinter
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan 27 10:46:05 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 27 Jan 2016 15:46:05 +0000
Subject: [New-bugs-announce] [issue26217] Fatal error when importing
 ``test.test_os`` in debug mode on Windows
Message-ID: <1453909565.67.0.482630553936.issue26217@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

I compiled CPython from latest trunk on GitHub (revision a587bc1eea903dfac94a85324cc6ab39755769a8), compiled with Py_DEBUG and went to run the test suite. Here's the (rather long) output:

E:\GitHub\cpython\PCbuild\win32>python_d -m test
== CPython 3.6.0a0 (default, Jan 26 2016, 23:23:12) [MSC v.1900 32 bit (Intel)]
==   Windows-7-6.1.7601-SP1 little-endian
==   hash algorithm: siphash24 32bit
==   E:\GitHub\cpython\build\test_python_464
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0,
bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[  1/400] test_grammar
[  2/400] test_opcodes
[  3/400] test_dict
[  4/400] test_builtin
[  5/400] test_exceptions
[  6/400] test_types
[  7/400] test_unittest
[  8/400] test_doctest
[  9/400] test_doctest2
[ 10/400] test_support
[ 11/400] test___all__
Assertion failed: compact->wstr_length == 0, file ..\Objects\unicodeobject.c, line 427
Fatal Python error: Aborted

Current thread 0x00000a88 (most recent call first):
  File "E:\GitHub\cpython\lib\ctypes\util.py", line 64 in find_library
  File "E:\GitHub\cpython\lib\uuid.py", line 473 in <module>
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 656 in exec_module
  File "<frozen importlib._bootstrap>", line 673 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 958 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 969 in _find_and_load
  File "E:\GitHub\cpython\lib\test\test_os.py", line 29 in <module>
  File "<frozen importlib._bootstrap>", line 222 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 656 in exec_module
  File "<frozen importlib._bootstrap>", line 673 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 958 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 969 in _find_and_load
  File "<string>", line 1 in <module>
  File "E:\GitHub\cpython\lib\test\test___all__.py", line 23 in check_all
  File "E:\GitHub\cpython\lib\test\test___all__.py", line 105 in test_all
  File "E:\GitHub\cpython\lib\unittest\case.py", line 600 in run
  File "E:\GitHub\cpython\lib\unittest\case.py", line 648 in __call__
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 122 in run
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 84 in __call__
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 122 in run
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 84 in __call__
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 122 in run
  File "E:\GitHub\cpython\lib\unittest\suite.py", line 84 in __call__
  File "E:\GitHub\cpython\lib\test\support\__init__.py", line 1679 in run
  File "E:\GitHub\cpython\lib\test\support\__init__.py", line 1780 in _run_suite
  File "E:\GitHub\cpython\lib\test\support\__init__.py", line 1814 in run_unittest
  File "E:\GitHub\cpython\lib\test\libregrtest\runtest.py", line 161 in test_runner
  File "E:\GitHub\cpython\lib\test\libregrtest\runtest.py", line 162 in runtest_inner
  File "E:\GitHub\cpython\lib\test\libregrtest\runtest.py", line 126 in runtest
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 295 in run_tests_sequential
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 356 in run_tests
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 392 in main
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 433 in main
  File "E:\GitHub\cpython\lib\test\libregrtest\main.py", line 455 in main_in_temp_cwd
  File "E:\GitHub\cpython\lib\test\__main__.py", line 3 in <module>
  File "E:\GitHub\cpython\lib\runpy.py", line 85 in _run_code
  File "E:\GitHub\cpython\lib\runpy.py", line 184 in _run_module_as_main

E:\GitHub\cpython\PCbuild\win32>python_d
Python 3.6.0a0 (default, Jan 26 2016, 23:23:12) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.test___all__
>>> import unittest
>>> unittest.main(test.test___all__)

<...>

test.test_openpty
test.test_operator
test.test_optparse
test.test_ordered_dict
test.test_os
Assertion failed: compact->wstr_length == 0, file ..\Objects\unicodeobject.c, line 427

E:\GitHub\cpython\PCbuild\win32>python_d
Python 3.6.0a0 (default, Jan 26 2016, 23:23:12) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.test_os
Assertion failed: compact->wstr_length == 0, file ..\Objects\unicodeobject.c, line 427

Call stack (from importing 'test.test_os'):

 	ucrtbased.dll!0f7d81f0()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for ucrtbased.dll]	
 	[External Code]	
>	python36_d.dll!_PyUnicode_CheckConsistency(_object * op, int check_content) Line 427	C
 	python36_d.dll!resize_compact(_object * unicode, int length) Line 920	C
 	python36_d.dll!unicode_resize(_object * * p_unicode, int length) Line 1844	C
 	python36_d.dll!PyUnicode_Append(_object * * p_left, _object * right) Line 11301	C
 	python36_d.dll!unicode_concatenate(_object * v, _object * w, _frame * f, unsigned char * next_instr) Line 5318	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 1565	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!PyEval_EvalCode(_object * co, _object * globals, _object * locals) Line 777	C
 	python36_d.dll!builtin_exec_impl(PyModuleDef * module, _object * source, _object * globals, _object * locals) Line 957	C
 	python36_d.dll!builtin_exec(PyModuleDef * module, _object * args) Line 275	C
 	python36_d.dll!PyCFunction_Call(_object * func, _object * args, _object * kwds) Line 109	C
 	python36_d.dll!ext_do_call(_object * func, _object * * * pp_stack, int flags, int na, int nk) Line 5041	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3233	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4824	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!function_call(_object * func, _object * arg, _object * kw) Line 604	C
 	python36_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2170	C
 	python36_d.dll!_PyObject_CallMethodIdObjArgs(_object * callable, _Py_Identifier * name, ...) Line 2428	C
 	python36_d.dll!PyImport_ImportModuleLevelObject(_object * name, _object * given_globals, _object * locals, _object * given_fromlist, int level) Line 1633	C
 	python36_d.dll!builtin___import__(_object * self, _object * args, _object * kwds) Line 213	C
 	python36_d.dll!PyCFunction_Call(_object * func, _object * args, _object * kwds) Line 98	C
 	python36_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2170	C
 	python36_d.dll!PyEval_CallObjectWithKeywords(_object * func, _object * arg, _object * kw) Line 4592	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 2759	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!PyEval_EvalCode(_object * co, _object * globals, _object * locals) Line 777	C
 	python36_d.dll!builtin_exec_impl(PyModuleDef * module, _object * source, _object * globals, _object * locals) Line 957	C
 	python36_d.dll!builtin_exec(PyModuleDef * module, _object * args) Line 275	C
 	python36_d.dll!PyCFunction_Call(_object * func, _object * args, _object * kwds) Line 109	C
 	python36_d.dll!ext_do_call(_object * func, _object * * * pp_stack, int flags, int na, int nk) Line 5041	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3233	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4824	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4815	C
 	python36_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4741	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3194	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!function_call(_object * func, _object * arg, _object * kw) Line 604	C
 	python36_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2170	C
 	python36_d.dll!_PyObject_CallMethodIdObjArgs(_object * callable, _Py_Identifier * name, ...) Line 2428	C
 	python36_d.dll!PyImport_ImportModuleLevelObject(_object * name, _object * given_globals, _object * locals, _object * given_fromlist, int level) Line 1633	C
 	python36_d.dll!builtin___import__(_object * self, _object * args, _object * kwds) Line 213	C
 	python36_d.dll!PyCFunction_Call(_object * func, _object * args, _object * kwds) Line 98	C
 	python36_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2170	C
 	python36_d.dll!PyEval_CallObjectWithKeywords(_object * func, _object * arg, _object * kw) Line 4592	C
 	python36_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 2759	C
 	python36_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 4029	C
 	python36_d.dll!PyEval_EvalCodeEx(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure) Line 4050	C
 	python36_d.dll!PyEval_EvalCode(_object * co, _object * globals, _object * locals) Line 777	C
 	python36_d.dll!run_mod(_mod * mod, _object * filename, _object * globals, _object * locals, PyCompilerFlags * flags, _arena * arena) Line 970	C
 	python36_d.dll!PyRun_InteractiveOneObject(_iobuf * fp, _object * filename, PyCompilerFlags * flags) Line 233	C
 	python36_d.dll!PyRun_InteractiveLoopFlags(_iobuf * fp, const char * filename_str, PyCompilerFlags * flags) Line 112	C
 	python36_d.dll!PyRun_AnyFileExFlags(_iobuf * fp, const char * filename, int closeit, PyCompilerFlags * flags) Line 74	C
 	python36_d.dll!run_file(_iobuf * fp, const wchar_t * filename, PyCompilerFlags * p_cf) Line 318	C
 	python36_d.dll!Py_Main(int argc, wchar_t * * argv) Line 768	C
 	python_d.exe!wmain(int argc, wchar_t * * argv) Line 14	C
 	[External Code]	

This was compiled using Microsoft Visual Studio Community 2015

----------
messages: 259024
nosy: ebarry
priority: normal
severity: normal
status: open
title: Fatal error when importing ``test.test_os`` in debug mode on Windows
versions: Python 3.6

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

From report at bugs.python.org  Wed Jan 27 11:10:06 2016
From: report at bugs.python.org (Wallison Resende Santos)
Date: Wed, 27 Jan 2016 16:10:06 +0000
Subject: [New-bugs-announce] [issue26218] Set PrependPath default to true
Message-ID: <1453911006.83.0.905556840018.issue26218@psf.upfronthosting.co.za>


New submission from Wallison Resende Santos:

Please, set the PrependPath configuration to true. It's a good option for console developers on windows.

----------
components: Installation
messages: 259028
nosy: Wallison Resende Santos
priority: normal
severity: normal
status: open
title: Set PrependPath default to true
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Jan 27 12:11:27 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 27 Jan 2016 17:11:27 +0000
Subject: [New-bugs-announce] [issue26219] implement per-opcode cache in ceval
Message-ID: <1453914687.03.0.978372578059.issue26219@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
assignee: yselivanov
components: Interpreter Core
nosy: yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: implement per-opcode cache in ceval
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Wed Jan 27 12:15:08 2016
From: report at bugs.python.org (Quentin Pradet)
Date: Wed, 27 Jan 2016 17:15:08 +0000
Subject: [New-bugs-announce] [issue26220] Unicode HOWTO references a
 question mark that isn't in snippet
Message-ID: <1453914908.97.0.691892593639.issue26220@psf.upfronthosting.co.za>


New submission from Quentin Pradet:

>From https://docs.python.org/3.6/howto/unicode.html#the-string-type:

> The following examples show the differences::
>
>     >>> b'\x80abc'.decode("utf-8", "strict")  #doctest: +NORMALIZE_WHITESPACE
>     Traceback (most recent call last):
>         ...
>     UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0:
>       invalid start byte
>     >>> b'\x80abc'.decode("utf-8", "replace")
>     '\ufffdabc'
>     >>> b'\x80abc'.decode("utf-8", "backslashreplace")
>     '\\x80abc'
>     >>> b'\x80abc'.decode("utf-8", "ignore")
>     'abc'
>
> (In this code example, the Unicode replacement character has been replaced by
> a question mark because it may not be displayed on some systems.)

I think the whole sentence after the snippet can be removed because this is exactly what Python 3.2+ outputs. It looks like the commit which added this sentence dates from Python 3.1: https://github.com/python/cpython/commit/34d4c82af56ebc1b65514a118f0ec7feeb8e172f, but another commit around Python 3.3 removed it: https://github.com/python/cpython/commit/63172c46706ae9b2a3bc80d639504a57fff4e716.

----------
assignee: docs at python
components: Documentation
messages: 259034
nosy: Quentin.Pradet, docs at python
priority: normal
severity: normal
status: open
title: Unicode HOWTO references a question mark that isn't in snippet
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/issue26220>
_______________________________________

From report at bugs.python.org  Wed Jan 27 12:25:33 2016
From: report at bugs.python.org (Ian Kelly)
Date: Wed, 27 Jan 2016 17:25:33 +0000
Subject: [New-bugs-announce] [issue26221] asynco run_in_executor swallows
 StopIteration
Message-ID: <1453915533.75.0.0706458699162.issue26221@psf.upfronthosting.co.za>


New submission from Ian Kelly:

I was playing around with this class for adapting regular iterators to async iterators using BaseEventLoop.run_in_executor:


import asyncio

class AsyncIteratorWrapper:

    def __init__(self, iterable, loop=None, executor=None):
        self._iterator = iter(iterable)
        self._loop = loop or asyncio.get_event_loop()
        self._executor = executor

    async def __aiter__(self):
        return self

    async def __anext__(self):
        try:
            return await self._loop.run_in_executor(
                    self._executor, next, self._iterator)
        except StopIteration:
            raise StopAsyncIteration


Unfortunately this fails because when next raises StopIteration, run_in_executor swallows the exception and just returns None back to the coroutine, resulting in an infinite iterator of Nones.

----------
components: asyncio
messages: 259036
nosy: gvanrossum, haypo, ikelly, yselivanov
priority: normal
severity: normal
status: open
title: asynco run_in_executor swallows StopIteration
versions: Python 3.5

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

From report at bugs.python.org  Wed Jan 27 12:45:28 2016
From: report at bugs.python.org (Rasmus Rynning Rasmussen)
Date: Wed, 27 Jan 2016 17:45:28 +0000
Subject: [New-bugs-announce] [issue26222] Missing code in linux_distribution
 python 2.7.11
Message-ID: <1453916728.01.0.709818070841.issue26222@psf.upfronthosting.co.za>


New submission from Rasmus Rynning Rasmussen:

During the transition from python 2.7.10 to 2.7.11 some code seems to have been lost. platform.linux_distribution() is not able to recognise Debian based distributions in python 2.7.11.

The following code was present in platform.py, python 2.7.10, but seems to be missing in 2.7.11

# check for the LSB /etc/lsb-release file first, needed so
# that the distribution doesn't get identified as Debian.
    try:
        with open("/etc/lsb-release", "rU") as etclsbrel:
            for line in etclsbrel:
                m = _distributor_id_file_re.search(line)
                if m:
                    _u_distname = m.group(1).strip()
                m = _release_file_re.search(line)
                if m:
                    _u_version = m.group(1).strip()
                m = _codename_file_re.search(line)
                if m:
                    _u_id = m.group(1).strip()
            if _u_distname and _u_version:
                return (_u_distname, _u_version, _u_id)
    except (EnvironmentError, UnboundLocalError):
        pass

----------
components: Build
messages: 259037
nosy: Rasmus Rynning Rasmussen
priority: normal
severity: normal
status: open
title: Missing code in linux_distribution python 2.7.11
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 27 14:15:13 2016
From: report at bugs.python.org (Serge Stroobandt)
Date: Wed, 27 Jan 2016 19:15:13 +0000
Subject: [New-bugs-announce] [issue26223] decimal.to_eng_string() does not
 implement engineering notation in all cases.
Message-ID: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>


New submission from Serge Stroobandt:

In https://docs.python.org/2/library/string.html#formatstrings the proprietary (IBM) specifcation "Decimal Arithmetic Specification" http://www.gobosoft.com/eiffel/gobo/math/decimal/daconvs.html is incorrectly being heralded as "the" specifiaction for engineering notation.

However, upon reading this IBM specifation carefully, one will note that the specifaction itself actually admits not applying the engineering notation in the case of infinite numbers.

An emphasized version of the exact quote accompanied with a discussion can be found here: http://stackoverflow.com/a/17974598/2192488

Correct behaviour for decimal.to_eng_string() would be to equally employ engineering notation in the case of infinite numbers.

I suggest renaming the current behaviour to decimal.to_ibm_string().

References:
http://www.augustatech.edu/math/molik/notation.pdf
https://en.wikipedia.org/wiki/Engineering_notation
https://en.wikipedia.org/wiki/General_Conference_on_Weights_and_Measures
http://www.bipm.org/en/CGPM/db/11/11/

PS: I am a MSc in Electronic Engineering.

----------
components: Extension Modules
files: engineering_notation.pdf
messages: 259047
nosy: Keith.Brafford, eric.smith, ezio.melotti, serge.stroobandt
priority: normal
severity: normal
status: open
title: decimal.to_eng_string() does not implement engineering notation in all cases.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file41730/engineering_notation.pdf

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

From report at bugs.python.org  Wed Jan 27 18:02:48 2016
From: report at bugs.python.org (Udi Oron)
Date: Wed, 27 Jan 2016 23:02:48 +0000
Subject: [New-bugs-announce] [issue26224] Add "version added" for
 documentation of asyncio.timeout for documentation of python 3.4, 3.5, 3.6
Message-ID: <1453935768.98.0.383268297204.issue26224@psf.upfronthosting.co.za>


New submission from Udi Oron:

It seems like `asyncio.timeout` is going to be added in 3.4.5, 3.5.2 and 3.6.

The current live documentation of python 3.4 and python 3.5.1 does not include a comment regarding it is not yet available in the current released versions of python.

The documentation should include a `.. versionadded:: 3.4.5`, `.. versionadded:: 3.5.2` or `.. versionadded:: 3.6` according to the branch.

----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio-timeout.patch
keywords: patch
messages: 259071
nosy: Udi Oron, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Add "version added" for documentation of asyncio.timeout for documentation of python 3.4, 3.5, 3.6
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41731/asyncio-timeout.patch

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

From report at bugs.python.org  Wed Jan 27 19:01:28 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Thu, 28 Jan 2016 00:01:28 +0000
Subject: [New-bugs-announce] [issue26225] New misleading wording in
 execution model documenation
Message-ID: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

In #24129, the wording describing class local bindings in 4.2.2 "Resolution of names" was changed for Python 3.4, 3.5, and 3.6. The new version is a lot clearer for classes--but now it's misleading for `exec`/`eval`.

---

> Class definition blocks and arguments to exec() and eval() are
> special in the context of name resolution. A class definition is...

... and then proceeds to explain how class lookup works, without ever mentioning `exec` and `eval`. This implies that they work the same way as classes, but of course that's not true:

    i = 'global'
    def f():
        i = 'nonlocal'
        class C:
            print(i)
            i = 'local'
            print(i)
    f()

That prints `global`, then `local`. But with `exec`:

    i = 'global'
    def f():
        i = 'nonlocal'
        exec("print(i)\ni = 'local'\nprint(i)\n")
    f()

That prints `nonlocal` then `local`.

I think just putting a paragraph break between the first sentence and the rest of the paragraph might be sufficient to avoid the confusion here. Or just removing any mention of `eval` and `exec`. If not, this probably needs a new one-liner paragraph saying something like "Arguments to `exec()` and `eval()` are also special, as described later."

---

Meanwhile, if you keep reading, you'll eventually find that `exec` is described in a later section, 4.2.4 "Interaction with dynamic features", but that's _also_ misleading:

> The eval() and exec() functions do not have access to the full
> environment for resolving names. Names may be resolved in the
> local and global namespaces of the caller. Free variables are not
> resolved in the nearest enclosing namespace, but in the global
> namespace.

If that were true, the `exec` example would have printed `global`, right?

I'm pretty sure that what's going on here is that `exec` implicitly calls `locals()` (or, rather, the C-API equivalent), which constructs a locals dict on demand, which, only if you're inside a function block, includes not just the currently-bound fast locals, but _also_ the cell_contents of the currently-bound free variables. So, as far as `exec` is concerned, `i` is not an unbound local, or a free variable, but a local, which is bound to the `'nonlocal'` cell value of `i` at the time `exec` was called.

Which means the following actually _does_ print `global`:

    i = 'global'
    def f():
        exec("print(i)\ni = 'local'\nprint(i)\n")
        i = 'nonlocal'
    f()

I have no idea how to make this clear. Maybe the simplest is to not try to give a full explanation here, and instead punt to the `locals()` function definition? Maybe something like this:

> The `eval()` and `exec()` functions do not have access to the full environment for resolving names, but rather to the approximation of that environment as constructed by the `locals()` function. Free variables that are not captured as locals are not resolved in the nearest enclosing namespace, but in the global...

... and from there, the same as the current paragraph.

----------
assignee: docs at python
components: Documentation
messages: 259073
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: New misleading wording in execution model documenation

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

From report at bugs.python.org  Wed Jan 27 19:25:51 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 28 Jan 2016 00:25:51 +0000
Subject: [New-bugs-announce] [issue26226] Various test suite failures on
 Windows
Message-ID: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

Compiled latest master and ran test suite (Py_DEBUG build). A few failures here and there, and some tests skipped. I haven't yet looked into getting the proper libraries to make some of the skipped tests execute, I'm trying to make the whole test suite pass first.

Attached file includes verbose output for all failed tests. The end of the file and the traceback at the end of the message here happen, then Python hangs and never resumes (tested for ~20 minutes).

Python 3.6.0a0 (default, Jan 27 2016, 10:49:09) [MSC v.1900 32 bit (Intel)] on w
in32
Type "help", "copyright", "credits" or "license" for more information.
>>> import test.regrtest
>>> test.regrtest.main_in_temp_cwd() # same as 'py -m test'
== CPython 3.6.0a0 (default, Jan 27 2016, 10:49:09) [MSC v.1900 32 bit (Intel)]
==   Windows-7-6.1.7601-SP1 little-endian
==   hash algorithm: siphash24 32bit
==   E:\GitHub\cpython\build\test_python_13304
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0,
bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[  1/400] test_grammar
[  2/400] test_opcodes
[  3/400] test_dict
[  4/400] test_builtin
[  5/400] test_exceptions
[  6/400] test_types
[  7/400] test_unittest
[  8/400] test_doctest
[  9/400] test_doctest2
[ 10/400] test_support
[ 11/400] test___all__
[ 12/400] test___future__
[ 13/400] test__locale
[ 14/400] test__opcode
[ 15/400] test__osx_support
[ 16/400] test_abc
[ 17/400] test_abstract_numbers
[ 18/400] test_aifc
[ 19/400] test_argparse
[ 20/400] test_array
[ 21/400] test_asdl_parser
[ 22/400] test_ast
[ 23/400] test_asynchat
[ 24/400] test_asyncio
E:\GitHub\cpython\lib\asyncio\sslproto.py:327: ResourceWarning: unclosed transport
<asyncio.sslproto._SSLProtocolTransport object at 0x05EA8BD0>
  warnings.warn("unclosed transport %r" % self, ResourceWarning)
test test_asyncio failed -- multiple errors occurred; run in verbose mode for details
[ 25/400/1] test_asyncore
[ 26/400/1] test_atexit
[ 27/400/1] test_audioop
[ 28/400/1] test_augassign
[ 29/400/1] test_base64
[ 30/400/1] test_bigaddrspace
[ 31/400/1] test_bigmem
[ 32/400/1] test_binascii
[ 33/400/1] test_binhex
[ 34/400/1] test_binop
[ 35/400/1] test_bisect
[ 36/400/1] test_bool
[ 37/400/1] test_buffer
[ 38/400/1] test_bufio
[ 39/400/1] test_bytes
[ 40/400/1] test_bz2
[ 41/400/1] test_calendar
[ 42/400/1] test_call
[ 43/400/1] test_capi
[ 44/400/1] test_cgi
[ 45/400/1] test_cgitb
[ 46/400/1] test_charmapcodec
[ 47/400/1] test_class
[ 48/400/1] test_cmath
[ 49/400/1] test_cmd
[ 50/400/1] test_cmd_line
[ 51/400/1] test_cmd_line_script
[ 52/400/1] test_code
[ 53/400/1] test_code_module
test test_code_module failed -- multiple errors occurred; run in verbose mode for details
[ 54/400/2] test_codeccallbacks
[ 55/400/2] test_codecencodings_cn
[ 56/400/2] test_codecencodings_hk
[ 57/400/2] test_codecencodings_iso2022
test test_codecencodings_iso2022 failed -- multiple errors occurred; run in verbose mode for details
[ 58/400/3] test_codecencodings_jp
[ 59/400/3] test_codecencodings_kr
[ 60/400/3] test_codecencodings_tw
[ 61/400/3] test_codecmaps_cn
[ 62/400/3] test_codecmaps_hk
[ 63/400/3] test_codecmaps_jp
[ 64/400/3] test_codecmaps_kr
[ 65/400/3] test_codecmaps_tw
[ 66/400/3] test_codecs
[ 67/400/3] test_codeop
[ 68/400/3] test_collections
[ 69/400/3] test_colorsys
[ 70/400/3] test_compare
[ 71/400/3] test_compile
[ 72/400/3] test_compileall
[ 73/400/3] test_complex
[ 74/400/3] test_concurrent_futures
[ 75/400/3] test_configparser
[ 76/400/3] test_contains
[ 77/400/3] test_contextlib
[ 78/400/3] test_copy
[ 79/400/3] test_copyreg
[ 80/400/3] test_coroutines
[ 81/400/3] test_cprofile
[ 82/400/3] test_crashers
[ 83/400/3] test_crypt
test_crypt skipped -- No module named '_crypt'
[ 84/400/3] test_csv
[ 85/400/3] test_ctypes
[ 86/400/3] test_curses
test_curses skipped -- Use of the 'curses' resource not enabled
[ 87/400/3] test_datetime
[ 88/400/3] test_dbm
[ 89/400/3] test_dbm_dumb
[ 90/400/3] test_dbm_gnu
test_dbm_gnu skipped -- No module named '_gdbm'
[ 91/400/3] test_dbm_ndbm
test_dbm_ndbm skipped -- No module named '_dbm'
[ 92/400/3] test_decimal
[ 93/400/3] test_decorators
[ 94/400/3] test_defaultdict
[ 95/400/3] test_deque
[ 96/400/3] test_descr
[ 97/400/3] test_descrtut
[ 98/400/3] test_devpoll
test_devpoll skipped -- test works only on Solaris OS family
[ 99/400/3] test_dictcomps
[100/400/3] test_dictviews
[101/400/3] test_difflib
[102/400/3] test_dis
[103/400/3] test_distutils

E:\GitHub\cpython\build\test_python_13304>exit 1

E:\GitHub\cpython\build\test_python_13304>exit 0
Warning -- files was modified by test_distutils
test test_distutils failed -- multiple errors occurred; run in verbose mode for details
[104/400/4] test_docxmlrpc
[105/400/4] test_dummy_thread
[106/400/4] test_dummy_threading
[107/400/4] test_dynamic
[108/400/4] test_dynamicclassattribute
[109/400/4] test_eintr
[110/400/4] test_email
[111/400/4] test_ensurepip
[112/400/4] test_enum
[113/400/4] test_enumerate
[114/400/4] test_eof
[115/400/4] test_epoll
test_epoll skipped -- test works only on Linux 2.6
[116/400/4] test_errno
[117/400/4] test_exception_variations
[118/400/4] test_extcall
[119/400/4] test_faulthandler
[120/400/4] test_fcntl
test_fcntl skipped -- No module named 'fcntl'
[121/400/4] test_file
[122/400/4] test_file_eintr
[123/400/4] test_filecmp
[124/400/4] test_fileinput
[125/400/4] test_fileio
[126/400/4] test_finalization
[127/400/4] test_float
[128/400/4] test_flufl
[129/400/4] test_fnmatch
[130/400/4] test_fork1
test_fork1 skipped -- object <module 'os' from 'E:\\GitHub\\cpython\\lib\\os.py'> has no attribute 'fork'
[131/400/4] test_format
[132/400/4] test_fractions
[133/400/4] test_frame
[134/400/4] test_fstring
[135/400/4] test_ftplib
[136/400/4] test_funcattrs
[137/400/4] test_functools
[138/400/4] test_future
[139/400/4] test_future3
[140/400/4] test_future4
[141/400/4] test_future5
[142/400/4] test_gc
[143/400/4] test_gdb
test_gdb skipped -- Couldn't find gdb on the path
[144/400/4] test_generators
[145/400/4] test_genericpath
[146/400/4] test_genexps
[147/400/4] test_getargs2
[148/400/4] test_getopt
[149/400/4] test_getpass
[150/400/4] test_gettext
[151/400/4] test_glob
[152/400/4] test_global
[153/400/4] test_grp
test_grp skipped -- No module named 'grp'
[154/400/4] test_gzip
[155/400/4] test_hash
[156/400/4] test_hashlib
[157/400/4] test_heapq
[158/400/4] test_hmac
[159/400/4] test_html
[160/400/4] test_htmlparser
[161/400/4] test_http_cookiejar
[162/400/4] test_http_cookies
[163/400/4] test_httplib
test test_httplib failed -- multiple errors occurred; run in verbose mode for details
[164/400/5] test_httpservers
Exception in thread Thread-857:
Traceback (most recent call last):
  File "E:\GitHub\cpython\lib\threading.py", line 916, in _bootstrap_inner
    self.run()
  File "E:\GitHub\cpython\lib\test\test_httpservers.py", line 42, in run
    self.server = HTTPServer(('localhost', 0), self.request_handler)
  File "E:\GitHub\cpython\lib\socketserver.py", line 443, in __init__
    self.server_bind()
  File "E:\GitHub\cpython\lib\http\server.py", line 140, in server_bind
    self.server_name = socket.getfqdn(host)
  File "E:\GitHub\cpython\lib\socket.py", line 662, in getfqdn
    hostname, aliases, ipaddrs = gethostbyaddr(name)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc9 in position 0: invalid
continuation byte

----------
files: failed_tests_output.txt
messages: 259075
nosy: ebarry
priority: normal
severity: normal
status: open
title: Various test suite failures on Windows
Added file: http://bugs.python.org/file41733/failed_tests_output.txt

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

From report at bugs.python.org  Wed Jan 27 19:58:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 00:58:50 +0000
Subject: [New-bugs-announce] [issue26227] Windows:
 socket.gethostbyaddr(name) fails for non-ASCII hostname
Message-ID: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On Windows, socket.gethostbyaddr() must decode the hostname from the ANSI code page, not from UTF-8. See for example this issue:
https://bugs.python.org/issue26226#msg259077

Attached patch changes the socket module to decode hostnames from the ANSI code page on Windows.

See also issues #9377, #16652 and #5004.

----------
components: Unicode, Windows
messages: 259078
nosy: ebarry, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: socket.gethostbyaddr(name) fails for non-ASCII hostname
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan 27 23:04:21 2016
From: report at bugs.python.org (Chris Torek)
Date: Thu, 28 Jan 2016 04:04:21 +0000
Subject: [New-bugs-announce] [issue26228] pty.spawn hangs on FreeBSD 9.3,
 10.x
Message-ID: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za>


New submission from Chris Torek:

The pty.spawn() code assumes that when the process on the slave side of the pty quits, the master side starts raising OSError when read-from or written-to.

That used to be true in FBSD, but then someone fixed (?) it, and now the master side simply returns EOF when read-from.  Furthermore, writes to the master simply disappear into the aether (this may be an OS bug, but even if the writes raised OSError, you would still have to type something in on stdin to get it copied over to get the error raised to get out of the loop).

The fix here makes an assumption that is true when using the built-in read calls: EOF on the master indicates that the slave is no longer reachable in any way and the whole thing should finish up immediately.  It might perhaps need a bit of documentation should someone want to substitute in their own read function (see enhancement request in issue22865).

I also fixed (sort of) issue17824, but only barely minimally, and put in a comment that it should really use the same mechanism as subprocess (but I think that should be a separate patch).

----------
files: pty.patch
keywords: patch
messages: 259088
nosy: Chris Torek
priority: normal
severity: normal
status: open
title: pty.spawn hangs on FreeBSD 9.3, 10.x
Added file: http://bugs.python.org/file41738/pty.patch

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

From report at bugs.python.org  Thu Jan 28 02:25:11 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Thu, 28 Jan 2016 07:25:11 +0000
Subject: [New-bugs-announce] [issue26229] Make number serialization ES6/V8
 compatible
Message-ID: <1453965911.58.0.319543725596.issue26229@psf.upfronthosting.co.za>


New submission from Anders Rundgren:

ECMA has in their latest release defined that JSON elements must be ordered during serialization.  This is easy to accomplish using Python's OrderedDict.  What is less trivial is that numbers have to be formatted in a certain way as well.  I have tested 100 millions specific and random values and found out that Python 3.5.1 is mathematically identical to ES6/V8 but has some differences in formatting:

   IEEE Double        ECMAScript 6/V8            Python 3.5.1

c43211ede4974a35, -333333333333333300000,    -3.333333333333333e+20
c3fce97ca0f21056, -33333333333333336000,     -3.3333333333333336e+19
c3c7213080c1a6ac, -3333333333333334000,      -3.333333333333334e+18
c39280f39a348556, -333333333333333400,       -3.333333333333334e+17
c35d9b1f5d20d557, -33333333333333340,        -3.333333333333334e+16

c327af4c4a80aaac, -3333333333333334,         -3333333333333334.0

bf0179ec9cbd821e, -0.000033333333333333335,  -3.3333333333333335e-05
becbf647612f3696, -0.0000033333333333333333, -3.3333333333333333e-06

4024000000000000, 10,                        10.0
0000000000000000, 0,                         0.0
4014000000000000, 5,                         5.0
3f0a36e2eb1c432d, 0.00005,                   5e-05
3ed4f8b588e368f1, 0.000005,                  5e-06

3ea0c6f7a0b5ed8d, 5e-7,                      5e-07

Why could this be important?

https://github.com/Microsoft/ChakraCore/issues/149

# Python test program
import binascii
import struct
import json

f = open('c:\\es6\\numbers\\es6testfile100m.txt','rb')

l = 0;
string = '';

while True:
  byte = f.read(1);
  if len(byte) == 0:
    exit(0)
  if byte == b'\n':
    l = l + 1;
    i = string.find(',')
    if i <= 0 or i >= len(string) - 1:
      print('Bad string: ' + str(i))
      exit(0)
    hex = string[:i]
    while len(hex) < 16:
      hex = '0' + hex
    o = dict()
    o['double'] = struct.unpack('>d',binascii.a2b_hex(hex))[0]
    py3Double = json.dumps(o)[11:-1]
    es6Double = string[i + 1:]
    if es6Double != py3Double:
      es6Dpos = es6Double.find('.')
      py3Dpos = py3Double.find('.')
      es6Epos = es6Double.find('e')
      py3Epos = py3Double.find('e')
      if py3Epos > 0:
        py3Exp = int(py3Double[py3Epos + 1:])
      if es6Dpos < 0 and py3Dpos > 0:
        if es6Epos < 0 and py3Epos > 0:
          py3New = py3Double[:py3Dpos] + py3Double[py3Dpos + 1:py3Epos - len(py3Double)]
          q = py3Exp - py3Epos + py3Dpos
          while q >= 0:
            py3New += '0'
            q -= 1
          if py3New != es6Double:
            print('E1: ' + py3New)
            exit(0)
        elif py3Epos < 0:
          py3New = py3Double[:-2]
          if py3New != es6Double:
            print('E2: ' + py3New)
            exit(0)
        else:
          print (error + hex + '#' + es6Double + '#' + py3Double)
          exit(0)
      elif es6Dpos > 0 and py3Dpos > 0 and py3Epos > 0 and es6Epos < 0:
        py3New = py3Double[py3Dpos - 1:py3Dpos] + py3Double[py3Dpos + 1:py3Epos - len(py3Double)]
        q = py3Exp + 1
        while q < 0:
          q += 1
          py3New = '0' + py3New
        py3New = py3Double[0:py3Dpos - 1] + '0.' + py3New 
        if py3New != es6Double:
          print('E3: ' + py3New + '#' + es6Double)
          exit(0)
      elif es6Dpos == py3Dpos and py3Epos > 0 and es6Epos > 0:
        py3New = py3Double[:py3Epos + 2] + str(abs(py3Exp))
        if py3New != es6Double:
          print('E4: ' + py3New + '#' + es6Double)
          exit(0)
      elif es6Dpos > 0 and py3Dpos < 0 and py3Epos > 0 and es6Epos < 0:
        py3New = py3Double[:py3Epos - len(py3Double)]
        q = py3Exp + 1
        while q < 0:
          q += 1
          py3New = '0' + py3New
        py3New = '0.' + py3New 
        if py3New != es6Double:
          print('E5: ' + py3New + '#' + es6Double)
          exit(0)
      else:
        print ('Unexpected: ' + hex + '#' + es6Double + '#' + py3Double)
        exit(0)
    string = ''
    if l % 10000 == 0:
      print(l)
  else:
    string += byte.decode(encoding='UTF-8')

----------
components: Interpreter Core
messages: 259105
nosy: anders.rundgren.net at gmail.com
priority: normal
severity: normal
status: open
title: Make number serialization ES6/V8 compatible
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 28 04:20:32 2016
From: report at bugs.python.org (tom liu)
Date: Thu, 28 Jan 2016 09:20:32 +0000
Subject: [New-bugs-announce] [issue26230] Cookies do not correct if
 cookiename includes [ or ]
Message-ID: <1453972832.46.0.774490417388.issue26230@psf.upfronthosting.co.za>


Changes by tom liu <tom_lt at qq.com>:


----------
components: Extension Modules
nosy: tom_lt
priority: normal
severity: normal
status: open
title: Cookies do not correct if cookiename includes [ or ]
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 28 05:43:17 2016
From: report at bugs.python.org (Jacky)
Date: Thu, 28 Jan 2016 10:43:17 +0000
Subject: [New-bugs-announce] [issue26231] HTTPResponse.close() should
 consume all remaining data in body if any
Message-ID: <1453977797.39.0.133146806463.issue26231@psf.upfronthosting.co.za>


New submission from Jacky:

HTTPResponse.close() in httplib should consume all remaining data in body if any. Or the followed request would get the unread content from the previous request, which result in the wrong result.

The following code shown that the second request will get a wrong status code if calling HTTPResponse.close() on the first response.

The whole code consists of a HTTP server and a client. The server will always return 403 for testing.


def client():
    conn = httplib.HTTPConnection(HOST, PORT)
    conn.request('GET', PATH, None, headers={})
    rsp = conn.getresponse()
    print rsp.status
    rsp.close()  # close response

    conn.request('GET', PATH, None, headers={})
    rsp2 = conn.getresponse()
    print rsp2.status  # --> should be 403

The full version see the attached file (The server used Tornado)

----------
components: Library (Lib)
files: zzz.py
messages: 259122
nosy: Jacky
priority: normal
severity: normal
status: open
title: HTTPResponse.close() should consume all remaining data in body if any
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41742/zzz.py

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

From report at bugs.python.org  Thu Jan 28 09:08:17 2016
From: report at bugs.python.org (David Szotten)
Date: Thu, 28 Jan 2016 14:08:17 +0000
Subject: [New-bugs-announce] [issue26232] Mock(spec=spec) has no effect
Message-ID: <1453990097.49.0.0657857764216.issue26232@psf.upfronthosting.co.za>


New submission from David Szotten:

Unless i misunderstand the docs, i would expect `Mock(foo)` to have the same effect as `create_autospec(foo)`, but that doesn't appear to be the case:

>>> m1 = mock.Mock(spec=lambda: None)
>>> m2 = mock.create_autospec(spec=lambda: None)
>>> m1(1)
<Mock name='mock()' id='4377526960'>
>>> m2(1)
# snip
TypeError: too many positional arguments

----------
components: Library (Lib)
messages: 259130
nosy: davidszotten
priority: normal
severity: normal
status: open
title: Mock(spec=spec) has no effect
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jan 28 10:11:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jan 2016 15:11:45 +0000
Subject: [New-bugs-announce] [issue26233] select.epoll.wait() should away
 calling malloc() each time
Message-ID: <1453993905.97.0.27003618713.issue26233@psf.upfronthosting.co.za>


New submission from STINNER Victor:

My colleague Fabio M. Di Nitto noticed that the memory allocation on the heap (PyMem_Malloc()) in select.epoll.wait() can have an impact on performance when select.epoll.wait() is a busy applicatin.

He proposed attached patch to allocate memory on the stack for up to FD_SETSIZE-1 events: see attached patch.

----------
components: Library (Lib)
files: epoll_stack.patch
keywords: patch
messages: 259141
nosy: haypo, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: select.epoll.wait() should away calling malloc() each time
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41743/epoll_stack.patch

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

From report at bugs.python.org  Thu Jan 28 19:07:33 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Jan 2016 00:07:33 +0000
Subject: [New-bugs-announce] [issue26234] The typing module includes 're'
 and 'io' in __all__
Message-ID: <1454026053.81.0.969583520836.issue26234@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

If you write "from typing import *" you get "re" and "io" for free, which is surprising if this import occurs after an actual "import re" or "import io".

The solution is not to include those two in __all__. You can still use them -- use "from typing import re" explicitly or reference them as "typing.re".

Because typing is provisional I'll fix this in 3.5.2 as well.

----------
messages: 259177
nosy: gvanrossum
priority: release blocker
severity: normal
status: open
title: The typing module includes 're' and 'io' in __all__
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jan 28 19:16:38 2016
From: report at bugs.python.org (paul j3)
Date: Fri, 29 Jan 2016 00:16:38 +0000
Subject: [New-bugs-announce] [issue26235] argparse docs: Positional *
 argument in mutually exclusive group requires a default parameter
Message-ID: <1454026598.04.0.15054739834.issue26235@psf.upfronthosting.co.za>


New submission from paul j3:

The documentation for Mutual exclusion

https://docs.python.org/3/library/argparse.html#mutual-exclusion

needs a note that a mutually exclusive group may contain one positional argument.  But that argument must be either nargs='?', or nargs='*'.  If '*' it must also have a default parameter (other than None).

(this issue came up recently on stackoverflow.  It may have also been raised in the past as a bug/issue, but I don't have time at moment to search.  I had to search through several layers of code to remember all the details.)

http://stackoverflow.com/questions/35044288/how-can-i-create-an-argparse-mutually-exclusive-group-with-multiple-positional-p

----------
assignee: docs at python
components: Documentation
messages: 259179
nosy: docs at python, paul.j3
priority: normal
severity: normal
status: open
title: argparse docs: Positional * argument in mutually exclusive group requires a default parameter
versions: Python 3.6

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

From report at bugs.python.org  Thu Jan 28 22:34:46 2016
From: report at bugs.python.org (Julia Dolgova)
Date: Fri, 29 Jan 2016 03:34:46 +0000
Subject: [New-bugs-announce] [issue26236] urllib2 initiate irregular call to
 gethostbyaddr
Message-ID: <1454038486.05.0.415307366057.issue26236@psf.upfronthosting.co.za>


New submission from Julia Dolgova:

I'm using python 2.7. My system is windows 7(64-bit). I also use proxy.
urllib2.urlopen usually implements 0,2..1sec but sometimes sends a strange UDP to 137 port (netbios-ns) of the remote server, waits 4..6 sec. and then sends HTTP-request.

If I disable Netbios over TCP/IP in my system settings no UDP to 137 port is sent, but urlopen still implements 4..6sec.

I've found out that the delay happens in 
_socket.gethostbyaddr(HostName)
called by socket.getfqdn(HostName)
called by urllib.proxy_bypass_registry(HostName)
called by urllib.proxy_bypass(HostName)
called by urllib2.ProxyHandler.proxy_open 

HostName='pykasso.rc-online.ru'

"nslookup pykasso.rc-online.ru" works quickly in my computer

I suppose the problem is that the hostname is passed into gethostbyaddr instead of IP

If I add an IP-verification of the string before socket.getfqdn() call in urllib.proxy_bypass_registry()
try:
        socket.inet_aton(rawHost) #### I added this operator
        fqdn = socket.getfqdn(rawHost)
        if fqdn != rawHost:
               host.append(fqdn)
except socket.error:
        pass

then no delay happens.

My proposal is to make an IP-verification in urllib.proxy_bypass_registry() or to add an opportunity for a programmer to refuse a proxy bypass attempt

----------
components: Library (Lib), Windows
messages: 259190
nosy: juliadolgova, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: urllib2 initiate irregular call to gethostbyaddr
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 29 04:40:26 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 29 Jan 2016 09:40:26 +0000
Subject: [New-bugs-announce] [issue26237] UnboundLocalError error while
 handling exception
Message-ID: <1454060426.66.0.838628390922.issue26237@psf.upfronthosting.co.za>


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

This works right in Python 2.7, but fails in python3:

UnboundLocalError: local variable 'e' referenced before assignment


def test():
    try:
        raise Exception('a')
    except Exception as e:
        pass
    else:
        return
    print(e)

test()

----------
messages: 259201
nosy: mmarkk
priority: normal
severity: normal
status: open
title: UnboundLocalError error while handling exception
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan 29 07:35:46 2016
From: report at bugs.python.org (lirenke)
Date: Fri, 29 Jan 2016 12:35:46 +0000
Subject: [New-bugs-announce] [issue26238] httplib use wrong hostname in
 https request with SNI support
Message-ID: <1454070946.61.0.657909359351.issue26238@psf.upfronthosting.co.za>


New submission from lirenke:

httplib give openssl SNI extension message like IP:PORT string. 
the apache server would return 400 code if SNI/request ServerName mismatch.

In class HTTPSConnection, we hope call self._get_hostport() before give the value to server_hostname.

===
if self._tunnel_host:
	server_hostname = self._tunnel_host
else:
	server_hostname = self.host

self.sock = self._context.wrap_socket(self.sock,
									  server_hostname=server_hostname)

===

----------
components: Library (Lib)
messages: 259207
nosy: lvhancy
priority: normal
severity: normal
status: open
title: httplib use wrong hostname in https request with SNI support
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan 29 17:00:48 2016
From: report at bugs.python.org (Jeremy Fergason)
Date: Fri, 29 Jan 2016 22:00:48 +0000
Subject: [New-bugs-announce] [issue26239] distutils link-objects is not
 normalized
Message-ID: <1454104848.79.0.657615243425.issue26239@psf.upfronthosting.co.za>


New submission from Jeremy Fergason:

When giving setup.cfg a link-objects argument build fails with an error message about cannot concatenate string with list.  

Need to add the following line to: Lib/distutils/command/build_ext.py

self.ensure_string_list('link_objects')

See patch here:

https://github.com/jdfergason/cpython/compare/master...jdfergason-distutils-fix?quick_pull=1

----------
components: Distutils
messages: 259223
nosy: dstufft, eric.araujo, jdfergason
priority: normal
severity: normal
status: open
title: distutils link-objects is not normalized
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan 30 00:18:03 2016
From: report at bugs.python.org (Antony Lee)
Date: Sat, 30 Jan 2016 05:18:03 +0000
Subject: [New-bugs-announce] [issue26240] Docstring of the subprocess module
 should be cleaned up
Message-ID: <1454131083.41.0.870668221205.issue26240@psf.upfronthosting.co.za>


New submission from Antony Lee:

subprocess.__doc__ currently contains copies for the docstrings of a bunch of functions in the module (... but not subprocess.run).  The docs for the Popen class should be moved into that class' docstring.  The module's docstring also mentions the list2cmdline "method" (actually a function, and the qualifier "method"/"function" is missing the second time this function is mentioned ("The list2cmdline is designed ...")), but that function doesn't appear in `__all__` and thus not in the official HTML docs (yes, I know pydoc subprocess.list2cmdline works).

----------
assignee: docs at python
components: Documentation
messages: 259238
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Docstring of the subprocess module should be cleaned up
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan 30 04:22:04 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Sat, 30 Jan 2016 09:22:04 +0000
Subject: [New-bugs-announce] [issue26241] repr() and str() are identical for
 floats in 3.5
Message-ID: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>


New submission from Anders Rundgren:

According to the documentation repr() and str() are different when it comes to number formatting.  A test with a 100 million random and selected IEEE 64-bit values returned no differences

----------
components: Interpreter Core
messages: 259244
nosy: anders.rundgren.net at gmail.com
priority: normal
severity: normal
status: open
title: repr() and str() are identical for floats in 3.5
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan 30 12:26:28 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 30 Jan 2016 17:26:28 +0000
Subject: [New-bugs-announce] [issue26242] reST formatting error in
 Doc/library/importlib.rst
Message-ID: <1454174788.27.0.0600197935954.issue26242@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://hg.python.org/cpython/file/default/Doc/library/importlib.rst#l1124

the spacing is wrong, it should be:

.. versionchanged:: 3.5

----------
assignee: docs at python
components: Documentation
messages: 259263
nosy: alex, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: reST formatting error in Doc/library/importlib.rst
versions: Python 3.5

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

From report at bugs.python.org  Sat Jan 30 13:41:07 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Jan 2016 18:41:07 +0000
Subject: [New-bugs-announce] [issue26243] zlib.compress level as keyword
 argument
Message-ID: <1454179267.96.0.292283649228.issue26243@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

Currently zlib.compress allow only positional arguments. For code readability reasons i think that we should allow the level argument to be keyword argument. Now when someone uses zlib.compress he will be able to do zlib.compess(some_data, level=7) instead of zlib.compress(some_data, 7).

There is a patch included with the change.

----------
components: Extension Modules
files: zlib-compress-level-keyword.patch
keywords: patch
messages: 259266
nosy: nadeem.vawda, palaviv, twouters
priority: normal
severity: normal
status: open
title: zlib.compress level as keyword argument
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file41760/zlib-compress-level-keyword.patch

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

From report at bugs.python.org  Sat Jan 30 13:48:48 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Jan 2016 18:48:48 +0000
Subject: [New-bugs-announce] [issue26244] zlib.compressobj level default
 value documentation
Message-ID: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

In the zlib.compressobj documentation the default value of the compress level is -1 while it is actually 6.

patch is included

----------
assignee: docs at python
components: Documentation, Extension Modules
files: zlib-compressobj-level-doc.patch
keywords: patch
messages: 259267
nosy: docs at python, nadeem.vawda, palaviv, twouters
priority: normal
severity: normal
status: open
title: zlib.compressobj level default value documentation
versions: Python 3.6
Added file: http://bugs.python.org/file41761/zlib-compressobj-level-doc.patch

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

From report at bugs.python.org  Sun Jan 31 04:31:55 2016
From: report at bugs.python.org (Yoha)
Date: Sun, 31 Jan 2016 09:31:55 +0000
Subject: [New-bugs-announce] [issue26245] AttributeError (GL_READ_WRITE)
 when importing OpenGL.GL
Message-ID: <1454232715.33.0.584791017033.issue26245@psf.upfronthosting.co.za>


New submission from Yoha:

Importing `OpenGL.GL` fails on Python 3.5:

```
Python 3.5.1+ (default, Jan 13 2016, 15:09:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL.GL
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/OpenGL/GL/__init__.py", line 3, in <module>
    from OpenGL.GL.VERSION.GL_1_1 import *
  File "/usr/lib/python3/dist-packages/OpenGL/GL/VERSION/GL_1_1.py", line 10, in <module>
    from OpenGL import platform, constants, constant, arrays
  File "/usr/lib/python3/dist-packages/OpenGL/arrays/__init__.py", line 22, in <module>
    formathandler.FormatHandler.loadAll()
  File "/usr/lib/python3/dist-packages/OpenGL/arrays/formathandler.py", line 28, in loadAll
    cls.loadPlugin( entrypoint )
  File "/usr/lib/python3/dist-packages/OpenGL/arrays/formathandler.py", line 35, in loadPlugin
    plugin_class = entrypoint.load()
  File "/usr/lib/python3/dist-packages/OpenGL/plugins.py", line 14, in load
    return importByName( self.import_path )
  File "/usr/lib/python3/dist-packages/OpenGL/plugins.py", line 28, in importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "/usr/lib/python3/dist-packages/OpenGL/arrays/vbo.py", line 430, in <module>
    def mapVBO( vbo, access=GL.GL_READ_WRITE ):
AttributeError: module 'OpenGL.GL' has no attribute 'GL_READ_WRITE'
```

It seems to work fine in Python 3.4:

```
Python 3.4.4 (default, Jan  5 2016, 15:35:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL.GL
>>> 
```

Or by first importing `OpenGL.GLU`:

```
Python 3.5.1+ (default, Jan 13 2016, 15:09:18) 
[GCC 5.3.1 20160101] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL.GLU
>>> import OpenGL.GL
>>> 
```

----------
components: Extension Modules
messages: 259276
nosy: yoha
priority: normal
severity: normal
status: open
title: AttributeError (GL_READ_WRITE) when importing OpenGL.GL
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sun Jan 31 05:05:17 2016
From: report at bugs.python.org (Liang Bo Wang)
Date: Sun, 31 Jan 2016 10:05:17 +0000
Subject: [New-bugs-announce] [issue26246] Code output toggle button uses
 removed jQuery method
Message-ID: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>


New submission from Liang Bo Wang:

The code output toggle button (the `>>>` button on the top right) has been disappeared and not functional on the current online documentation (both 3.4+ and 2.7). 


For example, see any doc page that has interpreter outputs:

    https://docs.python.org/3/tutorial/introduction.html#numbers
    https://docs.python.org/3.5/tutorial/introduction.html#numbers
    https://docs.python.org/3.4/tutorial/introduction.html#numbers
    https://docs.python.org/2/tutorial/introduction.html#numbers


These toggle buttons are created dynamically using jQuery by the script at Doc/tools/static/copybutton.js. However, the method .toggle() it used for click event handling has been deprecated since jQuery 1.8 and removed since jQuery 1.9.

    https://api.jquery.com/toggle-event/


Current Python documentation ships with jQuery v1.11.1 and it has a new .toggle() method with totally different behavior, which controls animation and hide the element. Therefore those buttons are invisible and has no effect.

    https://api.jquery.com/toggle/


To achieve the old behavior, one now needs to create this toggle event on one's own. The most popular way to store the toggle state is by jQuery's .data() data storage.

A patch is attached to make the button functional again.

----------
assignee: docs at python
components: Documentation
files: copybutton_js.patch
keywords: patch
messages: 259279
nosy: Liang Bo Wang, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Code output toggle button uses removed jQuery method
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41764/copybutton_js.patch

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

From report at bugs.python.org  Sun Jan 31 09:23:21 2016
From: report at bugs.python.org (Ismail s)
Date: Sun, 31 Jan 2016 14:23:21 +0000
Subject: [New-bugs-announce] [issue26247] Document Chrome/Chromium for
 python2.7
Message-ID: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>


New submission from Ismail s:

The table of browser types in https://docs.python.org/2.7/library/webbrowser.html?highlight=webbrowser#webbrowser.register does not say that Google Chrome/Chromium is available on python2.7, even though it is (https://hg.python.org/cpython/file/2.7/Lib/webbrowser.py#l307).

Also, according to the docs for python.3.5 (https://docs.python.org/3.5/library/webbrowser.html?highlight=webbrowser#webbrowser.register , just below the table), support for google chrome/chromium was added in python3.3, so maybe this was backported to python2.7 and the docs not updated?

----------
assignee: docs at python
components: Documentation
messages: 259280
nosy: Ismail s, docs at python
priority: normal
severity: normal
status: open
title: Document Chrome/Chromium for python2.7
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 31 11:43:42 2016
From: report at bugs.python.org (Ben Hoyt)
Date: Sun, 31 Jan 2016 16:43:42 +0000
Subject: [New-bugs-announce] [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
Message-ID: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>


New submission from Ben Hoyt:

Per Guido's comment about DirEntry documentation on Issue 26032, especially http://bugs.python.org/issue26032#msg257665, it'd be good to improve the docs of the scandir DirEntry methods with regard to symlinks and caching.

Attaching my stab at a documentation fix. Changes here are:

1) Clarify that the return values of is_dir()/is_file()/etc are cached separately for follow_symlinks True and False.
2) Be more specific about when the functions require a system call, and how it relates to caching and follow_symlinks.
3) DRY up common stuff between is_dir and is_file by saying "Caching, system calls made, and exceptions raised are as per is_dir" in is_file.
4) Tweak to the first paragraph of docs for is_dir/is_file to simplify: assume the follow_symlinks=True default, then note the follow_symlinks=False non-default case after.

I think they're all improvements, though I'm not sure about #3. Is it better to just repeat those couple of paragraphs verbatim?

I'm also not 100% sure about mentioning the DT_UNKNOWN thing. But you really can't get more specific about when system calls are required on Unix without mentioning it.

----------
assignee: docs at python
components: Documentation
files: direntry_doc_improvements.patch
keywords: patch
messages: 259282
nosy: benhoyt, docs at python, gvanrossum, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve scandir DirEntry docs, especially re symlinks and caching
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41765/direntry_doc_improvements.patch

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

From report at bugs.python.org  Sun Jan 31 12:48:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:48:24 +0000
Subject: [New-bugs-announce] [issue26249] Change PyMem_Malloc to use
 PyObject_Malloc allocator?
Message-ID: <1454262504.41.0.628053130208.issue26249@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #23601 showed speedup for the dict type by replacing PyMem_Malloc() with PyObject_Malloc() in dictobject.c.

When I worked on the PEP 445, it was discussed to use the Python fast memory allocator for small memory allocations (<= 512 bytes), but I think that nobody tested on benchmark.

So I open an issue to discuss that.

By the way, we should also benchmark the Windows memory allocator which limits fragmentations. Maybe we can skip the Python small memory allocator on recent version of Windows?

Attached patch implements the change. The main question is the speedup on various kinds of memory allocations (need a benchmark) :-)

I will try to run benchmarks.

--

If the patch slows down Python, maybe we can investigate if some Python types (like dict) mostly uses "small" memory blocks (<= 512 bytes).

----------
files: pymem.patch
keywords: patch
messages: 259290
nosy: haypo, rhettinger, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Change PyMem_Malloc to use PyObject_Malloc allocator?
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file41767/pymem.patch

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

From report at bugs.python.org  Sun Jan 31 12:51:52 2016
From: report at bugs.python.org (hao Qing)
Date: Sun, 31 Jan 2016 17:51:52 +0000
Subject: [New-bugs-announce] [issue26250] no document for
 sqlite3.Cursor.connection
Message-ID: <1454262712.53.0.251399487214.issue26250@psf.upfronthosting.co.za>


New submission from hao Qing:

it does have the Cursor.connection member in the pydoc result.
$ pydoc sqlite3.Cursor.connection
Help on member descriptor sqlite3.Cursor.connection in sqlite3.Cursor:

sqlite3.Cursor.connection
lines 1-3/3 (END)

but there is no document about sqlite3.Cursor.connection at here.
https://docs.python.org/2/library/sqlite3.html#sqlite3.Cursor

and so to version 3
https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor

----------
components: Library (Lib)
messages: 259292
nosy: hao Qing
priority: normal
severity: normal
status: open
title: no document for sqlite3.Cursor.connection
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 31 12:55:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:55:40 +0000
Subject: [New-bugs-announce] [issue26251] Use "Low-fragmentation Heap"
 memory allocator on Windows
Message-ID: <1454262940.96.0.668805369213.issue26251@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python has a memory allocator optimized for allocations <= 512 bytes: PyObject_Malloc(). It was discussed to replace it by the native "Low-fragmentation Heap" memory allocator on Windows.

I'm not aware of anyone who tried that. I would nice to try, especially to run benchmarks.

See also the issue #26249: "Change PyMem_Malloc to use PyObject_Malloc allocator?".

----------
components: Windows
messages: 259293
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Use "Low-fragmentation Heap" memory allocator on Windows
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Sun Jan 31 12:56:13 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 Jan 2016 17:56:13 +0000
Subject: [New-bugs-announce] [issue26252] Add an example to importlib docs
 on setting up an importer
Message-ID: <1454262973.06.0.14692878532.issue26252@psf.upfronthosting.co.za>


New submission from Brett Cannon:

This past week a lot of people have asked me about how to set up an importer. It's enough to warrant adding an example in the new Examples section of the importlib docs to explain how to do this using the pre-existing classes in importlib.machinery for illustrative  purposes.

----------
assignee: brett.cannon
components: Documentation
messages: 259295
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Add an example to importlib docs on setting up an importer
versions: Python 3.6

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

From report at bugs.python.org  Sun Jan 31 19:55:23 2016
From: report at bugs.python.org (Patrik Dufresne)
Date: Mon, 01 Feb 2016 00:55:23 +0000
Subject: [New-bugs-announce] [issue26253] tarfile in stream mode always set
 zlib compression level to 9
Message-ID: <1454288123.43.0.462874591937.issue26253@psf.upfronthosting.co.za>


New submission from Patrik Dufresne:

When using tarfile.open(mode='w|gz'), the compression level is hard-coded to 9. Seed _Stream._init_write_gz():
    self.zlib.compressobj(9,

1. In regards to zlib, I would start by replacing the value of 9 by zlib.Z_DEFAULT_COMPRESSION. This is the default value and zipfile is using it. Why using something different.

2. Then, I would also love to control the compression level when calling tarfile.open()

----------
components: Library (Lib)
messages: 259304
nosy: Patrik Dufresne
priority: normal
severity: normal
status: open
title: tarfile in stream mode always set zlib compression level to 9
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/issue26253>
_______________________________________

From report at bugs.python.org  Sun Jan 31 20:50:17 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Mon, 01 Feb 2016 01:50:17 +0000
Subject: [New-bugs-announce] [issue26254] ssl server doesn't work with ECC
 certificates
Message-ID: <1454291417.3.0.6306970178.issue26254@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

I tried to use ssl module to create a server with a certificate that uses an ECC key. However, this didn't work. Here is how to reproduce this:

First, generate a key and a certificate:

    $ openssl req -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -x509 -keyout key.pem -out cert.pem
    (type some passphrase, then just press Enter in response to the questions that it asks)

Then run this Python program:

    from socket import socket
    from ssl import wrap_socket
    s = socket()
    s.bind(('localhost', 12345))
    s.listen()
    wrap_socket(s.accept()[0], 'key.pem', 'cert.pem', True)

This program will wait for a connection, so try to connect:

    $ openssl s_client -connect localhost:12345

The program will ask for a passphrase, so type it. After that, you will get an exception:

    Traceback (most recent call last):
      File "test.py", line 6, in <module>
        wrap_socket(s.accept()[0], 'key.pem', 'cert.pem', True)
      File "/usr/lib/python3.5/ssl.py", line 1064, in wrap_socket
        ciphers=ciphers)
      File "/usr/lib/python3.5/ssl.py", line 747, in __init__
        self.do_handshake()
      File "/usr/lib/python3.5/ssl.py", line 983, in do_handshake
        self._sslobj.do_handshake()
      File "/usr/lib/python3.5/ssl.py", line 628, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:645)

If the certificate uses RSA key, it works. With ECC, I had no luck. I tried creating a context explicitly and using set_ciphers method to enable more ciphers. While it appears to support ECDSA ciphersuites, it can't use them for some reason.

----------
components: Extension Modules
messages: 259305
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: ssl server doesn't work with ECC certificates
type: behavior
versions: Python 3.5

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