From report at bugs.python.org  Mon Aug  1 03:43:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 01 Aug 2016 07:43:10 +0000
Subject: [New-bugs-announce] [issue27662] Check against PY_SSIZE_T_MAX
 instead of PY_SIZE_MAX in List_New
Message-ID: <1470037390.18.0.139195089898.issue27662@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

List_New checks against PY_SIZE_MAX. The upper bound of PyMem_Malloc is PY_SSIZE_T_MAX.

Instead of simply changing the constant, another method is delegating overflow check to PyMem_Calloc, so we can avoid the check in unnecessary check in PyMem_Malloc. But I am not sure hiding the check in PyMem_Calloc is a good idea or not.

----------
components: Interpreter Core
files: List_New.patch
keywords: patch
messages: 271774
nosy: martin.panter, xiang.zhang
priority: normal
severity: normal
status: open
title: Check against PY_SSIZE_T_MAX instead of PY_SIZE_MAX in List_New
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43962/List_New.patch

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

From report at bugs.python.org  Mon Aug  1 06:27:37 2016
From: report at bugs.python.org (G Young)
Date: Mon, 01 Aug 2016 10:27:37 +0000
Subject: [New-bugs-announce] [issue27663] Inconsistent CSV Writer Behaviour
Message-ID: <1470047257.41.0.340893509322.issue27663@psf.upfronthosting.co.za>


New submission from G Young:

When writing scientific notation to CSV with custom line-terminators, the behaviour is inconsistent depending on the line-terminator you use.

In the file provided, two different line-terminator result in one quoting the number as a string and the other not. IMO the second example is correct, but I don't understand why the behaviours should be any different.

----------
components: IO
files: bug.py
messages: 271779
nosy: G Young
priority: normal
severity: normal
status: open
title: Inconsistent CSV Writer Behaviour
versions: Python 3.5
Added file: http://bugs.python.org/file43963/bug.py

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

From report at bugs.python.org  Mon Aug  1 14:03:16 2016
From: report at bugs.python.org (Augie Fackler)
Date: Mon, 01 Aug 2016 18:03:16 +0000
Subject: [New-bugs-announce] [issue27664] Allow specifying prefix for thread
 name in concurrent.futures.ThreadPoolExecutor
Message-ID: <1470074596.72.0.973598099873.issue27664@psf.upfronthosting.co.za>


New submission from Augie Fackler:

This is mostly useful for when you've got a large number of threads and want to try and identify what threadpool is going nuts.

----------
components: Library (Lib)
files: cpython.patch
keywords: patch
messages: 271790
nosy: durin42
priority: normal
severity: normal
status: open
title: Allow specifying prefix for thread name in concurrent.futures.ThreadPoolExecutor
type: enhancement
Added file: http://bugs.python.org/file43967/cpython.patch

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

From report at bugs.python.org  Mon Aug  1 18:50:47 2016
From: report at bugs.python.org (Alexander Bayandin)
Date: Mon, 01 Aug 2016 22:50:47 +0000
Subject: [New-bugs-announce] [issue27665] Make create_server able to listen
 on several ports
Message-ID: <1470091847.64.0.679712938011.issue27665@psf.upfronthosting.co.za>


New submission from Alexander Bayandin:

Make create_server accept a list of ports to listen.
Now it contains only code changes without updates in docs and tests.
If these changes will be considered as helpful I'll be glad to add tests and update documentation for the method.

----------
components: asyncio
files: create_server-multiple-ports.patch
keywords: patch
messages: 271792
nosy: Alexander.Bayandin, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Make create_server able to listen on several ports
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43969/create_server-multiple-ports.patch

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

From report at bugs.python.org  Mon Aug  1 19:52:30 2016
From: report at bugs.python.org (Steve Fink)
Date: Mon, 01 Aug 2016 23:52:30 +0000
Subject: [New-bugs-announce] [issue27666] "stack smashing detected" in
 PyCursesWindow_Box
Message-ID: <1470095550.97.0.482934277649.issue27666@psf.upfronthosting.co.za>


New submission from Steve Fink:

When attempting to run |hg chistedit|, which uses the python curses module, I am getting *** stack smashing detected ***: /usr/bin/python terminated

The problem is in PyCursesWindow_Box in _cursesmodule.c:

        if (!PyArg_ParseTuple(args,"ll;vertint,horint", &ch1, &ch2))
            return NULL;

ch1 and ch2 are of type 'chtype', which is a 4-byte integer on my platform. (I am on a fresh install of Fedora 24 x86_64.) The format string 'l' is writing 8 bytes. It is hard to fit 8 bytes into a 4 byte variable.

I scanned through the rest of the file. Most places are very careful about this; if needed, they'll parse into a 'long' temporary and then assign. But here's another one in PyCurses_UngetMouse:

    MEVENT event;
    PyCursesInitialised;
    if (!PyArg_ParseTuple(args, "hiiil",
                          &event.id,
                          &event.x, &event.y, &event.z,
                          (int *) &event.bstate))
        return NULL;

event.bstate is of type mmask_t, which is also 4 bytes.

I did not find any more in that file.

% rpm -q python-libs
python-libs-2.7.12-1.fc24.x86_64

----------
components: Library (Lib)
messages: 271796
nosy: Steve Fink
priority: normal
severity: normal
status: open
title: "stack smashing detected" in PyCursesWindow_Box
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug  2 04:02:39 2016
From: report at bugs.python.org (Cambridge)
Date: Tue, 02 Aug 2016 08:02:39 +0000
Subject: [New-bugs-announce] [issue27667] subprocess32 unable to be
 installed via pip and python install
Message-ID: <1470124959.09.0.482017076841.issue27667@psf.upfronthosting.co.za>


New submission from Cambridge:

OS:RHEL 5.11
PYTHON:2.7.11/12

When i use pip or python install to install this extension:
pip install subprocess32-3.2.7.tar.gz

The error messages:

Processing ./subprocess32-3.2.7.tar.gz
Installing collected packages: subprocess32
  Running setup.py install for subprocess32 ... error
    Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-ekkMER-build/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-EebZzY-record/install-record.txt --single-version-externally-managed --compile:
    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-2.7
    copying subprocess32.py -> build/lib.linux-x86_64-2.7
    running build_ext
    building '_posixsubprocess' extension
    creating build/temp.linux-x86_64-2.7
    gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/python-2.7/include/python2.7 -c _posixsubprocess.c -o build/temp.linux-x86_64-2.7/_posixsubprocess.o
    _posixsubprocess.c: In function 'subprocess_cloexec_pipe':
    _posixsubprocess.c:764: warning: implicit declaration of function 'pipe2'
    _posixsubprocess.c:764: error: 'O_CLOEXEC' undeclared (first use in this function)
    _posixsubprocess.c:764: error: (Each undeclared identifier is reported only once
    _posixsubprocess.c:764: error: for each function it appears in.)
    error: command 'gcc' failed with exit status 1
    
    ----------------------------------------
Command "/usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-ekkMER-build/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-EebZzY-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-ekkMER-build/

----------
components: Extension Modules
messages: 271812
nosy: ldrljq
priority: normal
severity: normal
status: open
title: subprocess32 unable to be installed via pip and python install
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug  2 08:09:18 2016
From: report at bugs.python.org (antoine Zellmeyer)
Date: Tue, 02 Aug 2016 12:09:18 +0000
Subject: [New-bugs-announce] [issue27668] list illogical affectation
Message-ID: <1470139758.94.0.42567832187.issue27668@psf.upfronthosting.co.za>


New submission from antoine Zellmeyer:

>>> tab = [['x']*3]*3
>>> tab
[['x', 'x', 'x'], ['x', 'x', 'x'], ['x', 'x', 'x']]
>>> tab[1][0] = 5
>>> tab
[[5, 'x', 'x'], [5, 'x', 'x'], [5, 'x', 'x']]
>>> 

why not only the element tab[1][0] is changed ?

----------
assignee: terry.reedy
components: IDLE, Interpreter Core, Macintosh
messages: 271817
nosy: antoine Zellmeyer, ned.deily, ronaldoussoren, terry.reedy
priority: normal
severity: normal
status: open
title: list illogical affectation
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/issue27668>
_______________________________________

From report at bugs.python.org  Tue Aug  2 17:10:41 2016
From: report at bugs.python.org (Geoffrey Odhner)
Date: Tue, 02 Aug 2016 21:10:41 +0000
Subject: [New-bugs-announce] [issue27669] Bug in re.fullmatch() specific to
 Windows XP
Message-ID: <1470172241.08.0.328584992088.issue27669@psf.upfronthosting.co.za>


New submission from Geoffrey Odhner:

I have found a bug in python?s re.fullmatch() function when it?s running on Windows XP.  On Mac OS X or Windows 7 the bug doesn?t occur.  When I use fullmatch() with a regular expression that ends with ?$? it fails to match the string (on XP, but it matches on Mac OS and Win 7), but when I use that same regular expression with match() it works.  I?m not in urgent need of a fix, since replacing those particular calls with match() gets around the problem and is giving consistent behavior across platforms, but the inconsistency in behavior in fullmatch() between platforms should be fixed.  I?m using python 3.4.3 on all three platforms.

----------
components: Regular Expressions
messages: 271853
nosy: ezio.melotti, ggodhner, mrabarnett
priority: normal
severity: normal
status: open
title: Bug in re.fullmatch() specific to Windows XP
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  2 19:40:32 2016
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 02 Aug 2016 23:40:32 +0000
Subject: [New-bugs-announce] [issue27670] Use https instead of http in the
 PYTHON_VERSION constant
Message-ID: <1470181232.89.0.0745542408499.issue27670@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

The current url for bugs.python.org uses http and not https.

I propose a patch with https,

----------
components: Interpreter Core
messages: 271867
nosy: matrixise
priority: normal
severity: normal
status: open
title: Use https instead of http in the PYTHON_VERSION constant
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug  3 05:01:26 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 03 Aug 2016 09:01:26 +0000
Subject: [New-bugs-announce] [issue27671] FAQ: len() is still function for
 good reason.
Message-ID: <1470214886.13.0.870924776007.issue27671@psf.upfronthosting.co.za>


New submission from INADA Naoki:

https://docs.python.org/3/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list

> The major reason is history.
...
> but it?s a part of Python, and it?s too late to make such fundamental changes now. The functions have to remain to avoid massive code breakage.

People seeing this answer may think "it's bad design, but remains for historical reason."

But there is more positive reason why len is still function.
http://effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm

----------
assignee: docs at python
components: Documentation
messages: 271881
nosy: docs at python, methane
priority: normal
severity: normal
status: open
title: FAQ: len() is still function for good reason.

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

From report at bugs.python.org  Wed Aug  3 07:18:43 2016
From: report at bugs.python.org (Peter Tomcsanyi)
Date: Wed, 03 Aug 2016 11:18:43 +0000
Subject: [New-bugs-announce] [issue27672] x fromat of % operator broken in
 Python 3.5.2
Message-ID: <1470223123.65.0.568086751938.issue27672@psf.upfronthosting.co.za>


New submission from Peter Tomcsanyi:

In Python 3.4.4 (64-bit) and in many previous versions it worked like this:

>>> "%02x" % 12.99
'0c'

Now in Python 3.5.2 (64-bit) it shows an error:
>>> "%02x" % 12.99
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    "%02x" % 12.99
TypeError: %x format: an integer is required, not float

This problem broke some of my code which uses turtle.py (which is part of the cpython distribution), but I can see similar problems also in some third party code (e.g. I can see it in canvasvg3.py).
So I kindly ask for returning the 3.4-like interpretation of the x format (and o format and maybe also other formats).

----------
components: Interpreter Core
messages: 271894
nosy: PeterTom
priority: normal
severity: normal
status: open
title: x fromat of % operator broken in Python 3.5.2
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug  3 07:39:41 2016
From: report at bugs.python.org (Stefan Rosewig)
Date: Wed, 03 Aug 2016 11:39:41 +0000
Subject: [New-bugs-announce] [issue27673] lambda function in loop
Message-ID: <1470224381.05.0.371491506941.issue27673@psf.upfronthosting.co.za>


New submission from Stefan Rosewig:

Trying to build tkinter menu dynamically by reading an ini file (configparser) I detect an issue with the lambda function used inside a loop. 
If the loop variable is used as option in the lambda function, the lambda is not place in time using the current value, all functions are created when leaving the calling function using the last value of the loop variable. 
There is a simple workaround, just use a separate function to add the menu-item. 
The attached demo shows both, the "Working" menu which was created by a function and does what was expected and the "Failure" menu which was created inside the loop itself and doesn't do what was expected.
Since the problem is not bound to configparser I used a simple loop walking through a list of menu item names to simulate the reasing of an ini file. Inside the loop a menu item with the name is appende to the Failure menu calling lambda:cmd(name) as command. Also a function is called uding the name as parameter wich appends a Menu item to the Working menu using the identic options as for Failure menu.
When the loop is finidhed the value of teh loop variable is set to "senseless" which should have no effect.
The function cmd(param) just appends a string including the param value to the output.
if the script is started the menus ar built and look identical but if you click on a Working menu item the name of the item is printed. if you click on the Failure menu item "senseless" is printed for each item which is the value I set after the loop.

>From my point of view all lambda commands are build when the calling function is left using the value of the variable at this time. this lead in the demo  attached to identic function calls for the Failure menu. For the working menu a separate function is called and the lambda is build at the end of this function which leads to the expected behaviour.

I'm running Python 3.5.2 (v3.5.2:4def2a2901a5) 64 Bit on Windows-10 Pro 64

----------
components: Tkinter
files: lambda-prob.pyw
messages: 271897
nosy: Thaloss66
priority: normal
severity: normal
status: open
title: lambda function in loop
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file43989/lambda-prob.pyw

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

From report at bugs.python.org  Wed Aug  3 08:22:28 2016
From: report at bugs.python.org (=?utf-8?q?Artur_Sm=C4=99t?=)
Date: Wed, 03 Aug 2016 12:22:28 +0000
Subject: [New-bugs-announce] [issue27674] Quote mark breaks cookie processing
Message-ID: <1470226948.72.0.0645301470223.issue27674@psf.upfronthosting.co.za>


New submission from Artur Sm?t:

The problem is similar to https://bugs.python.org/issue22931 with square brackets in cookie values.
Incorrect value is serialized JSON in this case, for example:

>>> from Cookie import SimpleCookie
>>> cookie = SimpleCookie()
>>> cookie.load('a=b; c={"somekey":"value"}; d=e, f=g, some=other')
>>> cookie.output()
'Set-Cookie: a=b'
>>> 

>From my tests I figured out that quote mark (") is causing problems.

In fact, according to HTTP specification, cookies can't be JSON objects, but I think that python library shouldn't silently allow incorrect values. Probably incorrect cookies should be skipped, or some exception should be thrown there.

----------
components: Library (Lib)
messages: 271901
nosy: Artur Sm?t
priority: normal
severity: normal
status: open
title: Quote mark breaks cookie processing
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  3 11:11:43 2016
From: report at bugs.python.org (Edoardo Gerosa)
Date: Wed, 03 Aug 2016 15:11:43 +0000
Subject: [New-bugs-announce] [issue27675] IDLE does not fully color raw
 string directory paths to green when invoking os.chdir() if statement is
 executed with autocompletion drop down list still open
Message-ID: <1470237103.73.0.416964160416.issue27675@psf.upfronthosting.co.za>


New submission from Edoardo Gerosa:

A cosmetic bug was noticed when executing os.chdir() in IDLE. When inputting a raw string path in os.chdir() using autocompletion the last directory in the path will remain black if the user presses enter while the autocompletion drop down list is still open. The bug seems to affect only single quoted strings. To reproduce the bug input a raw single quoted string into os.chdir(); select directories through the drop down autocomplete list using Tab; once the destination directory is reached do not make the drop down list disappear, instead after selecting the destination directory type in the closing single quote and brace and hit enter: the final directory in the path will remain black and not turn green. (image file has been added to showcase bug).

----------
assignee: terry.reedy
components: IDLE
files: bug_pic.png
messages: 271910
nosy: egerosa, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE does not fully color raw string directory paths to green when invoking os.chdir() if statement is executed with autocompletion drop down list still open
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file43990/bug_pic.png

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

From report at bugs.python.org  Wed Aug  3 14:36:18 2016
From: report at bugs.python.org (Lukas Weber)
Date: Wed, 03 Aug 2016 18:36:18 +0000
Subject: [New-bugs-announce] [issue27676] comports() failing due to internal
 4G module
Message-ID: <1470249378.31.0.870337766904.issue27676@psf.upfronthosting.co.za>


New submission from Lukas Weber:

On my notebook I have a builtin 4G module (HP lt4112 Gobi 4G Module) it is using 3 COM ports.

Running: 
from serial.tools.list_ports import comports
comports()

is giving me:
File "C:\Program Files\Python27\lib\site-packages\serial\tools\list_ports_common.py", line 65, in usb_info
    ' LOCATION={}'.format(self.location) if self.location is not None else '')

having a look (and changing) at list_ports_common.py is telling me that pid and vid is None

this works, but might not be very proper:
    def usb_info(self):
        """return a string with USB related information about device"""
        return 'USB VID:PID={}:{}{}{}'.format(
            '{:04X}'.format(self.vid) if self.vid is not None else '',
            '{:04X}'.format(self.pid) if self.pid is not None else '',
            ' SER={}'.format(self.serial_number) if self.serial_number is not None else '',
            ' LOCATION={}'.format(self.location) if self.location is not None else '')

----------
components: Interpreter Core
messages: 271920
nosy: Lukas Weber
priority: normal
severity: normal
status: open
title: comports() failing due to internal 4G module
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  3 23:21:11 2016
From: report at bugs.python.org (Martin Vahi)
Date: Thu, 04 Aug 2016 03:21:11 +0000
Subject: [New-bugs-announce] [issue27677] Reopening issue 20930
Message-ID: <1470280871.61.0.758792707799.issue27677@psf.upfronthosting.co.za>


New submission from Martin Vahi:

I could not figure out, how to reopen the original issue. 
The details reside at 

https://bugs.python.org/issue20930

Thank You.

----------
components: Build
messages: 271945
nosy: Martin Vahi
priority: normal
severity: normal
status: open
title: Reopening issue 20930
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug  4 03:25:07 2016
From: report at bugs.python.org (Claudiu Saftoiu)
Date: Thu, 04 Aug 2016 07:25:07 +0000
Subject: [New-bugs-announce] [issue27678]
 itertools.permutations/.combinations should have len
Message-ID: <1470295507.75.0.86244083352.issue27678@psf.upfronthosting.co.za>


New submission from Claudiu Saftoiu:

Right now, itertools.permutations and itertools.combinations and itertools.product objects don't have a `len`. 

    >>> len(itertools.combinations(range(10), 5))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: object of type 'itertools.combinations' has no len()

I propose that a `len` be added to them, which computes (& caches) & returns the length. If the underlying iterator doesn't have a length, then they can raise a TypeError as they do now.

----------
messages: 271952
nosy: Claudiu Saftoiu
priority: normal
severity: normal
status: open
title: itertools.permutations/.combinations should have len
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Aug  4 04:32:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 04 Aug 2016 08:32:36 +0000
Subject: [New-bugs-announce] [issue27679] set_bitfields() unused in
 _ctypes_test
Message-ID: <1470299556.34.0.285781931231.issue27679@psf.upfronthosting.co.za>


New submission from Martin Panter:

Modules/_ctypes/_ctypes_test.c defines a structure called BITS and exports two C functions set_bitfields() and unpack_bitfields() that operate on it. However only unpack_bitfields() seems to have been used, in Lib/ctypes/test/test_bitfields.py. Either there is scope for enhancing the tests, or maybe there is no point and the function can be removed.

----------
components: Extension Modules, Tests, ctypes
messages: 271956
nosy: martin.panter
priority: normal
severity: normal
status: open
title: set_bitfields() unused in _ctypes_test
versions: Python 3.6

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

From report at bugs.python.org  Thu Aug  4 04:51:15 2016
From: report at bugs.python.org (Steve Holden)
Date: Thu, 04 Aug 2016 08:51:15 +0000
Subject: [New-bugs-announce] [issue27680] Reduce Github pull request rate
Message-ID: <1470300675.44.0.889172442592.issue27680@psf.upfronthosting.co.za>


New submission from Steve Holden:

I have seen a relatively large number of pull requests via the Github mirror repository, because would-be contributors presumably just look on Github and, having found Python there, assume this is the place for contributions.

The standard README file gives no clue that the Github repository should not be used as the basis for contributory pull requests, and neither should it.

Fortunately Github will display a README.md file in preference to REAMDE when one is found. This patch adds a message, highly visible to Github users, that they are in the wrong place.

For an indication of how the Github page will then look, visit https://github.com/holdenweb/python/tree/README where the patch is already installed.

----------
assignee: docs at python
components: Documentation
files: README.patch
keywords: needs review, patch
messages: 271958
nosy: docs at python, holdenweb
priority: normal
severity: normal
stage: patch review
status: open
title: Reduce Github pull request rate
type: enhancement
Added file: http://bugs.python.org/file44004/README.patch

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

From report at bugs.python.org  Thu Aug  4 05:44:58 2016
From: report at bugs.python.org (Quentin Santos)
Date: Thu, 04 Aug 2016 09:44:58 +0000
Subject: [New-bugs-announce] [issue27681] readline: consecutive rl_kill_word
 do not append
Message-ID: <1470303898.75.0.124841684362.issue27681@psf.upfronthosting.co.za>


New submission from Quentin Santos:

In readline, "kill" basically means "cut" and "yank", "paste. When killing twice in a row, it tries to group the kills. This can be shown to work with rl_unix_word_rubout; with the default emacs keymap, type:

>>> hello world

Then hit ^W (Control+W, rl_unix_word_rubout) twice, then ^Y (Control+Y, rl_yank). You should get back the two words.

Now, using rl_backward_kill_word (Meta ^H), twice, yanking only puts back the last killed word (here, "hello "). With rl_kill_word (^A for start of line, then ^D), twice, yanking also puts back only the last killed word (here, " world"). The expected behavior is to get back both words (there, "hello world").

The behavior appears in both CPython's REPL (2.7 and 3.5 at least) and in the readline module. Other programs (bash, pypy, irb) that use readline show the expected behavior, as well as zsh (with its own implementation of readline).

Granted, I can not really imagine and issue with a lowest priority.

----------
components: IO, Library (Lib)
messages: 271964
nosy: qsantos
priority: normal
severity: normal
status: open
title: readline: consecutive rl_kill_word do not append
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Thu Aug  4 08:33:13 2016
From: report at bugs.python.org (Sushant)
Date: Thu, 04 Aug 2016 12:33:13 +0000
Subject: [New-bugs-announce] [issue27682] Windows Error 10053,
 ConnectionAbortedError: [WinError 10053] An established connection
 was aborted by the software in your host machine
Message-ID: <1470313993.65.0.630797703267.issue27682@psf.upfronthosting.co.za>


New submission from Sushant:

While saving, this error shows up and is whatever is saving gets saved twice-

Traceback (most recent call last):
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 138, in run
    self.finish_response()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 180, in finish_response
    self.write(data)
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 274, in write
    self.send_headers()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 332, in send_headers
    self.send_preamble()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 255, in send_preamble
    ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 453, in _write
    result = self.stdout.write(data)
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\socket.py", line 593, in write
    return self._sock.send(b)
ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine
[04/Aug/2016 17:25:59] "GET /api/importeop/ HTTP/1.1" 500 59
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 51082)
Traceback (most recent call last):
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 138, in run
    self.finish_response()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 180, in finish_response
    self.write(data)
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 274, in write
    self.send_headers()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 332, in send_headers
    self.send_preamble()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 255, in send_preamble
    ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 453, in _write
    result = self.stdout.write(data)
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\socket.py", line 593, in write
    return self._sock.send(b)
ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 141, in run
    self.handle_error()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\site-packages\django\core\servers\basehttp.py", line 92, in handle_error
    super(ServerHandler, self).handle_error()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 368, in handle_error
    self.finish_response()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 180, in finish_response
    self.write(data)
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 274, in write
    self.send_headers()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 331, in send_headers
    if not self.origin_server or self.client_is_modern():
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 344, in client_is_modern
    return self.environ['SERVER_PROTOCOL'].upper() != 'HTTP/0.9'
TypeError: 'NoneType' object is not subscriptable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py", line 625, in process_request_thread
    self.finish_request(request, client_address)
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py", line 354, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\site-packages\django\core\servers\basehttp.py", line 99, in __init__
    super(WSGIRequestHandler, self).__init__(*args, **kwargs)
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\socketserver.py", line 681, in __init__
    self.handle()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\site-packages\django\core\servers\basehttp.py", line 179, in handle
    handler.run(self.server.get_app())
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\handlers.py", line 144, in run
    self.close()
  File "C:\Users\Sushant Gahlot\AppData\Local\Programs\Python\Python35-32\lib\wsgiref\simple_server.py", line 36, in close
    self.status.split(' ',1)[0], self.bytes_sent
AttributeError: 'NoneType' object has no attribute 'split'
----------------------------------------

----------
components: Library (Lib)
messages: 271969
nosy: SG
priority: normal
severity: normal
status: open
title: Windows Error 10053, ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug  4 09:07:37 2016
From: report at bugs.python.org (tklausmann)
Date: Thu, 04 Aug 2016 13:07:37 +0000
Subject: [New-bugs-announce] [issue27683] ipaddress subnet slicing iterator
 malfunction
Message-ID: <1470316057.21.0.151567664395.issue27683@psf.upfronthosting.co.za>


New submission from tklausmann:

Between Python 3.4 (3.4.5 I've tested with) and Python 3.5 (3.5.2), the behavior of ipaddress's subnet() method changed.

This code:

$ cat iat.py
import ipaddress

p = ipaddress.IPv4Network("172.0.0.4/30")
subnets = p.subnets(new_prefix=31)
n = next(subnets)

print(list(n.hosts()))

has two different outcomes on 3.4 vs. 3.5:

$ python3.4 iat.py 
[IPv4Address('172.0.0.4'), IPv4Address('172.0.0.5')]
$ python3.5 iat.py 
[]

AIUI, the 3.4 behavior is the correct one (or the docs need to be fixed).

----------
components: Library (Lib)
messages: 271972
nosy: tklausmann
priority: normal
severity: normal
status: open
title: ipaddress subnet slicing iterator malfunction
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug  4 12:37:30 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 04 Aug 2016 16:37:30 +0000
Subject: [New-bugs-announce] [issue27684] Incorrect exception message of
 ImportError constructor
Message-ID: <1470328650.69.0.0456485191226.issue27684@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

ImportError accepts name and path as keyword-only parameters, but when invalid keyword argument passed, it emits wrong exception message saying that ImportError does not take keyword arguments.

>>> ImportError(name='name', path='path')
ImportError()
>>> ImportError(foo=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ImportError does not take keyword arguments

Propose a patch to fix this. Hope it helps.

----------
components: Interpreter Core
files: ImportError_constructor_exception.patch
keywords: patch
messages: 271991
nosy: brett.cannon, xiang.zhang
priority: normal
severity: normal
status: open
title: Incorrect exception message of ImportError constructor
versions: Python 3.6
Added file: http://bugs.python.org/file44009/ImportError_constructor_exception.patch

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

From report at bugs.python.org  Thu Aug  4 16:03:00 2016
From: report at bugs.python.org (umank.behera)
Date: Thu, 04 Aug 2016 20:03:00 +0000
Subject: [New-bugs-announce] [issue27685] altinstall with --enable-shared
 showing incorrect behaviour
Message-ID: <1470340980.02.0.968762212838.issue27685@psf.upfronthosting.co.za>


New submission from umank.behera:

When I altinstall python 2.7.12 with
./configure --prefix=/opt/python --enable-shared
it comes up as python 2.7.5 (system default python)

But altinstall with
./configure --prefix=/opt/python
it comes up as 2.7.12, what am I missing?

This is on RHEL 7.2

This is not a pathing issue:

Without --enable-shared:
[root at myrig ~]# /opt/python/bin/python2.7 -V
Python 2.7.12

With --enable-shared:
[root at myrig ~]# /opt/python/bin/python2.7 -V
Python 2.7.5

----------
components: Build, Installation
messages: 271997
nosy: ubehera
priority: normal
severity: normal
status: open
title: altinstall with --enable-shared showing incorrect behaviour
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug  4 16:28:50 2016
From: report at bugs.python.org (Bharti Rana)
Date: Thu, 04 Aug 2016 20:28:50 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue27686=5D_AAAAA_1_800_919_09?=
 =?utf-8?b?OTIg4oWA4oWA4qu44oWA4oWAIFF1aWNrYm9va3MgRW50ZXJwcmlzZSBzdXBw?=
 =?utf-8?q?ort_phone_number=2C_Quickbooks_Enterprise_support_phone_number?=
Message-ID: <1470342530.77.0.178202145751.issue27686@psf.upfronthosting.co.za>


New submission from Bharti Rana:

AAAAA 1 800 919 0992 ????? Quickbooks Enterprise support phone number, Quickbooks Enterprise support phone number Quickbooks Enterprise phone number USA
QPML +?$? 1800 -919-0992 Quickbooks Enterprise tech support phone number, Quickbooks Enterprise tech support contact number, Quickbooks Enterprise technical support contact number, Quickbooks Enterprise contact number, Quickbooks Enterprise contact phone number, Quickbooks Enterprise contact telephone number, Quickbooks Enterprise 24 hour contact number, Quickbooks Enterprise contact number, Quickbooks Enterprise customer service contact number, Quickbooks Enterprise official number, Quickbooks Enterprise official contact number, Quickbooks Enterprise 800 contact number, Quickbooks Enterprise toll free number, 800 number for Quickbooks Enterprise support, Quickbooks Enterprise 24/7 support phone number Quickbooks Enterprise support phone number,Quickbooks Enterprise support phone number,Quickbooks Enterprise help phone number, Quickbooks Enterprise technical support number.Quickbooks Enterprise support number, Quickbooks Enterprise phone number, Quickbooks Enterprise HELP DESK number, Quickbooks Enterprise number, Quickbooks Enterprise phone number, Quickbooks Enterprise customer service phone number, Quickbooks Enterprise customer service phone number, Quickbooks Enterprise support phone number. Help?Call 1-800 -919-0992/.Quickbooks Enterprise 24/7 support phone number,Quickbooks Enterprise telephone number for support? call 1800 -919-0992?./Quickbooks Enterprise contact number, Quickbooks Enterprise contact phone number, Quickbooks Enterprise contact telephone number,,telephone number for Quickbooks Enterprise online support,Quickbooks Enterprise official support number,Quickbooks Enterprise official number,Quickbooks Enterprise official phone number,,,phone number for Quickbooks Enterprise support,,Quickbooks Enterprise 24/7 support phone number,,Quickbooks Enterprise support number,Quickbooks Enterprise telephone number for support QB SUPPORT ON ((1-800 -919-0992)) Quickbooks Enterprise PHONE NUMBER AND Quickbooks Enterprise SUPPORT PHONE NUMBER Online Support For (((1+800 +919+0992)!!! Quickbooks Enterprise ((Technical)) Support phone number,, Quickbooks Enterprise HELP DESK phone number Online Support For (((1+800 +919+0992)!!! Quickbooks Enterprise ((Technical)) Support phone number,, Quickbooks Enterprise HELP DESK phone number Helpline TECH ))1-800 -919-0992((Quickbooks Enterprise technical support phone number Quickbooks Enterprise phone number QB SUPPORT ON ((1-800 -919-0992)) Quickbooks Enterprise PHONE NUMBER AND Quickbooks Enterprise SUPPORT PHONE NUMBER Quickbooks Enterprise Toll Free, Intuit?(1-800 -919-0992)? Quickbooks Enterprise HELP DESK Phone Number vides online solution for all USA/CANADA clients. For any help of query call 1 800 919 0992 to get all Quickbooks Enterprise account solution. ??Call, 1-800 -919-0992 for all type help by Quickbooks Enterprise HELP DESK phone number, Intuit Quickbooks Enterprise HELP DESK Phone Number, Quickbooks Enterprise Help Desk Phone Number, Quickbooks Enterprise HELP DESK number, Quickbooks Enterprise technical support phone number,??? Quickbooks Enterprise phone number, Quickbooks Enterprise technical support number, Quickbooks Enterprise support phone number, Quickbooks Enterprise technical support, Quickbooks Enterprise Customer Service Phone Number, Quickbooks Enterprise Customer Service Number, Quickbooks Enterprise Phone Number, Quickbooks Enterprise Number,???? Quickbooks Enterprise Customer Service Helpline Number, Quickbooks Enterprise Customer Care Number, Quickbooks Enterprise support team phone number, ????? Quickbooks Enterprise help number-Quickbooks Enterprise Helpline Number; Quickbooks Enterprise help phone number-Quickbooks Enterprise Helpline Number, Quickbooks Enterprise HELP DESK Toll free Number, Quickbooks Enterprise Support Telephone Number, Quickbooks Enterprise HELP DESK Telephone number, Quickbooks Enterprise HELP DESK contact number, Quickbooks Enterprise support contact number, Quickbooks Enterprise technical support contact number. Helpline TECH ))1-800 +919+0992(( Quickbooks Enterprise Enterprise technical support phone number 1-800 +919+0992 Quickbooks Enterprise Enterprise POS phone number 1800 +919+0992 QB SUPPORT ON ((1-800 +919+0992)) Quickbooks Enterprise Enterprise PHONE NUMBER AND Quickbooks Enterprise Enterprise SUPPORT PHONE NUMBER Quickbooks Enterprise Enterprise Toll Free, Intuit?(1-800 +919+0992)? Quickbooks Enterprise Enterprise Tech Support Phone Number POSvides online solution for all USA/CANADA clients. For any help of query call 1 800 +919+0992 to get all Quickbooks Enterprise Enterprise account solution. ??Call, 1-800 +919+0992 for all type help by Quickbooks Enterprise Enterprise tech support phone number, Intuit Quickbooks Enterprise Enterprise Tech Support Phone Number, Quickbooks Enterprise Enterprise Help Desk Phone Number, Quickbooks Enterprise Enterprise tech support number, Quickbooks Enterprise Enterprise technical support phone number,??? Quickbooks Enterprise Enterprise phone number, Quickbooks Enterprise Enterprise technical support number, Quickbooks Enterprise Enterprise support phone number, Quickbooks Enterprise Enterprise technical support, Quickbooks Enterprise Enterprise Customer Service Phone Number, Quickbooks Enterprise Enterprise Customer Service Number, Quickbooks Enterprise Enterprise Phone Number, Quickbooks Enterprise Enterprise Number,???? Quickbooks Enterprise Enterprise Customer Service Helpline Number, Quickbooks Enterprise Enterprise Customer Care Number, Quickbooks Enterprise Enterprise support team phone number, ????? Quickbooks Enterprise Enterprise help number- Quickbooks Enterprise Enterprise Helpline Number; Quickbooks Enterprise Enterprise help phone number- Quickbooks Enterprise Enterprise Helpline Number, Quickbooks Enterprise Enterprise Tech Support Toll free Number, Quickbooks Enterprise Enterprise Support Telephone Number, Quickbooks Enterprise Enterprise Tech Support Telephone number, Quickbooks Enterprise Enterprise Tech Support contact number, Quickbooks Enterprise Enterprise support contact number, Quickbooks Enterprise Enterprise technical support contact number. Call, Quickbooks Enterprise Enterprise tech support phone number, Intuit Quickbooks Enterprise Enterprise Tech Support Phone Number, Quickbooks Enterprise Enterprise Help Desk Phone Number, Quickbooks Enterprise Enterprise tech support number, Quickbooks Enterprise Enterprise technical support phone number, Quickbooks Enterprise Enterprise phone number, Quickbooks Enterprise Enterprise technical support number, Quickbooks Enterprise Enterprise support phone number. It is very popular toll free number which POSvide by Quickbooks Enterprise Enterprise technical support, Quickbooks Enterprise Enterprise Customer Service Phone Number, Quickbooks Enterprise Enterprise Customer Service Number, Quickbooks Enterprise Enterprise Phone Number, Quickbooks Enterprise Enterprise Number, Quickbooks Enterprise Enterprise Customer Service Helpline Number, Quickbooks Enterprise Enterprise Customer Care Number, Quickbooks Enterprise Enterprise support team phone number. Call, Quickbooks Enterprise Enterprise tech support phone number, Intuit Quickbooks Enterprise Enterprise Tech Support Phone Number, Quickbooks Enterprise Enterprise Help Desk Phone Number, Quickbooks Enterprise Enterprise tech support number, Quickbooks Enterprise Enterprise technical support phone number, Quickbooks Enterprise Enterprise phone number, Quickbooks Enterprise Enterprise technical support number, Quickbooks Enterprise Enterprise support phone number, Quickbooks Enterprise Enterprise technical support, Quickbooks Enterprise Enterprise Customer Service Phone Number, Quickbooks Enterprise Enterprise Customer Service Number, Quickbooks Enterprise Enterprise Phone Number, Quickbooks Enterprise Enterprise Number, Quickbooks Enterprise Enterprise Customer Service Helpline Number,Describe USA intuit Help ??1+800 +919+0992?? Quickbooks Enterprise PREMIER technical support phone number 1-800 -919-0992 Quickbooks Enterprise PREMIER customer service phone number usa here.USA intuit Help ??1+800 +919+0992?? Quickbooks Enterprise PREMIER technical support phone number 1-800 -919-0992 Quickbooks Enterprise PREMIER customer service phone number usa # Quickbooks Enterprise PREMIER Toll Free, ?(+1.800 .919.0992)?-: Quickbooks Enterprise PREMIER Tech Support Phone Number PREMIERvides online solution for all USA/CANADA clients. For any help of query call 1 800 to get all Quickbooks Enterprise PREMIER account solution. ??Call, +1.800 .919.0992 for all type help by Quickbooks Enterprise PREMIER tech support phone number, Quickbooks Enterprise PREMIER Tech Support Phone Number, Quickbooks Enterprise PREMIER Help Desk Phone Number, Quickbooks Enterprise PREMIER tech support number, Quickbooks Enterprise PREMIER technical support phone number,??? Quickbooks Enterprise PREMIER phone number, Quickbooks Enterprise PREMIER technical support number, Quickbooks Enterprise PREMIER support phone number, Quickbooks Enterprise PREMIER technical support, Quickbooks Enterprise PREMIER Customer Service Phone Number, Quickbooks Enterprise PREMIER Customer Service Number, Quickbooks Enterprise PREMIER Phone Number, Quickbooks Enterprise PREMIER Number,???? Quickbooks Enterprise PREMIER Customer Service Helpline Number, Quickbooks Enterprise PREMIER Customer Care Number, Quickbooks Enterprise PREMIER support team phone number, ????? Quickbooks Enterprise PREMIER help number- Quickbooks Enterprise PREMIER Helpline Number; Quickbooks Enterprise PREMIER help phone number- Quickbooks Enterprise PREMIER Helpline Number, Quickbooks Enterprise PREMIER Tech Support Toll free Number, Quickbooks Enterprise PREMIER Support Telephone Number, Quickbooks Enterprise PREMIER Tech Support Telephone number, Quickbooks Enterprise PREMIER Tech Support contact number, Quickbooks Enterprise PREMIER support contact number, Quickbooks Enterprise PREMIER technical support contact number. Call, Quickbooks Enterprise PREMIER tech support phone number, Quickbooks Enterprise PREMIER Tech Support Phone Number, Quickbooks Enterprise PREMIER Help Desk Phone Number, Quickbooks Enterprise PREMIER tech support number, Quickbooks Enterprise PREMIER technical support phone number, Quickbooks Enterprise PREMIER phone number, Quickbooks Enterprise PREMIER technical support number, Quickbooks Enterprise PREMIER support phone number. It is very popular toll free number which PREMIERvide by Quickbooks Enterprise PREMIER technical support, Quickbooks Enterprise PREMIER Customer Service Phone Number, Quickbooks Enterprise PREMIER Customer Service Number, Quickbooks Enterprise PREMIER Phone Number, Quickbooks Enterprise PREMIER Number, Quickbooks Enterprise PREMIER Customer Service Helpline Number, Quickbooks Enterprise PREMIER Customer Care Number, Quickbooks Enterprise PREMIER support team phone number. Call, Quickbooks Enterprise PREMIER tech support phone number, Quickbooks Enterprise PREMIER Tech Support Phone Number, Quickbooks Enterprise PREMIER Help Desk Phone Number, Quickbooks Enterprise PREMIER tech support number, Quickbooks Enterprise PREMIER technical support phone number, Quickbooks Enterprise PREMIER phone number, Quickbooks Enterprise PREMIER technical support number, Quickbooks Enterprise PREMIER support phone number, Quickbooks Enterprise PREMIER technical support, Quickbooks Enterprise PREMIER Customer Service Phone Number, Quickbooks Enterprise PREMIER Customer Service Number, Quickbooks Enterprise PREMIER Phone Number, Quickbooks Enterprise PREMIER Number, Quickbooks Enterprise PREMIER Customer Service Helpline Number, Quickbooks Enterprise PREMIER Customer Care Number,CALL ??? 1800 .919.0992 Quickbooks Enterprise pro s.u.p.p.o.r.t. .p.h.o.n.e. .n.u.m.b.e.r. usa/ca 1800 .919.0992 Quickbooks Enterprise pro s.u.p.p.o.r.t. .p.h.o.n.e. .n.u.m.b.e.r. usa Intuit?(1-800 -919-0992)Quickbooks Enterprise pro Tech Support Phone NumberIntuit??????(1-800 -919-0992)Quickbooks Enterprise pro Tech Support Phone Number provides online solution for all USA/CANADA clients. For any help of query call 1 800 919 0992 to get all Quickbooks Enterprise pro account solution. ??Call, 1-800 -919-0992 for all type help by Quickbooks Enterprise pro tech support phone number, Intuit Quickbooks Enterprise pro Tech Support Phone Number, Quickbooks Enterprise pro Help Desk Phone Number, Quickbooks Enterprise pro tech support number, Quickbooks Enterprise pro technical support phone number,??? Quickbooks Enterprise pro phone number, Quickbooks Enterprise pro technical support number, Quickbooks Enterprise pro support phone number, Quickbooks Enterprise pro technical support, Quickbooks Enterprise pro CustomeraService?? Phone Number, Quickbooks Enterprise pro Customer Service Number, Quickbooks Enterprise pro Phone Number, Quickbooks Enterprise pro Number,???? Quickbooks Enterprise pro Customer Service Helpline Number, Quickbooks Enterprise pro Customer Care Number, Quickbooks Enterprise pro support team phone number, ????? Quickbooks Enterprise pro help number-Quickbooks Enterprise pro Helpline Number; Quickbooks Enterprise pro help phone number-Quickbooks Enterprise pro Helpline Number, Quickbooks Enterprise pro Tech Support Toll free Number, Quickbooks Enterprise pro Support Telephone Number, Quickbooks Enterprise pro Tech Support Telephone number, Quickbooks Enterprise pro Tech Support contact number, Quickbooks Enterprise pro support contact number, Quickbooks Enterprise pro technical support contact number. Call, Quickbooks Enterprise pro tech support phone number, Intuit Quickbooks Enterprise pro Tech Support Phone Number, Quickbooks Enterprise pro Help Desk Phone Number, Quickbooks Enterprise pro tech support number, Quickbooks Enterprise pro technical support phone number, Quickbooks Enterprise pro phone number, Quickbooks Enterprise pro technical support number, Quickbooks Enterprise pro support phone number. It is very popular toll free number which provide by Quickbooks Enterprise pro technical support, Quickbooks Enterprise pro Customer Service Phone Number, Quickbooks Enterprise pro Customer Service Number, Quickbooks Enterprise pro Phone Number, Quickbooks Enterprise pro Number, Quickbooks Enterprise pro Customer Service Helpline Number, Quickbooks Enterprise pro Customer Care Number, Quickbooks Enterprise pro support team phone number. Call, Quickbooks Enterprise pro tech support phone number, Intuit Quickbooks Enterprise pro Tech Support Phone Number, Quickbooks Enterprise pro Help Desk Phone Number, Quickbooks Enterprise pro tech support number, Quickbooks Enterprise pro technical support phone number, Quickbooks Enterprise pro phone number, Quickbooks Enterprise pro technical support number, Quickbooks Enterprise pro support phone number, Quickbooks Enterprise pro technical support, Quickbooks Enterprise pro Customer Service Phone Number, Quickbooks Enterprise pro Customer Service Number, Quickbooks Enterprise pro Phone Number, Quickbooks Enterprise pro Number, Quickbooks Enterprise pro Customer Service Helpline Number, Quickbooks Enterprise pro Customer Care Number, Quickbooks Enterprise pro support team phone number, Quickbooks Enterprise pro help number-Quickbooks Enterprise pro Helpline Number; Quickbooks Enterprise pro help phone number, Quickbooks Enterprise pro Helpline Number1800 -919-0992 Quickbooks Enterprise technical help telephone number, Quickbooks Enterprise technical help contact number, Quickbooks Enterprise technical support contact number, Quickbooks Enterprise contact number, Quickbooks Enterprise contact phone number, Quickbooks Enterprise contact telephone number, Quickbooks Enterprise 24 hour contact number,

----------
components: asyncio
files: (1-800-919-0992)Call, Quickbooks  tech support phone number, Intuit Quickbooks  Tech Support Phone Number, Quickbooks  Help Desk Phone Number.pdf
messages: 272000
nosy: bhartirana2323, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: AAAAA 1 800 919 0992 ????? Quickbooks Enterprise support phone number, Quickbooks Enterprise support phone number
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44011/(1-800-919-0992)Call, Quickbooks  tech support phone number, Intuit Quickbooks  Tech Support Phone Number, Quickbooks  Help Desk Phone Number.pdf

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

From report at bugs.python.org  Thu Aug  4 16:44:42 2016
From: report at bugs.python.org (jort bloem)
Date: Thu, 04 Aug 2016 20:44:42 +0000
Subject: [New-bugs-announce] [issue27687] Linux shutil.move between
 mountpoints as root does not retain ownership
Message-ID: <1470343482.28.0.365470977104.issue27687@psf.upfronthosting.co.za>


New submission from jort bloem:

When using shutil.move() between mounts (i.e. when it does a copy/delete), running as root, ownership should be maintained.

To test: log in as root, create a file owned by a regular user. In python, use shutil.move() to move it to another mountpoint. Check that the ownership of the moved file is the same as the ownership of the original file.

----------
components: Library (Lib)
messages: 272001
nosy: jort.bloem
priority: normal
severity: normal
status: open
title: Linux shutil.move between mountpoints as root does not retain ownership
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Aug  4 23:37:04 2016
From: report at bugs.python.org (Michael Lee)
Date: Fri, 05 Aug 2016 03:37:04 +0000
Subject: [New-bugs-announce] [issue27688] Expand documentation about Any in
 the typing module
Message-ID: <1470368224.56.0.159287783102.issue27688@psf.upfronthosting.co.za>


New submission from Michael Lee:

This patch updates the section about `Any` in the typing module. Previously, that section was relatively sparse and didn't seem to do a very good job of helping the reader understand what the distinction between `Any` and `object` is.

This patch expands that section and adds several examples borrowed from the mypy docs and PEP 484.

----------
assignee: docs at python
components: Documentation
files: object-vs-any.patch
keywords: patch
messages: 272009
nosy: docs at python, gvanrossum, michael0x2a
priority: normal
severity: normal
status: open
title: Expand documentation about Any in the typing module
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44012/object-vs-any.patch

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

From report at bugs.python.org  Fri Aug  5 00:09:00 2016
From: report at bugs.python.org (Michael Lee)
Date: Fri, 05 Aug 2016 04:09:00 +0000
Subject: [New-bugs-announce] [issue27689] Add documentation for
 typing.Generator
Message-ID: <1470370140.25.0.341729775697.issue27689@psf.upfronthosting.co.za>


New submission from Michael Lee:

This patch adds (previously missing) documentation for `typing.Generator`.

----------
assignee: docs at python
components: Documentation
files: document-generators.patch
keywords: patch
messages: 272010
nosy: docs at python, gvanrossum, michael0x2a
priority: normal
severity: normal
status: open
title: Add documentation for typing.Generator
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44013/document-generators.patch

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

From report at bugs.python.org  Fri Aug  5 01:39:53 2016
From: report at bugs.python.org (Lilin Lao)
Date: Fri, 05 Aug 2016 05:39:53 +0000
Subject: [New-bugs-announce] [issue27690] os.path.normcase broken.
Message-ID: <1470375593.32.0.328295264297.issue27690@psf.upfronthosting.co.za>


New submission from Lilin Lao:

orz> python
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Failed calling sys.__interactivehook__
Traceback (most recent call last):
  File "C:\Users\lao\AppData\Local\Programs\Python\Python35\lib\site.py", line 388, in register_readline
    import readline
  File "C:\Users\lao\AppData\Local\Programs\Python\Python35\lib\site-packages\readline.py", line 6, in <module>
    from pyreadline.rlmain import Readline
  File "C:\Users\lao\AppData\Local\Programs\Python\Python35\lib\site-packages\pyreadline\__init__.py", line 12, in <module>
    from . import logger, clipboard, lineeditor, modes, console
  File "C:\Users\lao\AppData\Local\Programs\Python\Python35\lib\site-packages\pyreadline\logger.py", line 10, in <module>
    import socket, logging, logging.handlers
  File "C:\Users\lao\AppData\Local\Programs\Python\Python35\lib\logging\__init__.py", line 170, in <module>
    _srcfile = os.path.normcase(addLevelName.__code__.co_filename)
AttributeError: module 'ntpath' has no attribute 'normcase'
>>> exit()

----------
components: Windows
messages: 272013
nosy: lll9p, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.normcase broken.
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Fri Aug  5 05:26:35 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 05 Aug 2016 09:26:35 +0000
Subject: [New-bugs-announce] [issue27691] X509 cert with GEN_RID subject alt
 name causes SytemError
Message-ID: <1470389195.49.0.571813101842.issue27691@psf.upfronthosting.co.za>


New submission from Christian Heimes:

A X509 cert with a registered id general name in subject alternative name causes a SystemError: error return without exception set. This prevents host name validation of certs with a registered id.

>>> import _ssl
>>> _ssl._test_decode_cert('rid.pem')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: error return without exception set

The problem is caused by a bug in OpenSSL's print function for general names. Python's _get_peer_alt_names() uses GENERAL_NAME_print() to print GEN_IPADD, GEN_RID and others into a buffer. The buffer is then split at ':' into two strings. This works for all fields except for GEN_RID because OpenSSL doesn't put a ':' after 'Registered ID', https://github.com/openssl/openssl/blob/master/crypto/x509v3/v3_alt.c#L183 . _get_peer_alt_names() fails and returns NULL without setting a proper exception.

It looks like we haven't had tests for GEN_RID as well as some other field types.

Related Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1364268

----------
components: Extension Modules
files: rid.pem
messages: 272020
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: X509 cert with GEN_RID subject alt name causes SytemError
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44014/rid.pem

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

From report at bugs.python.org  Fri Aug  5 06:33:46 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 05 Aug 2016 10:33:46 +0000
Subject: [New-bugs-announce] [issue27692] Clean serveral unnecessary NULL
 checks in exceptions.c
Message-ID: <1470393226.79.0.545777561503.issue27692@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

While studying exceptions.c, find several unnecessary NULL checks that can be removed.

----------
components: Interpreter Core
files: small_cleanup_exceptions.patch
keywords: patch
messages: 272023
nosy: martin.panter, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: Clean serveral unnecessary NULL checks in exceptions.c
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44017/small_cleanup_exceptions.patch

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

From report at bugs.python.org  Fri Aug  5 09:03:06 2016
From: report at bugs.python.org (Dietmar Schindler)
Date: Fri, 05 Aug 2016 13:03:06 +0000
Subject: [New-bugs-announce] [issue27693] curses.textpad.Textbox(win).edit()
 won't edit last character
Message-ID: <1470402186.89.0.461540221424.issue27693@psf.upfronthosting.co.za>


New submission from Dietmar Schindler:

curses.textpad.Textbox(win).edit() does not allow to enter a character (or change one, if already there) at the very last position in a window (the lower right hand corner), though it allows to position the cursor there. This applies to the whole screen as well as other windows (also if the window's right margin isn't the screen margin). A sample program is attached (try to fill the last line completely with some character).

----------
components: Library (Lib)
files: edit.py
messages: 272027
nosy: Dietmar Schindler
priority: normal
severity: normal
status: open
title: curses.textpad.Textbox(win).edit() won't edit last character
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file44020/edit.py

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

From report at bugs.python.org  Fri Aug  5 10:51:57 2016
From: report at bugs.python.org (Haaroon Y)
Date: Fri, 05 Aug 2016 14:51:57 +0000
Subject: [New-bugs-announce] [issue27694] Socket incorrectly states IP
 address that start with a zero after a dot are illegal
Message-ID: <1470408717.78.0.306514411984.issue27694@psf.upfronthosting.co.za>


New submission from Haaroon Y:

Using the socket library and the method socket.inet_aton(ipAddr) it incorrectly states IP address such as 
192.168.093.1 and 192.092.2.1 are not legal when they are.

----------
components: Library (Lib)
messages: 272033
nosy: Haaroon Y
priority: normal
severity: normal
status: open
title: Socket incorrectly states IP address that start with a zero after a dot are illegal
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  5 13:39:36 2016
From: report at bugs.python.org (Franco Costantini)
Date: Fri, 05 Aug 2016 17:39:36 +0000
Subject: [New-bugs-announce] [issue27695] Compilation doesnt' end
Message-ID: <1470418776.19.0.267562911935.issue27695@psf.upfronthosting.co.za>


New submission from Franco Costantini:

Hi, we currently are fuzzing Python programs to find valid code that fails to compile. We found this program never finishes its compilation.

$ echo "raise ValueError ; 2 ** 12345678912345" > inf.py
$ python -m py_compile inf.py

We realize the computation is a large one and takes a very long time, in this case the compiler consumes more and more memory over time. Perhaps the compiler shouldn't try to calculate this indefinitely and just return an error.

Regards

----------
messages: 272046
nosy: fcostantini
priority: normal
severity: normal
status: open
title: Compilation doesnt' end
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  5 17:31:26 2016
From: report at bugs.python.org (Kyle Altendorf)
Date: Fri, 05 Aug 2016 21:31:26 +0000
Subject: [New-bugs-announce] [issue27696] win_add2path.py does not add user
 site directory
Message-ID: <1470432686.16.0.44318212583.issue27696@psf.upfronthosting.co.za>


New submission from Kyle Altendorf:

Since the detected user path has the text `%APPDATA%` replaced into it `os.path.isdir()` returns `False`.  As a result, the user site path is not added to the `%PATH%` variable.

The patch adds `os.path.expandvars()` to the `isdir()` check to resolve this issue.

----------
files: win_add2path.patch
keywords: patch
messages: 272060
nosy: altendky
priority: normal
severity: normal
status: open
title: win_add2path.py does not add user site directory
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44028/win_add2path.patch

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

From report at bugs.python.org  Fri Aug  5 17:57:18 2016
From: report at bugs.python.org (nathan snobelen)
Date: Fri, 05 Aug 2016 21:57:18 +0000
Subject: [New-bugs-announce] [issue27697] Obscure bug in the int() function
Message-ID: <1470434238.47.0.90762321591.issue27697@psf.upfronthosting.co.za>


New submission from nathan snobelen:

Hi, I've noticed a bug in int() when converting a specific range of numbers it will incorrectly round the last digit down.

We have some payment code which formats numbers for processing in our system and we noticed that the payment of 1108431.38 was dropped by a penny to 1108431.37.  I looked into it and found that it is dropped when it is multiplied by 100 (to remove the decimal) and then converted back to an int.

Note, this bug only applies to the following range of numbers: 1108431.38 - 1108431.41.  Any other number I tried was unaffected. 

The following code will replicate the bug:

import math

amount1 = 110843138.0
amount2 = 1108431.38 * 100

print "Orig amount1 " + str(amount1)
print "Orig amount2 " + str(amount2)

print "Converted amount1 " + str(int(amount1))
print "Converted amount2 " + str(int(amount2))

Try it, and you will see that "amount1" remains correct, but "amount2" is affected.  Multiplying by 100 seems to trigger it... however note that even after it has been multiplied by 100 it is still correct... it's only when you then apply the int() function that the penny drops.

So it would appear that something is wrong in the int() function.

Cheers,
Nathan

----------
components: Library (Lib)
messages: 272062
nosy: nathan snobelen
priority: normal
severity: normal
status: open
title: Obscure bug in the int() function
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug  6 06:02:26 2016
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 06 Aug 2016 10:02:26 +0000
Subject: [New-bugs-announce] [issue27698] socketpair not in socket.__all__
 on Windows
Message-ID: <1470477746.64.0.384028109592.issue27698@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

It seems socketpair is added for Windows in Py3.5, but it isn't imported with `from socket import *`. Can it be added to __all__?

----------
components: Library (Lib)
messages: 272084
nosy: veky
priority: normal
severity: normal
status: open
title: socketpair not in socket.__all__ on Windows
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Aug  6 07:08:34 2016
From: report at bugs.python.org (David Kirkby)
Date: Sat, 06 Aug 2016 11:08:34 +0000
Subject: [New-bugs-announce] [issue27699] very important news
Message-ID: <00006de2ea9b$2c37101c$3370f337$@onetel.net>


New submission from David Kirkby:

Yo! 

Here are some very  important news for  you,  please read that information <http://think.styleloft.us/aevlzdu>

Best Wishes, david.kirkby

----------
files: image001.jpg
messages: 272092
nosy: drkirkby
priority: normal
severity: normal
status: open
title: very important news
Added file: http://bugs.python.org/file44031/image001.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27699>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1895 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20160806/1e973ecc/attachment.jpg>

From report at bugs.python.org  Sat Aug  6 12:42:59 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 06 Aug 2016 16:42:59 +0000
Subject: [New-bugs-announce] [issue27700] Document asyncio.AbstractEventLoop,
 not asyncio.BaseEventLoop
Message-ID: <1470501779.75.0.27358865288.issue27700@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The asyncio docs currently document the event loop interface as belonging to BaseEventLoop. But the intention of PEP 3156 was for the interface to belong to AbstractEventLoop. In typeshed we ended up exporting only AbstractEventLoop, but this runs into trouble when type-checking code written against the asyncio docs in the CPython repo rather against the PEP.

Unless there's a serious objection I would like to see the docs changed to match the PEP here, and switch from BaseEventLoop to AbstractEventLoop.

Thoughts?

----------
assignee: gvanrossum
components: Documentation
messages: 272101
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Document asyncio.AbstractEventLoop, not asyncio.BaseEventLoop
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Aug  7 04:45:56 2016
From: report at bugs.python.org (Ed Schouten)
Date: Sun, 07 Aug 2016 08:45:56 +0000
Subject: [New-bugs-announce] [issue27701] [posixmodule] [Refactoring patch]
 Simply call into *at() functions unconditionally when present
Message-ID: <1470559556.18.0.347536673064.issue27701@psf.upfronthosting.co.za>


New submission from Ed Schouten:

CloudABI is a sandboxed UNIX-like environment (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). As it implements a security framework similar to FreeBSD's Capsicum, file system access is only permitted by using POSIX-2008-style directory file descriptors. To explain it simply, the API is as follows:

- Take POSIX 2008
- Remove all the non-*at() functions
- Remove AT_FDCWD

It would be nice if Python could support CloudABI out of the box, but in my opinion this should be done in a way that's as unintrusive as possible. We shouldn't make a mess out of Python, just to support CloudABI. I've been looking at Python's posixmodule and I think there's some low-hanging fruit. We can make changes that significantly reduce the size of our patchset for CloudABI, while also making the existing code easier to understand:

- When support for *at() functions was added, they didn't replace the calls to the non-*at() functions. The non-*at() functions are still invoked when dir_fd == AT_FDCWD. This can be changed to invoke the *at() functions unconditionally. The advantage of this approach is that AT_FDCWD then only needs to be used in dir_fd_converter() and a small number of other places. It also means that the code builds on systems that don't prove the non-*at() functions.

- The *_DIR_FD_CONVERTER macros aren't used in a small number of places, requiring us to do additional checks against AT_FDCWD in os_*_impl(). In os.link(), os.rename() and os.replace(), we call into dir_fd_converter() unconditionally, only to let the respective implementation functions perform additional checks. If dir_fd_unavailable() would be used instead, the implementations would be cleaner.

The attached patch does this refactoring, also making some minor cleanups along the way.

----------
components: Extension Modules
files: posixmodule-refactoring.diff
keywords: patch
messages: 272114
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present
versions: Python 3.6
Added file: http://bugs.python.org/file44033/posixmodule-refactoring.diff

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

From report at bugs.python.org  Sun Aug  7 06:37:13 2016
From: report at bugs.python.org (Ed Schouten)
Date: Sun, 07 Aug 2016 10:37:13 +0000
Subject: [New-bugs-announce] [issue27702] [Patch] Only use SOCK_RAW when
 defined
Message-ID: <1470566233.96.0.229880145452.issue27702@psf.upfronthosting.co.za>


New submission from Ed Schouten:

POSIX only requires socket types SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET to be present. SOCK_RAW is optional, as it is placed between [RS] tags in the specification:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html

It looks like Python's socketmodule.c does try to use it unconditionally. Comply to POSIX by only exposing it optionally, just like we do for some of the other socket types (SOCK_RDM, etc).

----------
components: Extension Modules
files: sock_raw.diff
keywords: patch
messages: 272117
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] Only use SOCK_RAW when defined
versions: Python 3.6
Added file: http://bugs.python.org/file44034/sock_raw.diff

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

From report at bugs.python.org  Sun Aug  7 08:51:57 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 07 Aug 2016 12:51:57 +0000
Subject: [New-bugs-announce] [issue27703] Replace two Py_XDECREFs with
 Py_DECREFs in do_raise
Message-ID: <1470574317.03.0.634036537179.issue27703@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

In do_raise, the two Py_XDECREFs at the final of the success branch seem doing unnecessary NULL checks.

----------
components: Interpreter Core
files: do_raise.patch
keywords: patch
messages: 272119
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: Replace two Py_XDECREFs with Py_DECREFs in do_raise
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44035/do_raise.patch

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

From report at bugs.python.org  Sun Aug  7 15:22:27 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 07 Aug 2016 19:22:27 +0000
Subject: [New-bugs-announce] [issue27704] bytes(x) is slow when x is
 bytearray
Message-ID: <1470597747.43.0.480552843757.issue27704@psf.upfronthosting.co.za>


New submission from INADA Naoki:

When bytes(x), bytes_new checks if x is integer via PyNumber_AsSize_t(x).
It cause TypeError internally.

When x is not an integer, especially bytearray or memoryview, the internal
exception cause significant overhead.

# HEAD
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
1000000 loops, best of 3: 0.696 usec per loop
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
1000000 loops, best of 3: 0.699 usec per loop
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
1000000 loops, best of 3: 0.701 usec per loop

# this patch
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
1000000 loops, best of 3: 0.265 usec per loop
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
1000000 loops, best of 3: 0.265 usec per loop
$ ./python -m timeit -s 'data=bytearray(b"xyz")' 'bytes(data)'
1000000 loops, best of 3: 0.267 usec per loop

----------
components: Interpreter Core
files: fast-bytearray-fromobject.patch
keywords: patch
messages: 272130
nosy: methane
priority: normal
severity: normal
status: open
title: bytes(x) is slow when x is bytearray
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44039/fast-bytearray-fromobject.patch

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

From report at bugs.python.org  Sun Aug  7 17:02:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 07 Aug 2016 21:02:29 +0000
Subject: [New-bugs-announce] [issue27705] Updating old
 C:/Windows/System32/ucrtbased.dll
Message-ID: <1470603749.52.0.375133152623.issue27705@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This is a continuation of msg269741 from #26624, summarizing how to resolve this message.

 C:\WINDOWS\SYSTEM32\ucrtbased.dll is version 10.0.10240.16384
 WARN: ucrtbased contains known issues. Please update Visual Studio or the Windows SDK.  See: http://bugs.python.org/issue26624

F:\Python\dev\36\PCbuild\python.vcxproj(91,5): warning MSB3073: The command ""F:\Python\dev\36\PCBuild\win32\python_d.exe" "F:\Python\dev\36\PC\validate_ucrtbase.py" ucrtbased" exited with code 1.

Merely updating Visual Studio is not enough.  One must update the Windows SDK either directly or while updating Visual Studio by making sure that the new SDK is requested under Features.

[X] Windows and Web Development
    [X] Universal Windows App Development Tools
        [X] Tools (1.4.1) and Windows 10 SDK (10.0.14393)

(Versions and even the menu may change in the future.)

The best way to update Visual Studio is probably to uninstall it first via  Control Panel / Programs and Features / Microsoft Visual Studio Community 2015 (or whichever version you have).

I did not.  After downloading the current installer
  vs_community__9c4d694197656e43997d069a0ead2003.exe
I just ran without uninstalling.  It automatically installs in the current vs2015 directory,  Instead of a clean install, it updated and ended with the same 'bad hash' message as reported in msg269741.

I then went to Programs and Features and chose 'Repair'.  The first time it failed because it did not like the existing 
  Microsoft Visual C++ 2015 Redistributable (x86 or x64)
files being present.  With those removed, and the SDK feature checked, Repair worked and Python builds without the warning.

The current SDK is not listed as 'Microsoft Windows SDK...' but as
  Windows Software Development Kit - Windows 10.0.14393

Steve: my suggestion is that "Please update Visual Studio or the Windows SDK." be changed to "Please update the Windows SDK, possibly by updating Visual Studio with the Windows SDK feature selected."  Also change the issue number from 26624 to whatever this one gets.

----------
assignee: docs at python
components: Build, Documentation, Windows
messages: 272132
nosy: docs at python, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Updating old C:/Windows/System32/ucrtbased.dll
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Aug  7 20:15:14 2016
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Mon, 08 Aug 2016 00:15:14 +0000
Subject: [New-bugs-announce] [issue27706] Random.seed,
 whose purpose is purportedly determinism,
 behaves non-deterministically with strings due to hash randomization
Message-ID: <1470615314.72.0.24682085223.issue27706@psf.upfronthosting.co.za>


New submission from Glyph Lefkowitz:

The purpose of 'seeding' a random number generator is usually to supply a deterministic sequence of values starting from a known point.  This works fine if you seed random.Random with an integer.  Often (for example, see Minecraft's map generation interface) one wants to begin with a human-memorable string as the seed, and superficially it would seem that passing a string to Random.seed would serve exactly this use-case.  In fact in its original incarnation it did.

However, since the introduction of PYTHONHASHSEED in 2.6.8, it's possible that strings now hash to different values, and on 3.2+, they'll _always_ hash to different values unless otherwise configured (which, as per the reason for introducing this feature in the first place, is a security flaw).

Right now the way to work around this is to get some deterministic hash from your string; one mechanism being a truncated SHA256 hash, for example, like this:

Random(struct.unpack("!I", sha256(seed.encode("utf-8")).digest()[:4])[0])

but this strikes me as an obscure trick to require of someone just trying to get their D&D character generator to produce the same values twice in a row for unit testing.

I'm not sure what the resolution should be, but I figured I should report this since I tripped over it.

----------
components: Library (Lib)
messages: 272137
nosy: glyph
priority: normal
severity: normal
status: open
title: Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization
type: behavior

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

From report at bugs.python.org  Mon Aug  8 04:49:01 2016
From: report at bugs.python.org (Robin)
Date: Mon, 08 Aug 2016 08:49:01 +0000
Subject: [New-bugs-announce] [issue27707] List reports incorrect length if
 modifed after yield
Message-ID: <1470646141.92.0.720392766058.issue27707@psf.upfronthosting.co.za>


New submission from Robin:

reproduction script below. In the last print statement, it shows me a list with items in it, but with a length of 0

def generator():
	l = []
	yield l
	l.append(1)
	# this correctly prints 1
	print(len(l))

# this should print [([1], 1)], but actually gives [([1], 0)]
print([(l, len(l)) for l in generator()])

----------
components: Interpreter Core
messages: 272151
nosy: robinh
priority: normal
severity: normal
status: open
title: List reports incorrect length if modifed after yield
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug  8 06:57:19 2016
From: report at bugs.python.org (Ethan Glass)
Date: Mon, 08 Aug 2016 10:57:19 +0000
Subject: [New-bugs-announce] [issue27708] Roudning/Large Int representation
 error with multiplication and division
Message-ID: <1470653839.78.0.546281473501.issue27708@psf.upfronthosting.co.za>


New submission from Ethan Glass:

Python represents large integers as floating-points, which may or may not be the cause or part of the cause of division of said large integers evaluating to a floating-point number usually within a 1-integer range of the correct result.

----------
components: ctypes
messages: 272160
nosy: eglass
priority: normal
severity: normal
status: open
title: Roudning/Large Int representation error with multiplication and division
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Aug  8 11:40:57 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 08 Aug 2016 15:40:57 +0000
Subject: [New-bugs-announce] [issue27709] difflib.HtmlDiff produces
 different output from difflib.ndiff
Message-ID: <1470670857.15.0.245619921121.issue27709@psf.upfronthosting.co.za>


New submission from SilentGhost:

msg264842 in issue26945 reports an odd results of HtmlDiff.make_file, digging into it I've noticed couple of things: different output to one generated directly from difflib.ndiff and underlying issue further up the stack that generates same faulty output with a slightly modified files.

The patch I'm attaching fixes the issue with different outputs, from make_file and ndiff, by not removing EOL characters, I had to re-generate expected test output file.

----------
components: Library (Lib)
files: donttrim.diff
keywords: patch
messages: 272173
nosy: SilentGhost, jlwing, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: difflib.HtmlDiff produces different output from difflib.ndiff
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44049/donttrim.diff

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

From report at bugs.python.org  Mon Aug  8 11:43:13 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Aug 2016 15:43:13 +0000
Subject: [New-bugs-announce] [issue27710] Disallow fold not in [0,
 1] in time and datetime constructors
Message-ID: <1470670993.43.0.0364864987438.issue27710@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

The current implementation does not restrict values accepted by the fold argument:

>>> from datetime import *
>>> time(fold=2)
datetime.time(0, 0, fold=2)
>>> datetime(1, 1, 1, fold=2)
datetime.datetime(1, 1, 1, 0, 0, fold=2)

----------
assignee: belopolsky
messages: 272174
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Disallow fold not in [0, 1] in time and datetime constructors
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Aug  8 12:18:06 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Aug 2016 16:18:06 +0000
Subject: [New-bugs-announce] [issue27711] datetime.utctimetuple() method
 should respect fold disambiguation
Message-ID: <1470673086.15.0.122790254735.issue27711@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

With TZ = America/New_York:

>>> t0 = datetime(2016, 11, 6, 1, 30, fold=0)
>>> t1 = datetime(2016, 11, 6, 1, 30, fold=1)
>>> t0.utctimetuple()[:6]
(2016, 11, 6, 1, 30, 0)
>>> t1.utctimetuple()[:6]
(2016, 11, 6, 1, 30, 0)
>>> t0.timestamp()
1478410200.0
>>> t1.timestamp()
1478413800.0

The correct values for utctimetuple() should be the same as

>>> datetime.utcfromtimestamp(t0.timestamp()).timetuple()[:6]
(2016, 11, 6, 5, 30, 0)
>>> datetime.utcfromtimestamp(t1.timestamp()).timetuple()[:6]
(2016, 11, 6, 6, 30, 0)

----------
assignee: belopolsky
messages: 272175
nosy: belopolsky
priority: normal
severity: normal
status: open
title: datetime.utctimetuple() method should respect fold disambiguation
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Aug  8 12:23:52 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 08 Aug 2016 16:23:52 +0000
Subject: [New-bugs-announce] [issue27712] Tiny typos in import.rst
Message-ID: <1470673432.71.0.249763506601.issue27712@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
assignee: docs at python
components: Documentation
files: import_doc.patch
keywords: patch
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Tiny typos in import.rst
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44050/import_doc.patch

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

From report at bugs.python.org  Mon Aug  8 14:06:06 2016
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 08 Aug 2016 18:06:06 +0000
Subject: [New-bugs-announce] [issue27713] Spurious "platform dependent
 libraries" warnings when running make
Message-ID: <1470679566.14.0.658709147971.issue27713@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

When installing Python 3.5.2 from source on Ubuntu 14.04 and running
make, I get the below "Could not find platform dependent libraries"
warnings (which I prefixed with "***" for better visibility).

>From this message which has more background, these warnings are
apparently harmless:

https://mail.python.org/pipermail/python-dev/2016-August/145783.html


    	      -DHGBRANCH="\"`LC_ALL=C `\"" \
    	      -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
    gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Programs/_freeze_importlib.o Programs/_freeze_importlib.c
    gcc -pthread   -o Programs/_freeze_importlib Programs/_freeze_importlib.o Modules/getbuildinfo.o Parser/acceler.o [**snipped for brevity**]  Modules/xxsubtype.o -lpthread -ldl  -lutil   -lm  
    if test "no" != "yes"; then \
    	    ./Programs/_freeze_importlib \
    	        ./Lib/importlib/_bootstrap.py Python/importlib.h; \
    	fi
    ***: Could not find platform dependent libraries <exec_prefix>
    ***: Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
    if test "no" != "yes"; then \
    	    ./Programs/_freeze_importlib \
    	        ./Lib/importlib/_bootstrap_external.py Python/importlib_external.h; \
    	fi
    ***: Could not find platform dependent libraries <exec_prefix>
    ***: Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
    gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Python/frozen.o Python/frozen.c
    rm -f libpython3.5m.a
    ar rc libpython3.5m.a Modules/getbuildinfo.o

----------
components: Installation
messages: 272186
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: Spurious "platform dependent libraries" warnings when running make
versions: Python 3.5

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

From report at bugs.python.org  Mon Aug  8 19:14:56 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 08 Aug 2016 23:14:56 +0000
Subject: [New-bugs-announce] [issue27714] some test_idle tests are not
 re-runnable, producing false failures with regrtest -w option
Message-ID: <1470698096.85.0.204645941326.issue27714@psf.upfronthosting.co.za>


New submission from Ned Deily:

If you run test_idle using the standard Python regression test runner, regrtest, and use regrtest's -w option (to re-run failure test verbosely) *without* using regrtest's -j option (to run tests in separate processes), any real test failure triggering a rerun will cause a number of additional false IDLE test case failures because some test cases modify global state in such a way as to be not re-runable.

An example: at the moment there is a real IDLE test case failure (see Issue27830).  If I run test_idle with both -w and -j options:

$ /usr/local/bin/python3.6 -m test -w -j2 -uall test_idle
Run tests in parallel using 2 child processes
0:00:01 [1/1/1] test_idle failed
can't invoke "event" command:  application has been destroyed
    while executing
"event generate $w <<ThemeChanged>>"
    (procedure "ttk::ThemeChanged" line 6)
    invoked from within
"ttk::ThemeChanged"
test test_idle failed -- Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py", line 389, in test_click_help_source
    Equal(dialog.result, ('__test__', __file__))
AssertionError: Tuples differ: ('__test__', 'file:///Library/Frameworks/Python.framewo[58 chars].py') != ('__test__', '/Library/Frameworks/Python.framework/Vers[51 chars].py')

First differing element 1:
'file:///Library/Frameworks/Python.framewo[57 chars]y.py'
'/Library/Frameworks/Python.framework/Vers[50 chars]y.py'

  ('__test__',
-  'file:///Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py')
?   -------

+  '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py')
1 test failed:
    test_idle
Re-running failed tests in verbose mode
Re-running test 'test_idle' in verbose mode
test_autocomplete_event (idlelib.idle_test.test_autocomplete.AutoCompleteTest) ... ok
test_delayed_open_completions (idlelib.idle_test.test_autocomplete.AutoCompleteTest) ... ok
[...]
test_shell_show (idlelib.idle_test.test_warning.ShellWarnTest) ... ok
test_showwarnings (idlelib.idle_test.test_warning.ShellWarnTest) ... ok

======================================================================
FAIL: test_click_help_source (idlelib.idle_test.test_query.HelpsourceGuiTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py", line 389, in test_click_help_source
    Equal(dialog.result, ('__test__', __file__))
AssertionError: Tuples differ: ('__test__', 'file:///Library/Frameworks/Python.framewo[58 chars].py') != ('__test__', '/Library/Frameworks/Python.framework/Vers[51 chars].py')

First differing element 1:
'file:///Library/Frameworks/Python.framewo[57 chars]y.py'
'/Library/Frameworks/Python.framework/Vers[50 chars]y.py'

  ('__test__',
-  'file:///Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py')
?   -------

+  '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py')

----------------------------------------------------------------------
Ran 219 tests in 0.977s

FAILED (failures=1)

only the 1 valid test case failure shows up.

But if I run test_idle with just -w (no -j) options:

$ /usr/local/bin/python3.6 -m test -w -uall test_idle
Run tests sequentially
0:00:00 [1/1] test_idle
can't invoke "event" command:  application has been destroyed
    while executing
"event generate $w <<ThemeChanged>>"
    (procedure "ttk::ThemeChanged" line 6)
    invoked from within
"ttk::ThemeChanged"
test test_idle failed -- Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py", line 389, in test_click_help_source
    Equal(dialog.result, ('__test__', __file__))
AssertionError: Tuples differ: ('__test__', 'file:///Library/Frameworks/Python.framewo[58 chars].py') != ('__test__', '/Library/Frameworks/Python.framework/Vers[51 chars].py')

First differing element 1:
'file:///Library/Frameworks/Python.framewo[57 chars]y.py'
'/Library/Frameworks/Python.framework/Vers[50 chars]y.py'

  ('__test__',
-  'file:///Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py')
?   -------

+  '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py')

test_idle failed
1 test failed:
    test_idle
Re-running failed tests in verbose mode
Re-running test 'test_idle' in verbose mode
test_autocomplete_event (idlelib.idle_test.test_autocomplete.AutoCompleteTest) ... ok
test_delayed_open_completions (idlelib.idle_test.test_autocomplete.AutoCompleteTest) ... ok
[...]
test_no_delete (idlelib.idle_test.test_text.TkTextTest) ... ok
test_init_modal (idlelib.idle_test.test_textview.TextViewTest) ... ERROR
test_init_nonmodal (idlelib.idle_test.test_textview.TextViewTest) ... ERROR
test_ok (idlelib.idle_test.test_textview.TextViewTest) ... ERROR
test_view_file (idlelib.idle_test.test_textview.ViewFunctionTest) ... ok
test_view_text (idlelib.idle_test.test_textview.ViewFunctionTest) ... ok
ERROR
test_init (idlelib.idle_test.test_tree.TreeTest) ... ok
[...]
test_showwarnings (idlelib.idle_test.test_warning.ShellWarnTest) ... ok

======================================================================
ERROR: test_init_modal (idlelib.idle_test.test_textview.TextViewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_textview.py", line 40, in setUp
    TV.transient.__init__()
NameError: name 'TV' is not defined

======================================================================
ERROR: test_init_nonmodal (idlelib.idle_test.test_textview.TextViewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_textview.py", line 40, in setUp
    TV.transient.__init__()
NameError: name 'TV' is not defined

======================================================================
ERROR: test_ok (idlelib.idle_test.test_textview.TextViewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_textview.py", line 40, in setUp
    TV.transient.__init__()
NameError: name 'TV' is not defined

======================================================================
ERROR: tearDownModule (idlelib.idle_test.test_textview)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_textview.py", line 26, in tearDownModule
    del TV
NameError: name 'TV' is not defined

======================================================================
FAIL: test_click_help_source (idlelib.idle_test.test_query.HelpsourceGuiTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py", line 389, in test_click_help_source
    Equal(dialog.result, ('__test__', __file__))
AssertionError: Tuples differ: ('__test__', 'file:///Library/Frameworks/Python.framewo[58 chars].py') != ('__test__', '/Library/Frameworks/Python.framework/Vers[51 chars].py')

First differing element 1:
'file:///Library/Frameworks/Python.framewo[57 chars]y.py'
'/Library/Frameworks/Python.framework/Vers[50 chars]y.py'

  ('__test__',
-  'file:///Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py')
?   -------

+  '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_query.py')

----------------------------------------------------------------------
Ran 219 tests in 0.998s

FAILED (failures=1, errors=4)

now there are 4 or 5 errors in addition to the 1 failure.

The fifth false error is somewhat timing dependent, e.g. it shows up some of the time while the other 4 always show up:

======================================================================
ERROR: setUpClass (idlelib.idle_test.test_autocomplete.AutoCompleteTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/idle_test/test_autocomplete.py", line 34, in setUpClass
    macosx.setupApp(cls.root, None)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/macosx.py", line 245, in setupApp
    overrideRootMenu(root, flist)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/idlelib/macosx.py", line 215, in overrideRootMenu
    del mainmenu.menudefs[-1][1][0]
IndexError: list assignment index out of range


It's not a critical problem but it can be very confusing if you have not run into the problem before and can cause lost time trying to track down the false errors.

----------
assignee: terry.reedy
components: IDLE
messages: 272200
nosy: ned.deily, terry.reedy
priority: low
severity: normal
status: open
title: some test_idle tests are not re-runnable, producing false failures with regrtest -w option
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Aug  8 22:43:25 2016
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 09 Aug 2016 02:43:25 +0000
Subject: [New-bugs-announce] [issue27715] call-matcher breaks if a method is
 mocked with spec=True
Message-ID: <1470710605.81.0.432461136624.issue27715@psf.upfronthosting.co.za>


New submission from Carl Meyer:

When constructing call-matchers to match expected vs actual calls, if `spec=True` was used when patching a function, mock attempts to bind the recorded (and expected) call args to the function signature. But if a method was mocked, the signature includes `self` and the recorded call args don't. This can easily lead to a `TypeError`:

```
from unittest.mock import patch

class Foo:
    def bar(self, x):
        return x

with patch.object(Foo, 'bar', spec=True) as mock_bar:
    f = Foo()
    f.bar(7)

mock_bar.assert_called_once_with(7)

```

The above code worked in mock 1.0, but fails in Python 3.5 and 3.6 tip with this error:

```
TypeError: missing a required argument: 'x'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "../mock-method.example.py", line 11, in <module>
    mock_bar.assert_called_once_with(7)
  File "/home/carljm/projects/python/cpython/Lib/unittest/mock.py", line 203, in assert_called_once_with
    return mock.assert_called_once_with(*args, **kwargs)
  File "/home/carljm/projects/python/cpython/Lib/unittest/mock.py", line 822, in assert_called_once_with
    return self.assert_called_with(*args, **kwargs)
  File "/home/carljm/projects/python/cpython/Lib/unittest/mock.py", line 811, in assert_called_with
    raise AssertionError(_error_message()) from cause
AssertionError: Expected call: bar(7)
Actual call: bar(<__main__.Foo object at 0x7fdca80b7550>, 7)
```
```

If you try to pass in the instance as an expected call arg, the error goes away but it just fails to match:

```
AssertionError: Expected call: bar(<__main__.Foo object at 0x7f5cbab35fd0>, 7)
Actual call: bar(7)
```

So AFAICT there is no way to successfully use `spec=True` when patching a method of a class.

Oddly, using `autospec=True` instead of `spec=True` _does_ record the instance as an argument in the recorded call args, meaning that you have to pass it in as an argument to e.g. `assert_called_with`. But in many (most?) cases where you're patching a method of a class, your test doesn't have access to the instance, elsewise you'd likely just patch the instance instead of the class in the first place.

I don't see a good reason why `autospec=True` and `spec=True` should differ in this way (if both options are needed, there should be a separate flag to control that behavior; it doesn't seem related to the documented differences between autospec and spec). I do think a) there needs to be some way to record call args to a method and assert against those call args without needing the instance (or resorting to manual assertions against a sliced `call_args`), and b) there should be some way to successfully use `spec=True` when patching a method of a class.

----------
components: Library (Lib)
files: mock-method.example.py
messages: 272209
nosy: carljm
priority: normal
severity: normal
status: open
title: call-matcher breaks if a method is mocked with spec=True
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44054/mock-method.example.py

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

From report at bugs.python.org  Tue Aug  9 07:33:16 2016
From: report at bugs.python.org (Cory Benfield)
Date: Tue, 09 Aug 2016 11:33:16 +0000
Subject: [New-bugs-announce] [issue27716] http.client truncates UTF-8
 encoded headers
Message-ID: <1470742396.79.0.719108941731.issue27716@psf.upfronthosting.co.za>


New submission from Cory Benfield:

Originally reported as Requests issue #3485: https://github.com/kennethreitz/requests/issues/3485

On Python 3, http.client uses the email module to parse its HTTP headers. The email module, for better or worse, requires that it parse headers as *text*: that is, that they be decoded from bytes first and then parsed.

This doesn't work for UTF-8 encoded headers. For example, the URL `'http://pl.bab.la/slownik/angielski-polski/'` returns the following Link header, encoded as UTF-8: `Link: <http://www.babla.cn/??-???/>; rel="alternate"; hreflang="zh-Hans", <http://cs.bab.la/slovnik/anglicky-polsky/>; rel="alternate"; hreflang="cs", <http://da.bab.la/ordbog/engelsk-polsk/>; rel="alternate"; hreflang="da", <http://de.bab.la/woerterbuch/englisch-polnisch/>; rel="alternate"; hreflang="de", <http://www.babla.gr/???????-????????/>; rel="alternate"; hreflang="el", <http://en.bab.la/dictionary/english-polish/>; rel="alternate"; hreflang="en", <http://eo.bab.la/vortaro/angla-pola/>; rel="alternate"; hreflang="eo", <http://es.bab.la/diccionario/ingles-polaco/>; rel="alternate"; hreflang="es", <http://fi.bab.la/sanakirja/englanti-puola/>; rel="alternate"; hreflang="fi", <http://fr.bab.la/dictionnaire/anglais-polonais/>; rel="alternate"; hreflang="fr", <http://www.babla.in/?????????-?????/>; rel="alternate"; hreflang="hi", <http://hu.bab.la/sz?t?r/angol-lengyel/>; rel="alternate"; hreflang="hu", <http://www.babla.co.id/bahasa-inggris-bahasa-polandia/>; rel="alternate"; hreflang="id", <http://it.bab.la/dizionario/inglese-polacco/>; rel="alternate"; hreflang="it", <http://ja.bab.la/??/??-??????/>; rel="alternate"; hreflang="ja", <http://www.babla.kr/??-????/>; rel="alternate"; hreflang="ko", <http://nl.bab.la/woordenboek/engels-pools/>; rel="alternate"; hreflang="nl", <http://www.babla.no/engelsk-polsk/>; rel="alternate"; hreflang="no", <http://pl.bab.la/slownik/angielski-polski/>; rel="alternate"; hreflang="pl", <http://pt.bab.la/dicionario/ingles-polones/>; rel="alternate"; hreflang="pt", <http://ro.bab.la/dictionar/engleza-poloneza/>; rel="alternate"; hreflang="ro", <http://www.babla.ru/??????????-????????/>; rel="alternate"; hreflang="ru", <http://sv.bab.la/lexikon/engelsk-polsk/>; rel="alternate"; hreflang="sv", <http://sw.bab.la/kamusi/kiingereza-kipolishi/>; rel="alternate"; hreflang="sw", <http://www.babla.co.th/english-polish/>; rel="alternate"; hreflang="th", <http://tr.bab.la/sozluk/ingilizce-lehce/>; rel="alternate"; hreflang="tr", <http://www.babla.vn/tieng-anh-tieng-ba-lan/>; rel="alternate"; hreflang="vi"`.

When decoded using ISO-8859-1, this header gets truncated and this also causes the header block parsing to stop. This means that we don't see the Content-Length header, causing the HTTP client to wait for connection closure to consider the body terminated.

Really the only correct fix for this is for http.client to stop insisting that the headers be decoded before they are parsed, and instead to decode *after*. That way, at least, user code can recover the headers and handle them more sensibly.

----------
components: Library (Lib)
messages: 272236
nosy: Lukasa
priority: normal
severity: normal
status: open
title: http.client truncates UTF-8 encoded headers
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug  9 08:29:35 2016
From: report at bugs.python.org (Eyal Mor)
Date: Tue, 09 Aug 2016 12:29:35 +0000
Subject: [New-bugs-announce] [issue27717] sqlite documentation bug
Message-ID: <1470745775.08.0.0704550754852.issue27717@psf.upfronthosting.co.za>


New submission from Eyal Mor:

In the SQlite module documentation there a code section showing how to securely use the sqlite.execute method.
The problem with this code section is that just from a glance, without reading the paragraph before, or the comments in the section, users could use the insecure version.
It would be better if only a secure example would be in the code section.

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

Section:
# Never do this -- insecure!
symbol = 'RHAT'
c.execute("SELECT * FROM stocks WHERE symbol = '%s'" % symbol)

# Do this instead
t = ('RHAT',)
c.execute('SELECT * FROM stocks WHERE symbol=?', t)
print c.fetchone()

# Larger example that inserts many records at a time
purchases = [('2006-03-28', 'BUY', 'IBM', 1000, 45.00),
             ('2006-04-05', 'BUY', 'MSFT', 1000, 72.00),
             ('2006-04-06', 'SELL', 'IBM', 500, 53.00),
            ]
c.executemany('INSERT INTO stocks VALUES (?,?,?,?,?)', purchases)

----------
assignee: docs at python
components: Documentation
files: Screen Shot 2016-08-09 at 3.28.05 PM.png
messages: 272238
nosy: Eyal Mor, docs at python
priority: normal
severity: normal
status: open
title: sqlite documentation bug
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/file44056/Screen Shot 2016-08-09 at 3.28.05 PM.png

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

From report at bugs.python.org  Tue Aug  9 08:41:19 2016
From: report at bugs.python.org (Gabriel Pettier (Tshirtman))
Date: Tue, 09 Aug 2016 12:41:19 +0000
Subject: [New-bugs-announce] [issue27718] help('signal') incomplete (e.g:
 signal.signal not visible)
Message-ID: <1470746479.88.0.0919609545752.issue27718@psf.upfronthosting.co.za>


New submission from Gabriel Pettier (Tshirtman):

Up to apparently python 3.5, using help('signal') used to show the 'signal.signal' function among others, now it's not in the list, while of course help('signal.signal') does work, it was reported to me to still be the case in 3.6a1.

----------
assignee: docs at python
components: Documentation
messages: 272240
nosy: Gabriel Pettier (Tshirtman), docs at python
priority: normal
severity: normal
status: open
title: help('signal') incomplete (e.g: signal.signal not visible)
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug  9 12:08:46 2016
From: report at bugs.python.org (Ben Hoyt)
Date: Tue, 09 Aug 2016 16:08:46 +0000
Subject: [New-bugs-announce] [issue27719] Misleading note about "args"
 attribute in "User-defined Exceptions" section of tutorial
Message-ID: <1470758926.96.0.219997040874.issue27719@psf.upfronthosting.co.za>


New submission from Ben Hoyt:

In the official tutorial in the "User-defined Exceptions" section (https://docs.python.org/3.5/tutorial/errors.html#user-defined-exceptions) there's a note about a user-defined Exception subclass as follows:

"In this example, the default __init__() of Exception has been overridden. The new behavior simply creates the value attribute. This replaces the default behavior of creating the args attribute."

That last sentence is wrong: it used to be that way (it is in Python 2.x and I believe in Python pre 3.2), but now the implementation of BaseException.__new__ now sets args, so even when you override __init__ and don't call super() args is set. I think that's what you want, so I'm putting this down to a documentation bug. I think the sentence "This replaces the default behavior of creating the args attribute." should simply be removed (BaseException.__init__ basically does nothing now).

This change happened for Python 3.3 and was backported to Python 3.2. See also:

* The relevant part of BaseException.__new__ in the CPython codebase: https://github.com/python/cpython/blob/601ee5fab5df81a25611da0667030de531c1cda9/Objects/exceptions.c#L44-L48
* The issue where this behaviour was changed: http://bugs.python.org/issue1692335
* The commit where it was changed: https://hg.python.org/cpython/rev/68e2690a471d (on GitHub at https://github.com/python/cpython/commit/a71a87e695b05a67bd22c6ac74311b1f56f3932e)
* You can repro this and confirm that "args" is definitely set with the attached script:

$ python exception_args_test.py 
sys.version_info(major=3, minor=5, micro=2, releaselevel='final', serial=0)
Error args: ('error!',)

----------
assignee: docs at python
components: Documentation
files: exception_args_test.py
messages: 272256
nosy: benhoyt, docs at python, georg.brandl, sbt
priority: normal
severity: normal
status: open
title: Misleading note about "args" attribute in "User-defined Exceptions" section of tutorial
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44058/exception_args_test.py

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

From report at bugs.python.org  Tue Aug  9 13:25:19 2016
From: report at bugs.python.org (Antti Haapala)
Date: Tue, 09 Aug 2016 17:25:19 +0000
Subject: [New-bugs-announce] [issue27720] decimal.Context.to_eng_string
 wrong docstring
Message-ID: <1470763519.71.0.509753850108.issue27720@psf.upfronthosting.co.za>


New submission from Antti Haapala:

https://docs.python.org/3/library/decimal.html#decimal.Context.to_eng_string

The docstring for `Context.to_eng_string` says "Converts a number to a string, using scientific notation.", which is, less extra comma, exactly the docstring for `Context.to_sci_string`. It should probably say "using engineering notation".

Additionally, docstring for Decimal.to_eng_string uses the term "an engineering-type string", which no one uses outside the said docstring. It should probably also say "Convert to a string using engineering notation."

----------
assignee: docs at python
components: Documentation
messages: 272259
nosy: docs at python, ztane
priority: normal
severity: normal
status: open
title: decimal.Context.to_eng_string wrong docstring

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

From report at bugs.python.org  Tue Aug  9 15:35:52 2016
From: report at bugs.python.org (Joseph Bane)
Date: Tue, 09 Aug 2016 19:35:52 +0000
Subject: [New-bugs-announce] [issue27721] strtobool returns 0 and 1 rather
 than False and True
Message-ID: <1470771352.57.0.859185223412.issue27721@psf.upfronthosting.co.za>


New submission from Joseph Bane:

The distutils strtobool function returns 0 or 1 rather than the native boolean type True or False values:

https://hg.python.org/cpython/file/3.5/Lib/distutils/util.py#l304

Please see the attached patch for updates to this function. I have included updates to use a f-string in the raise and casefold instead of lower.

----------
components: Distutils
files: patch.diff
keywords: patch
messages: 272263
nosy: Joseph Bane, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: strtobool returns 0 and 1 rather than False and True
type: enhancement
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file44060/patch.diff

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

From report at bugs.python.org  Tue Aug  9 18:02:53 2016
From: report at bugs.python.org (Ankur Dedania)
Date: Tue, 09 Aug 2016 22:02:53 +0000
Subject: [New-bugs-announce] [issue27722] Path.touch's keyword argument mode
 documented incorrectly
Message-ID: <1470780173.7.0.896294950108.issue27722@psf.upfronthosting.co.za>


New submission from Ankur Dedania:

Path.touch's keyword argument mode documented incorrectly.

In the documents, it shows keyword argument mode defaulted to 0o777, however within the code it is set to 0o666.

----------
assignee: docs at python
components: Documentation
messages: 272269
nosy: AnkurDedania, docs at python
priority: normal
severity: normal
status: open
title: Path.touch's keyword argument mode documented incorrectly
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug  9 21:40:43 2016
From: report at bugs.python.org (Michael Lee)
Date: Wed, 10 Aug 2016 01:40:43 +0000
Subject: [New-bugs-announce] [issue27723] Document typing.Text and
 typing.AnyStr
Message-ID: <1470793243.78.0.0997445491252.issue27723@psf.upfronthosting.co.za>


New submission from Michael Lee:

This patch documents typing.Text and typing.AnyStr.

I decided against creating a new top-level section to document Text/AnyStr mainly because it seems like how exactly str/bytes/unicode is handled by mypy and described in PEP 484 might be changing sometime in the future and didn't want to add text that would need to be changed later on -- I'm not sure if that was the right call or not.

----------
assignee: docs at python
components: Documentation
files: document-text-and-anystr.patch
keywords: patch
messages: 272286
nosy: docs at python, gvanrossum, michael0x2a
priority: normal
severity: normal
status: open
title: Document typing.Text and typing.AnyStr
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44062/document-text-and-anystr.patch

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

From report at bugs.python.org  Wed Aug 10 04:18:00 2016
From: report at bugs.python.org (Daisuke Miyakawa)
Date: Wed, 10 Aug 2016 08:18:00 +0000
Subject: [New-bugs-announce] [issue27724] PEP3119 inconsintent with actual
 CPython impl
Message-ID: <1470817080.1.0.906916235476.issue27724@psf.upfronthosting.co.za>


New submission from Daisuke Miyakawa:

Python 3.5.2 (and Python 2.7.12) uses Py_TPFLAGS_IS_ABSTRACT while PEP 3119 menttions "Py_TPFLAGS_ABSTRACT" for it. At some point had the name of the flag been changed without modifying PEP?

----------
assignee: docs at python
components: Documentation
messages: 272321
nosy: Daisuke Miyakawa, docs at python
priority: normal
severity: normal
status: open
title: PEP3119 inconsintent with actual CPython impl
versions: Python 3.5

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

From report at bugs.python.org  Wed Aug 10 05:51:37 2016
From: report at bugs.python.org (REIX Tony)
Date: Wed, 10 Aug 2016 09:51:37 +0000
Subject: [New-bugs-announce] [issue27725] Use Py_SIZE(x) instead of
 x->ob_size
Message-ID: <1470822697.33.0.602349991034.issue27725@psf.upfronthosting.co.za>


New submission from REIX Tony:

I'm porting Python 2.7.* on AIX.

I am now using a version 13.1.3.2 of XLC.
I was previously using version 12.1.0.14 .
It appears that this new compiler shows a potential issue in Python v2 code. This issue seems to appear when -O2 is used.

I was porting Python 2.7.11 with -O2 instead of -O0 when I got it.

The issue appears when running tests involving power() with Decimals where the x_sub() routine is used.

The following Python code shows the issue:
  from decimal import *
  c = Context(7, ROUND_UP)
  d = c.power(Decimal(0.7), Decimal(3.4))
  print d
Good result is:  0.2973948 .
The bug returns: 2.440099 

However, I have about 22 errors when running:
./python Lib/test/regrtest.py -v test_decimal
It is random in 64bit and quite constant in 32bit.

The issue deals with using x->ob-size.
There is a macro:
Include/object.h:#define Py_SIZE(ob)  (((PyVarObject*)(ob))->ob_size)

The issue appears in last lines of Objects/longobject.c:x_sub() routine, when changing the sign:   z->ob_size = -(z->ob_size);

I have looked at version 2.7.12 and 2.7.10 of Python: they contain the same code as in 2.7.11.
And ->ob_size is used about 45 times, mainly in Objects/longobject.c. However, Py_SIZE(...) is used ten times more (475).

- Looking at version 3.5.1 of Python, I see that ->ob_size is now used only once, in: Objects/object.c .
And Py_SIZE(...) is now used 616 times.

And I also see that the Python 2.7.11-12 x_sub() code:
      if (sign < 0)
        z->ob_size = -(z->ob_size);
      return long_normalize(z);
has been replaced in Python 3.5.1 by:
      if (sign < 0) {
        _PyLong_Negate(&z);
        if (z == NULL)
            return NULL;
      }
      return long_normalize(z);

  /* If a freshly-allocated int is already shared, it must
      be a small integer, so negating it must go to PyLong_FromLong */
  Py_LOCAL_INLINE(void)
  _PyLong_Negate(PyLongObject **x_p)
  {
     PyLongObject *x;

     x = (PyLongObject *)*x_p;
     if (Py_REFCNT(x) == 1) {
         Py_SIZE(x) = -Py_SIZE(x);
         return;
     }

     *x_p = (PyLongObject *)PyLong_FromLong(-MEDIUM_VALUE(x));
     Py_DECREF(x);
 }


So, it looks to me that Python v2 version should do the same that Python v3 has done: replace x->ob-size by Py_SIZE(x) everywhere, and improve the code of x_sub() by using some _PyLong_Negate() routine or macro.

----------
components: Library (Lib)
messages: 272324
nosy: trex58
priority: normal
severity: normal
status: open
title: Use Py_SIZE(x) instead of x->ob_size
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 10 07:23:24 2016
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 10 Aug 2016 11:23:24 +0000
Subject: [New-bugs-announce] [issue27726] ctags -t does not exists in
 Makefile.pre.in
Message-ID: <1470828204.23.0.262773554003.issue27726@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

I use Exuberant Ctags 5.8 on my Fedora 24, and this version does not accept the '-t' argument, as defined in the 'tags' target of the Makefile.

----------
files: Makefile.pre.in.diff
keywords: patch
messages: 272326
nosy: larry, matrixise
priority: normal
severity: normal
status: open
title: ctags -t does not exists in Makefile.pre.in
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44067/Makefile.pre.in.diff

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

From report at bugs.python.org  Wed Aug 10 10:37:47 2016
From: report at bugs.python.org (Kaeptm Blaubaer)
Date: Wed, 10 Aug 2016 14:37:47 +0000
Subject: [New-bugs-announce] [issue27727] Update Tools/freeze to use
 .vcxproj files
Message-ID: <1470839867.79.0.0217135468923.issue27727@psf.upfronthosting.co.za>


New submission from Kaeptm Blaubaer:

The Tools/freeze script is broken because the .dsp files no longer exists.

----------
components: Demos and Tools
messages: 272334
nosy: Kaeptm Blaubaer
priority: normal
severity: normal
status: open
title: Update Tools/freeze to use .vcxproj files
type: compile error

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

From report at bugs.python.org  Wed Aug 10 13:58:34 2016
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 10 Aug 2016 17:58:34 +0000
Subject: [New-bugs-announce] [issue27728] HTTPConnection.requests has a
 mutable as default value for headers
Message-ID: <1470851914.31.0.44404108288.issue27728@psf.upfronthosting.co.za>


New submission from St?phane Wirtel:

http.client.HTTPConnection.request, the argument 'headers' has a default value, and this one is a mutable (dict).

----------
messages: 272352
nosy: matrixise
priority: normal
severity: normal
status: open
title: HTTPConnection.requests has a mutable as default value for headers
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 10 18:59:55 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Aug 2016 22:59:55 +0000
Subject: [New-bugs-announce] [issue27729] Provide a better error message
 when the file path is too long on Windows
Message-ID: <1470869995.82.0.0225093644584.issue27729@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Windows has a max path length when the path doesn't start with r'\\?\'. When you hit that limit you get a FileNotFoundError but no explanation that it was because of some file path length. It would be nice to clarify this case in the exception message (probably by changing PyErr_SetExcFromWindowsErrWithFilenameObjects() in Python/errors.c).

----------
components: Windows
messages: 272382
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: Provide a better error message when the file path is too long on Windows
type: behavior

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

From report at bugs.python.org  Wed Aug 10 19:02:05 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Aug 2016 23:02:05 +0000
Subject: [New-bugs-announce] [issue27730] Update shutil to work with max
 file path length on Windows
Message-ID: <1470870125.62.0.00624513832595.issue27730@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It would be nice to have a place in the stdlib that can work with long file names on Windows no matter what. shutils seems like a possibly reasonable place.

----------
components: Windows
messages: 272384
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update shutil to work with max file path length on Windows

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

From report at bugs.python.org  Wed Aug 10 19:09:48 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 10 Aug 2016 23:09:48 +0000
Subject: [New-bugs-announce] [issue27731] Opt-out of MAX_PATH on Windows 10
Message-ID: <1470870588.24.0.387323259693.issue27731@psf.upfronthosting.co.za>


New submission from Steve Dower:

According to https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx we can opt-out of MAX_PATH limitations on a selection of functions on the latest version of Windows 10. This will allow unprefixed paths (i.e. no "\\?\") to exceed 260 characters for many common functions.

I will enable this for Python 3.6.

----------
assignee: steve.dower
components: Windows
messages: 272385
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Opt-out of MAX_PATH on Windows 10
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 10 21:02:30 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 11 Aug 2016 01:02:30 +0000
Subject: [New-bugs-announce] [issue27732] IDLE tests should be quiet
Message-ID: <1470877350.75.0.899143333504.issue27732@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

IDLE uses tkinter.widget.bell() in various places to signal an exceptional situation.  Examples include 'Find' when the target cannot be found and 'Expand word' when there is no expansion (or are no more expansions.

[The tk manual page is http://www.tcl.tk/man/tcl8.6/TkCmd/bell.htm.  I have no idea what difference it makes which window the bell is rung on.

When running test_idle, there are about 5 beeps.  They serve no purpose and can only discourage buildbot owners from running gui tests, even if they could.  Test_tk and test_ttk_guionly are silent.

A solution is to replace something like 'self.text.bell' with 'self.bell', where the latter is either the former or 'lambda: None', depending on a 'utest=False' parameter.

The replacement could lead to the following bonus in a follow-on issue: a separate function could be augmented to emit a 'visual bell', a signal that is seen rather than heard.  This would benefit both the hard-of-hearing and those who edit with sound turned off or redirected to headphones not worn.  Notepad++ somehow flashes the Search dialog title bar as well a adding a message to the status bar.  I would rather flash (blink) the text not found or expanded.  The idea is to replace a hard-coded external function with a custom wrapper subject to future improvement.

----------
assignee: terry.reedy
components: IDLE
messages: 272390
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE tests should be quiet
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Aug 11 00:04:12 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 11 Aug 2016 04:04:12 +0000
Subject: [New-bugs-announce] [issue27733] Test that self.bell is called in
 IDLE classes when intended.
Message-ID: <1470888252.5.0.707581681371.issue27733@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Spinoff of #27732, which changed 5 tested bell-using classes to consistently call 'self.bell()' (instead of self.text.bell or whatever) so tests for such classes could replace the function with a quiet function.  For 4 of the classes, the replacement is currently 'lambda: None'.  For undo, it is a quiet mock that replaced a noisy mock wrapping and calling the original bell().  The purpose of the mock, either way, is to test that bell() is called when intended.

I plan to add a new idle_test.mock_tk.bell function.  I am considering having it automatically reset 'called' when 'called is accessed.  In any case, this issue is about extending the use of mock bells to other tests.

----------
assignee: terry.reedy
components: IDLE
messages: 272397
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Test that self.bell is called in IDLE classes when intended.
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Aug 11 01:04:51 2016
From: report at bugs.python.org (=?utf-8?b?0KTQuNC70LjQv9C/INCf0L7QvdC+0LzQsNGA0LXQsg==?=)
Date: Thu, 11 Aug 2016 05:04:51 +0000
Subject: [New-bugs-announce] [issue27734] Memory leaks at Python35-32
Message-ID: <1470891891.94.0.11080010974.issue27734@psf.upfronthosting.co.za>


Changes by ?????? ????????? <qpilipp at gmail.com>:


----------
components: 2to3 (2.x to 3.x conversion tool)
nosy: ?????? ?????????
priority: normal
severity: normal
status: open
title: Memory leaks at Python35-32
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug 11 04:17:22 2016
From: report at bugs.python.org (Ram Vallury)
Date: Thu, 11 Aug 2016 08:17:22 +0000
Subject: [New-bugs-announce] [issue27735] 'module' object has no attribute
 'SIGALRM' - singal module
Message-ID: <1470903442.61.0.511890043327.issue27735@psf.upfronthosting.co.za>


New submission from Ram Vallury:

'module' object has no attribute 'SIGALRM'

SIGALRM is not identified in windows, python 2.7.
There is no explicit mention of this in documentation as well.

===
$ python
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> def handler(signum, frame):
...     print 'Signal handler called with signal', signum
...     raise IOError("Couldn't open device!")
...
>>> signal.signal(signal.SIGALRM, handler)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'SIGALRM'
>>>
====

----------
components: Windows
messages: 272420
nosy: paul.moore, rvallury, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 'module' object has no attribute 'SIGALRM' - singal module
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 11 04:46:27 2016
From: report at bugs.python.org (Simon McVittie)
Date: Thu, 11 Aug 2016 08:46:27 +0000
Subject: [New-bugs-announce] [issue27736] repeated
 Py_Initialize/PyRun_SimpleString/Py_Finalize segfaults
Message-ID: <1470905187.92.0.13440650895.issue27736@psf.upfronthosting.co.za>


New submission from Simon McVittie:

dbus-python has a regression test for https://bugs.freedesktop.org/show_bug.cgi?id=23831 which repeatedly initializes the interpreter, imports dbus and finalizes the interpreter. This test passes in Python up to 3.5, but is failing under Python 3.6 nightly builds on Travis-CI, and in Python 3.6.0a3 (package version 3.6.0~a3-1) on Debian.

I've been able to reproduce the crash without anything specific to dbus with this C code:

#include <stdio.h>

#include <Python.h>

int main(void)
{
    int i;

    puts("1..1");

    for (i = 0; i < 100; ++i) {
        Py_Initialize();
        if (PyRun_SimpleString("\n") != 0) {
            puts("not ok 1 - there was an exception");
            return 1;
        }
        Py_Finalize();
    }

    puts("ok 1 - was able to loop 100 times");

    return 0;
}

It appears the crash is reliably in the 10th repeat:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff783a4bb in type_dealloc (type=0x7ffff7d8ad80 <DirEntryType>)
    at ../Objects/typeobject.c:3032
3032	../Objects/typeobject.c: No such file or directory.
(gdb) bt
#0  0x00007ffff783a4bb in type_dealloc (type=0x7ffff7d8ad80 <DirEntryType>)
    at ../Objects/typeobject.c:3032
#1  0x00007ffff7817a1b in insertdict (value=<optimized out>, hash=<optimized out>, 
    key=<optimized out>, mp=<optimized out>) at ../Objects/dictobject.c:806
#2  PyDict_SetItem (
    op=op at entry={'open': None, 'O_DIRECT': None, 'chdir': None, 'O_ACCMODE': None, '__package__': None, 'WCOREDUMP': None, 'setgroups': None, 'O_CREAT': None, 'O_CLOEXEC': None, 'chown': None, 'sched_getscheduler': None, 'RTLD_NODELETE': None, 'terminal_size': None, 'EX_IOERR': None, 'sched_setaffinity': None, 'XATTR_SIZE_MAX': None, 'fstat': None, 'sched_rr_get_interval': None, 'O_LARGEFILE': None, 'times_result': None, 'get_inheritable': None, 'WIFEXITED': None, 'ST_NODEV': None, 'forkpty': None, 'ctermid': None, 'O_RSYNC': None, 'SCHED_FIFO': None, 'stat': None, 'replace': None, 'EX_NOINPUT': None, 'WUNTRACED': None, 'set_blocking': None, '_have_functions': None, 'unsetenv': None, 'setresgid': None, 'fchown': None, 'getgrouplist': None, 'openpty': None, 'lockf': None, 'chroot': None, 'readv': None, 'EX_NOHOST': None, 'error': None, 'WEXITSTATUS': None, 'WIFSIGNALED': None, 'WNOHANG': None, 'POSIX_FADV_WILLNEED': None, 'SEEK_HOLE': None, 'dup': None, 'POSIX_FADV_NOREUSE': None, 'kill': None, 'statvfs_result': None, 'WIFCON...(truncated), 
    key='DirEntry', value=value at entry=None) at ../Objects/dictobject.c:1228
#3  0x00007ffff782659c in _PyModule_ClearDict (
    d={'open': None, 'O_DIRECT': None, 'chdir': None, 'O_ACCMODE': None, '__package__': None, 'WCOREDUMP': None, 'setgroups': None, 'O_CREAT': None, 'O_CLOEXEC': None, 'chown': None, 'sched_getscheduler': None, 'RTLD_NODELETE': None, 'terminal_size': None, 'EX_IOERR': None, 'sched_setaffinity': None, 'XATTR_SIZE_MAX': None, 'fstat': None, 'sched_rr_get_interval': None, 'O_LARGEFILE': None, 'times_result': None, 'get_inheritable': None, 'WIFEXITED': None, 'ST_NODEV': None, 'forkpty': None, 'ctermid': None, 'O_RSYNC': None, 'SCHED_FIFO': None, 'stat': None, 'replace': None, 'EX_NOINPUT': None, 'WUNTRACED': None, 'set_blocking': None, '_have_functions': None, 'unsetenv': None, 'setresgid': None, 'fchown': None, 'getgrouplist': None, 'openpty': None, 'lockf': None, 'chroot': None, 'readv': None, 'EX_NOHOST': None, 'error': None, 'WEXITSTATUS': None, 'WIFSIGNALED': None, 'WNOHANG': None, 'POSIX_FADV_WILLNEED': None, 'SEEK_HOLE': None, 'dup': None, 'POSIX_FADV_NOREUSE': None, 'kill': None, 'statvfs_result': None, 'WIFCON...(truncated))
    at ../Objects/moduleobject.c:593
#4  0x00007ffff782672e in _PyModule_Clear (m=m at entry=<module at remote 0x7ffff65e6598>)
    at ../Objects/moduleobject.c:544
#5  0x00007ffff78d5874 in PyImport_Cleanup () at ../Python/import.c:452
#6  0x00007ffff78e3a38 in Py_FinalizeEx () at ../Python/pylifecycle.c:588
#7  0x0000000000400795 in main () at /home/smcv/src/dbus-python/test/import-repeatedly.c:19
(gdb) frame 7
#7  0x0000000000400795 in main () at /home/smcv/src/dbus-python/test/import-repeatedly.c:19
19	        Py_Finalize();
(gdb) p i
$1 = 10

----------
components: Interpreter Core
messages: 272423
nosy: smcv
priority: normal
severity: normal
status: open
title: repeated Py_Initialize/PyRun_SimpleString/Py_Finalize segfaults
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Thu Aug 11 09:51:04 2016
From: report at bugs.python.org (Tim Graham)
Date: Thu, 11 Aug 2016 13:51:04 +0000
Subject: [New-bugs-announce] [issue27737] email.header.Header.encode()
 crashes with IndexError on spaces only value
Message-ID: <1470923464.88.0.417077764128.issue27737@psf.upfronthosting.co.za>


New submission from Tim Graham:

Python 2.7:
>>> from email.header import Header
>>> Header(' ').encode()
''

Python 3.2+ (I didn't check older versions of Python 3):
>>> Header(' ').encode()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/tim/code/cpython/Lib/email/header.py", line 391, in encode
    value = formatter._str(linesep)
  File "/home/tim/code/cpython/Lib/email/header.py", line 427, in _str
    self.newline()
  File "/home/tim/code/cpython/Lib/email/header.py", line 439, in newline
    self._lines[-1] += str(self._current_line)
IndexError: list index out of range

(Originally reported at https://code.djangoproject.com/ticket/27051)

----------
components: Library (Lib)
files: whitespace-header-test.diff
keywords: patch
messages: 272447
nosy: Tim.Graham
priority: normal
severity: normal
status: open
title: email.header.Header.encode() crashes with IndexError on spaces only value
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44077/whitespace-header-test.diff

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

From report at bugs.python.org  Thu Aug 11 11:15:32 2016
From: report at bugs.python.org (John Sahr)
Date: Thu, 11 Aug 2016 15:15:32 +0000
Subject: [New-bugs-announce] [issue27738] odd behavior in creating list of
 lambda expressions
Message-ID: <1470928532.31.0.43414210382.issue27738@psf.upfronthosting.co.za>


New submission from John Sahr:

The following produces unexpected behavior.
I think that it should produce a list of six different lambda expressions,
but after creation, all six lambda expressions produce the same output.
It's possible that I'm missing something about Python.

##### begin example #######
from math import *

mm = []

for n in range(6):
    f = lambda x: sin(n*x)
    print f, f(1.0)
    mm.append(f)
    
print '***'

for m in mm:
    print m, m(1.0)
###### end example ####

----------
messages: 272454
nosy: John Sahr
priority: normal
severity: normal
status: open
title: odd behavior in creating list of lambda expressions
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 11 12:10:33 2016
From: report at bugs.python.org (Ankur Dedania)
Date: Thu, 11 Aug 2016 16:10:33 +0000
Subject: [New-bugs-announce] [issue27739] add math.sign/signum
Message-ID: <1470931833.72.0.660123073724.issue27739@psf.upfronthosting.co.za>


New submission from Ankur Dedania:

Add a new function to the math module sign/signum https://en.wikipedia.org/wiki/Sign_function

----------
messages: 272459
nosy: AnkurDedania
priority: normal
severity: normal
status: open
title: add math.sign/signum
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Aug 11 14:13:23 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 11 Aug 2016 18:13:23 +0000
Subject: [New-bugs-announce] [issue27740] Fix doc of Py_CompileStringExFlags
Message-ID: <1470939203.79.0.619794104629.issue27740@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

I think the doc of Py_CompileStringExFlags has two flaws:

1. Py_CompileStringExFlags should be replaced by Py_CompileStringObject from the context. Py_CompileStringExFlags in the context is meaningless.

2. *filename* is a byte string that should be decoded but not decoded from. It is ... = decode(filename) but not filename = decode(...).

----------
assignee: docs at python
components: Documentation
files: Py_CompileStringExFlags_doc.patch
keywords: patch
messages: 272468
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Fix doc of Py_CompileStringExFlags
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44078/Py_CompileStringExFlags_doc.patch

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

From report at bugs.python.org  Thu Aug 11 14:48:31 2016
From: report at bugs.python.org (Nicholas Colclasure)
Date: Thu, 11 Aug 2016 18:48:31 +0000
Subject: [New-bugs-announce] [issue27741] datetime.datetime.strptime
 functionality description incorrect
Message-ID: <1470941311.19.0.0562450492824.issue27741@psf.upfronthosting.co.za>


New submission from Nicholas Colclasure:

The datetime.datetime.strptime documentation states that it is equivalent to datetime(*(time.strptime(date_string, format)[0:6])), but the time.struct_time returned by time.strptime does not include microseconds, implying that datetime's strptime would also not include microseconds, but testing of the functions shows that it does include them.

Removing the false statement of equivalence would be enough to remove this bug from the documentation.

----------
assignee: docs at python
components: Documentation
messages: 272474
nosy: Valectar, docs at python
priority: normal
severity: normal
status: open
title: datetime.datetime.strptime functionality description incorrect
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Aug 12 04:47:14 2016
From: report at bugs.python.org (Wolfgang Rohdewald)
Date: Fri, 12 Aug 2016 08:47:14 +0000
Subject: [New-bugs-announce] [issue27742] Random.seed(5,
 version=1) generates different values in PYthon2 and Python3
Message-ID: <1470991634.5.0.402741312706.issue27742@psf.upfronthosting.co.za>


New submission from Wolfgang Rohdewald:

The documentation promises backwards compatible seeders. I understand this as such that they generate the same random sequences. But for Python 2.7.12 and 3.5.2 this is not so, even if I pass an integer as seed value. The attached script returns different values.

Maybe I misunderstand the documentation - I believe it means that seed(version=1) uses the backwards compatible seeder, but it does not say so explicitly. If that is not so, the documentation does not say how to invoke the backwards compatible seeder.

----------
components: Library (Lib)
files: r.py
messages: 272506
nosy: wrohdewald
priority: normal
severity: normal
status: open
title: Random.seed(5, version=1) generates different values in PYthon2 and Python3
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file44082/r.py

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

From report at bugs.python.org  Fri Aug 12 05:42:43 2016
From: report at bugs.python.org (tzickel)
Date: Fri, 12 Aug 2016 09:42:43 +0000
Subject: [New-bugs-announce] [issue27743] Python 2 has a wrong artificial
 limit on the amount of memory that can be allocated in ctypes
Message-ID: <1470994963.77.0.387843517386.issue27743@psf.upfronthosting.co.za>


New submission from tzickel:

Python 2 has a wrong artificial limit on the amount of memory that can be allocated in ctypes via sequence repeating (i.e. using create_string_buffer or c_char * <large number>)

The problem is practical in Windows 64 bit, when running python 64 bit, since in that platform the sys.maxint is 2GB and while sys.maxsize is as large as in other platforms, trying to allocate more than 2GB of memory results in a different exception than other platforms (where sys.maxint = sys.maxsize):

Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, ctypes
>>> ctypes.c_char * (sys.maxint + 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: class must define a '_length_' attribute, which must be a positive integer

>>> ctypes.create_string_buffer(sys.maxint + 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Python27-64\lib\ctypes\__init__.py", line 65, in create_string_buffer
    buftype = c_char * init
AttributeError: class must define a '_length_' attribute, which must be a positive integer

on other platforms you get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: cannot fit 'long' into an index-sized integer

Thus to allocate more than 2GB, you need to use other methods (numpy or something else).

>From my reading of the code, I assume the bug is this line:
https://github.com/python/cpython/blob/2.7/Modules/_ctypes/_ctypes.c#L1388

Where the code checks if _length_ is an integer (PyInt_Check). As soon as the number is bigger than sys.maxint, it's a long, and while it's a valid size for the platform (< sys.maxsize), it will bork there. Since this seems like an artificial limit, I think it should be fixed, since it's practical to allocate this sizes on 64 bit systems for some applications.

Python 3 has no issue, since it has no int type :)

----------
components: ctypes
messages: 272510
nosy: Bob, Christoph Sarnowski, Patrick Stewart, doko, jpe, larry, mark.dickinson, mattip, meador.inge, python-dev, rkuska, steve.dower, tzickel, vinay.sajip
priority: normal
severity: normal
status: open
title: Python 2 has a wrong artificial limit on the amount of memory that can be allocated in ctypes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 12 06:21:30 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Aug 2016 10:21:30 +0000
Subject: [New-bugs-announce] [issue27744] Add AF_ALG (Linux Kernel crypto)
 to socket module
Message-ID: <1470997290.77.0.995104201782.issue27744@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Linux has a netlink-based user-space interface for Kernel cryptography. Kernel based crypto has a couple of advantages that are explained at http://www.chronox.de/libkcapi/html/ch01s02.html . The document doesn't mention that a crypto socket also supports splicing and sendfile. Files no longer have to be copied to user-space.

My experimental branch https://github.com/tiran/cpython/commits/feature/af_alg implements af_alg support. Example:

from socket import socket, AF_ALG, SOCK_SEQPACKET, SOL_ALG, ALG_SET_KEY
from binascii import hexlify
with socket(AF_ALG, SOCK_SEQPACKET, 0) as alg:
    alg.bind(('hash', 'hmac(sha512)'))
    alg.setsockopt(SOL_ALG, ALG_SET_KEY, b'key')
    op, _ = alg.accept()
    with open('/etc/passwd', 'rb') as f:
        op.sendfile(f)
    print(hexlify(op.recv(64)))
    op.close()

----------
components: Extension Modules
messages: 272516
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Add AF_ALG (Linux Kernel crypto) to socket module
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Aug 12 06:44:09 2016
From: report at bugs.python.org (Lele Gaifax)
Date: Fri, 12 Aug 2016 10:44:09 +0000
Subject: [New-bugs-announce] [issue27745] Fix typos in Argument Clinic howto
Message-ID: <1470998649.34.0.55275760151.issue27745@psf.upfronthosting.co.za>


New submission from Lele Gaifax:

The attached patch, available also as https://github.com/lelit/cpython/commit/9e33f33e87ad594daae71ccdbe6f0a5c5f8aca65, fixes a few typos in the Argument Clinic howto document.

----------
components: Argument Clinic
files: ac-doc-typos.patch
keywords: patch
messages: 272518
nosy: larry, lelit
priority: normal
severity: normal
status: open
title: Fix typos in Argument Clinic howto
versions: Python 3.6
Added file: http://bugs.python.org/file44083/ac-doc-typos.patch

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

From report at bugs.python.org  Fri Aug 12 08:13:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Aug 2016 12:13:42 +0000
Subject: [New-bugs-announce] [issue27746] ResourceWarnings in test_asyncio
Message-ID: <1471004022.68.0.202760199133.issue27746@psf.upfronthosting.co.za>


New submission from Martin Panter:

$ ./python -bWerror -m test -r -u all
. . .
0:12:58 [ 70/402] test_asyncio
Exception ignored in: <bound method _SSLProtocolTransport.__del__ of <asyncio.sslproto._SSLProtocolTransport object at 0x7fed4638f0c0>>
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/asyncio/sslproto.py", line 329, in __del__
    source=self)
ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x7fed4638f0c0>
Exception ignored in: <bound method _SSLProtocolTransport.__del__ of <asyncio.sslproto._SSLProtocolTransport object at 0x7fed46317c88>>
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/asyncio/sslproto.py", line 329, in __del__
    source=self)
ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x7fed46317c88>
Exception ignored in: <bound method _SSLProtocolTransport.__del__ of <asyncio.sslproto._SSLProtocolTransport object at 0x7fed46310f60>>
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/asyncio/sslproto.py", line 329, in __del__
    source=self)
ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x7fed46310f60>
Executing <Task finished coro=<CoroutineTests.test_async_def_wrapped.<locals>.start() done, defined at /media/disk/home/proj/python/cpython/Lib/test/test_asyncio/test_pep492.py:149> result=None created at /media/disk/home/proj/python/cpython/Lib/asyncio/base_events.py:367> took 0.351 seconds

If necessary, you should be able to run with python -Wall -X tracemalloc=33 to get a stack dump where the resources (transport objects or whatever) were allocated.

----------
components: Tests, asyncio
messages: 272529
nosy: gvanrossum, haypo, martin.panter, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: ResourceWarnings in test_asyncio
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug 12 10:01:01 2016
From: report at bugs.python.org (Paulo Gabriel Poiati)
Date: Fri, 12 Aug 2016 14:01:01 +0000
Subject: [New-bugs-announce] [issue27747] Broken example in the queue module
 documentation
Message-ID: <1471010461.03.0.586274907081.issue27747@psf.upfronthosting.co.za>


New submission from Paulo Gabriel Poiati:

I believe the code example at https://docs.python.org/3.6/library/queue.html is broken. The break condition in the worker loop (when the queued value is None) must call the `task_done` before breaking, otherwise the code blocks indefinitely in the `queue.join()` statement.

----------
assignee: docs at python
components: Documentation
messages: 272540
nosy: Paulo Gabriel Poiati, docs at python
priority: normal
severity: normal
status: open
title: Broken example in the queue module documentation
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug 12 13:12:36 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 12 Aug 2016 17:12:36 +0000
Subject: [New-bugs-announce] [issue27748] Simplify test_winsound
Message-ID: <1471021956.0.0.678344945934.issue27748@psf.upfronthosting.co.za>


New submission from Zachary Ware:

test_winsound is rather annoying.  It currently attempts to determine whether a sound card is present, and whether particular system sounds are available.  These checks are fragile at best, and I routinely see failures that shouldn't be.  In particular, if I have an open RDP session to my ware-win81-release buildbot, test_winsound fails because it thinks the sounds should fail to play, but instead they succeed.

Rather than attempt to make the checks more robust, I suggest that we instead rip out the checks and simply ensure that each call that might succeed either returns normally or raises RuntimeError.  After all, we can't actually test whether a sound really played or not.

----------
assignee: zach.ware
components: Tests, Windows
files: simplify_test_winsound.diff
keywords: patch
messages: 272546
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: low
severity: normal
stage: patch review
status: open
title: Simplify test_winsound
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44089/simplify_test_winsound.diff

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

From report at bugs.python.org  Fri Aug 12 14:59:30 2016
From: report at bugs.python.org (wevsty)
Date: Fri, 12 Aug 2016 18:59:30 +0000
Subject: [New-bugs-announce] [issue27749] python 3.5.2 maybe crash
Message-ID: <1471028370.6.0.516756873542.issue27749@psf.upfronthosting.co.za>


New submission from wevsty:

When I use Python 3.5.2 some of the time will be a crash.displayed crash module is python35.dll.
I run Python environment is Windows Server 2012R2.I think crash dump maybe will be helpful.Report.wer and carsh dump can be downloaded via the following link.
http://o8z0k9748.bkt.clouddn.com/Python_crash_Dump_20160813_AF1A29AF.7z

I have another question when i using managers lib multiprocessing Maybe have exception.
my code is?
Session_lock.G_Process_Lock = multiprocessing.Manager().Lock()
def execute_select_command(command):
    try:
        with Session_lock.G_Process_Lock:
            values = []
            conn = sqlite3.connect(SQLite_DB_NAME)
            cursor = conn.cursor()
            try:
                cursor.execute(command)
                values = cursor.fetchall()
            except Exception as e:
                pass
            finally:
                cursor.close()
                conn.close()
            return values
    except Exception as e:
        print(e)
        traceback.print_exc()
    finally:
        pass

This code is possible to print out the information.

Traceback (most recent call last):
  File "C:/Users/Administrator/Desktop/Monitor_URL\Monitor_SQL.py", line 44, in execute_select_command
    return values
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35\lib\multiprocessing\managers.py", line 949, in __exit__
    return self._callmethod('release')
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35\lib\multiprocessing\managers.py", line 716, in _callmethod
    conn.send((self._id, methodname, args, kwds))
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35\lib\multiprocessing\connection.py", line 206, in send
    self._send_bytes(ForkingPickler.dumps(obj))
  File "C:\Users\Administrator\AppData\Local\Programs\Python\Python35\lib\multiprocessing\connection.py", line 280, in _send_bytes
    ov, err = _winapi.WriteFile(self._handle, buf, overlapped=True)
TypeError: WriteFile() argument 1 must be int, not None

This maybe seem like a lib problem.

----------
components: Library (Lib)
messages: 272557
nosy: wevsty
priority: normal
severity: normal
status: open
title: python 3.5.2 maybe crash
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Fri Aug 12 15:08:52 2016
From: report at bugs.python.org (chinmay hegde)
Date: Fri, 12 Aug 2016 19:08:52 +0000
Subject: [New-bugs-announce] [issue27750] Idle editor crashes when input
 size more than 250 lines given
Message-ID: <1471028932.53.0.0266667136467.issue27750@psf.upfronthosting.co.za>


New submission from chinmay hegde:

Idle editor crashes when input size more than 250 lines given.

Steps to reproduce:-
try with below snippet of code

for i in range(250):
    n=input()

Execute the snippet of code. But while giving the input copy all 250 inputs with single paste.
Editor is crashed. On clicking it's giving "Not responding"

System Config:-
OS - Windows 10
Python Version - 3.5.2
IDLE version - 3.5.2
Tk version - 8.6.4

----------
assignee: terry.reedy
components: IDLE
messages: 272558
nosy: chinmay hegde, terry.reedy
priority: normal
severity: normal
status: open
title: Idle editor crashes when input size more than 250 lines given
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Fri Aug 12 21:52:56 2016
From: report at bugs.python.org (YoSTEALTH)
Date: Sat, 13 Aug 2016 01:52:56 +0000
Subject: [New-bugs-announce] [issue27751] Itertools -> Recipes -> pairwise()
Message-ID: <1471053176.82.0.676475972394.issue27751@psf.upfronthosting.co.za>


New submission from YoSTEALTH:

# Link: https://docs.python.org/3/library/itertools.html#itertools-recipes
# Function pairwise() in Itertools -> Recipes could be improved!? Here is the code:


import time
import itertools


def pairwise(iterable):
    "s -> (s0,s1), (s1,s2), (s2, s3), ..."
    a, b = itertools.tee(iterable)
    next(b, None)
    return zip(a, b)


def new_pairwise(iterable):
    "s -> (s0,s1), (s1,s2), (s2, s3), ..."
    return zip(iterable, iterable[1:])


combine = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9)


if __name__ == '__main__':
    start_time = time.time()

    # Current
    print('Current:')
    print(list(pairwise(combine)))
    # output: [(0, 1), (1, 2), (2, 3), (3, 4), (4, 5), (5, 6), (6, 7), (7, 8), (8, 9)]

    print()

    # New
    print('New:')
    print(list(new_pairwise(combine)))
    # output: [(0, 1), (1, 2), (2, 3), (3, 4), (4, 5), (5, 6), (6, 7), (7, 8), (8, 9)]

    # Benchmark
    # for _ in range(1000000):
    #     list(pairwise(combine))  # Time: 2.61199975
    #     list(new_pairwise(combine))  # Time: 1.14828038

    print('\n\nTime: {}'.format(round(time.time() - start_time, 8)), end='')

----------
messages: 272572
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: Itertools -> Recipes -> pairwise()
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Sat Aug 13 02:49:56 2016
From: report at bugs.python.org (lockywolf)
Date: Sat, 13 Aug 2016 06:49:56 +0000
Subject: [New-bugs-announce] [issue27752] CSV DictReader default dialect
 name 'excel' is misleading, as MS Excel doesn't actually use ',
 ' as a separator.
Message-ID: <1471070996.16.0.75939310279.issue27752@psf.upfronthosting.co.za>


New submission from lockywolf:

Hello, everyone.

I want to report a minor usability issue:

I wanted to use the csv module to load CSV's and the documentation says that the default dialect for reading CSVs is 'excel'.

However, the delimiter used with this dialect in Python is a comma (','), whereas in fact (even though is's called _comma_ separated values) MS Excel (2016) uses a semicolon (';') as a delimiter.
Therefore, the Python's 'excel' actually doesn't read Excel generated files.

----------
components: Library (Lib)
messages: 272579
nosy: lockywolf
priority: normal
severity: normal
status: open
title: CSV DictReader default dialect name 'excel' is misleading, as MS Excel doesn't actually use ',' as a separator.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug 13 11:17:50 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 13 Aug 2016 15:17:50 +0000
Subject: [New-bugs-announce] [issue27753] py_compile.compile() does not
 specify if it can accept a file like object or a bytes like object with the
 file's data.
Message-ID: <1471101470.06.0.092616932845.issue27753@psf.upfronthosting.co.za>


New submission from Decorater:

py_compile.compile() does not specify if it can accept a file like object or a bytes like object with the file's data.

Although I need something that can allow me to import byte like objects if the object contains valid python script data.
(basically it would have to act as a import unless I have to exec the data in it which would be totally bad as it would not be able to retain all of the data.

Long story short I need a way to import the data returned from the dec_script() function in this: https://bpaste.net/show/694c231c566c

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 272590
nosy: Decorater, docs at python
priority: normal
severity: normal
status: open
title: py_compile.compile() does not specify if it can accept a file like object or a bytes like object with the file's data.
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Aug 13 13:37:04 2016
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 13 Aug 2016 17:37:04 +0000
Subject: [New-bugs-announce] [issue27754] Changing the meaning of
 bool.__invert__
Message-ID: <1471109824.62.0.86263104398.issue27754@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

Not that I'm very much for it, but I'd like this not to be forgotten:

https://mail.python.org/pipermail/python-ideas/2016-April/039665.html

Is this going to be done in Py3.6? Or officially dropped?

----------
messages: 272597
nosy: veky
priority: normal
severity: normal
status: open
title: Changing the meaning of bool.__invert__

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

From report at bugs.python.org  Sat Aug 13 15:52:27 2016
From: report at bugs.python.org (Justin Foo)
Date: Sat, 13 Aug 2016 19:52:27 +0000
Subject: [New-bugs-announce] [issue27755] Retire DynOptionMenu with a ttk
 Combobox
Message-ID: <1471117947.7.0.659308305751.issue27755@psf.upfronthosting.co.za>


New submission from Justin Foo:

One aspect of the IDLE interface that looks extremely old is the the dropdown menu. In the patch, I think I've preserved whatever essential functionality DynOptionMenu used to have, but I'm relatively unfamiliar with Tk so I'm not sure.

----------
assignee: terry.reedy
components: IDLE
messages: 272609
nosy: jfoo, terry.reedy
priority: normal
severity: normal
status: open
title: Retire DynOptionMenu with a ttk Combobox
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Aug 13 16:26:13 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 13 Aug 2016 20:26:13 +0000
Subject: [New-bugs-announce] [issue27756] Add pyd icon for 3.6
Message-ID: <1471119973.85.0.0311186784534.issue27756@psf.upfronthosting.co.za>


New submission from Decorater:

I did some working and did a halfed one for pyd's it basically combines it icon from python.exe with the DLL "gears" for windows DLL's beig under that. Hopefully it will work. (Anyone could use this as a base file and restyle it or whatever if they want. At least I tried.

(note: the file would have to go under the PC directory as well. Hopefully something from the python installer can associate them with pyd files so that way people can distinquish them from any other file type (like pdbs,lib,w/e with no icon(s)).

----------
files: pyd.ico
messages: 272613
nosy: Decorater
priority: normal
severity: normal
status: open
title: Add pyd icon for 3.6
versions: Python 3.6
Added file: http://bugs.python.org/file44098/pyd.ico

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

From report at bugs.python.org  Sat Aug 13 19:23:40 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 13 Aug 2016 23:23:40 +0000
Subject: [New-bugs-announce] [issue27757] eval() does not allow import
 statements to run.
Message-ID: <1471130620.63.0.743725137456.issue27757@psf.upfronthosting.co.za>


New submission from Decorater:

runnign exec on import lines are fine however if I run the following code in a exec:

>>>import py2pycx;py2pycx.api.compress_script(sys.path[0] + '\resources\Dependencies', 'six.py')
Traceback (most recent call last):
  File ".\resources\Dependencies\DecoraterBotCore\BotCommands.py", line 261, in debug_code
    debugcode = eval(debugcode)
  File "<string>", line 1
    import py2pycx;py2pycx.api.compress_script(sys.path[0] + '\resources\Dependencies\', 'six.py')
         ^
SyntaxError: invalid syntax

It says it is a SyntaxError. It would be nice if eval could support import statements as well so I do not have to import the module in the file/package to be able to use eval with the functions it has.

----------
messages: 272621
nosy: Decorater
priority: normal
severity: normal
status: open
title: eval() does not allow import statements to run.

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

From report at bugs.python.org  Sat Aug 13 20:16:14 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Aug 2016 00:16:14 +0000
Subject: [New-bugs-announce] [issue27758] integer overflow in the _csv
 module's join_append_data function
Message-ID: <1471133774.9.0.7207224009.issue27758@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Thomas E Hybel on PSRT reports:

This vulnerability is an integer overflow leading to a heap buffer overflow. I
have attached a proof-of-concept script below.

The vulnerability resides in the Modules/_csv.c file, in the join_append and
join_append_data functions.

join_append initially calls join_append_data with copy_phase=0 to compute the
new length of its internal "rec" buffer. Then it grows the buffer. Finally it
calls join_append_data with copy_phase=1 to perform the actual writing.

The root issue is that join_append_data does not check for overflow when
computing the field rec_len which it returns. By having join_append_data called
on a few fields of appropriate length, we can make rec_len roll around and
become a small integer.

Note that there is already a check in join_append for whether (rec_len < 0). But
this check is insufficient as we can cause rec_len to grow sufficiently in a
single call to never let join_append see a negative size.

After the overflow happens, rec_len is a small integer, and thus when
join_append calls join_check_rec_size to potentially grow the rec buffer, no
enlargement happens. After this, join_append_data is called again, now with
copy_phase=1, and with a giant field_len.

Thus join_append_data writes the remaining data out-of-bounds of the self->rec
buffer which is located on the heap. Such a complete heap corruption should
definitely be exploitable to gain remote code execution.


Further details:

Tested version: Python-3.5.2, 32 bits

Proof-of-concept reproducer script (32-bits only):

--- begin script ---

import _csv

class MockFile:
    def write(self, _):
        pass

writer = _csv.writer(MockFile())
writer.writerow(["A"*0x10000, '"'*0x7fffff00]) 

--- end script ---

Python (configured with --with-pydebug) segfaults when the script is run. A
backtrace can be seen below. Note that the script only crashes on 32-bit
versions of Python. That's because the rec_len variable is an ssize_t, which is
4 bytes wide on 32-bit architectures, but 8 bytes wide on 64-bit arches.


(gdb) r
Starting program: /home/ubuntu32/python3/Python-3.5.2/python ../poc1.py
...
Program received signal SIGSEGV, Segmentation fault.
PyType_IsSubtype (a=0x0, b=b at entry=0x82d9aa0 <PyModule_Type>) at Objects/typeobject.c:1343
1343        mro = a->tp_mro;
(gdb) bt
#0  PyType_IsSubtype (a=0x0, b=b at entry=0x82d9aa0 <PyModule_Type>) at Objects/typeobject.c:1343
#1  0x080e29d9 in PyModule_GetState (m=0xb7c377f4) at Objects/moduleobject.c:532
#2  0xb7fd1a33 in join_append_data (self=self at entry=0xb7c2ffac, field_kind=field_kind at entry=0x1, field_data=field_data at entry=0x37c2f038,
    field_len=field_len at entry=0x7fffff00, quoted=quoted at entry=0xbffff710, copy_phase=copy_phase at entry=0x1)
    at /home/ubuntu32/python3/Python-3.5.2/Modules/_csv.c:1060
#3  0xb7fd1d6e in join_append (self=self at entry=0xb7c2ffac, field=field at entry=0x37c2f018, quoted=0x1, quoted at entry=0x0)
    at /home/ubuntu32/python3/Python-3.5.2/Modules/_csv.c:1138
...

----------
components: Library (Lib)
messages: 272624
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: integer overflow in the _csv module's join_append_data function
type: security
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/issue27758>
_______________________________________

From report at bugs.python.org  Sat Aug 13 20:26:49 2016
From: report at bugs.python.org (Mark Williams)
Date: Sun, 14 Aug 2016 00:26:49 +0000
Subject: [New-bugs-announce] [issue27759] selectors incorrectly retain
 invalid file descriptors
Message-ID: <1471134409.41.0.274513488512.issue27759@psf.upfronthosting.co.za>


New submission from Mark Williams:

Registering a file descriptor with EpollSelector.register that epoll(7) refuses results in the selector retaining a SelectorKey for that file descriptor, even though it's not monitored.

The following program attempts to register a file on the filesystem with an EpollSelector.  epoll_ctl(2) returns EPERM when given a such a file descriptor, so it shouldn't be registered with the selector, but it is registered.


import selectors
import tempfile
import traceback

sel = selectors.EpollSelector()

with tempfile.TemporaryFile() as f:
    try:
        sel.register(f, selectors.EVENT_READ)
    except PermissionError:
        traceback.print_exc()
    print("This should have raised a KeyError:", sel.get_key(f))


It produces this output on Pythons 3.4-3.6:

Traceback (most recent call last):
  File "/tmp/sel.py", line 9, in <module>
    sel.register(f, selectors.EVENT_READ)
  File "/usr/lib/python3.4/selectors.py", line 402, in register
    self._epoll.register(key.fd, epoll_events)
PermissionError: [Errno 1] Operation not permitted
This should have raised a KeyError: SelectorKey(fileobj=<_io.BufferedRandom name=8>, fd=8, events=1, data=None)

A similar problem exists with KqueueSelector.  Consider the following program:


import selectors
import tempfile
import traceback

sel = selectors.KqueueSelector()

f = tempfile.TemporaryFile()
filedescriptor = f.fileno()
f.close()

try:
    sel.register(filedescriptor, selectors.EVENT_READ)
except OSError:
    traceback.print_exc()

print("This should have raised a KeyError:", sel.get_key(filedescriptor))


In this case selectors._fileobj_to_fd doesn't detect that the integer file descriptor is closed.  

Note that _fileobj_to_fd should not be changed! Attempting to use, say, fcntl(fd, fcntl.GET_FD) to detect a closed file descriptor introduces a TOCTTOU bug.  Another thread (or another process, if the file descriptor refers to a socket shared between two or more processes and one calls shutdown(2) on it) can change the state of the file descriptor between the time it's checked and the time it's registered.  A new file might even be opened and given the previous file descriptor.

The attached patch catches any exception raised by EpollSelector.register or KqueueSelector.register, removes the SelectorKey from BaseSelector's table, and then re-raises the exception.

Note that I've included asyncio as an affected component, because asyncio wraps the selectors module.

----------
components: asyncio
files: selectors.patch
keywords: patch
messages: 272626
nosy: Mark.Williams, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: selectors incorrectly retain invalid file descriptors
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44100/selectors.patch

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

From report at bugs.python.org  Sat Aug 13 21:32:26 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Aug 2016 01:32:26 +0000
Subject: [New-bugs-announce] [issue27760] integer overflow in binascii.b2a_qp
Message-ID: <1471138346.27.0.267197396975.issue27760@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Thomas E Hybel reports:

This vulnerability resides in /Modules/binascii.c in the function
binascii_b2a_qp_impl. The problem is that the integer variable "odatalen" can
overflow to become a small number.

The function binascii_b2a_qp_impl qp-encodes binary data. First it computes the
output string's length in the variable "odatalen":

    /* First, scan to see how many characters need to be encoded */
    in = 0;
    while (in < datalen) {
        if ((databuf[in] > 126) || ... )
        {
            ...
            odatalen += 3;
            in++;
        }
        ...
    }

As we can see, each input character can result in more than three
output-characters. Then we allocate the output string:

    odata = (unsigned char *) PyMem_Malloc(odatalen);

And finally we encode the input-string and write the result into odata.

If our string is so large that "odatalen" will wrap around and become a small
number, then the odata buffer will be too small to hold the data. Our input is
then copied into this too-small buffer. So the integer overflow results in a
heap buffer overflow.

Here's a proof-of-concept script:

--- begin script ---

import binascii
binascii.b2a_qp(b"\x80"*0x531dec0e) # this number gives odatalen=2

--- end script ---

Note that this script assumes a 32-bit system where the "odatalen" variable will
be 4 bytes wide. When run on Python-3.5.2, 32-bits, we get a segfault:

(gdb) r ../poc3.py
Starting program: /home/ubuntu32/python3/Python-3.5.2/python ../poc3.py

Breakpoint 1, binascii_b2a_qp_impl (module=module at entry=0xb7c370f4,
    data=data at entry=0xbffff6e4, quotetabs=0x0, istext=0x1, header=0x0)
    at /home/ubuntu32/python3/Python-3.5.2/Modules/binascii.c:1448
1448        odata = (unsigned char *) PyMem_Malloc(odatalen);
(gdb) p odatalen
$27 = 0x2
(gdb) p datalen
$28 = 0x531dec0e
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xb7fd1f63 in to_hex (ch=0x80, s=s at entry=0x83c5fff "")
    at /home/ubuntu32/python3/Python-3.5.2/Modules/binascii.c:1333
1333        s[1] = "0123456789ABCDEF"[uvalue % 16];
(gdb) bt
#0  0xb7fd1f63 in to_hex (ch=0x80, s=s at entry=0x83c5fff "")
    at /home/ubuntu32/python3/Python-3.5.2/Modules/binascii.c:1333
#1  0xb7fd22fa in binascii_b2a_qp_impl (module=module at entry=0xb7c370f4,
    data=data at entry=0xbffff6e4, quotetabs=0x0, istext=0x1, header=0x0)
    at /home/ubuntu32/python3/Python-3.5.2/Modules/binascii.c:1476
#2  0xb7fd2510 in binascii_b2a_qp (module=module at entry=0xb7c370f4,
    args=args at entry=0xb7cbbb5c, kwargs=kwargs at entry=0x0)
    at /home/ubuntu32/python3/Python-3.5.2/Modules/clinic/binascii.c.h:510
#3  0x080e0ef4 in PyCFunction_Call (func=func at entry=0xb7c37534,
    args=args at entry=0xb7cbbb5c, kwds=kwds at entry=0x0)
    at Objects/methodobject.c:98

----------
components: Library (Lib)
messages: 272634
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: integer overflow in binascii.b2a_qp
type: security
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/issue27760>
_______________________________________

From report at bugs.python.org  Sat Aug 13 22:26:23 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 14 Aug 2016 02:26:23 +0000
Subject: [New-bugs-announce] [issue27761] Private _nth_root function loses
 accuracy on PowerPC
Message-ID: <1471141583.56.0.32662922065.issue27761@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

First reported by Martin Panter here:

http://bugs.python.org/issue27181#msg272488

I'm afraid I don't know enough about PowerPC to suggest a fix other than weakening the test on that platform.

----------
assignee: steven.daprano
messages: 272638
nosy: martin.panter, steven.daprano
priority: normal
severity: normal
status: open
title: Private _nth_root function loses accuracy on PowerPC
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Aug 13 22:42:48 2016
From: report at bugs.python.org (Joshua Haas)
Date: Sun, 14 Aug 2016 02:42:48 +0000
Subject: [New-bugs-announce] [issue27762] ConfigParser ignores in-line
 comments for lines with semi-colons
Message-ID: <1471142568.14.0.155713837509.issue27762@psf.upfronthosting.co.za>


New submission from Joshua Haas:

According to the 2.7 docs at https://docs.python.org/2/library/configparser.html, you can create in-line comments using ";" if it is preceded by white space.

However, if the value of a config option contains a semi-colon, for example "password=my;pass123", then only the first colon will be checked by the parser.

In the config file:
password=my;pass123 ;expires in 2018

Expected value:
my;pass123

Returned value:
my;pass123 ;expires in 2018

This is easily remedied with a while loop, lines 525-529 in the attached patch. Otherwise the docs should be changed to reflect this behavior, but a patch definitely seems more appropriate to me. Python 3.5 gives the expected value when using inline_comment_prefixes=';'.

----------
components: Library (Lib)
files: ConfigParser_patch.py
messages: 272641
nosy: jahschwa
priority: normal
severity: normal
status: open
title: ConfigParser ignores in-line comments for lines with semi-colons
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file44101/ConfigParser_patch.py

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

From report at bugs.python.org  Sun Aug 14 15:32:52 2016
From: report at bugs.python.org (Evelyn Mitchell)
Date: Sun, 14 Aug 2016 19:32:52 +0000
Subject: [New-bugs-announce] [issue27763] Add complex case to test_builtin
 abs()
Message-ID: <1471203172.09.0.573399775535.issue27763@psf.upfronthosting.co.za>


New submission from Evelyn Mitchell:

The description of abs() says "If the argument is a complex number, its magnitude is returned." but test_builtin doesn't include any complex number test cases.

----------
components: Library (Lib)
messages: 272688
nosy: Evelyn Mitchell
priority: low
severity: normal
stage: test needed
status: open
title: Add complex case to test_builtin abs()

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

From report at bugs.python.org  Sun Aug 14 16:41:01 2016
From: report at bugs.python.org (Ed Schouten)
Date: Sun, 14 Aug 2016 20:41:01 +0000
Subject: [New-bugs-announce] [issue27764] [Patch] Complete bits necessary
 for making fcntl's file locking optional
Message-ID: <1471207261.97.0.678306569451.issue27764@psf.upfronthosting.co.za>


New submission from Ed Schouten:

Python's fcntl module already provides some support for making support for file locking optional. For example, constants like F_SETFL are only defined if present. Unfortunately, the accompanying functions 'flock()' and 'lockf()' are present unconditionally.

CloudABI, a sandboxed runtime environment for UNIX (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), doesn't implement these ways of doing file locking, for the reason that these operations do not fit nicely within its process model. These locks are per-process; not per-descriptor. This means that processes cannot safely be composed or decomposed.

Attached is a relatively small patch to make flock() and lockf() optional, only compiling them when the necessary APIs are present. The LOCK_* constants are now also defined optionally.

----------
components: Extension Modules
files: patch-no-flock.txt
messages: 272692
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] Complete bits necessary for making fcntl's file locking optional
versions: Python 3.6
Added file: http://bugs.python.org/file44105/patch-no-flock.txt

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

From report at bugs.python.org  Mon Aug 15 03:20:28 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 15 Aug 2016 07:20:28 +0000
Subject: [New-bugs-announce] [issue27765] Accept UTF-8 encoded bytes as
 input to json.loads()
Message-ID: <1471245628.7.0.787756575079.issue27765@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In two recent Python 3 porting projects, a key incompatibility I encountered was that "json.loads(data)" on UTF-8 encoded bytes required an explicit decoding step under Python 3, rather than implicitly decoding the data as UTF-8.

Unlike many other wire formats, assuming UTF-8 for binary JSON data is a pretty safe assumption, and there's no type ambiguity here since the output type is still a properly decoded JSON object.

(This RFE has been split out from the larger RFE at #19837, which also covers implicit *encoding* to UTF-8, which is a more questionable idea)

----------
components: Library (Lib)
messages: 272725
nosy: ezio.melotti, ncoghlan, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Accept UTF-8 encoded bytes as input to json.loads()
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Aug 15 04:57:42 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 15 Aug 2016 08:57:42 +0000
Subject: [New-bugs-announce] [issue27766] Add ChaCha20 Poly1305 to SSL
 ciphers
Message-ID: <1471251462.7.0.145357415362.issue27766@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The ssl module has two cipher suite configurations, one for server-side and the other for client-side. Issue #26470 will add OpenSSL 1.1.0 support, which will introduce new cipher suites with ChaCha 20 stream cipher and Poly1305 authenticator.

CHAHA20 should be used when GCM is not available (AES GCM > CHACHA20 > AES CBC).

$ bin/openssl ciphers 'ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:DH+CHACHA20:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+HIGH:RSA+3DES:!aNULL:!eNULL:!MD5'
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:DHE-RSA-DES-CBC3-SHA:DHE-DSS-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-CCM8:AES256-CCM:AES128-CCM8:AES128-CCM:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:CAMELLIA256-SHA256:CAMELLIA128-SHA256:CAMELLIA256-SHA:CAMELLIA128-SHA:DES-CBC3-SHA

Bonus points:
Prefer CHACHA20 over AESGCM on hardware without AES-NI and CLMUL CPU instructions.

----------
components: Library (Lib)
messages: 272740
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen
priority: normal
severity: normal
status: open
title: Add ChaCha20 Poly1305 to SSL ciphers
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Aug 15 07:33:36 2016
From: report at bugs.python.org (Ron Carr)
Date: Mon, 15 Aug 2016 11:33:36 +0000
Subject: [New-bugs-announce] [issue27767] Receive "A required privilege is
 not held by the Client" error message when Installing python on Windows 10
 64 bit
Message-ID: <1471260816.48.0.169081591166.issue27767@psf.upfronthosting.co.za>


New submission from Ron Carr:

Hi,

I am unable to install Python 3.6.0, 3.5.2 and 2.7.12, on my Windows 10 64 bit system, receive error message "A required privilege is not held by the client". I have turned UAC, and changed registry setting to zero. Also have ensured my Administrator has full access rights, but still get the same error. I have also turned off my virus checker.

Any help would be greatly appeciated.

Regards,

Ballterrier

----------
components: Installation
messages: 272752
nosy: ballterrier
priority: normal
severity: normal
status: open
title: Receive "A required privilege is not held by the Client" error message when Installing python on Windows 10 64 bit
type: security
versions: Python 3.6

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

From report at bugs.python.org  Mon Aug 15 09:55:07 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 15 Aug 2016 13:55:07 +0000
Subject: [New-bugs-announce] [issue27768] ssl: add public API for IA-32
 processor capabilities vector
Message-ID: <1471269307.92.0.240465818653.issue27768@psf.upfronthosting.co.za>


New submission from Christian Heimes:

OpenSSL has a function called OPENSSL_ia32cap_loc() to get the processor's capability vector in X86 and X86_64 systems. The information is useful to decide which cipher suite to prefer. For example on machines without AES-NI and CLMUL CPU instructions, ChaCha20 should be prefered over AES-GCM. 

https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap_loc.html

#27766 just exposes the plain OPENSSL_ia32cap_loc(). A richer API should parse the bit field and expose the bits as structure.

----------
components: Extension Modules
messages: 272763
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen
priority: normal
severity: normal
status: open
title: ssl: add public API for IA-32 processor capabilities vector
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Aug 15 11:13:41 2016
From: report at bugs.python.org (Qwert225)
Date: Mon, 15 Aug 2016 15:13:41 +0000
Subject: [New-bugs-announce] [issue27769] "Replace All" with up direction
 and no wrapping replaces only the bottommost of all matching upward entries
Message-ID: <1471274021.81.0.142329752999.issue27769@psf.upfronthosting.co.za>


New submission from Qwert225:

IDLE's "Replace All" option with up direction and disabled "Wrap around" replaces only the bottommost of all matching upward entries instead of replacing all matching upward entries.

----------
assignee: terry.reedy
components: IDLE
messages: 272768
nosy: Qwert225, terry.reedy
priority: normal
severity: normal
status: open
title: "Replace All" with up direction and no wrapping replaces only the bottommost of all matching upward entries
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Aug 15 19:42:41 2016
From: report at bugs.python.org (Decorater)
Date: Mon, 15 Aug 2016 23:42:41 +0000
Subject: [New-bugs-announce] [issue27770] remove run_until_complete
Message-ID: <1471304561.4.0.720328212485.issue27770@psf.upfronthosting.co.za>


New submission from Decorater:

I use a library that uses run_until_complete that is used for HTTP connections. However it does not work well when you want to reconnect anything that makes it start via recursion. So, I am suggesting the removal of run_until_complete and then tell everyone that uses it to replace their code that had it with run_forever.
( and to have their start function to create a event loop so that way if the loop is closed recursing to restart it after closed would make it not throw a RuntimeError)

run_forever seems to be almost exactly alike run_until_complete except it can run forever.

Pros with removing run_until_complete:
+ A lot easier to handle.
+ No pain from run_until_complete.
+ Cleanup some *code* in asyncio.
+ Helps with heavy http load for reconnecting websockets if they use run_forever instead.

Cons:
- Existing code from libs or anyone that uses run_until_complete will break.
- run_forever can still throw a RuntimeError if you try to use run_forever after closing a event loop.
- Event Loop would have to be recreated or reopened after being closed.

----------
components: asyncio
messages: 272809
nosy: Decorater, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: remove run_until_complete
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 16 00:31:29 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Aug 2016 04:31:29 +0000
Subject: [New-bugs-announce] [issue27771] Add a clear screen button or menu
 choice for IDLE
Message-ID: <1471321889.54.0.890375613715.issue27771@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Learners in my classes commonly request this feature.  Beyond just providing a cosmetic clean-up, this would be useful for recovering from IDLE's catastrophic slow-downs after trying to print a very wide line (i.e. the repr of a string containing a full webpage or text file, see http://bugs.python.org/issue1442493 ).

----------
assignee: terry.reedy
components: IDLE
keywords: easy
messages: 272826
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a clear screen button or menu choice for IDLE
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 16 00:35:18 2016
From: report at bugs.python.org (Ben Finney)
Date: Tue, 16 Aug 2016 04:35:18 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue27772=5D_Refer_to_actual_fo?=
 =?utf-8?q?rmat_string_when_creating_=E2=80=9Czero_padding=E2=80=9D_error_?=
 =?utf-8?q?message?=
Message-ID: <1471322118.97.0.225723730885.issue27772@psf.upfronthosting.co.za>


New submission from Ben Finney:

When using a format specifier with leading zero, the format spec mini-language (as documented at https://docs.python.org/3/library/string.html#format-specification-mini-language>) says:

> '=' [?] becomes the default when ?0? immediately precedes the field width.

When the ?=? option is only implied, the error message ?ValueError: '=' alignment not allowed in string format specifier? becomes surprising and incomprehensible to someone who does not know that implied behaviour.

In issue 15560, Terry Reedy says:

> If the spec string is still available, it could be searched and the message adjusted if '=' is not present.  That proposal should be a new issue if someone wants to push it.

This issue raises that proposal.

The error message should be changed so that:

* It makes sense whether or not the ?=? option is explicit in the format specifier.

Or:

* Different messages are produced when the ?=? option is explicit versus when it is implicit.

I think the former option is better, but either will satisfy this request.

----------
messages: 272827
nosy: bignose
priority: normal
severity: normal
status: open
title: Refer to actual format string when creating ?zero padding? error message
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Aug 16 00:53:37 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Aug 2016 04:53:37 +0000
Subject: [New-bugs-announce] [issue27773] Excessive Py_XDECREF in the ssl
 module:
Message-ID: <1471323217.11.0.35836445166.issue27773@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Thomas E. Hybel reports:

This vulnerability exists in the function newPySSLSocket in /Modules/_ssl.c. The
problem is that Py_XDECREF is called on an object, self->server_hostname, which
isn't owned anymore.

The code looks like this:

    static PySSLSocket *
    newPySSLSocket(PySSLContext *sslctx, PySocketSockObject *sock,
                   enum py_ssl_server_or_client socket_type,
                   char *server_hostname,
                   PySSLMemoryBIO *inbio, PySSLMemoryBIO *outbio)
    {
        PySSLSocket *self;
        ...
        if (server_hostname != NULL) {
            hostname = PyUnicode_Decode(server_hostname, strlen(server_hostname),
                                       "idna", "strict");
            ...
            self->server_hostname = hostname;
        }
        ...
        if (sock != NULL) {
            self->Socket = PyWeakref_NewRef((PyObject *) sock, NULL);
            if (self->Socket == NULL) {
                Py_DECREF(self);
                Py_XDECREF(self->server_hostname);
                return NULL;
            }
        }
    }

We're initializing the "self" variable. If a hostname was given as an argument,
we call PyUnicode_Decode to initialize self->server_hostname = hostname. At this
point both "self" and "self->server_hostname" have a reference count of 1.

Later on we set self->Socket to be a new weakref. However if the call to
PyWeakref_NewRef fails (the object cannot be weakly referenced) then we run
Py_DECREF(self). Since the reference count of "self" drops to 0, PySSL_dealloc
is called, which runs this line:

    Py_XDECREF(self->server_hostname);

Now self->server_hostname's refcount drops to 0 and it is freed.

Then, back in newPySSLSocket, we run Py_XDECREF(self->server_hostname); which is
inappropriate both because "self" is now freed, and because
self->server_hostname's refcount was already dropped in PySSL_dealloc.

So this can be seen either as a use-after-free or as a double free
vulnerability.


Here's a reproducer:

--- begin script ---

import ssl, socket, _socket

s = ssl.wrap_socket(socket.socket(socket.AF_INET, socket.SOCK_STREAM))
s.context._wrap_socket(_socket.socket(), server_side=1)

--- end script ---

On my machine (Python-3.5.2, 64-bits, --with-pydebug) it crashes:

(gdb) r ./poc8.py
Starting program: /home/xx/Python-3.5.2/python ./poc8.py

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff67f7d9c in newPySSLSocket (sslctx=sslctx at entry=0x7ffff5ed15f8, sock=sock at entry=0x7ffff7e31dc0,
    socket_type=socket_type at entry=PY_SSL_SERVER, server_hostname=<optimized out>, inbio=inbio at entry=0x0, outbio=outbio at entry=0x0)
    at /home/xx/Python-3.5.2/Modules/_ssl.c:562
562                Py_XDECREF(self->server_hostname);
(gdb) p self->server_hostname
$14 = (PyObject *) 0xdbdbdbdbdbdbdbdb


I believe this should be fixed by simply removing the line
"Py_XDECREF(self->server_hostname);"



While fixing this, you might want to fix another issue in newPySSLSocket which
I'll describe next.

The separate problem lies here:

    if (server_hostname != NULL) {
        hostname = PyUnicode_Decode(server_hostname, strlen(server_hostname),
                                   "idna", "strict");
        if (hostname == NULL) {
            Py_DECREF(self);
            return NULL;
        }
        self->server_hostname = hostname;
    }

As we can see, PyUnicode_Decode is called. If PyUnicode_Decode fails, we call
Py_DECREF(self). However the field self->server_hostname is an uninitialized
variable at this point! So the code in PySSL_dealloc which calls
Py_XDECREF(self->server_hostname) could actually be working with an arbitrary,
uninitialized pointer.

Technically this is a separate vulnerability from the first, but I couldn't find
a way to trigger it other than low-memory situations which aren't very
reliable.

This could be fixed by initializing self->server_hostname to NULL before calling
Py_DECREF(self).

----------
messages: 272829
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Excessive Py_XDECREF in the ssl module:
type: crash
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug 16 01:00:44 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Aug 2016 05:00:44 +0000
Subject: [New-bugs-announce] [issue27774] Py_DECREF on a non-owned object in
 _sre
Message-ID: <1471323644.28.0.628758969625.issue27774@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Thomas E Hybel reports:

This vulnerability exists in the function _sre_SRE_Match_groupdict_impl which
resides in the /Modules/_sre.c file.

The problem is that the code calls Py_DECREF(key); without having done a
corresponding Py_INCREF on the key.

Here's the relevant code:

    static PyObject *
    _sre_SRE_Match_groupdict_impl(MatchObject *self, PyObject *default_value)
    {
        ...
        for (index = 0; index < PyList_GET_SIZE(keys); index++) {
            ...
            PyObject* key;
            ...
            key = PyList_GET_ITEM(keys, index);
            ...
            value = match_getslice(self, key, default_value);
            if (!value) {
                Py_DECREF(key);
                goto failed;
            }
            ...
        }
        ...
    }

We initialize the "key" variable via PyList_GET_ITEM(keys, index) which simply
takes keys->ob_item[index]. There is no increase in reference count.

If match_getslice fails, we then call Py_DECREF(key). This is simply wrong. It
will result in the key object getting freed prematurely, leading to
use-after-free scenarios.

Here's a script which reproduces this:

--- begin script ---

import _sre
import time

p = _sre.compile(
    "A",                # pattern
    0,                  # flags
    [1],                # code
    1,                  # groups
    {0xdeadbeef: 0},    # groupindex
    0                   # indexgroup
)  

m = p.match("AAAA")

for _ in range(5):
    # each call to m.groupdict decreases the refcount of 0xdeadbeef once
    try:
        m.groupdict()
    except IndexError:
        pass
       
--- end script ---

Running the script crashes python on my machine:

(gdb) r ./poc7.py
Starting program: /home/xx/Python-3.5.2/python ./poc7.py

Program received signal SIGSEGV, Segmentation fault.
0x0000000000567d71 in match_getindex (self=self at entry=0x7ffff7e2da18, index=index at entry=0x7ffff6d582c0)
    at ./Modules/_sre.c:2055
2055        if (PyLong_Check(index))
(gdb) bt
#0  0x0000000000567d71 in match_getindex (self=self at entry=0x7ffff7e2da18, index=index at entry=0x7ffff6d582c0)
    at ./Modules/_sre.c:2055
#1  0x0000000000568946 in match_getslice (self=self at entry=0x7ffff7e2da18, index=index at entry=0x7ffff6d582c0,
    def=def at entry=0x8831c0 <_Py_NoneStruct>) at ./Modules/_sre.c:2076
#2  0x0000000000568a99 in _sre_SRE_Match_groupdict_impl (self=self at entry=0x7ffff7e2da18,
    default_value=0x8831c0 <_Py_NoneStruct>) at ./Modules/_sre.c:2198
#3  0x0000000000568bc5 in _sre_SRE_Match_groupdict (self=0x7ffff7e2da18, args=<optimized out>,
    kwargs=<optimized out>) at ./Modules/clinic/_sre.c.h:518

----------
messages: 272831
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Py_DECREF on a non-owned object in _sre
type: security
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/issue27774>
_______________________________________

From report at bugs.python.org  Tue Aug 16 04:27:37 2016
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 16 Aug 2016 08:27:37 +0000
Subject: [New-bugs-announce] [issue27775] `shlex.split(None)` causes
 infinite loop
Message-ID: <1471336057.05.0.0455905912371.issue27775@psf.upfronthosting.co.za>


New submission from Ram Rachum:

I had a code that would freeze, and after debugging I realized that a bug in my code caused `shlex.split(None)` to be called, which puts Python in an infinite loop.

We probably want to do an `if not isinstance(s, ...): raise TypeError('Bla bla')` at the start of the `shlex` function, or maybe at `shlex.__init__`, or maybe both.

What bothers me though, is that it seems that shlex can accept both a string and a stream, so we should allow both of these and not others. Now, I don't know how to check whether it's a proper stream. Would `isinstance(s, io.IOBase)` be good enough? Will it catch all of the streams that people might use in `shlex.split`?

(Also, I recently proposed something related in python-ideas: https://groups.google.com/forum/#!searchin/python-ideas/stream%7Csort:relevance/python-ideas/uYlnnH52VEA/PSHkQRtaBwAJ )

----------
components: Library (Lib)
messages: 272847
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `shlex.split(None)` causes infinite loop
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 16 08:55:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2016 12:55:06 +0000
Subject: [New-bugs-announce] [issue27776] PEP 524: Make os.urandom()
 blocking on Linux
Message-ID: <1471352106.68.0.0657257565728.issue27776@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Issue to track the implementation of the PEP 524.

----------
messages: 272852
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 524: Make os.urandom() blocking on Linux
type: security
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 16 09:55:45 2016
From: report at bugs.python.org (rr-)
Date: Tue, 16 Aug 2016 13:55:45 +0000
Subject: [New-bugs-announce] [issue27777] cgi.FieldStorage can't parse
 simple body with Content-Length and no Content-Disposition
Message-ID: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za>


New submission from rr-:

Sending requests with Content-Length but without Content-Disposition headers causes following error:

Traceback (most recent call last):
  File "./test", line 19, in <module>
    form = cgi.FieldStorage(fp=env['wsgi.input'], environ=env)
  File "/usr/lib/python3.5/cgi.py", line 561, in __init__
    self.read_single()
  File "/usr/lib/python3.5/cgi.py", line 740, in read_single
    self.read_binary()
  File "/usr/lib/python3.5/cgi.py", line 762, in read_binary
    self.file.write(data)
TypeError: write() argument must be str, not bytes

I've attached a test file that reproduces the issue.

The issue is because read_single decides whether to read the content as binary or text depending on content-length - if it's > 0, it uses read_binary which assumes binary input, and rewrites this input to self.file, assuming self.file is opened in binary mode.

At the same, self.file is opened in text mode, because self._binary_file is set to False, which in turn is because there's no Content-Disposition header.

At very least, the decision whether to use binary or text should be consistent in both places (self.length >= 0 vs self._binary_file).

Related: https://bugs.python.org/issue27308
Note that unlike https://bugs.python.org/issue24764 this issue does NOT concern multipart requests.

----------
components: Library (Lib)
files: test
messages: 272856
nosy: rr-
priority: normal
severity: normal
status: open
title: cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
versions: Python 3.5
Added file: http://bugs.python.org/file44124/test

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

From report at bugs.python.org  Tue Aug 16 13:25:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2016 17:25:41 +0000
Subject: [New-bugs-announce] [issue27778] PEP 524: Add os.getrandom()
Message-ID: <1471368341.7.0.188364803995.issue27778@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds os.getrandom(): thin wrapper on the Linux getrandom() syscall.

os.getrandom() can return less bytes than requested.

The patch is incomplete: it doesn't include documentation.

I chose to not implement a loop to not loose entropy if a following call fails (ex: fail with EINTR). Rationale:
https://mail.python.org/pipermail/security-sig/2016-July/000072.html

We should also add Solaris support later.

See also #27776: "PEP 524: Make os.urandom() blocking on Linux".

----------
components: Library (Lib)
files: getrandom.patch
keywords: patch
messages: 272867
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 524: Add os.getrandom()
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file44127/getrandom.patch

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

From report at bugs.python.org  Tue Aug 16 15:28:55 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Aug 2016 19:28:55 +0000
Subject: [New-bugs-announce] [issue27779] Sync-up docstrings in C version of
 the the decimal module
Message-ID: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The pure python version of decimal has extensive docstrings with text and explanatory examples drawn directly from the decimal arithmetic specification.  Those should all be copied to the C version as well.  This will improve usability for interactive use and improve help().

I would like to leave this work for one of the new aspiring core devs (perhaps Elizabeth, Lisa, or Nofar).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 272875
nosy: docs at python, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Sync-up docstrings in C version of the the decimal module
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug 16 18:18:56 2016
From: report at bugs.python.org (geeknik)
Date: Tue, 16 Aug 2016 22:18:56 +0000
Subject: [New-bugs-announce] [issue27780] Memory leak during Python build
 (from git c3ff7e7) on Debian 8.5 x64
Message-ID: <1471385936.65.0.896010126062.issue27780@psf.upfronthosting.co.za>


New submission from geeknik:

CC=afl-clang-fast CXX=afl-clang-fast++ AFL_USE_ASAN=1 ./configure --disable-ipv6

Passes fine.

AFL_USE_ASAN=1 make

Ends with the following:

Parser/pgen ./Grammar/Grammar Include/graminit.h Python/graminit.c

=================================================================
==29392==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 12416 byte(s) in 8 object(s) allocated from:
    #0 0x4a1f2e in realloc (/root/cpython/Parser/pgen+0x4a1f2e)
    #1 0x4cfcca in PyMem_RawRealloc /root/cpython/Objects/obmalloc.c:414:12

Indirect leak of 2080 byte(s) in 3 object(s) allocated from:
    #0 0x4a1f2e in realloc (/root/cpython/Parser/pgen+0x4a1f2e)
    #1 0x4cfcca in PyMem_RawRealloc /root/cpython/Objects/obmalloc.c:414:12

Indirect leak of 898 byte(s) in 86 object(s) allocated from:
    #0 0x4a1c3b in __interceptor_malloc (/root/cpython/Parser/pgen+0x4a1c3b)
    #1 0x7fbd7abe3989 in __strdup /build/glibc-uPj9cH/glibc-2.19/string/strdup.c:42

Indirect leak of 520 byte(s) in 1 object(s) allocated from:
    #0 0x4a1c3b in __interceptor_malloc (/root/cpython/Parser/pgen+0x4a1c3b)
    #1 0x4d3fa0 in PyMem_RawMalloc /root/cpython/Objects/obmalloc.c:396:12
    #2 0x4d3fa0 in _PyObject_Alloc /root/cpython/Objects/obmalloc.c:1467

Indirect leak of 178 byte(s) in 33 object(s) allocated from:
    #0 0x4a1c3b in __interceptor_malloc (/root/cpython/Parser/pgen+0x4a1c3b)
    #1 0x4c6756 in translabel /root/cpython/Parser/grammar.c:197:28
    #2 0x4c6756 in _Py_translatelabels /root/cpython/Parser/grammar.c:141

SUMMARY: AddressSanitizer: 16092 byte(s) leaked in 131 allocation(s).
Makefile:804: recipe for target 'Include/graminit.h' failed
make: *** [Include/graminit.h] Error 23

----------
components: Build
messages: 272889
nosy: geeknik
priority: normal
severity: normal
status: open
title: Memory leak during Python build (from git c3ff7e7) on Debian 8.5 x64

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

From report at bugs.python.org  Tue Aug 16 23:49:41 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Aug 2016 03:49:41 +0000
Subject: [New-bugs-announce] [issue27781] Change sys.getfilesystemencoding()
 on Windows to UTF-8
Message-ID: <1471405781.01.0.933321108026.issue27781@psf.upfronthosting.co.za>


New submission from Steve Dower:

I've attached my first pass at a patch to change the file system encoding on Windows to UTF-8 and remove use of the *A APIs.

It would be trivial to change the encoding from UTF-8 back to CP_ACP and change the error mode if that's what we decide is better, but my vote is strongly for an encoding that never drops characters when converted from UTF-16.

Discussion is still ongoing on python-ideas, so let's argue about yes/no and utf-8/mbcs there and just discuss the patch here.

----------
assignee: steve.dower
components: Windows
files: fsencoding.diff
keywords: patch
messages: 272899
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Change sys.getfilesystemencoding() on Windows to UTF-8
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44130/fsencoding.diff

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

From report at bugs.python.org  Wed Aug 17 02:04:37 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 17 Aug 2016 06:04:37 +0000
Subject: [New-bugs-announce] [issue27782] Multi-phase extension module
 initialization, inconsistent exceptions and conflicts between code and PEP
Message-ID: <1471413877.95.0.607516843714.issue27782@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

>From doc [1], when create_module returns a non-module instance,  m_methods, m_traverse, m_clear, m_free must be NULL. But actually in the codes, only m_traverse, m_clear, m_free are checked and emitting consistent errors. If m_methods is NULL, it will fail in [2] and emit an inconsistent misleading argument error. And what's more confusing is, in [3], it says "regardless of type, the module's functions are initialized from m_methods, if any", which I think conflicts with the codes and doc.

[1] https://docs.python.org/3.6/c-api/module.html#c.Py_mod_create
[2] https://hg.python.org/cpython/file/tip/Objects/moduleobject.c#l300
[3] https://www.python.org/dev/peps/pep-0489/#post-creation-steps

----------
components: Interpreter Core
messages: 272903
nosy: encukou, ncoghlan, xiang.zhang
priority: normal
severity: normal
status: open
title: Multi-phase extension module initialization, inconsistent exceptions and conflicts between code and PEP
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Aug 17 02:32:24 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 17 Aug 2016 06:32:24 +0000
Subject: [New-bugs-announce] [issue27783] potential use of unitialized
 memory in operator.methodcaller
Message-ID: <1471415544.41.0.8047190552.issue27783@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Thomas E Hybel reports:

This vulnerability exists in /Modules/_operator.c in the function
methodcaller_new.

Here is the problematic code:

    mc = PyObject_GC_New(methodcallerobject, &methodcaller_type);
    if (mc == NULL)
        return NULL;
   
    newargs = PyTuple_GetSlice(args, 1, PyTuple_GET_SIZE(args));
    if (newargs == NULL) {
        Py_DECREF(mc);
        return NULL;
    }

We first allocate an "mc" object. Then we call PyTuple_GetSlice. If that fails,
e.g. because we're out of memory, then we call Py_DECREF(mc). But mc's variables
have not been initialized yet. methodcaller_dealloc will therefore free several
arbitrary pointers.

This could be fixed by setting mc's member variables to NULL right after
allocating it.

Proof-of-concept script:

--- begin script ---

import operator

args = ("AAAA",)*0x10000000
ag = operator.methodcaller(*args)

--- end script ---

(Note that this PoC only works if the machine runs out of memory at the right
time; you may have to experiment with the size of "args." This was tested on a
32-bit box, therefore it had a small address space.)

Here's the crash and backtrace:

(gdb) r ../poc10.py
Starting program: /home/ubuntu32/python3/Python-3.5.2/python ../poc10.py

Program received signal SIGSEGV, Segmentation fault.
0x081d4255 in methodcaller_dealloc (mc=mc at entry=0xb7c31b94) at ./Modules/_operator.c:976
976        Py_XDECREF(mc->name);
(gdb) p mc->name
$3 = (PyObject *) 0xcbcbcbcb
(gdb) bt
#0  0x081d4255 in methodcaller_dealloc (mc=mc at entry=0xb7c31b94) at ./Modules/_operator.c:976
#1  0x080e4bff in _Py_Dealloc (op=op at entry=0xb7c31b94) at Objects/object.c:1786
#2  0x081d361a in methodcaller_new (type=0x82f0200 <methodcaller_type>, args=0x37c2d024, kwds=0x0) at ./Modules/_operator.c:956
...

----------
components: Library (Lib)
messages: 272904
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: potential use of unitialized memory in operator.methodcaller
type: crash
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/issue27783>
_______________________________________

From report at bugs.python.org  Wed Aug 17 04:23:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2016 08:23:42 +0000
Subject: [New-bugs-announce] [issue27784] Random failure of test_TCPServer()
 of test.test_socketserver.SocketServerTest and test_handle_accept() of
 test.test_asyncore.TestAPI_UseIPv6Select on FreeBSD buildbots
Message-ID: <1471422222.08.0.731040607027.issue27784@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

test_handle_accept (test.test_asyncore.TestAPI_UseIPv6Select) ... ERROR

======================================================================
ERROR: test_handle_accept (test.test_asyncore.TestAPI_UseIPv6Select)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_asyncore.py", line 500, in tearDown
    asyncore.close_all()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncore.py", line 561, in close_all
    x.close()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncore.py", line 397, in close
    self.socket.close()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socket.py", line 407, in close
    self._real_close()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socket.py", line 401, in _real_close
    _ss.close(self)
ConnectionResetError: [Errno 54] Connection reset by peer

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


0:15:27 [319/402/4] test_socketserver failed -- running: test_tokenize (190 sec), test_datetime (279 sec), test_tools (194 sec)
(...)
test_TCPServer (test.test_socketserver.SocketServerTest) ... creating server
ADDR = ('127.0.0.1', 42875)
CLASS = <class 'socketserver.TCPServer'>
server running
test client 0
test client 1
Exception in thread <class 'socketserver.TCPServer'> serving:
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socketserver.py", line 238, in serve_forever
    self._handle_request_noblock()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socketserver.py", line 319, in _handle_request_noblock
    self.handle_error(request, client_address)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socketserver.py", line 317, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socketserver.py", line 349, in process_request
    self.shutdown_request(request)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socketserver.py", line 510, in shutdown_request
    self.close_request(request)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socketserver.py", line 514, in close_request
    request.close()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socket.py", line 407, in close
    self._real_close()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/socket.py", line 401, in _real_close
    _ss.close(self)
ConnectionResetError: [Errno 54] Connection reset by peer

ERROR
/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py:628: ResourceWarning: unclosed <socket.socket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 42877), raddr=('127.0.0.1', 42875)>
  outcome.errors.clear()
/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py:628: ResourceWarning: unclosed <socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 42875)>
  outcome.errors.clear()
(...)
======================================================================
ERROR: test_TCPServer (test.test_socketserver.SocketServerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_socketserver.py", line 175, in test_TCPServer
    self.stream_examine)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1956, in decorator
    return func(*args)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_socketserver.py", line 141, in run_server
    testfunc(svrcls.address_family, addr)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_socketserver.py", line 153, in stream_examine
    buf = data = receive(s, 100)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_socketserver.py", line 46, in receive
    raise RuntimeError("timed out on %r" % (sock,))
RuntimeError: timed out on <socket.socket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 42877), raddr=('127.0.0.1', 42875)>

----------------------------------------------------------------------
Ran 25 tests in 25.825s

----------
messages: 272910
nosy: haypo
priority: normal
severity: normal
status: open
title: Random failure of test_TCPServer() of test.test_socketserver.SocketServerTest and test_handle_accept() of test.test_asyncore.TestAPI_UseIPv6Select on FreeBSD buildbots

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

From report at bugs.python.org  Wed Aug 17 05:08:41 2016
From: report at bugs.python.org (squish_user)
Date: Wed, 17 Aug 2016 09:08:41 +0000
Subject: [New-bugs-announce] [issue27785] Module platform: Versions of
 Windows
Message-ID: <1471424921.88.0.870177840736.issue27785@psf.upfronthosting.co.za>


New submission from squish_user:

I use the module 'platform' to get information on the system my script is executed. I have 4 different operating systems in use: Windows 7, Windows 8, Windows 8.1 and Windows 10.

By using the module platform version 1.0.3 I get the following results by
platform.version().startswith:
Windows 7: 6.1
Windows 8: 6.2
Windows 8.1: 6.3
Windows 10: 10.0

I upgraded the module platform to version 1.0.7 (delivered with the squish-version squish-6.0.3-qt56x-win32-msvc12)

Now I get the following results:
platform.version()
Windows 7: 6.1.7601
Windows 8: 6.2.9200
Windows 8.1: 6.2.9200
Windows 10: 6.2.9200

So there is no longer a difference between Windows 8 and Windows 10.

----------
components: Library (Lib)
messages: 272915
nosy: lemburg, squish_user
priority: normal
severity: normal
status: open
title: Module platform: Versions of Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 17 09:17:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2016 13:17:12 +0000
Subject: [New-bugs-announce] [issue27786] longobject.c: simplify x_sub(),
 inline _PyLong_Negate()
Message-ID: <1471439832.76.0.773919988568.issue27786@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When reading the issue #27725, I saw that x_sub() of Objects/longobject.c is too careful just to change the sign of the newly created number: z cannot be shared at the end of the function, before z is normalized.

Attached patch simplifies the code.

See also the issue #27073, another similar simplification.

----------
files: x_sub.patch
keywords: patch
messages: 272933
nosy: haypo, mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: longobject.c: simplify x_sub(), inline _PyLong_Negate()
versions: Python 3.6
Added file: http://bugs.python.org/file44132/x_sub.patch

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

From report at bugs.python.org  Wed Aug 17 10:33:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 17 Aug 2016 14:33:36 +0000
Subject: [New-bugs-announce] [issue27787] Avoid test_main() in test_httplib;
 gc.collect() dangling threads
Message-ID: <1471444416.58.0.403066422395.issue27787@psf.upfronthosting.co.za>


New submission from Martin Panter:

In Issue 12319, there are many iterations of a patch that adds a new TestCase subclass to Lib/test/test_httplib.py. However it never got run by the main regrtest infrastructure, because nobody remembered to add the class to the list of test classes. So I want to remove test_main(). It seems this would let the classes be automatically discovered (like normal unittest usage).

I understand @reap_threads is to avoid background threads continuing between tests (especially when a test fails). I improved the cleanup of the background thread in one test. There are three other test methods using test.ssl_servers.make_https_server(), which also runs a background thread, but that already seems to clean itself up properly, via case.addCleanup(server.join).

I found that the test infrastructure randomly complained about dangling threads without @reap_threads. It uses a set of weak references to thread objects. The solution seems to be to call gc.collect() before checking. This is what @reap_threads does, so maybe my patch would eliminate the need for @reap_threads in other test files as well. In fact, if everybody called join() on their threads, we may be able to eliminate @reap_threads altogether.

----------
components: Tests
files: httplib-tests.patch
keywords: patch
messages: 272954
nosy: martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid test_main() in test_httplib; gc.collect() dangling threads
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44134/httplib-tests.patch

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

From report at bugs.python.org  Wed Aug 17 12:10:58 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 17 Aug 2016 16:10:58 +0000
Subject: [New-bugs-announce] [issue27788] platform module's version number
 doesn't match its docstring
Message-ID: <1471450258.8.0.170997912559.issue27788@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Not sure if it's worth keeping the version number around, but ATM the module has __version__ set to 1.0.7 while the docstring mentions a 1.0.8.

----------
components: Library (Lib)
messages: 272964
nosy: brett.cannon, lemburg
priority: normal
severity: normal
status: open
title: platform module's version number doesn't match its docstring
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 17 17:15:06 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 17 Aug 2016 21:15:06 +0000
Subject: [New-bugs-announce] [issue27789] test_asyncio Resource Warnings
Message-ID: <1471468506.77.0.2823677848.issue27789@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

3.6, Windows 10, debug build. The following appeared before and after pulling and rebuilding today. I am reporting as per Victor's request on pydev list.

0:00:22 [ 52/402] test_asyncio passed
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x03B57658>
  source=self)
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x03B57E70>
  source=self)
F:\Python\dev\36\lib\asyncio\sslproto.py:329: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x03AA9038>
  source=self)

----------
components: Tests, asyncio
messages: 272986
nosy: giampaolo.rodola, gvanrossum, haypo, terry.reedy, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: test_asyncio Resource Warnings
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 17 17:21:21 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 17 Aug 2016 21:21:21 +0000
Subject: [New-bugs-announce] [issue27790] test_distutils spews linker
 messages on Windows
Message-ID: <1471468881.84.0.977496152734.issue27790@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

3.6, Win10, VS recently reinstalled to 'Update 3'.  I believe these messages are somewhat new.

0:01:00 [111/402] test_distutils failed (env changed)
xxmodule.c
   Creating library C:\Users\Terry\AppData\Local\Temp\tmpbjffnmc3\Debug\Users\Terry\AppData\Local\Temp\tmpbjffnmc3\xx_d.cp36-win32.lib and object C:\Users\Terry\AppData\Local\Temp\tmpbjffnmc3\Debug\Users\Terry\AppData\Local\Temp\tmpbjffnmc3\xx_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
foo.c
   Creating library C:\Users\Terry\AppData\Local\Temp\tmp7302jrpo\tempt\Users\Terry\AppData\Local\Temp\tmp9132twos\foo_d.cp36-win32.lib and object C:\Users\Terry\AppData\Local\Temp\tmp7302jrpo\tempt\Users\Terry\AppData\Local\Temp\tmp9132twos\foo_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
foo.c
   Creating library C:\Users\Terry\AppData\Local\Temp\tmp7302jrpo\tempt\Users\Terry\AppData\Local\Temp\tmp9132twos\foo_d.cp36-win32.lib and object C:\Users\Terry\AppData\Local\Temp\tmp7302jrpo\tempt\Users\Terry\AppData\Local\Temp\tmp9132twos\foo_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
xxmodule.c
   Creating library C:\Users\Terry\AppData\Local\Temp\tmp9hq4ci8e\Debug\Users\Terry\AppData\Local\Temp\tmp9hq4ci8e\xx_d.cp36-win32.lib and object C:\Users\Terry\AppData\Local\Temp\tmp9hq4ci8e\Debug\Users\Terry\AppData\Local\Temp\tmp9hq4ci8e\xx_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
foo.c
   Creating library C:\Users\Terry\AppData\Local\Temp\tmp3qv0ulce\tempt\Users\Terry\AppData\Local\Temp\tmph1jy_aqh\foo_d.cp36-win32.lib and object C:\Users\Terry\AppData\Local\Temp\tmp3qv0ulce\tempt\Users\Terry\AppData\Local\Temp\tmph1jy_aqh\foo_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
foo.c
   Creating library C:\Users\Terry\AppData\Local\Temp\tmp3qv0ulce\tempt\Users\Terry\AppData\Local\Temp\tmph1jy_aqh\foo_d.cp36-win32.lib and object C:\Users\Terry\AppData\Local\Temp\tmp3qv0ulce\tempt\Users\Terry\AppData\Local\Temp\tmph1jy_aqh\foo_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance
xxmodule.c
   Creating library build\temp.win32-3.6-pydebug\Debug\xx_d.cp36-win32.lib and object build\temp.win32-3.6-pydebug\Debug\xx_d.cp36-win32.exp
LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance

F:\Python\dev\36\build\test_python_3596>exit 1

F:\Python\dev\36\build\test_python_3596>exit 0
Warning -- files was modified by test_distutils

----------
components: Distutils, Tests, Windows
messages: 272991
nosy: dstufft, eric.araujo, haypo, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_distutils spews linker messages on Windows

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

From report at bugs.python.org  Wed Aug 17 17:42:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2016 21:42:51 +0000
Subject: [New-bugs-announce] [issue27791] test_threading:
 test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter:
 not the last thread"
Message-ID: <1471470171.51.0.873764356804.issue27791@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

0:00:46 [ 41/402] test_threading crashed
Fatal Python error: Py_EndInterpreter: not the last thread

Current thread 0x0000000802006400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 2445 in run_in_subinterp
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 877 in test_threads_join_2
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 600 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 648 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1810 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1844 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 179 in test_runner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 180 in runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 133 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest_mp.py", line 71 in run_tests_slave
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 472 in _main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 465 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 527 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 46 in _main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 50 in <module>
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 184 in _run_module_as_main
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 184, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 2, in <module>
    main()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 527, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 465, in main
    self._main(tests, kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 485, in _main
    self.run_tests()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 413, in run_tests
    run_tests_multiprocess(self)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest_mp.py", line 221, in run_tests_multiprocess
    raise Exception(msg)
Exception: Child error on test_threading: Exit code -6
*** Error code 1

----------
components: Tests
keywords: buildbot
messages: 272995
nosy: haypo, koobs
priority: normal
severity: normal
status: open
title: test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread"
versions: Python 3.6

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

From report at bugs.python.org  Thu Aug 18 08:09:44 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Aug 2016 12:09:44 +0000
Subject: [New-bugs-announce] [issue27792] bool % int has inconsistent return
 type.
Message-ID: <1471522184.6.0.180727658767.issue27792@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Seen on reddit [1]: 

>>> True % 1
0
>>> True % 2
True

I believe that we should be returning an int in both these cases; this looks like a longobject.c fast path gone wrong.

[1] https://www.reddit.com/r/learnpython/comments/4y5bh1/can_someone_explain_why_true_1_0_but_true_2_true/

----------
messages: 273020
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: bool % int has inconsistent return type.
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Aug 18 08:27:26 2016
From: report at bugs.python.org (avraf)
Date: Thu, 18 Aug 2016 12:27:26 +0000
Subject: [New-bugs-announce] [issue27793] Double underscore variables in
 module are mangled when used in class
Message-ID: <1471523246.01.0.475585276103.issue27793@psf.upfronthosting.co.za>


New submission from avraf:

import re

__no_spaces_pattern           = r'\S+'
__match_chars_until_space     = re.compile(__no_spaces_pattern).match
__match_chars_from_last_space = re.compile(__no_spaces_pattern + '$').match

def __get_chars_until_space(name):
    return __match_chars_until_space(name).group()

def __get_chars_from_last_space(name):
    return __match_chars_from_last_space(name).group()

__random_unique_five_digit_number = 12345
__random_id_generator = lambda: __random_unique_five_digit_number


class Person(object):
    def __init__(self, name):
        self.name = name
        
    @property
    def first_name(self):
        return __get_chars_until_space(self.name)
    
    @property
    def last_name(self):
        return __get_chars_from_last_space(self.name)


I get this error when importing and running in another file.
It seems python mangles every occurrence of double underscores seen in a class. Even if the double underscores variable appears in the body of a method and belongs to the module.

This behavior is very unexpected.

Traceback (most recent call last):
  File "beef.py", line 5, in <module>
    print bob.first_name
  File "/home/dude/style/static_private_methods/real_static_private_functions.py", line 22, in first_name
    return __get_chars_until_space(self.name)
NameError: global name '_Person__get_chars_until_space' is not defined

----------
messages: 273023
nosy: avraf
priority: normal
severity: normal
status: open
title: Double underscore variables in module are mangled when used in class
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 18 09:57:19 2016
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 18 Aug 2016 13:57:19 +0000
Subject: [New-bugs-announce] [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
Message-ID: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>


New submission from Antti Haapala:

Today we had an internal server error in production. I went to see the sentry logs for the error, and was dismayed: the error was `AttributeError: can't set attribute`, and the faulting line was `setattr(obj, attr, value)` that happens in a for-loop that uses computed properties coming from who knows.

Well, I quickly ruled out that it was because the code was trying to set a value to a read-only property descriptor, the only problem was to find out *which of all these read-only properties* was it trying to set:

Python 3.6.0a3+ (default, Aug 11 2016, 11:45:31) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
...     @property
...     def bar(self): pass
... 
>>> setattr(Foo(), 'bar', 42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't set attribute

Could we change this for Python 3.6 so that the message for this could include the name of the property just like `AttributeError: has no attribute 'baz'` does?

----------
messages: 273027
nosy: ztane
priority: normal
severity: normal
status: open
title: setattr a read-only property; the AttributeError should show the attribute that failed
type: enhancement

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

From report at bugs.python.org  Thu Aug 18 10:32:49 2016
From: report at bugs.python.org (Kaeptm Blaubaer)
Date: Thu, 18 Aug 2016 14:32:49 +0000
Subject: [New-bugs-announce] [issue27795] Cygwin compile errors
Message-ID: <1471530769.75.0.763200127256.issue27795@psf.upfronthosting.co.za>


New submission from Kaeptm Blaubaer:

If I try to compile Python 3.5 with Cygwin, I get a lot of errors.

----------
components: Build, Windows
messages: 273031
nosy: Kaeptm Blaubaer, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cygwin compile errors
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug 18 15:38:12 2016
From: report at bugs.python.org (Brendan Moloney)
Date: Thu, 18 Aug 2016 19:38:12 +0000
Subject: [New-bugs-announce] [issue27796] Expose DirEntry constructor
Message-ID: <1471549092.38.0.988541483557.issue27796@psf.upfronthosting.co.za>


New submission from Brendan Moloney:

As per a discussion on python-ideas [1], the consensus is that we should allow users to create a DirEntry object themselves. This would just take a path and call stat on it and cache the result of that stat call.

Nick Coghlan mentioned possibly allowing a pre-existing stat result to optionally be passed into the constructor [2].

[1] https://mail.python.org/pipermail/python-ideas/2016-August/041716.html
[2] https://mail.python.org/pipermail/python-ideas/2016-August/041713.html

----------
messages: 273063
nosy: moloney
priority: normal
severity: normal
status: open
title: Expose DirEntry constructor
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Aug 19 03:38:02 2016
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 19 Aug 2016 07:38:02 +0000
Subject: [New-bugs-announce] [issue27797] ASCII file with UNIX line
 conventions and enough lines throws SyntaxError when ASCII-compatible codec
 is declared
Message-ID: <1471592282.81.0.915425823239.issue27797@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

To reproduce, create an ASCII file with > io.DEFAULT_BUFFER_SIZE bytes (can be blank lines) and *UNIX line endings*, with the first two lines reading:

  #!/usr/bin/env python
  # -*- coding: cp1252 -*-

Try to run this as a script on Windows:

    C:\Python35\python.exe encoding-problem-cp1252.py
     File "encoding-problem-cp1252.py", line 2
    SyntaxError: encoding problem: cp1252

Converting the file to use CRLF (Windows) line endings makes the problem go away.

This appears to be a fallout from issue #20731.

Demo file that reproduces this issue at 710 bytes: https://github.com/techtonik/testbin/raw/fbb8aec3650b45f690c4febfd621fe5d6892b14a/python/encoding-problem-cp1252.py

First reported by anatoly techtonik at https://stackoverflow.com/questions/39032416/python-3-5-syntaxerror-encoding-prob-em-cp1252

----------
components: Interpreter Core, Windows
messages: 273087
nosy: mjpieters, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ASCII file with UNIX line conventions and enough lines throws SyntaxError when ASCII-compatible codec is declared
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug 19 05:54:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Aug 2016 09:54:06 +0000
Subject: [New-bugs-announce] [issue27798] test_sysconfig: test_srcdir()
 fails on "x86 Gentoo Installed with X 3.x" buildbot
Message-ID: <1471600446.77.0.0232561146513.issue27798@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%203.x/builds/879/steps/test/logs/stdio

======================================================================
FAIL: test_srcdir (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.6/test/test_sysconfig.py", line 346, in test_srcdir
    self.assertTrue(os.path.isdir(srcdir), srcdir)
AssertionError: False is not true : /buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.6/config-3.6m

======================================================================
FAIL: test_get_makefile_filename (test.test_sysconfig.MakefileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.6/test/test_sysconfig.py", line 414, in test_get_makefile_filename
    self.assertTrue(os.path.isfile(makefile), makefile)
AssertionError: False is not true : /buildbot/buildarea/3.x.ware-gentoo-x86.installed/build/target/lib/python3.6/config-3.6m/Makefile

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

----------
components: Distutils, Tests
keywords: buildbot
messages: 273104
nosy: dstufft, eric.araujo, haypo
priority: normal
severity: normal
status: open
title: test_sysconfig: test_srcdir() fails on "x86 Gentoo Installed with X 3.x" buildbot
versions: Python 3.6

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

From report at bugs.python.org  Fri Aug 19 07:52:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Aug 2016 11:52:00 +0000
Subject: [New-bugs-announce] [issue27799] Fix base64-codec and bz2-codec
 incremental decoders
Message-ID: <1471607520.64.0.769874977976.issue27799@psf.upfronthosting.co.za>


New submission from Martin Panter:

This is split off a large patch I posted at Issue 20132. My new patch here fixes the following two flaws.

1. There is special code in the bz2 decoder that returns an empty text str object at EOF, even though bz2-codec is a bytes-to-bytes codec:
>>> import codecs
>>> decoder = codecs.getincrementaldecoder("bz2")()
>>> decoder.decode(codecs.encode(b"data", "bz2"))
b'data'
>>> decoder.decode(b"", final=True)  # Should return bytes object
''

2. The base64 decoder does not handle partial sets of four codes, because it treats each input chunk as a stand-alone base64 encoding:
>>> tuple(codecs.iterdecode((b"AA", b"AA\r\n"), "base64"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/codecs.py", line 1039, in iterdecode
    output = decoder.decode(input)
  File "/usr/lib/python3.5/encodings/base64_codec.py", line 35, in decode
    return base64.decodebytes(input)
  File "/usr/lib/python3.5/base64.py", line 554, in decodebytes
    return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

----------
components: Library (Lib)
files: base64-decoder.patch
keywords: patch
messages: 273106
nosy: martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Fix base64-codec and bz2-codec incremental decoders
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44149/base64-decoder.patch

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

From report at bugs.python.org  Fri Aug 19 08:07:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 19 Aug 2016 12:07:00 +0000
Subject: [New-bugs-announce] [issue27800] Regular expressions with multiple
 repeat codes
Message-ID: <1471608420.14.0.872966965651.issue27800@psf.upfronthosting.co.za>


New submission from Martin Panter:

In the documentation for the ?re? module, it says repetition codes like {4} and ?*? operate on the preceding regular expression. But even though ?a{4}? is a valid expression, the obvious way to apply a ?*? repetition to it fails:

>>> re.compile("a{4}*")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/proj/python/cpython/Lib/re.py", line 223, in compile
    return _compile(pattern, flags)
  File "/home/proj/python/cpython/Lib/re.py", line 292, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/home/proj/python/cpython/Lib/sre_compile.py", line 555, in compile
    p = sre_parse.parse(p, flags)
  File "/home/proj/python/cpython/Lib/sre_parse.py", line 792, in parse
    p = _parse_sub(source, pattern, 0)
  File "/home/proj/python/cpython/Lib/sre_parse.py", line 406, in _parse_sub
    itemsappend(_parse(source, state))
  File "/home/proj/python/cpython/Lib/sre_parse.py", line 610, in _parse
    source.tell() - here + len(this))
sre_constants.error: multiple repeat at position 4

As a workaround, I found I can wrap the inner repetition in (?:. . .):

>>> re.compile("(?:a{4})*")
re.compile('(?:a{4})*')

The problems with the workaround are (a) it is far from obvious, and (b) it adds more complicated syntax. Either this limitation should be documented, or if there is no good reason for it, it should be lifted. It is not clear if my workaround is entirely valid, or if I just found a way to bypass some sanity check.

My original use case was scanning a base-64 encoding for Issue 27799:

# Without the second level of brackets, this raises a "multiple repeat" error
chunk_re = br'(?: (?: [^A-Za-z0-9+/=]* [A-Za-z0-9+/=] ){4} )*'

----------
components: Regular Expressions
messages: 273107
nosy: ezio.melotti, martin.panter, mrabarnett
priority: normal
severity: normal
status: open
title: Regular expressions with multiple repeat codes
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Aug 19 08:39:39 2016
From: report at bugs.python.org (Dwayne Crooks)
Date: Fri, 19 Aug 2016 12:39:39 +0000
Subject: [New-bugs-announce] [issue27801] test_update_lines_cols fails from
 test.test_curses.MiscTests fails on Ubuntu 14.04 LTS
Message-ID: <1471610379.95.0.850112382064.issue27801@psf.upfronthosting.co.za>


New submission from Dwayne Crooks:

I was installing Python 3.5.2 from source on a Ubuntu 14.04 LTS virtual machine (it uses https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20160816.0.0).

This is part of the result of running: ./python -m test -u curses -v test_curses

======================================================================
ERROR: test_update_lines_cols (test.test_curses.MiscTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/Python-3.5.2/Lib/test/test_curses.py", line 397, in test_update_lines_cols
    curses.update_lines_cols()
AttributeError: module 'curses' has no attribute 'update_lines_cols'

----------------------------------------------------------------------
Ran 20 tests in 0.237s

FAILED (errors=1, skipped=4)

----------
components: Tests
messages: 273113
nosy: dwaynecrooks
priority: normal
severity: normal
status: open
title: test_update_lines_cols fails from test.test_curses.MiscTests fails on Ubuntu 14.04 LTS
versions: Python 3.5

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

From report at bugs.python.org  Fri Aug 19 08:42:24 2016
From: report at bugs.python.org (Neil Girdhar)
Date: Fri, 19 Aug 2016 12:42:24 +0000
Subject: [New-bugs-announce] [issue27802] Add __eq__ and __ne__ to
 collections.abc.Sequence.
Message-ID: <1471610544.87.0.654898838156.issue27802@psf.upfronthosting.co.za>


New submission from Neil Girdhar:

Both Mapping and Set provide __eq__ and __ne__.  Why not have Sequence do the same?

----------
messages: 273114
nosy: neil.g
priority: normal
severity: normal
status: open
title: Add __eq__ and __ne__ to collections.abc.Sequence.

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

From report at bugs.python.org  Fri Aug 19 14:11:37 2016
From: report at bugs.python.org (Erwan Le Pape)
Date: Fri, 19 Aug 2016 18:11:37 +0000
Subject: [New-bugs-announce] [issue27803] ctypes automatic byref failing on
 custom classes attributes
Message-ID: <1471630297.02.0.563258836934.issue27803@psf.upfronthosting.co.za>


New submission from Erwan Le Pape:

When using a custom class to store a ctype value, passing that class as a function argument explicitly declared to be a pointer type fails to pass the _as_parameter_ class attribute as a pointer and instead raises a TypeError.

For example:
>>> from ctypes import *
>>> from ctypes.wintypes import *
>>>
>>> class CustomPHKEY(object):
...     def __init__(self, value):
...             self._as_parameter_ = HKEY(value)
...
>>>
>>> function = windll.function
>>> function.argtypes = [POINTER(HKEY)]
>>> function.restype = LONG
>>> result = CustomPHKEY(0)
>>> function(result)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected LP_c_void_p instance instead of c_void_p

Shouldn't ctypes apply the required byref() conversion automatically? Or is this behavior normal and automatic byref() only concerns native ctypes types?

I only flagged Python 3.5 and Python 2.7 since they are the only ones I explicitly tested this on but I suspect other versions are affected.

----------
components: ctypes
messages: 273149
nosy: amaury.forgeotdarc, belopolsky, lepaperwan, meador.inge
priority: normal
severity: normal
status: open
title: ctypes automatic byref failing on custom classes attributes
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Aug 19 15:53:26 2016
From: report at bugs.python.org (=?utf-8?q?Gr=C3=A9goire_Cutzach?=)
Date: Fri, 19 Aug 2016 19:53:26 +0000
Subject: [New-bugs-announce] [issue27804] IDLE 3.5.2 crashes when typing ^
 on keyboard
Message-ID: <1471636406.37.0.977189718518.issue27804@psf.upfronthosting.co.za>


New submission from Gr?goire Cutzach:

When typing ^ (CIRCUMFLEX ACCENT Unicode: U+005E, UTF-8: 5E) on azerty Keyboard, IDLE quits/crashes.
Encountered on a mac running OS X 10.11.6

----------
assignee: terry.reedy
components: IDLE
messages: 273155
nosy: Gr?goire Cutzach, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE 3.5.2 crashes when typing ^ on keyboard
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Fri Aug 19 16:11:12 2016
From: report at bugs.python.org (Shane Hathaway)
Date: Fri, 19 Aug 2016 20:11:12 +0000
Subject: [New-bugs-announce] [issue27805] In Python 3, open('/dev/stdout',
 'a') raises OSError with errno=ESPIPE
Message-ID: <1471637472.92.0.246311076418.issue27805@psf.upfronthosting.co.za>


New submission from Shane Hathaway:

With Python 2, the following call worked:

open('/dev/stdout', 'a')

Users of Supervisor have been depending on that for a long time. 

With Python 3.5, this is what happens:

>>> open('/dev/stdout', 'a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 29] Illegal seek

Presumably, this happens because Python 3 opens the file in 'w' mode and seeks to the end, while Python 2 passed the 'a' flag directly to the underlying C library; the underlying library is apparently smart enough to treat 'a' and 'w' identically when opening character device files and FIFOs.

It's a nasty little surprise for those upgrading from Python 2.

----------
components: IO
messages: 273158
nosy: hathawsh
priority: normal
severity: normal
status: open
title: In Python 3, open('/dev/stdout', 'a') raises OSError with errno=ESPIPE
versions: Python 3.5

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

From report at bugs.python.org  Fri Aug 19 17:58:19 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Aug 2016 21:58:19 +0000
Subject: [New-bugs-announce] [issue27806] 2.7 32-bit builds fail on future
 releases of OS X due to dependency on deleted header file
Message-ID: <1471643899.93.0.569141042934.issue27806@psf.upfronthosting.co.za>


New submission from Ned Deily:

Attempts to build Python 2.7 using OS X/macOS public beta versions of the latest command-line tools can fail due to the removal of the system header file for QuickTime/QuickTime.h, one of the long deprecated Carbon APIs.  Currently, Python only attempts to build modules dependent on this file when building for 32-bit archs so this problem typically only affects builds with --with-universal-archs= configure options like "intel" or "intel-32".  It would be nice to preserve the ability to make use of QuickTime on older systems where the header file is still available.  Since the old Python mac modules don't exist in Python 3.x, this is only a 2.7 issue.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 273159
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: 2.7 32-bit builds fail on future releases of OS X due to dependency on deleted header file
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 19 18:05:23 2016
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 19 Aug 2016 22:05:23 +0000
Subject: [New-bugs-announce] [issue27807] Prevent site-packages .pth files
 from causing test_site failure
Message-ID: <1471644323.86.0.0589241929234.issue27807@psf.upfronthosting.co.za>


New submission from Chris Angelico:

Having matplotlib installed globally causes test_site to fail, due to the .pth file importing types. The point of the test is to monitor startup dependencies (and thus time) for the core interpreter and standard library, not third-party libraries, so having a test failure due to a .pth is not overly useful.

Solution suggested by Steve Dower: hack out all .pth handling during this one test, leaving everything else unchanged.

----------
components: Tests
messages: 273160
nosy: Rosuav
priority: normal
severity: normal
status: open
title: Prevent site-packages .pth files from causing test_site failure
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Aug 19 19:59:55 2016
From: report at bugs.python.org (Casey Lucas)
Date: Fri, 19 Aug 2016 23:59:55 +0000
Subject: [New-bugs-announce] [issue27808] os.waitpid does not return (0,
 0) when child has not exited (FreeBSD)
Message-ID: <1471651195.23.0.67845273163.issue27808@psf.upfronthosting.co.za>


New submission from Casey Lucas:

I'm not sure if this a Python issue or a FreeBSD issue but the return value from os.waitpid is not reliably (0,0) on FreeBSD when the WNOHANG is used and the child process has not yet exited.  Python docs say that the return value will be (0,0) but this is not the case.  I believe it is because the FreeBSD implementation of waitpid writes an uninitialized value to the status field when a child process is not available.  See also: http://stackoverflow.com/questions/38984449/is-status-value-from-os-waitpid-unreliable-when-os-wnohang-is-used-under-freebsd

Maybe this is just a documentation issue?  Or does the C code in the Python library need to handle this case?

----------
components: FreeBSD, Library (Lib)
files: waitpid_test.py
messages: 273167
nosy: Casey Lucas, koobs
priority: normal
severity: normal
status: open
title: os.waitpid does not return (0,0) when child has not exited (FreeBSD)
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file44161/waitpid_test.py

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

From report at bugs.python.org  Fri Aug 19 20:21:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2016 00:21:25 +0000
Subject: [New-bugs-announce] [issue27809] _PyObject_FastCall(): add support
 for keyword arguments
Message-ID: <1471652485.87.0.888349728997.issue27809@psf.upfronthosting.co.za>


New submission from STINNER Victor:

_PyObject_FastCall() (added in the issue #27128) already supports keyword arguments for C functions, but not Python functions.

Attached patch adds support for keyword arguments in _PyFunction_FastCall(), to allow to use _PyObject_FastCall() in more cases.

Examples of functions that can be modified to _PyObject_FastCall() with this change:

* builtin_sorted()
* builtin___build_class__()
* init_subclass()
* PyEval_CallObjectWithKeywords(func, NULL, kwargs)
* methoddescr_call(), classmethoddescr_call(), wrapperdescr_call()
* PyFile_GetLine()

Moreover, supporting keywords is required for another more important step: add a new METH_CALL calling convention for C functions.

----------
files: fastcall_kwargs.patch
keywords: patch
messages: 273170
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: _PyObject_FastCall(): add support for keyword arguments
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44162/fastcall_kwargs.patch

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

From report at bugs.python.org  Fri Aug 19 20:32:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2016 00:32:46 +0000
Subject: [New-bugs-announce] [issue27810] Add METH_FASTCALL: new calling
 convention for C functions
Message-ID: <1471653166.26.0.257085519078.issue27810@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #27128 added _PyObject_FastCall() to avoid the creation of temporary tuples when calling functions.

I propose to add a new METH_FASTCALL calling convention. The example using METH_VARARGS | METH_KEYWORDS:
   PyObject* func(DirEntry *self, PyObject *args, PyObject *kwargs)
becomes:
   PyObject* func(DirEntry *self, PyObject **args, int nargs, PyObject *kwargs)

Using METH_VARARGS, args is a Python tuple. Using METH_FASTCALL, args is a C array of PyObject*, and there is a second nargs parameter.

Later, Argument Clinic will be modified to *generate* code using the new METH_FASTCALL calling convention. Code written with Argument Clinic will only need to be updated by Argument Clinic to get the new faster calling convention (avoid the creation of a temporary tuple for positional arguments).

This issue depends on the issue #27809 "_PyObject_FastCall(): add support for keyword arguments". I will wait until this dependency is implemented, before working on the implementation of this part.

For a full implementation, see my first attempt in the issue #26814. I will extract the code from this branch to write a new patch.

----------
messages: 273173
nosy: haypo
priority: normal
severity: normal
status: open
title: Add METH_FASTCALL: new calling convention for C functions
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Aug 20 05:35:05 2016
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 20 Aug 2016 09:35:05 +0000
Subject: [New-bugs-announce] [issue27811] _PyGen_Finalize() should not fail
 with an exception
Message-ID: <1471685705.62.0.520066392301.issue27811@psf.upfronthosting.co.za>


New submission from Armin Rigo:

_PyGen_Finalize() should not fail with an exception.  Doing so can cause various SystemErrors or even fatal errors.  For example, run this with "python -Werror":

    import gc
    async def f():
        pass
    f()
    gc.collect()   # RuntimeWarning, but with -Werror

Patch attached.  Test missing (turn the above example in a test; also I didn't re-run all tests with this patch).

----------
files: patch1.diff
keywords: needs review, patch
messages: 273199
nosy: arigo
priority: normal
severity: normal
status: open
title: _PyGen_Finalize() should not fail with an exception
versions: Python 3.6
Added file: http://bugs.python.org/file44165/patch1.diff

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

From report at bugs.python.org  Sat Aug 20 05:42:54 2016
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 20 Aug 2016 09:42:54 +0000
Subject: [New-bugs-announce] [issue27812] PyFrameObject.f_gen can be left
 pointing to a dangling generator
Message-ID: <1471686174.13.0.999892263925.issue27812@psf.upfronthosting.co.za>


New submission from Armin Rigo:

PyFrameObject.f_gen is a pointer (not a reference) to a generator/coroutine object.  But the latter doesn't always correctly clean it up when it dies.  This pointer is used by frame.clear().

Here is an example I made, which ends in a segfault.  This example assumes we apply the patch of issue27811 first, otherwise it just crashes earlier in the same way as issue27811.

    # execute this with "python -Werror"
    import gc
    async def f():
        pass
    cr = f()
    frame = cr.cr_frame
    del cr
    gc.collect()
    # create some randomness to reuse the memory just freed by 'cr'
    import asyncio
    print("ping")
    frame.clear()

Patch attached.  No test, but you can copy the above example.

----------
components: Interpreter Core
files: patch2.diff
keywords: needs review, patch
messages: 273200
nosy: arigo
priority: normal
severity: normal
status: open
title: PyFrameObject.f_gen can be left pointing to a dangling generator
versions: Python 3.6
Added file: http://bugs.python.org/file44166/patch2.diff

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

From report at bugs.python.org  Sat Aug 20 06:17:00 2016
From: report at bugs.python.org (ZHY)
Date: Sat, 20 Aug 2016 10:17:00 +0000
Subject: [New-bugs-announce] [issue27813] When I assign for a item which
 list of single item
Message-ID: <1471688220.69.0.490084662561.issue27813@psf.upfronthosting.co.za>


New submission from ZHY:

it seems can't set a value for item which I want to.

----------
components: Windows
files: ???.png
messages: 273201
nosy: anngg2008, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: When I assign for a item which list of single item
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44167/???.png

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

From report at bugs.python.org  Sat Aug 20 08:28:02 2016
From: report at bugs.python.org (=?utf-8?q?Michael_B=C3=BCsch?=)
Date: Sat, 20 Aug 2016 12:28:02 +0000
Subject: [New-bugs-announce] [issue27814] contextlib.suppress: Add whitelist
 argument
Message-ID: <1471696082.59.0.515606435532.issue27814@psf.upfronthosting.co.za>


New submission from Michael B?sch:

This adds a whitelist parameter with the name 'unless' to contextlib.suppress, so one can specify exceptions that will not be suppressed.

This is useful for specifying single sub-exceptions that we still want to catch, even of we want to suppress all other siblings.

Or it can be used to suppress all exceptions except some very specific ones by suppressing BaseException and whitelisting things like SyntaxError, NameError and the like.

Usage looks like this:

with suppress(OSError, unless = PermissionError):
    with open("foobar", "wb") as f:
        f.write(...


I selected the name 'unless' instead of 'whitelist' or such, because I think that pronounces nicely in the 'with' line context. However please feel free to make better suggestions.

----------
components: Library (Lib)
files: contextlib-suppress-whitelist.patch
keywords: patch
messages: 273206
nosy: mb_, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: contextlib.suppress: Add whitelist argument
type: enhancement
Added file: http://bugs.python.org/file44168/contextlib-suppress-whitelist.patch

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

From report at bugs.python.org  Sat Aug 20 09:19:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Aug 2016 13:19:11 +0000
Subject: [New-bugs-announce] [issue27815] Make SSL suppress_ragged_eofs
 default more secure
Message-ID: <1471699151.03.0.676654185488.issue27815@psf.upfronthosting.co.za>


New submission from Martin Panter:

In the SSL module, the wrap_socket() function (and corresponding SSLContext method) take a flag called ?suppress_ragged_eofs?. It defaults to True, which makes me uncomfortable. The documentation says:

'''
The parameter ?suppress_ragged_eofs? specifies how the SSLSocket.recv() method should signal unexpected EOF from the other end of the connection. If specified as True (the default), it returns a normal EOF (an empty bytes object) in response to unexpected EOF errors raised from the underlying socket; if False, it will raise the exceptions back to the caller.
'''

I understand the ?unexpected EOF error? happens when the underlying socket indicates EOF, but the connection was not shut down at the SSL protocol level. As well as EOF from the other end of the connection, it can happen due to a proxy, or anything else on the network that can affect the connection. I think it may be better report this error by default, just like other unsecured network-level errors like connection reset or timeout. Otherwise it is too easy to treat this insecure EOF condition as if it were a secure EOF signal of the remote peer.

The flag was added as part of r64578, for Issue 1223, in Python 2.6. The reason given in that bug report was to help Python work with a HTTP server. However my theory is the server was closing the connection wrongly; if so, the server should have been fixed, rather than Python.

There is plenty of precedence for using suppress_ragged_eofs=True with HTTPS servers. As well as Issue 1223, there is Issue 494762 and Issue 500311. And in my experiments, Curl and Firefox both seem to treat the error the same as a secure EOF. Maybe there should be a way to keep supporting HTTPS servers that trigger the error (though I would rather not by default).

Attached is a HTTP proxy server that will let you break a connection after returning a set number of bytes (or any time by killing the server), which can trigger the error condition.

Example output of proxy server:
$ python truncating_proxy.py --limit 12345
Proxy server at http://127.0.0.1:46687
Proxying connection to www.python.org:443
Forwarded 12345 B to client

Python 2?s httplib module does not treat a short HTTP response as an error, so the following request gets truncated without much indication of a problem:
$ https_proxy=http://127.0.0.1:46687 python2 -c 'import urllib2; print(urllib2.urlopen("https://www.python.org/").read())'
<!doctype html>
[. . .]
        <!--[if lt IE 8]>
        <div id="oldie-warning" class

----------
components: Library (Lib)
files: truncating_proxy.py
messages: 273208
nosy: martin.panter
priority: normal
severity: normal
status: open
title: Make SSL suppress_ragged_eofs default more secure
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file44169/truncating_proxy.py

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

From report at bugs.python.org  Sat Aug 20 12:21:59 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 20 Aug 2016 16:21:59 +0000
Subject: [New-bugs-announce] [issue27816] sock.proto does not reflect actual
 protocol
Message-ID: <1471710119.38.0.449496094278.issue27816@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The proto property of a socket object does not reflect the actual protocol of the socket file descriptor:

>>> import socket
>>> SO_PROTOCOL = getattr(socket, 'SO_PROTOCOL', 38)
>>> tcp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> tcp.proto
0
>>> tcp.getsockopt(socket.SOL_SOCKET, SO_PROTOCOL)
6
>>> socket.getprotobyname('tcp')
6

----------
components: Extension Modules
messages: 273222
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: sock.proto does not reflect actual protocol
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Aug 20 12:50:27 2016
From: report at bugs.python.org (Andreas Bolsch)
Date: Sat, 20 Aug 2016 16:50:27 +0000
Subject: [New-bugs-announce] [issue27817] String variable misinterpreted as
 boolean
Message-ID: <1471711827.55.0.419886306441.issue27817@psf.upfronthosting.co.za>


New submission from Andreas Bolsch:

Applies to 2.7.10 and 2.7.12:

Installed LinuxCNC from source at https://github.com/LinuxCNC/linuxcnc :
./configure --with-realtime=uspace --enable-simulator --enable-non-distributable=yes --prefix=/usr --libdir=/usr/lib64
make
make install

Configured device as per attached files, that's a simulated XYZ-mill.

Now start application with: 
linuxcnc linuxcnc/configs/my-mill/my-mill.ini

The "Manual Control Widget" has a radio button denoted "X", "Y", "Z" with values "x", "y" and "z" to select the active axis. "X" and "Z" work as desired, but "Y" does not. Instead:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1537, in __call__
    return self.func(*args)
  File "/usr/bin/axis", line 2323, in jog_plus
    a = "xyzabcuvw".index(a)
ValueError: substring not found

Reason: The Tcl button variable "current_axis" gets "y" assigned to as desired. The corresponding python variable "a" however, gets "True". I've tracked that down to "FromObj" in "_tkinter.c" where "value->typePtr" equals "app->OldBooleanType". 

In 2.7.8 and 2.7.9 the behavior is ok, but in 2.7.10 and 2.7.12 button value "y" (and of course "yes", "no" etc.) is transformed into boolean a value ...    

This change of behaviour depends only on _tkinter.so, exchanging just *this single* file makes the problem (dis-) appear.

----------
components: Tkinter
messages: 273224
nosy: Andreas Bolsch
priority: normal
severity: normal
status: open
title: String variable misinterpreted as boolean
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug 20 15:43:26 2016
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 20 Aug 2016 19:43:26 +0000
Subject: [New-bugs-announce] [issue27818] Speed up number format spec parsing
Message-ID: <1471722206.62.0.0499297323883.issue27818@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

I noticed that quite some time during number formatting is spent parsing the format spec. The attached patch speeds up float formatting by 5-15% and integer formatting by 20-30% for me overall when using f-strings (Ubuntu 16.04, 64bit).

----------
components: Interpreter Core
files: faster_format.patch
keywords: patch
messages: 273243
nosy: scoder
priority: normal
severity: normal
status: open
title: Speed up number format spec parsing
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44173/faster_format.patch

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

From report at bugs.python.org  Sat Aug 20 17:12:28 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 20 Aug 2016 21:12:28 +0000
Subject: [New-bugs-announce] [issue27819] Always distribute sdist packages
 as gztar.
Message-ID: <1471727548.71.0.177629890403.issue27819@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Per https://github.com/pypa/setuptools/pull/748#issuecomment-241212548, distutils should by default produce gztar formats on all platforms.

----------
assignee: jason.coombs
components: Distutils
messages: 273245
nosy: dstufft, eric.araujo, jason.coombs
priority: normal
severity: normal
status: open
title: Always distribute sdist packages as gztar.
versions: Python 3.6

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

From report at bugs.python.org  Sat Aug 20 20:29:10 2016
From: report at bugs.python.org (Dario D'Amico)
Date: Sun, 21 Aug 2016 00:29:10 +0000
Subject: [New-bugs-announce] [issue27820] Possible bug in smtplib when
 initial_response_ok=False
Message-ID: <1471739350.63.0.520286317175.issue27820@psf.upfronthosting.co.za>


Changes by Dario D'Amico <dario.damico at gmail.com>:


----------
components: Library (Lib)
nosy: Dario D'Amico
priority: normal
severity: normal
status: open
title: Possible bug in smtplib when initial_response_ok=False
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sun Aug 21 06:23:15 2016
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 21 Aug 2016 10:23:15 +0000
Subject: [New-bugs-announce] [issue27821] IDLE custom keymaps don't work
 anymore (Windows, Python 3.6.0a3)
Message-ID: <1471774995.74.0.570792584911.issue27821@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

I had a custom keymap in IDLE. Since I installed 3.6.0a3, it doesn't work anymore. Worse, I cannot switch to anything except "IDLE Classic Windows" - Apply does nothing, but when I click OK, it doesn't switch.

I suppose https://hg.python.org/cpython/rev/e6e6c71776b0 is the suspect, but I can't be sure. I tried editing .idlerc by hand, setting name, name2 and default, but nothing seems to help. :-/

Please resolve this, I'm lost without my favorite Python IDE. :-o

----------
assignee: terry.reedy
components: IDLE
messages: 273289
nosy: terry.reedy, veky
priority: normal
severity: normal
status: open
title: IDLE custom keymaps don't work anymore (Windows, Python 3.6.0a3)
versions: Python 3.6

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

From report at bugs.python.org  Sun Aug 21 06:40:53 2016
From: report at bugs.python.org (Paul McGuire)
Date: Sun, 21 Aug 2016 10:40:53 +0000
Subject: [New-bugs-announce] [issue27822] Fail to create _SelectorTransport
 with unbound socket
Message-ID: <1471776053.58.0.243290742982.issue27822@psf.upfronthosting.co.za>


New submission from Paul McGuire:

In writing a simple UDP client using asyncio, I tripped over a call to getsockname() in the _SelectorTransport class in asyncio/selector_events.py.


    def __init__(self, loop, sock, protocol, extra=None, server=None):
        super().__init__(extra, loop)
        self._extra['socket'] = sock
        self._extra['sockname'] = sock.getsockname()

Since this is a sending-only client, the socket does not get bound to an address. On Linux, this is not a problem; getsockname() will return ('0.0.0.0', 0) for IPV4, ('::', 0, 0, 0) for IPV6, and so on. But on Windows, a socket that is not bound to an address will raise this error when getsockname() is called:

    OSError: [WinError 10022] An invalid argument was supplied

This forces me to write a wrapper for the socket to intercept getsockname() and return None.

In asyncio/proactor_events.py, this is guarded against, with this code in the _ProactorSocketTransport class:

        try:
            self._extra['sockname'] = sock.getsockname()
        except (socket.error, AttributeError):
            if self._loop.get_debug():
                logger.warning("getsockname() failed on %r",
                             sock, exc_info=True)


Please add similar guarding code to the _SelectorTransport class in asyncio/selector_events.py.

----------
components: asyncio
messages: 273290
nosy: Paul McGuire, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Fail to create _SelectorTransport with unbound socket
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Aug 21 12:27:48 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 21 Aug 2016 16:27:48 +0000
Subject: [New-bugs-announce] [issue27823] Change bare AttributeError
 messages to be more informative
Message-ID: <1471796868.81.0.379385981847.issue27823@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

Attached patch changes bare attribute errors to add a useful error message. As such, `raise AttributeError` and `raise AttributeError(None)` (but not `raise AttributeError('')` for example) inside any of the attribute lookup or descriptor methods (__getattribute__, __getattr__, __setattr__, __delattr__, __get__, __set__, and __delete__). This is a followup to #27794.

As such, the following is now much more useful and less boilerplate:

class A:
    _dynamic_names = {}
    def __getattr__(self, name):
        if name in self._dynamic_names:
            return self._dynamic_names[name]
        raise AttributeError

Then, doing the following:

A().spam

Will result in a `AttributeError("'A' object has no attribute 'spam'")`, while keeping the original traceback. The patch is pretty much complete, but I have a few concerns:

- Performance hit, especially on something that's used virtually everywhere and everytime (attribute access); although PEP 487's __set_name__ lookup already hurts performance slightly. The few micro-benchmarks I ran weren't very significant, but there is a small drop in performance nonetheless.
- Four new PyErr_* API functions, one which isn't used in the current patch, but since it's 3 lines I decided to leave it in anyway.
- I don't carry over the cause or context of the raised exception to the new one. Keeping the traceback around is pretty trivial, since it has its own slot in the thread state struct, but since not all exceptions are actual exceptions at the C level (and the new exceptions I raise aren't either, at the C level), I don't know how to carry over context or cause.

Oh, and exceptions set at the C level with e.g. `PyErr_SetNone` are also properly handled that way; this would fix #27794 as a side-effect, but a few lines will need to be changed (in Objects/descrobject.c) for this to work. Such changes are not included with the patch.

Thoughts, concerns, opinions, ideas? Maybe something I didn't think of?

----------
components: Interpreter Core
files: change_attr_error_messages_1.patch
keywords: patch
messages: 273300
nosy: ebarry, r.david.murray, xiang.zhang, ztane
priority: normal
severity: normal
stage: patch review
status: open
title: Change bare AttributeError messages to be more informative
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44180/change_attr_error_messages_1.patch

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

From report at bugs.python.org  Sun Aug 21 13:07:12 2016
From: report at bugs.python.org (Joshua Haas)
Date: Sun, 21 Aug 2016 17:07:12 +0000
Subject: [New-bugs-announce] [issue27824] update ConfigParser docs regarding
 in-line comments
Message-ID: <1471799232.17.0.640576355958.issue27824@psf.upfronthosting.co.za>


New submission from Joshua Haas:

Originally reported at http://bugs.python.org/issue27762 as a behavior bug but was determined to be won't fix. Thus I think this needs to be mentioned in the documentation at https://docs.python.org/2/library/configparser.html

I propose that directly after the following:

"(For backwards compatibility, only ; starts an inline comment, while # does not.)"

be added:

"Inline comments will not be recognised in lines that contain ; before the comment itself. To ensure that inline comments work as expected, do not use ; in config values."

----------
assignee: docs at python
components: Documentation
messages: 273306
nosy: docs at python, jahschwa
priority: normal
severity: normal
status: open
title: update ConfigParser docs regarding in-line comments
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 21 16:56:47 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 21 Aug 2016 20:56:47 +0000
Subject: [New-bugs-announce] [issue27825] Make the documentation for
 statistics' data argument clearer.
Message-ID: <1471813007.76.0.49945343113.issue27825@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The docs for statistics.mean say, "Return the sample arithmetic mean of data, a sequence or iterator of real-valued numbers."  Most of the functions in statistics have a `data` argument, but this function is the only one that says, "a sequence or iterator."  The examples all show lists.

The page would be better if the introduction mentioned what `data` could be, instead of having to guess that median can take an iterator because mean says that it can.

----------
assignee: docs at python
components: Documentation
messages: 273318
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: Make the documentation for statistics' data argument clearer.

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

From report at bugs.python.org  Sun Aug 21 20:12:06 2016
From: report at bugs.python.org (Artem Smotrakov)
Date: Mon, 22 Aug 2016 00:12:06 +0000
Subject: [New-bugs-announce] [issue27826] Null-pointer dereference in
 tuplehash() function
Message-ID: <1471824726.59.0.89956573815.issue27826@psf.upfronthosting.co.za>


New submission from Artem Smotrakov:

A null-pointer dereference may happen while deserialization incorrect data with marshal.loads() function.

Here is a test which reproduces this (see also attached marshal_tuplehash_null_dereference.py):


import marshal

value = (       # tuple1
        "this is a string", #string1
        [
            1,  # int1
            2,  # int2
            3,  # int3
            4   # int4
        ],
        (       #tuple2
            "more tuples",  #string2
            1.0,    # float1
            2.3,    # float2
            4.5     # float3
        ),
        "this is yet another string"
    )

dump = marshal.dumps(value)

data = bytearray(dump)
data[10] = 40
data[4] = 16
data[103] = 143
data[97] = 245
data[78] = 114
data[35] = 188

marshal.loads(bytes(data))



This code modifies the serialized data with the following:
- update type of 'int2' element to TYPE_SET, 'int3' element becomes a length of the set
- update 'float3' element to TYPE_REF which points to tuple1

Here is a stack trace reported by ASan:

ASAN:SIGSEGV
=================================================================
==20296==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x000000582064 bp 0x7ffc9e581310 sp 0x7ffc9e5812f0 T0)
#0 0x582063 in PyObject_Hash Objects/object.c:769
#1 0x5a3662 in tuplehash Objects/tupleobject.c:358
#2 0x5820ae in PyObject_Hash Objects/object.c:771
#3 0x5a3662 in tuplehash Objects/tupleobject.c:358
#4 0x5820ae in PyObject_Hash Objects/object.c:771
#5 0x58fac8 in set_add_key Objects/setobject.c:422
#6 0x59a85c in PySet_Add Objects/setobject.c:2323
#7 0x760d9d in r_object Python/marshal.c:1310
#8 0x76029d in r_object Python/marshal.c:1223
#9 0x760015 in r_object Python/marshal.c:1195
#10 0x7621dc in read_object Python/marshal.c:1465
#11 0x7639be in marshal_loads Python/marshal.c:1767
#12 0x577ff3 in PyCFunction_Call Objects/methodobject.c:109
#13 0x708a05 in call_function Python/ceval.c:4744
#14 0x6fb5a7 in PyEval_EvalFrameEx Python/ceval.c:3256
#15 0x70276f in _PyEval_EvalCodeWithName Python/ceval.c:4050
#16 0x70299f in PyEval_EvalCodeEx Python/ceval.c:4071
#17 0x6e07d7 in PyEval_EvalCode Python/ceval.c:778
#18 0x432354 in run_mod Python/pythonrun.c:980
#19 0x431e5b in PyRun_FileExFlags Python/pythonrun.c:933
#20 0x42e929 in PyRun_SimpleFileExFlags Python/pythonrun.c:396
#21 0x42caba in PyRun_AnyFileExFlags Python/pythonrun.c:80
#22 0x45f995 in run_file Modules/main.c:319
#23 0x4619c8 in Py_Main Modules/main.c:777
#24 0x41d258 in main Programs/python.c:69
#25 0x7f374629babf in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20abf)
#26 0x41ce28 in _start 

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV Objects/object.c:769 PyObject_Hash
==20296==ABORTING



What happens when it tries to read int2 element:
- int2 element is now a set of length 3
- add int4 element to the set
- add tuple2 element
-- when it adds an element to a set, it calculates a hash of the element
-- when it calculates a hash of a tuple, it calculates hashes of all elements of the tuple
-- while calculating a hash of tuple2, it calculates a hash of tuple1 since #float3 now is a TYPE_REF which points to tuple1
-- but tuple1 is not complete yet: length of tuple1 is 4, but only string1 was added to it
-- tuplehash() function reads a length of a tuple, and then calls PyObject_Hash() for each element
-- but it doesn't check if all elements were added to the tuple
-- as a result, a null-pointer dereference happens in tuplehash() while reading second element of tuple1

https://hg.python.org/cpython/file/tip/Objects/tupleobject.c#l347

...
static Py_hash_t
tuplehash(PyTupleObject *v)
{
    Py_uhash_t x;  /* Unsigned for defined overflow behavior. */
    Py_hash_t y;
    Py_ssize_t len = Py_SIZE(v);    <= for tuple1 it returns 4, but tuple1 contains only one element (string1)
    PyObject **p;
    Py_uhash_t mult = _PyHASH_MULTIPLIER;
    x = 0x345678UL;
    p = v->ob_item;
    while (--len >= 0) {
        y = PyObject_Hash(*p++);    <= null-pointer dereference happens here while reading second element
...


I could reproduce it with python3.5, and latest build of https://hg.python.org/cpython (Aug 20th, 2016).

Here is a simple patch which updates tuplehash() to check "p" for null:

diff -r 6e6aa2054824 Objects/tupleobject.c
--- a/Objects/tupleobject.c	Sat Aug 20 21:22:03 2016 +0300
+++ b/Objects/tupleobject.c	Sat Aug 20 23:17:16 2016 -0700
@@ -355,7 +355,13 @@
     x = 0x345678UL;
     p = v->ob_item;
     while (--len >= 0) {
-        y = PyObject_Hash(*p++);
+        PyObject *next = *p++;
+        if (next == NULL) {
+            PyErr_SetString(PyExc_TypeError,
+                            "Cannot compute a hash, tuple seems to be invalid");
+            return -1;
+        }
+        y = PyObject_Hash(next);
         if (y == -1)
             return -1;
         x = (x ^ y) * mult;


According to https://docs.python.org/3.4/library/marshal.html, the marshal module is not intended to be secure against erroneous or maliciously constructed data, but it might be better to avoid a crash here.

----------
files: marshal_tuplehash_null_dereference.py
messages: 273322
nosy: artem.smotrakov
priority: normal
severity: normal
status: open
title: Null-pointer dereference in tuplehash() function
type: crash
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44183/marshal_tuplehash_null_dereference.py

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

From report at bugs.python.org  Mon Aug 22 05:33:48 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 22 Aug 2016 09:33:48 +0000
Subject: [New-bugs-announce] [issue27827] pathlib is_reserved fails for some
 reserved paths on Windows
Message-ID: <1471858428.08.0.847859442583.issue27827@psf.upfronthosting.co.za>


New submission from Eryk Sun:

pathlib._WindowsFlavour.is_reserved assumes Windows uses an exact match up to the file extension for reserved DOS device names. However, this misses cases involving trailing spaces and colons, such as the following examples:

Trailing colon:

    >>> pathlib.Path('C:/foo/NUL:').is_reserved()
    False
    >>> print(os.path._getfullpathname('C:/foo/NUL:'))
    \\.\NUL

Trailing spaces:

    >>> pathlib.Path('C:/foo/NUL  ').is_reserved()
    False
    >>> print(os.path._getfullpathname('C:/foo/NUL  '))
    \\.\NUL

Trailing spaces followed by a file extension:

    >>> pathlib.Path('C:/foo/NUL  .txt').is_reserved()
    False
    >>> print(os.path._getfullpathname('C:/foo/NUL  .txt'))
    \\.\NUL

Windows calls RtlIsDosDeviceName_Ustr to check whether a path represents a DOS device name. Here's a link to the reverse-engineered implementation of this function in ReactOS 4.1:

http://code.reactos.org/browse/reactos/branches/ros-branch-0_4_1/reactos/sdk/lib/rtl/path.c?r=71210#to85

The ReactOS implementation performs the following steps:

    * Return false for a UNC or unknown path type or an empty path.
    * Strip a final ":" if present. Return false if it was the
      only character.
    * Strip trailing dot and space characters.
    * Iterate over the path in reverse. If the current character is
      a "\\" or "/" or a ":" drive letter separator (at index 1),
      then if the next character matches the first letter of a DOS
      device name, splice out the base name as a potential match.
      Else return false.
    * Return false if the first character at this point does not 
      match the first letter of a DOS device name.
    * Remove the file extension, starting at the first dot or colon.
    * Remove trailing spaces.
    * Return the name offset and length if it equals
        * "COM" or "LPT" plus a digit
        * "PRN", "AUX", "NUL, or "CON"
    * Else return false.

It seems that ":" and "." are effectively equivalent for the purposes of is_reserved. Given this is the case, it could return whether parts[-1].partition('.')[0].partition(':')[0].rstrip(' ').upper() is in self.reserved_names. Or maybe use a regex for the entire check.

If a script is running on Windows, I think the best approach is to call os.path.abspath, which calls _getfullpathname. This lets Windows itself determine if the path maps to the \\.\ device namespace. However, I realize that is_reserved is intended to be cross-platform.

By the way, the comment for this method says that r"foo\NUL" isn't reserved, but it is. Maybe the author checked by trying to open NUL in a non-existing foo directory. DOS device names are only reserved in practice when opening and creating files in existing directories (as opposed to reserved in principle with GetFullPathName, which doesn't check for a valid path). NT can thus return an error that's consistent with how DOS behaved in the 1980s -- because that's really important, you know.

----------
components: Library (Lib), Windows
messages: 273344
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: pathlib is_reserved fails for some reserved paths on Windows
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Aug 22 07:14:57 2016
From: report at bugs.python.org (Yuriy Zhuravlev)
Date: Mon, 22 Aug 2016 11:14:57 +0000
Subject: [New-bugs-announce] [issue27828] Regression in cookie parsing with
 single key without value
Message-ID: <1471864497.53.0.24227724695.issue27828@psf.upfronthosting.co.za>


New submission from Yuriy Zhuravlev:

After I migrated my site to Python 3.5 from 3.4 many users of my site have not been able to login. After small research I found out that users cookies there was a key without value and new Python get empty SimpleCookie result. 
Example for Python 3.5.2:

>>> import http.cookies as Cookie
>>> _cookies = Cookie.SimpleCookie()
>>> _cookies.load("rgoods_1=2; __test;")
>>> _cookies
<SimpleCookie: >

Example for Python 3.4.5:

>>> import http.cookies as Cookie
>>> _cookies = Cookie.SimpleCookie()
>>> _cookies.load("rgoods_1=2; __test;")
>>> _cookies
<SimpleCookie: rgoods_1='2'>

I don't know many about right cookie format but drop the wrong key for me is the best solution. I have seen many discussions about Cookie parsers but I was not see words about single keys. If it will be dublicate I am sorry.

----------
components: Library (Lib)
messages: 273355
nosy: Yuriy Zhuravlev
priority: normal
severity: normal
status: open
title: Regression in cookie parsing with single key without value
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Aug 22 08:17:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2016 12:17:55 +0000
Subject: [New-bugs-announce] [issue27829] test.regrtest: changed environment
 variables are not logged
Message-ID: <1471868275.54.0.211153776881.issue27829@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It's common to get a random "env failed" issue when tests are run by buildbots, but changed environment variables are not logged, so the "env changed "information cannot be used to fix the issue :-/

Example:
------------------
...
0:07:32 [160/402] test_io failed (env changed) (51 sec)
0:07:33 [161/402] test_threading_local passed
...
0:13:04 [289/402/2] test_ssl failed (env changed) -- running: test_multiprocessing_spawn (119 sec)
0:13:05 [290/402/2] test_wsgiref passed -- running: test_multiprocessing_spawn (120 sec)
...
2 tests altered the execution environment:
    test_io test_ssl
------------------
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%20CURRENT%20Debug%203.x/builds/932/steps/test/logs/stdio

I expected "Warning -- xxx was modfied by test_xxx" lines, but no, there is no such line. I don't know if it's related to stderr buffering or something else?

This buildbot runs tests in subprocesses.

----------
components: Tests
messages: 273364
nosy: haypo
priority: normal
severity: normal
status: open
title: test.regrtest: changed environment variables are not logged
versions: Python 3.6

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

From report at bugs.python.org  Mon Aug 22 18:44:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2016 22:44:24 +0000
Subject: [New-bugs-announce] [issue27830] Add _PyObject_FastCallKeywords():
 pass keyword arguments as (key, value) pairs
Message-ID: <1471905864.17.0.99232719056.issue27830@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In the issue #27809, I added support for keyword arguments to the function _PyObject_FastCallDict() (previously called _PyObject_FastCall). Keyword arguments are passed as a Python dictionary (dict).

_PyObject_FastCallDict() is efficient when keyword arguments are not used. But when keyword arguments are used, the creation of a temporary dictionary to pass keyword arguments can defeat the "fastcall" optimization for positional arguments.

See Serhiy Storchaka's comment:
http://bugs.python.org/issue27809#msg273367

Extract: "It may be more efficient to push values and names as continuous arrays (issue27213). PyArg_ParseTupleAndKeywords() accepts a tuple and a dict, but private function _PyArg_ParseTupleAndKeywordsFast() (issue27574) can be changed to accept positional and keyword arguments as continuous arrays: (int nargs, PyObject **args, int nkwargs, PyObject **kwnames, PyObject **kwargs)."

And Stefan Behnel's comment:
http://bugs.python.org/issue27809#msg273391

Serhiy proposed to pass keyword arguments as (key, value) pairs in C array. We can probably use the simple "stack" format used in Python/ceval.c:

   PyObject* _PyObject_FastCallKeywords(PyObject *func, PyObject **stack, int nargs, int nkwargs)

where nargs is number of positional arguments at the beginning of stack, and nkwargs is the number of (key, value) pairs at the end of stack.

This function would be the fundation for a new C calling convention: METH_FASTCALL, see the issue #27810.

----------
components: Interpreter Core
messages: 273408
nosy: haypo, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add _PyObject_FastCallKeywords(): pass keyword arguments as (key, value) pairs
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Mon Aug 22 21:57:16 2016
From: report at bugs.python.org (geeknik)
Date: Tue, 23 Aug 2016 01:57:16 +0000
Subject: [New-bugs-announce] [issue27831] Python 3.4.5 leaks memory when
 attempting to load non-existent file
Message-ID: <1471917436.63.0.291205173926.issue27831@psf.upfronthosting.co.za>


New submission from geeknik:

While fuzzing Python 3.4.5 with AFL, ASAN and libdislocator, I fat fingered the keyboard ASAN pops up a LeakSanitizer error. Apparently trying to open a non-existent file causes Python 3.4.5 to leak >880KB of memory.

./python: can't open file 'id:000109': [Errno 2] No such file or directory

=================================================================
==16921==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 620904 byte(s) in 469 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12

Direct leak of 41800 byte(s) in 29 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x769b2f in PyEval_EvalCodeEx /root/python-3.4.5/Python/ceval.c:3588:14

Direct leak of 28160 byte(s) in 7 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x60459c in set_add_key /root/python-3.4.5/Objects/setobject.c:373:12

Direct leak of 26095 byte(s) in 33 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4dc54d in PyMem_RawMalloc /root/python-3.4.5/Objects/obmalloc.c:276:12
    #2 0x4dc54d in _PyObject_Malloc /root/python-3.4.5/Objects/obmalloc.c:1314

Direct leak of 18176 byte(s) in 31 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4dc54d in PyMem_RawMalloc /root/python-3.4.5/Objects/obmalloc.c:276:12
    #2 0x4dc54d in _PyObject_Malloc /root/python-3.4.5/Objects/obmalloc.c:1314
    #3 0x8a80e9 in _PyObject_GC_NewVar /root/python-3.4.5/Modules/gcmodule.c:1765:26

Direct leak of 3584 byte(s) in 16 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x636d59 in type_call /root/python-3.4.5/Objects/typeobject.c:883:11

Direct leak of 1472 byte(s) in 15 object(s) allocated from:
    #0 0x4bc5ce in realloc (/root/python-3.4.5/python+0x4bc5ce)
    #1 0x4da38a in PyMem_Realloc /root/python-3.4.5/Objects/obmalloc.c:308:12

Direct leak of 448 byte(s) in 2 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x836b0e in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:418:14
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 264 byte(s) in 2 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #3 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546820 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2509:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5468ad in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2510:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5e7712 in PyModule_Create2 /root/python-3.4.5/Objects/moduleobject.c:105:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545fdf in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2494:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546793 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2508:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546213 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2498:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54693a in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2511:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5454db in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2474:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546a54 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2513:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54570f in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2478:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546447 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2502:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54632d in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2500:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5462a0 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2499:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x70abc2 in _PyUnicode_Init /root/python-3.4.5/Objects/unicodeobject.c:15006:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546186 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2497:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5460f9 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2496:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54606c in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2495:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5f3ad1 in _Py_ReadyTypes /root/python-3.4.5/Objects/object.c:1573:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545dab in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2490:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545d1e in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2489:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545c91 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2488:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54544e in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2473:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546561 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2504:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5458b6 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2481:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545943 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2482:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5465ee in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2505:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546ae1 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2514:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545829 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2480:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54579c in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2479:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x63743f in type_getattro /root/python-3.4.5/Objects/typeobject.c:2893:13

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545682 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2477:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5463ba in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2501:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5453c1 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2472:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5469c7 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2512:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545334 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2471:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5452a7 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2470:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54521a in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2469:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545a5d in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2484:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545aea in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2485:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x70ab95 in _PyUnicode_Init /root/python-3.4.5/Objects/unicodeobject.c:15003:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x70ab68 in _PyUnicode_Init /root/python-3.4.5/Objects/unicodeobject.c:15000:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5f41d9 in _Py_ReadyTypes /root/python-3.4.5/Objects/object.c:1693:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5f40cb in _Py_ReadyTypes /root/python-3.4.5/Objects/object.c:1675:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5f4044 in _Py_ReadyTypes /root/python-3.4.5/Objects/object.c:1666:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5f3d74 in _Py_ReadyTypes /root/python-3.4.5/Objects/object.c:1618:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54667b in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2506:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5f3aa4 in _Py_ReadyTypes /root/python-3.4.5/Objects/object.c:1570:9
    #3 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #4 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x80812b in init_builtin /root/python-3.4.5/Python/import.c:1136:19
    #3 0x80812b in _imp_init_builtin_impl /root/python-3.4.5/Python/import.c:1963
    #4 0x80812b in _imp_init_builtin /root/python-3.4.5/Python/import.c:1950
    #5 0xa3937f in PyCFunction_Call /root/python-3.4.5/Objects/methodobject.c:120:23

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54720a in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2530:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x8aa9a1 in PyInit__thread /root/python-3.4.5/./Modules/_threadmodule.c:1367:9
    #3 0xa3937f in PyCFunction_Call /root/python-3.4.5/Objects/methodobject.c:120:23

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x8aa970 in PyInit__thread /root/python-3.4.5/./Modules/_threadmodule.c:1365:9
    #3 0xa3937f in PyCFunction_Call /root/python-3.4.5/Objects/methodobject.c:120:23

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x9862de in PyInit__io /root/python-3.4.5/./Modules/_io/_iomodule.c:697:9
    #3 0xa3937f in PyCFunction_Call /root/python-3.4.5/Objects/methodobject.c:120:23

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x986021 in PyInit__io /root/python-3.4.5/./Modules/_io/_iomodule.c:685:5
    #3 0xa3937f in PyCFunction_Call /root/python-3.4.5/Objects/methodobject.c:120:23

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x547297 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2531:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545b77 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2486:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x547329 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2532:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x545c04 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2487:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x54717d in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2529:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x5470f0 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2528:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x547063 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2527:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546fd6 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2526:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546f49 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2525:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546ebc in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2524:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546e2f in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2523:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546da2 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2522:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546d15 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2521:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546c88 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2520:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546bfb in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2519:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546b6e in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2517:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 224 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x546708 in _PyExc_Init /root/python-3.4.5/Objects/exceptions.c:2507:5
    #3 0x836b09 in _Py_InitializeEx_Private /root/python-3.4.5/Python/pythonrun.c:416:5
    #4 0x4e2e82 in Py_Main /root/python-3.4.5/Modules/main.c:654:5
    #5 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Direct leak of 96 byte(s) in 3 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da1c7 in PyMem_RawMalloc /root/python-3.4.5/Objects/obmalloc.c:276:12

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x4e31d4 in Py_Main /root/python-3.4.5/Modules/main.c:677:5
    #3 0x4d9c8e in main /root/python-3.4.5/./Modules/python.c:69:11

Indirect leak of 68376 byte(s) in 77 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4dc54d in PyMem_RawMalloc /root/python-3.4.5/Objects/obmalloc.c:276:12
    #2 0x4dc54d in _PyObject_Malloc /root/python-3.4.5/Objects/obmalloc.c:1314
    #3 0x626fa2 in PyType_GenericAlloc /root/python-3.4.5/Objects/typeobject.c:916:15

Indirect leak of 36042 byte(s) in 34 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4dc54d in PyMem_RawMalloc /root/python-3.4.5/Objects/obmalloc.c:276:12
    #2 0x4dc54d in _PyObject_Malloc /root/python-3.4.5/Objects/obmalloc.c:1314

Indirect leak of 6432 byte(s) in 11 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4dc54d in PyMem_RawMalloc /root/python-3.4.5/Objects/obmalloc.c:276:12
    #2 0x4dc54d in _PyObject_Malloc /root/python-3.4.5/Objects/obmalloc.c:1314
    #3 0x8a80e9 in _PyObject_GC_NewVar /root/python-3.4.5/Modules/gcmodule.c:1765:26

Indirect leak of 6016 byte(s) in 47 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x636d59 in type_call /root/python-3.4.5/Objects/typeobject.c:883:11

Indirect leak of 4574 byte(s) in 5 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4dc54d in PyMem_RawMalloc /root/python-3.4.5/Objects/obmalloc.c:276:12
    #2 0x4dc54d in _PyObject_Malloc /root/python-3.4.5/Objects/obmalloc.c:1314
    #3 0x636d59 in type_call /root/python-3.4.5/Objects/typeobject.c:883:11

Indirect leak of 2912 byte(s) in 7 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12

Indirect leak of 1242 byte(s) in 1 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4dc54d in PyMem_RawMalloc /root/python-3.4.5/Objects/obmalloc.c:276:12
    #2 0x4dc54d in _PyObject_Malloc /root/python-3.4.5/Objects/obmalloc.c:1314
    #3 0x641c91 in tp_new_wrapper /root/python-3.4.5/Objects/typeobject.c:5524:11

Indirect leak of 1152 byte(s) in 9 object(s) allocated from:
    #0 0x4bc2db in malloc (/root/python-3.4.5/python+0x4bc2db)
    #1 0x4da307 in PyMem_Malloc /root/python-3.4.5/Objects/obmalloc.c:299:12
    #2 0x641c91 in tp_new_wrapper /root/python-3.4.5/Objects/typeobject.c:5524:11

SUMMARY: AddressSanitizer: 883433 byte(s) leaked in 869 allocation(s).

----------
components: Interpreter Core
messages: 273415
nosy: geeknik
priority: normal
severity: normal
status: open
title: Python 3.4.5 leaks memory when attempting to load non-existent file
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 23 04:39:41 2016
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 23 Aug 2016 08:39:41 +0000
Subject: [New-bugs-announce] [issue27832] fractions.Fraction with 3
 arguments: error passes silently
Message-ID: <1471941581.22.0.742866227558.issue27832@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

During the discussion about http://bugs.python.org/issue27539, we found the following weird behavior:

    >>> from fractions import Fraction as F
    >>> F(2, 3, 4)
    Fraction(2, 3)

It looks like the third argument is simply disregarded, but it's not so: if it's false, the fraction is not normalized, and it breaks a lot of arithmetic assumptions.

    >>> F(4, 2, 0)
    Fraction(4, 2)
    >>> _ == 2
    False

The secret is additional argument "_normalize" to Fraction.__new__, which was added for optimization in various cases (where we know that numerator and denominator are relatively prime, so the gcd needn't be computed). That argument was obviously meant for internal use only (its name starts with '_'), so accepting the above forms can be viewed as a bug. Although cases can be made for being able to set that argument from the outside, surely in most cases people passing 3 arguments are doing it by accident, not on purpose.

That bug is easily fixed, by declaring the argument as keyword only. The line 84 in lib/fractions.py should be changed from

-     def __new__(cls, numerator=0, denominator=None, _normalize=True):

to

+     def __new__(cls, numerator=0, denominator=None, *, _normalize=True):

That way, those who know what they are doing, can still pass the _normalize argument, but it's much harder to accidentally pass it for people who don't know nor care about it.

Of course, all the code from that file already passes _normalize by keyword, so no other code should be changed.

----------
messages: 273422
nosy: veky
priority: normal
severity: normal
status: open
title: fractions.Fraction with 3 arguments: error passes silently

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

From report at bugs.python.org  Tue Aug 23 04:56:53 2016
From: report at bugs.python.org (Guni)
Date: Tue, 23 Aug 2016 08:56:53 +0000
Subject: [New-bugs-announce] [issue27833] Process is locked when try to
 execute Queue.put() inside
Message-ID: <1471942613.74.0.630952786652.issue27833@psf.upfronthosting.co.za>


New submission from Guni:

Hello,

When I try to put a long string (I mean longer then 65523 chars) in a queue if the put is inside in Process it's block the process and Process.Join() never execute.

Let's me give an example:
---------------
from multiprocessing import Queue, Process

def getLongString():
	s = ""
	for i in range(1, 65524):
		s += "1"
	return s

def p1(q):
	print('START')
	q.put(getLongString())
	print('END')

q = Queue()

prs1 = Process(target=p1, args=(q,))
prs1.start()
prs1.join()

print('FINISH')
----------------

##############
The result of it 65524 chars will be:
START
END
##############

##############
The result of it 65523 chars will be:
START
END
FINISH
##############

----------
messages: 273426
nosy: Guni
priority: normal
severity: normal
status: open
title: Process is locked when try to execute Queue.put() inside
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 23 05:26:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2016 09:26:05 +0000
Subject: [New-bugs-announce] [issue27834] test_datetime fails on "x86 Gentoo
 Non-Debug with X 3.x" buildbot
Message-ID: <1471944365.03.0.344913769784.issue27834@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%203.x/builds/1286/steps/test/logs/stdio

======================================================================
ERROR: test_gaps (test.datetimetester.ZoneInfoTest[Asia/Qyzylorda])
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/datetimetester.py", line 4700, in setUp
    self.tz = ZoneInfo.fromname(self.zonename)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/datetimetester.py", line 4531, in fromname
    return cls.fromfile(f)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/datetimetester.py", line 4523, in fromfile
    self = cls(ut, ti)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/datetimetester.py", line 4476, in __init__
    self.lt = self.invert(ut, ti)
  File "/buildbot/buildarea/3.x.ware-gentoo-x86.nondebug/build/Lib/test/datetimetester.py", line 4486, in invert
    lt[0][i] += ti[i-1][0] // SEC
OverflowError: Python int too large to convert to C long

----------
components: Tests
keywords: buildbot
messages: 273428
nosy: belopolsky, haypo
priority: normal
severity: normal
status: open
title: test_datetime fails on "x86 Gentoo Non-Debug with X 3.x" buildbot
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 23 05:52:35 2016
From: report at bugs.python.org (alexander.sturm)
Date: Tue, 23 Aug 2016 09:52:35 +0000
Subject: [New-bugs-announce] [issue27835] SystemExit in setUpClass etc.
 terminates test run
Message-ID: <1471945955.42.0.0930690369777.issue27835@psf.upfronthosting.co.za>


New submission from alexander.sturm:

In the following example code, a SystemExit is raised in setUpClass of a unittest.TestCase, which causes the python instance to terminate. This behavior is inconsistent with how SystemExit is handled in other places (e.g. in setUp/tearDown methods, or in actual test methods), where it is caught by unittest to prevent termination. See also issue #10611.

import unittest
class Test(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        raise SystemExit()

    def test_something(self):
        pass

result = unittest.TestResult()
suite = unittest.TestSuite()
suite.addTest(unittest.defaultTestLoader.loadTestsFromTestCase(Test))
suite.run(result)
print result

----------
components: Library (Lib)
messages: 273430
nosy: alexander.sturm
priority: normal
severity: normal
status: open
title: SystemExit in setUpClass etc. terminates test run
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Tue Aug 23 06:16:01 2016
From: report at bugs.python.org (Chris Wood)
Date: Tue, 23 Aug 2016 10:16:01 +0000
Subject: [New-bugs-announce] [issue27836] VCRUNTIME140.DLL not found
Message-ID: <1471947361.22.0.714353433435.issue27836@psf.upfronthosting.co.za>


New submission from Chris Wood:

Windows 7 / 64-bit / 4 Gb Ram / Intel i5 processor.

This seems to have been discussed intermittently in the past, but none of the previous answers fixed my problem.

I installed 3.5, and when I tried running it (both from the Windows cmd line and from the python cmd line) I received the error

"The prodecure entry point strncmp could not be located in the dynamic link library VCRRUNTIME140.dll"

I installed 2.7.12 and received the same error.

I then uninstalled 2.7.12 and installed 2.7.11 and found that running this worked from the python cmd line but not from the windows cmd line.

I then tried installing 3.5.11 and found vcruntime140.dll in the python directory. I copied this to the python 2.7 folder, uninstalled 3.5.11 (and 3.5.12 ? after realising that the original installation didn?t seem to have completed successfully anyway, despite saying it had!), and now when I run python from both the windows cmd line and python cmd line it seems to work.

----------
components: Installation
messages: 273431
nosy: Chris Wood
priority: normal
severity: normal
status: open
title: VCRUNTIME140.DLL not found
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Tue Aug 23 08:22:13 2016
From: report at bugs.python.org (Niko Yasui)
Date: Tue, 23 Aug 2016 12:22:13 +0000
Subject: [New-bugs-announce] [issue27837] Logging Cookbook Improvement
Message-ID: <1471954933.3.0.792473866028.issue27837@psf.upfronthosting.co.za>


New submission from Niko Yasui:

Removed the unnecessary listener function and changed the worker loggers from root to children. Also replaced print statements with logging statements and a stdout handler to illustrate the usefulness of handler levels. This version also doesn't require a manual listener process or thread, since it's all handled by the interpreter in the background. 

As far as I know, it's just a one-line change from multiprocessing to threading, so it should be easy to adapt this example to improve the threading example as well.

The previous example was hard for me to understand, and when I integrated it to my code, printed duplicates of every log item to all my handlers (including stdout) even though I hadn't added a stdout handler. Evidently this was my fault, since the original example code doesn't do that, but this updated code should be cleaner and easier to understand to avoid such integration problems in the first place. I hope it is a worthy contribution the docs. Feel free to provide any tips to improve it.

----------
assignee: docs at python
components: Documentation
files: multi_log_cookbook.py
messages: 273437
nosy: Niko Yasui, docs at python
priority: normal
severity: normal
status: open
title: Logging Cookbook Improvement
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file44198/multi_log_cookbook.py

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

From report at bugs.python.org  Tue Aug 23 09:40:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2016 13:40:58 +0000
Subject: [New-bugs-announce] [issue27838] test_os.test_chown() random
 failure on "AMD64 FreeBSD CURRENT Debug 3.x" buildbot
Message-ID: <1471959658.26.0.0626423066304.issue27838@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

======================================================================
ERROR: test_chown (test.test_os.ChownFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_os.py", line 1138, in test_chown
    os.chown(support.TESTFN, uid, gid_1)
PermissionError: [Errno 1] Operation not permitted: '@test_12983_tmp'

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

----------
components: Tests
keywords: buildbot
messages: 273444
nosy: haypo, koobs
priority: normal
severity: normal
status: open
title: test_os.test_chown() random failure on "AMD64 FreeBSD CURRENT Debug 3.x" buildbot
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 23 09:48:59 2016
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 23 Aug 2016 13:48:59 +0000
Subject: [New-bugs-announce] [issue27839] "Python [...] calls
 sys.displayhook() on unhandled exceptions"
Message-ID: <1471960139.35.0.924295727518.issue27839@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

<https://docs.python.org/3/library/asyncio-dev.html#detect-exceptions-never-consumed> reads:
"Python usually calls sys.displayhook() on unhandled exceptions. If Future.set_exception() is called, but the exception is never consumed, sys.displayhook() is not called."

I believe this should be s/displayhook/excepthook/g.

----------
assignee: docs at python
components: Documentation
messages: 273446
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: "Python [...] calls sys.displayhook() on unhandled exceptions"

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

From report at bugs.python.org  Tue Aug 23 10:34:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2016 14:34:03 +0000
Subject: [New-bugs-announce] [issue27840] functools.partial: don't copy
 keywoard arguments in partial_call()?
Message-ID: <1471962843.41.0.64844621448.issue27840@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I justed optimized partial_call() for positional arguments in the change c1a698edfa1b to avoid the creation of a temporary tuple when possible.

I noticed that keyword parameters from partial() constructor are always copied. Is it mandatory? Can't we avoid copying them?

Example:
---
import functools
hello = functools.partial(print, "Hello World", end='!\n')
hello()
---

hello keyword arguments are {'end'; '!\n'}.

Attached patch avoids copying keyword arguments when the partial objects is not called with new keyword arguments.

Tests pass, but I don't know if there is a risk that some strange function modify keyword arguments in-place?

----------
files: partial_call_kwargs.patch
keywords: patch
messages: 273456
nosy: haypo, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: functools.partial: don't copy keywoard arguments in partial_call()?
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44199/partial_call_kwargs.patch

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

From report at bugs.python.org  Tue Aug 23 10:54:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2016 14:54:11 +0000
Subject: [New-bugs-announce] [issue27841] Use fast call in method_call() and
 slot_tp_new()
Message-ID: <1471964051.45.0.0189105602427.issue27841@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch avoids the creation of a temporary tuple in method_call() and slot_tp_new() by using the new fast call calling convention.

It uses a small buffer allocated on the stack C if the function is called with 4 arguments or less, or it allocates a buffer in the heap memory.

The function also avoids INCREF/DECREF: references are borrowed, not strong references.

The patch adds a private _PyObject_Call_Preprend() helper function written to optimize such way of packing positional arguments, it's like:

   args = (obj,) + args
   func(*args, **kw)

----------
files: call_prepend.patch
keywords: patch
messages: 273461
nosy: haypo, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use fast call in method_call() and slot_tp_new()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44200/call_prepend.patch

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

From report at bugs.python.org  Tue Aug 23 12:42:42 2016
From: report at bugs.python.org (Steve Holden)
Date: Tue, 23 Aug 2016 16:42:42 +0000
Subject: [New-bugs-announce] [issue27842] Order CSV header fields
Message-ID: <1471970562.41.0.180278117892.issue27842@psf.upfronthosting.co.za>


New submission from Steve Holden:

It's sometimes annoying that a csv.DictReader doesn't retain the field ordering given in the first line of the file. Sometimes it matters.

This patch converts the reader so that it returns an OrderedDict rather than a plain dict, thereby retaining the ordering.

All tests still pass (though I haven't yet added a test to verify that the field ordering *is* retained - didn't think it was worth it if the patch won't be added, but will happily add that test otherwise).

I have updated the documentation, but was unable in the time available to find out how to correctly reference the OrderedDict class so that it was correctly hyperlinked.

----------
components: Library (Lib)
files: csv.patch
hgrepos: 353
keywords: needs review, patch
messages: 273486
nosy: holdenweb
priority: normal
severity: normal
stage: patch review
status: open
title: Order CSV header fields
versions: Python 3.6
Added file: http://bugs.python.org/file44202/csv.patch

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

From report at bugs.python.org  Tue Aug 23 12:54:43 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 23 Aug 2016 16:54:43 +0000
Subject: [New-bugs-announce] [issue27843] Spaces in filenames in setuptools
Message-ID: <1471971283.59.0.779486093888.issue27843@psf.upfronthosting.co.za>


New submission from Michael Felt:

p.s. - guessing on the component - this is after make install

+ make install DESTDIR=/var/aixtools/aixtools/python/3.6.0.164 > .buildaix/install.out
+ mkinstallp.ksh /var/aixtools/aixtools/python/3.6.0.164 > .buildaix/mkinstallp.out

+++++
renamed:./opt/lib/python3.6/site-packages/setuptools/script (dev).tmpl:./opt/lib/python3.6/site-packages/setuptools/script_dev_.tmpl
renamed:./opt/lib/python3.6/site-packages/setuptools/command/launcher manifest.xml:./opt/lib/python3.6/site-packages/setuptools/command/launcher_manifest.xml
+++++

My script scans for files with "hard to package" filenames, and I see two in site-packages/setuptools

No idea if this is new to Python-3.6, or if it has been around for a long time, but it does not seem "handy" to distribute files with " " in the filename.

----------
components: Installation
messages: 273490
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Spaces in filenames in setuptools
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 23 13:01:26 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 23 Aug 2016 17:01:26 +0000
Subject: [New-bugs-announce] [issue27844] Python-3.6a4 build messages to
 stderr (on AIX and xlc compiler)
Message-ID: <1471971686.29.0.126107373304.issue27844@psf.upfronthosting.co.za>


New submission from Michael Felt:

FYI: Compiler warnings that appear on stderr (skipping any messages sent to stdout) - xlc V11 as the reporting compiler.

Two that may need attention are the redefines of _POSIX_C_SOURCE and _XOPEN_SOURCE in pyconfig.h

Also surprised by the message:
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]

I do not recall seeing that message in other builds.

Note also: no messages (to stderr) from configure

Details:

+ CPPFLAGS="-I/opt/include -I/opt/buildaix/include" CFLAGS="-I/opt/include -qmaxmem=-1 -qarch=pwr4 -O2 -I/opt/buildaix/includes"\
        ./configure\
                --prefix=/opt \
                --sysconfdir=/var/python/etc\
                --sharedstatedir=/var/python/com\
                --localstatedir=/var/python\
                --mandir=/usr/share/man\
                --infodir=/opt/share/info/python --without-computed-gotos\
                        > .buildaix/configure.out
+ make > .buildaix/make.out
"Objects/moduleobject.c", line 241.20: 1506-068 (W) Operation between types "struct _object*(*)(struct _object*,struct PyModuleDef*)" and "void*" is not allowed.
"./pyconfig.h", line 1472.9: 1506-236 (W) Macro name _POSIX_C_SOURCE has been redefined.
"./pyconfig.h", line 1472.9: 1506-358 (I) "_POSIX_C_SOURCE" is defined on line 147 of /usr/include/standards.h.
"./pyconfig.h", line 1494.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined.
"./pyconfig.h", line 1494.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 143 of /usr/include/standards.h.
"./Modules/posixmodule.c", line 5532.11: 1506-131 (W) Explicit dimension specification or initializer required for an auto or static array.
"./Modules/xxsubtype.c", line 293.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
nm: libpython3.6m.a: 0654-200 Cannot open the specified file.
nm: A file or directory in the path name does not exist.
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", line 392.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", line 392.5: 1506-159 (E) Bit field type specified for N is not valid. Type unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", line 392.5: 1506-159 (E) Bit field type specified for O is not valid. Type unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", line 392.5: 1506-159 (E) Bit field type specified for P is not valid. Type unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", line 392.5: 1506-159 (E) Bit field type specified for Q is not valid. Type unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", line 392.5: 1506-159 (E) Bit field type specified for R is not valid. Type unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes_test.c", line 392.5: 1506-159 (E) Bit field type specified for S is not valid. Type unsigned assumed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/arraymodule.c", line 2996.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 84.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 85.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*,int(*)(struct _object*,void*),void*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 86.22: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct {...}*,struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 87.21: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*,const char*,struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 235.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 281.21: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _object*,struct PyModuleDef*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 454.21: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _object*,struct PyModuleDef*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 475.21: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _object*,struct PyModuleDef*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 496.21: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _object*,struct PyModuleDef*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 510.21: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _object*,struct PyModuleDef*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 511.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 531.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 552.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_testmultiphase.c", line 573.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ssl.c", line 302.17: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct {...}*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/pyexpat.c", line 1358.27: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const char*,int)" is not allowed.
"./pyconfig.h", line 1472.9: 1506-236 (W) Macro name _POSIX_C_SOURCE has been redefined.
"./pyconfig.h", line 1472.9: 1506-358 (I) "_POSIX_C_SOURCE" is defined on line 147 of /usr/include/standards.h.
"./pyconfig.h", line 1494.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined.
"./pyconfig.h", line 1494.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 143 of /usr/include/standards.h.
"./pyconfig.h", line 1472.9: 1506-236 (W) Macro name _POSIX_C_SOURCE has been redefined.
"./pyconfig.h", line 1472.9: 1506-358 (I) "_POSIX_C_SOURCE" is defined on line 147 of /usr/include/standards.h.
"./pyconfig.h", line 1494.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined.
"./pyconfig.h", line 1494.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 143 of /usr/include/standards.h.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/xxlimited.c", line 112.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*,int(*)(struct _object*,void*),void*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/xxlimited.c", line 113.22: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/xxlimited.c", line 114.22: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct {...}*,struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/xxlimited.c", line 115.21: 1506-196 (W) Initialization between types "void*" and "int(*)(struct {...}*,const char*,struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/xxlimited.c", line 204.25: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct _object*,struct _object*,int)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/xxlimited.c", line 242.30: 1506-068 (W) Operation between types "void*" and "struct _object*(*)(struct _typeobject*,struct _object*,struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/xxlimited.c", line 283.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes.c", line 3324.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes.c", line 3869.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes.c", line 5482.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes.c", line 5483.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes.c", line 5484.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes.c", line 5485.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/_ctypes.c", line 5487.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned int*,int)" is not allowed.
"/data/prj/aixtools/python/python-3.6.0.164/Modules/_ctypes/callproc.c", line 813.32: 1506-280 (W) Function argument assignment between types "void(*)(void)" and "void*" is not allowed.
+ make install DESTDIR=/var/aixtools/aixtools/python/3.6.0.164 > .buildaix/install.out
+ mkinstallp.ksh /var/aixtools/aixtools/python/3.6.0.164 > .buildaix/mkinstallp.out
renamed:./opt/lib/python3.6/site-packages/setuptools/script (dev).tmpl:./opt/lib/python3.6/site-packages/setuptools/script_dev_.tmpl
renamed:./opt/lib/python3.6/site-packages/setuptools/command/launcher manifest.xml:./opt/lib/python3.6/site-packages/setuptools/command/launcher_manifest.xml

----------
components: Build
messages: 273491
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Python-3.6a4 build messages to stderr (on AIX and xlc compiler)
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 23 17:44:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2016 21:44:34 +0000
Subject: [New-bugs-announce] [issue27845] Optimize update_keyword_args()
 function
Message-ID: <1471988674.88.0.138357624643.issue27845@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In the review of my issue #27830 "Add _PyObject_FastCallKeywords(): pass keyword arguments as (key, value) pairs", Antoine Pitrou wrote about _PyStack_AsDict():

"It's a pity that you're doing two dict lookups per keyword argument.
Another strategy would be to check that `PyDict_Size() == nk` at the end, and if not, try to find the duplicate keyword."

https://bugs.python.org/review/27830/diff/18203/Objects/abstract.c#newcode2326_Objects/abstract.c:2326


In fact, I simply copied code from update_keyword_args(), helper function used by do_call() and ext_do_call() in Python/ceval.c.

This function is quite old, the last major change was made in 2001:
---
changeset:   15711:2481b5fe86d6
branch:      legacy-trunk
user:        Jeremy Hylton <jeremy at alum.mit.edu>
date:        Wed Jan 03 23:52:36 2001 +0000
files:       Python/ceval.c
description:
Revised implementation of CALL_FUNCTION and friends.
More revision still needed.

(...)
---


But this change just moved code. It looks like the real code was in fact added by this change made in 2000:
---
changeset:   12082:603db0d0aed1
branch:      legacy-trunk
user:        Jeremy Hylton <jeremy at alum.mit.edu>
date:        Tue Mar 28 23:49:17 2000 +0000
files:       Grammar/Grammar Include/opcode.h Lib/dis.py Misc/ACKS Python/ceval.c Python/compile.c Python/graminit.c
description:
slightly modified version of Greg Ewing's extended call syntax patch

executive summary:
Instead of typing 'apply(f, args, kwargs)' you can type 'f(*arg, **kwargs)'.
Some file-by-file details follow.

(...)
---

----------
messages: 273518
nosy: haypo
priority: normal
severity: normal
status: open
title: Optimize update_keyword_args() function
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 24 05:25:37 2016
From: report at bugs.python.org (=?utf-8?q?Jens_J=C3=B8rgen_Mortensen?=)
Date: Wed, 24 Aug 2016 09:25:37 +0000
Subject: [New-bugs-announce] [issue27846] Base64 expansion factor is 4 to 3,
 not 6 to 4
Message-ID: <1472030737.8.0.133776759316.issue27846@psf.upfronthosting.co.za>


New submission from Jens J?rgen Mortensen:

The documentation has a note saying: "Base64 has an expansion factor of 6 to 4".  I believe it should be 4 to 3.

https://docs.python.org/dev/library/base64.html

----------
assignee: docs at python
components: Documentation
messages: 273543
nosy: Jens.J?rgen.Mortensen, docs at python
priority: normal
severity: normal
status: open
title: Base64 expansion factor is 4 to 3, not 6 to 4
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 24 05:57:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2016 09:57:23 +0000
Subject: [New-bugs-announce] [issue27847] os.set_inheritable() looks to be
 broken on OpenIndiana
Message-ID: <1472032643.28.0.131031350322.issue27847@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On Python 3.5, it seems ok:
---
test_get_inheritable_cloexec (test.test_socket.InheritanceTest) ... ok
test_set_inheritable (test.test_socket.InheritanceTest) ... ok
test_set_inheritable_cloexec (test.test_socket.InheritanceTest) ... ok
---
http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.5/builds/1159/steps/test/logs/stdio

But not on on Python 3.6:
======================================================================
FAIL: test_get_set_inheritable (test.test_os.FDInheritanceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_os.py", line 2723, in test_get_set_inheritable
    self.assertEqual(os.get_inheritable(fd), True)
AssertionError: False != True

======================================================================
FAIL: test_openpty (test.test_os.FDInheritanceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_os.py", line 2796, in test_openpty
    self.assertEqual(os.get_inheritable(master_fd), False)
AssertionError: True != False

======================================================================
FAIL: test_set_inheritable_cloexec (test.test_os.FDInheritanceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_os.py", line 2747, in test_set_inheritable_cloexec
    0)
AssertionError: 1 != 0

----------------------------------------------------------------------
http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/11800/steps/test/logs/stdio

----------
messages: 273544
nosy: haypo
priority: normal
severity: normal
status: open
title: os.set_inheritable() looks to be broken on OpenIndiana
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 24 08:11:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2016 12:11:41 +0000
Subject: [New-bugs-announce] [issue27848] C function calls: use Py_ssize_t
 rather than C int for number of arguments
Message-ID: <1472040701.62.0.862525052497.issue27848@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I recently added new functions to call functions in C, especially _PyObject_FastCallDict(). I started with the C int type for the number of positional arguments: "int nargs".

But slowly, when I started to patch code to use _PyObject_FastCallDict(), I used more and more Py_ssize_t variables for the number of arguments, variable downcasted to int to call _PyObject_FastCallDict().

It is similar to the old issue #18295.

I propose to avoid any risk of integer overflow by using Py_ssize_t everywhere. It *might* produce more efficient machine code, since "i++" may require extra code to handle overflow when the int rather is used. But I'm not sure that Py_ssize_t is better, especially when -fwrapv option of the GCC compiler is used.

Attached patch implements this idea.

The patch also uses Py_ssize_t for some BUILD_xxx opcodes like BUILD_LIST_UNPACK. The change is not directly related. I wrote it in the hope that machine code could be more efficient, and avoid having to ask myself if types could overflow or not.

----------
files: Py_ssize_t.patch
keywords: patch
messages: 273549
nosy: haypo, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: C function calls: use Py_ssize_t rather than C int for number of arguments
versions: Python 3.6
Added file: http://bugs.python.org/file44209/Py_ssize_t.patch

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

From report at bugs.python.org  Wed Aug 24 08:30:04 2016
From: report at bugs.python.org (David Kirkby)
Date: Wed, 24 Aug 2016 12:30:04 +0000
Subject: [New-bugs-announce] [issue27849] that is so great!
Message-ID: <00002dc2a9cf$b82bb005$ad9602b8$@onetel.net>


New submission from David Kirkby:

Hey, 

Look what  I've just found  on the web!  It's so amazing, check it out <http://guxustatri.scalrentals.com/aednig>

Yours, david.kirkby

----------
messages: 273550
nosy: drkirkby
priority: normal
severity: normal
status: open
title: that is so great!

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

From report at bugs.python.org  Wed Aug 24 09:43:48 2016
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 24 Aug 2016 13:43:48 +0000
Subject: [New-bugs-announce] [issue27850] Remove 3DES from cipher list
 (sweet32 CVE-2016-2183)
Message-ID: <1472046228.4.0.176948453237.issue27850@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Another attack with a catchy name and logo. This time 3DES is showing its age. 3DES should be removed from the list of server ciphers in ssl._RESTRICTED_SERVER_CIPHERS. For client ciphers we can leave it in for now. An attack requires dynamic code execution of code from a malicious 3rd party and several hundred GB of traffic. It's relevant for browsers with JS but not for majority of Python applications. OpenSSL 1.1.0 will remove 3DES support by default anyway.

https://www.openssl.org/blog/blog/2016/08/24/sweet32/
https://sweet32.info/

> As seen previously, the full attack should require 236.6 blocks (785 GB) to recover a two-block cookie, which should take 38 hours in our setting. Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.

----------
components: Library (Lib)
messages: 273559
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen
priority: critical
severity: normal
status: open
title: Remove 3DES from cipher list (sweet32 CVE-2016-2183)
type: security
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Aug 24 11:57:11 2016
From: report at bugs.python.org (Dan Wilt)
Date: Wed, 24 Aug 2016 15:57:11 +0000
Subject: [New-bugs-announce] [issue27851] re.sub() bug with IGNORECASE
Message-ID: <1472054231.08.0.443800311603.issue27851@psf.upfronthosting.co.za>


New submission from Dan Wilt:

Working with re.sub() noted strange behavior with re.I set, seems like a bug. Noted in both Python 2.7.12 and Python 3.5.2, Anaconda custom build (32-bit) on Windows 7.

>>> import re
>>> re.sub('\.', '', '.....')
''
>>> re.sub('\.', '', '.....', re.I)
'...'
>>> re.sub('\.', '', '.....', re.L)
'.'

The first case is the expected behavior, the second and third aren't. Oddly enough,

>>> re.sub('\.', '', '.....', re.L | re.I)
''

MWE file attached (python3)

Thanks, I'm a heavy python user, but not all that advanced - hope this is helpful and I'm not just being stupid.

----------
components: Regular Expressions
files: re_bug.py
messages: 273575
nosy: Dan Wilt, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.sub() bug with IGNORECASE
type: behavior
versions: Python 2.7, Python 3.5
Added file: https://bugs.python.org/file44212/re_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27851>
_______________________________________

From report at bugs.python.org  Wed Aug 24 13:29:50 2016
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 24 Aug 2016 17:29:50 +0000
Subject: [New-bugs-announce] [issue27852] itertools -> flatten_all()
Message-ID: <1472059790.24.0.14619033581.issue27852@psf.upfronthosting.co.za>


New submission from YoSTEALTH:

# Maybe a Recipe for itertools

from collections.abc import Iterable

def flatten_all(iterable):
    # -> 'one'
    # <- ['one']
    # -> ['one', [b'two', b'three'], ['four', ('five', (1, {'e', 'ee'}, (2, (3, ))), ['six'])], generator()]
    # <- ['one', b'two', b'three', 'four', 'five', 1, 'ee', 'e', 2, 3, 'six', 0, 1, 2]

    if isinstance(iterable, Iterable) and not isinstance(iterable, (str, bytes)):
        for it in iterable:
            yield from flatten_all(it)
    else:  # int & others types as is.
        yield iterable


if __name__ == "__main__":

    # Test Only
    def generator():
        for i in range(3):
            yield i

    a = ['one', [b'two', b'three'], ['four', ('five', (1, {'e', 'ee'}, (2, (3, ))), ['six'])], generator()]
    # a = 'one'
    # a = (True, False)

    print(list(flatten_all(a)))

----------
messages: 273581
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: itertools -> flatten_all()
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27852>
_______________________________________

From report at bugs.python.org  Wed Aug 24 13:37:06 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Aug 2016 17:37:06 +0000
Subject: [New-bugs-announce] [issue27853] Add title to examples in importlib
 docs
Message-ID: <1472060226.45.0.838492797903.issue27853@psf.upfronthosting.co.za>


New submission from Brett Cannon:

By not having section titles for the various examples in the importlib examples there is no way to directly link to a specific example.

----------
assignee: brett.cannon
components: Documentation
messages: 273583
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Add title to examples in importlib docs
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27853>
_______________________________________

From report at bugs.python.org  Wed Aug 24 18:34:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 24 Aug 2016 22:34:26 +0000
Subject: [New-bugs-announce] [issue27854] Installed 2.7: IDLE Help disabled
 because help.html is missing
Message-ID: <1472078066.3.0.116550230826.issue27854@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Since 2.7.11, 3.4.4, and 3.5.1, idlelib contains a committed help.html, displayed by Help => IDLE Help.  In my Windows 2.7.12 installation, the file is missing, even after 'Repair'.  IDLE Help silently does nothing.  I don't remember if I tested the 2.7.11 installation.  It is present in current 3.5/6 installations. Someone needs to test on other machines and OSes to determine if this omission is specific to my machine or the (2.7) Windows installer.

----------
assignee: terry.reedy
components: IDLE, Installation
messages: 273605
nosy: benjamin.peterson, terry.reedy
priority: normal
severity: normal
status: open
title: Installed 2.7: IDLE Help disabled because help.html is missing
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27854>
_______________________________________

From report at bugs.python.org  Wed Aug 24 20:11:33 2016
From: report at bugs.python.org (E Rippey)
Date: Thu, 25 Aug 2016 00:11:33 +0000
Subject: [New-bugs-announce] [issue27855] 2to3: Wrong code output w/ has_key
Message-ID: <1472083893.01.0.491707564074.issue27855@psf.upfronthosting.co.za>


New submission from E Rippey:

The "has_key" fixer in 2to3 produces wrong code on the following example:

input:"a.has_key(b)and x"
output:"b in aand x"

Note the lack of space before "and" in the input.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 273613
nosy: rippey.e
priority: normal
severity: normal
status: open
title: 2to3: Wrong code output w/ has_key
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27855>
_______________________________________

From report at bugs.python.org  Wed Aug 24 20:13:13 2016
From: report at bugs.python.org (Kameshwar Singh)
Date: Thu, 25 Aug 2016 00:13:13 +0000
Subject: [New-bugs-announce] [issue27856] Issue while passing the parameter
Message-ID: <1472083993.75.0.861909153235.issue27856@psf.upfronthosting.co.za>


New submission from Kameshwar Singh:

Hello Team,

I have one issue while using below function. I am using python 2.7.11 version on both OSX and Windows.

batch_result = SFbulk.get_batch_results(batch, result_id, job, maxfields=1)

If I am using above function on Windows machine, its working fine but on OSX its throwing error for maxfields=1 parameter.
And if I am using below code.
maxfields=1
batch_result = SFbulk.get_batch_results(batch, result_id, job, maxfields)

In this case, this is running fine on OSX but throwing error on Windows.

Please help me on this.

----------
components: Windows
messages: 273614
nosy: kameshwar, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Issue while passing the parameter
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27856>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:00:39 2016
From: report at bugs.python.org (JAG3R)
Date: Thu, 25 Aug 2016 04:00:39 +0000
Subject: [New-bugs-announce] [issue27857] n identical objects divide into m
 different groups
Message-ID: <1472097639.26.0.83015178754.issue27857@psf.upfronthosting.co.za>


New submission from JAG3R:

hello, everyone. I'm a newbie learner.^^
Recently, I learn the itertools and write this function...
heap(m,n)----->
X=[]
X.append([n  ,0,...,0] (len=m))
X.append([n-1,1,...,0])
...
X.append([n-1,0,...,1])
X.append([n-2,2,...,0])
X.append([n-2,1,1..,0])
...
X.append([0  ,0,...,n])
return X

----------
assignee: terry.reedy
components: IDLE
files: heap.py
messages: 273621
nosy: JAG3R, terry.reedy
priority: normal
severity: normal
status: open
title: n identical objects divide into m different groups
type: enhancement
versions: Python 2.7
Added file: https://bugs.python.org/file44216/heap.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27857>
_______________________________________

From report at bugs.python.org  Thu Aug 25 07:42:15 2016
From: report at bugs.python.org (=?utf-8?b?SsOhY2h5bSBCYXJ2w61uZWs=?=)
Date: Thu, 25 Aug 2016 11:42:15 +0000
Subject: [New-bugs-announce] [issue27858] Add identity function to functools
Message-ID: <1472125335.99.0.627029201806.issue27858@psf.upfronthosting.co.za>


New submission from J?chym Barv?nek:

An identity function is sometimes useful in functional-style programming as a dummy or default value.

For example, we can sometimes see a pattern like this (e.g. in itertools.groupby):

def f(params, key=None):
  if key is None:
    key = lambda x: x
  ...


However, if we had a canonical itentity function:

def identity(x):
  return x

we could instead write:

def f(params, key=identity):
  ...

and the intended use of the function f and it's functioning would be more obvious simply from it's signature, while also saving a little code. 

As zen of Python says: Explicit is better than implicit.

Of course, we can now write:

def f(params, key=lambda x: x):
  ...

but the reason why is not used is probably that it feels a bit awkward to more people than just me.

----------
components: Library (Lib)
messages: 273643
nosy: J?chym Barv?nek
priority: normal
severity: normal
status: open
title: Add identity function to functools
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27858>
_______________________________________

From report at bugs.python.org  Thu Aug 25 11:02:10 2016
From: report at bugs.python.org (Nick Papior)
Date: Thu, 25 Aug 2016 15:02:10 +0000
Subject: [New-bugs-announce] [issue27859] argparse - subparsers does not
 retain namespace
Message-ID: <1472137330.56.0.683571624156.issue27859@psf.upfronthosting.co.za>


New submission from Nick Papior:

Using argparse does not retain the Namespace variable across sub-parsers.

This prohibits customization of Actions due to "upper" level arguments not being stored in the namespace passed to the sub-parsers.

Hence, one may not create different sub-parsers which depend on an upper level flag.

The reason is the subparser command:
    subnamespace, arg_strings = parser.parse_known_args(arg_strings, None)

Which by default passes `None` as the namespace argument.

A simple patch would be to copy the original namespace, which may then be altered. And subsequently restored, based on changes to that namespace.

----------
components: Library (Lib)
files: argparse_subspacenamespace.py
messages: 273654
nosy: Nick Papior
priority: normal
severity: normal
status: open
title: argparse - subparsers does not retain namespace
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file44222/argparse_subspacenamespace.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27859>
_______________________________________

From report at bugs.python.org  Thu Aug 25 11:14:28 2016
From: report at bugs.python.org (Moritz Sichert)
Date: Thu, 25 Aug 2016 15:14:28 +0000
Subject: [New-bugs-announce] [issue27860] Improvements to ipaddress module
Message-ID: <1472138068.64.0.756560879111.issue27860@psf.upfronthosting.co.za>


New submission from Moritz Sichert:

This patch fixes the following minor issues with the ipaddress module:

- Removed unused property _BaseV4._valid_mask_octets
- Removed unused methods _BaseV4._is_valid_netmask() and _BaseV4._is_hostmask()
- Replaced several calls to superclass constructors by super()

It also refactors the constructors of IPv4Network, IPv4Interface, IPv6Network, and IPv6Interface.
They all now use the new method _get_addr_prefix_tuple() to parse the argument. It now matches the following sentence of the documentation of IPv4/6Interface:
"The meaning of address is as in the constructor of IPv4Network".

Additionally they now also accept a bytes or an IPv4/6Address object representing a netmask (or a hostmask [only IPv4]) as second element of an address/netmask tuple. This makes it easier to work with C-APIs that provide netmasks only as bytes object.

This patch does not try to solve issue 27683.

----------
components: Library (Lib)
files: ipaddress-improvement.patch
keywords: patch
messages: 273655
nosy: moritzs
priority: normal
severity: normal
status: open
title: Improvements to ipaddress module
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file44223/ipaddress-improvement.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27860>
_______________________________________

From report at bugs.python.org  Thu Aug 25 11:36:51 2016
From: report at bugs.python.org (tehybel)
Date: Thu, 25 Aug 2016 15:36:51 +0000
Subject: [New-bugs-announce] [issue27861] sqlite3 type confusion and
 multiple frees
Message-ID: <1472139411.37.0.427895086159.issue27861@psf.upfronthosting.co.za>


New submission from tehybel:

The first issue is a type confusion which resides in the sqlite3 module, in the
file connection.c. The function pysqlite_connection_cursor takes an optional
argument, a factory callable:

    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|O", kwlist,
                                     &factory)) {
        return NULL;
    }

If the factory callable is given, it is called to initialize a cursor:

    cursor = PyObject_CallFunction(factory, "O", self);

After this the cursor, which is a PyObject *, is cast directly to a
pysqlite_Cursor without performing any type checking:

    if (cursor && self->row_factory != Py_None) {
        Py_INCREF(self->row_factory);
        Py_XSETREF(((pysqlite_Cursor *)cursor)->row_factory, self->row_factory);
    }

Here is a small script which is tested on Python-3.5.2, 64-bit, with
--with-pydebug enabled:

--- begin script ---

import sqlite3

conn = sqlite3.connect('poc2.db')
conn.row_factory = 12
conn.cursor(lambda x: "A"*0x10000)

--- end script ---


When run, this produces a segfault:

(gdb) r ./poc2.py

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6496ad8 in pysqlite_connection_cursor (self=0x7ffff68cc370, args=<optimized out>, kwargs=<optimized out>)
    at /home/xx/Python-3.5.2/Modules/_sqlite/connection.c:322
warning: Source file is more recent than executable.
322         Py_XSETREF(((pysqlite_Cursor *)cursor)->row_factory, self->row_factory);
(gdb) p cursor
$13 = (PyObject *) 0xa46b90
(gdb) p self->row_factory
$14 = (PyObject *) 0x8d05f0 <small_ints+816>
(gdb) x/3i $pc
=> 0x7ffff6496ad8 <pysqlite_connection_cursor+221>: mov    rax,QWORD PTR [rdi+0x10]
   0x7ffff6496adc <pysqlite_connection_cursor+225>: sub    rax,0x1
   0x7ffff6496ae0 <pysqlite_connection_cursor+229>: mov    QWORD PTR [rdi+0x10],rax
(gdb) p $rdi
$15 = 0x4141414141414141

An arbitrary word in memory is decremented.


------


The second issue exists in the function pysqlite_connection_set_isolation_level
which resides in /Modules/_sqlite/connection.c. It can result in memory getting
freed multiple times.

The problem is that the variable self->isolation_level is not cleared before
being DECREF'd.

The code looks like this:

    static int pysqlite_connection_set_isolation_level(pysqlite_Connection* self, PyObject* isolation_level)
    {
        ...
        Py_XDECREF(self->isolation_level);
        ...
    }

This call to Py_XDECREF can trigger an arbitrary amount of python code, e.g. via
self->isolation_level's __del__ method. That code could then call 
pysqlite_connection_set_isolation_level again, which would trigger another
Py_XDECREF call on the same self->isolation_level, which can thus be freed an
arbitrary number of times.

One way to fix this is to use Py_CLEAR instead.

Here's a proof-of-concept script which results in a segfault here:

--- begin script ---

import sqlite3

class S(str):
    def __del__(self):
        conn.isolation_level = S("B")

conn = sqlite3.connect('poc6.db')
conn.isolation_level = S("A")
conn.isolation_level = ""

--- end script ---

When run it segfaults here, with Python-3.5.2 and --with-pydebug enabled:

(gdb) r ./poc6.py
Starting program: /home/xx/Python-3.5.2/python ./poc6.py

Program received signal SIGSEGV, Segmentation fault.
_Py_ForgetReference (op=op at entry=0x7ffff6d81b80) at Objects/object.c:1757
1757        if (op == &refchain ||
(gdb) bt
#0  _Py_ForgetReference (op=op at entry=0x7ffff6d81b80) at Objects/object.c:1757
#1  0x000000000049f8c0 in _Py_Dealloc (op=0x7ffff6d81b80) at Objects/object.c:1785
#2  0x000000000046ced8 in method_dealloc (im=im at entry=0x7ffff7f25de8) at Objects/classobject.c:198
#3  0x000000000049f8c5 in _Py_Dealloc (op=op at entry=0x7ffff7f25de8) at Objects/object.c:1786
...

----------
components: Extension Modules
messages: 273659
nosy: ghaering, tehybel
priority: normal
severity: normal
status: open
title: sqlite3 type confusion and multiple frees
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27861>
_______________________________________

From report at bugs.python.org  Thu Aug 25 12:06:57 2016
From: report at bugs.python.org (EungJun Yi)
Date: Thu, 25 Aug 2016 16:06:57 +0000
Subject: [New-bugs-announce] [issue27862] Make urllib.parse runnable as a
 script
Message-ID: <1472141217.33.0.887571401039.issue27862@psf.upfronthosting.co.za>


New submission from EungJun Yi:

It would be nice if urllib.prase runnable as a script so I can easily parse urls in command line or shell script.

I have attached a patch.

----------
components: Library (Lib)
files: 0001-Make-urllib.parse-runnable-as-a-script.patch
keywords: patch
messages: 273660
nosy: EungJun.Yi
priority: normal
severity: normal
status: open
title: Make urllib.parse runnable as a script
type: enhancement
versions: Python 3.5
Added file: https://bugs.python.org/file44226/0001-Make-urllib.parse-runnable-as-a-script.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27862>
_______________________________________

From report at bugs.python.org  Thu Aug 25 12:17:10 2016
From: report at bugs.python.org (tehybel)
Date: Thu, 25 Aug 2016 16:17:10 +0000
Subject: [New-bugs-announce] [issue27863] multiple issues in _elementtree
 module
Message-ID: <1472141830.55.0.358852521473.issue27863@psf.upfronthosting.co.za>


New submission from tehybel:

I'll describe 7 issues in the /Modules/_elementtree.c module here. They
include multiple use-after-frees, type confusions and instances of
out-of-bounds array indexing.



Issue 1: use-after-free in element_get_text

The problematic code looks like this:
    
    LOCAL(PyObject*)
    element_get_text(ElementObject* self)
    { 
        /* return borrowed reference to text attribute */

        PyObject* res = self->text;

        if (JOIN_GET(res)) { 
            res = JOIN_OBJ(res);
            if (PyList_CheckExact(res)) {
                res = list_join(res);
                if (!res)
                    return NULL;
                self->text = res;
            }
        }

        return res;
    }

As we can see, if res is a list, we call list_join with res, which is
self->text. list_join will decrease self->text's reference count. When that
happens, arbitrary python code can run. If that code uses self->text, a
use-after-free occurs.

PoC (Proof-of-Concept segfaulting script):

---

import _elementtree as et

class X(str):
    def __del__(self):
        print(elem.text)

b = et.TreeBuilder()
b.start("test")
b.data(["AAAA", X("BBBB")])
b.start("test2")

elem = b.close()
print(elem.text)

---


Issue 2: use-after-free in element_get_tail

The same type of issue also exists in element_get_tail and should be fixed
there, too.



Issue 3: type confusion in elementiter_next

The function elementiter_next iterates over a tree consisting of elements.
Each element has an array of children. 
    
Before doing any casts, most of the elementtree code is careful to check that
these children are, indeed, elements; that is, that their type is correct. The
problem is that elementiter_next does not validate these child objects before
performing a cast. Here is the relevant line:
    
    elem = (ElementObject *)cur_parent->extra->children[child_index];
    
If the child is not an element, a type confusion occurs. Here's a PoC:

-----

import _elementtree as et

state = {
    "tag": "tag",
    "_children": [1,2,3],
    "attrib": "attr",
    "tail": "tail",
    "text": "text",
}

e = et.Element("ttt")
e.__setstate__(state)

for x in e.iter():
    print(x)

-----



Issue 4: array-out-of-bounds indexing in element_subscr

This issue occurs when taking the subscript of an element. This is done using
the element_subscr function. The function calls PySlice_GetIndicesEx:

    if (PySlice_GetIndicesEx(item,
            self->extra->length,
            &start, &stop, &step, &slicelen) < 0) {
        return NULL; 
    }

The problem is that to evaluate the indices, PySlice_GetIndicesEx might call
back into python code. That code might cause the element's self->extra->length
to change. If this happens, the variables "start", "stop" and "step" might no
longer be appropriate.

The code then uses these variables for array indexing:

    for (cur = start, i = 0; i < slicelen;
         cur += step, i++) {
        PyObject* item = self->extra->children[cur]; 
        ...
    }

But this could go out of bounds and interpret arbitrary memory as a PyObject.
Here's a PoC that reproduces this:

---

import _elementtree as et

class X:
    def __index__(self):
        e[:] = []
        return 1

e = et.Element("elem")
for _ in range(10):
    e.insert(0, et.Element("child"))

print(e[0:10:X()])

---

Running it results in a segfault:

(gdb) r ./poc14.py
Starting program: /home/xx/Python-3.5.2/python ./poc14.py

Program received signal SIGSEGV, Segmentation fault.
0x000000000049f933 in PyObject_Repr (v=0x7ffff68af058) at Objects/object.c:471
471     if (Py_TYPE(v)->tp_repr == NULL)
(gdb) print *v
$37 = {_ob_next = 0xdbdbdbdbdbdbdbdb, _ob_prev = 0xdbdbdbdbdbdbdbdb, ob_refcnt = 0xdbdbdbdbdbdbdbdc,
  ob_type = 0xdbdbdbdbdbdbdbdb}

As we can see, "v" is freed memory with arbitrary contents.



Issue 5: array-out-of-bounds indexing in element_ass_subscr

A separate issue of the same type, also due to a call to PySlice_GetIndicesEx,
exists in element_ass_subscr. Here's a proof-of-concept script for that:

---

import _elementtree as et

class X:
    def __index__(self):
        e[:] = []
        return 1

e = et.Element("elem")
for _ in range(10):
    e.insert(0, et.Element("child"))

e[0:10:X()] = []

---

To fix these, I believe we could check whether self->extra->length changed
after calling PySlice_GetIndicesEx, and bail out if so. (You can grep the
codebase for "changed size during iteration" for examples of some similarish
cases.)





Issue 6: use-after-free in treebuilder_handle_start

In the function treebuilder_handle_start we see these lines:

    if (treebuilder_set_element_text(self->last, self->data))
        return NULL;

Here self->last is the most recent element, and we are setting its text to
self->data. This assignment happens via the function
treebuilder_set_element_text which in turn calls
treebuilder_set_element_text_or_tail. There, if the element self->last is not
an exact instance of Element_Type, we run these lines:

    PyObject *joined = list_join(data);
    int r;
    if (joined == NULL)
        return -1;
    r = _PyObject_SetAttrId(element, name, joined);
    Py_DECREF(joined);
    return r;

The comment for list_join says this:

    /* join list elements (destroying the list in the process) */

So note that we destroy the given list. If we go back to the initial function,
treebuilder_handle_start, then we recall that "element" is really self->last and
"data" is actually self->data. When list_join(data) is called, self->data will
therefore be destroyed. So we have to be careful and ensure that self->data is
overwritten; otherwise it could get used after being freed.

Unfortunately the call to _PyObject_SetAttrId could fail -- for example if
"element" is an integer. Then treebuilder_handle_start just bails out without
clearing self->data. This results in a use-after-free.

Here's a PoC:

---

import _elementtree as et

b = et.TreeBuilder(element_factory=lambda x, y: 123)

b.start("tag", {})
b.data("ABCD")
b.start("tag2", {})

---

It sets self->last to be an integer, 123. When we try to set the attribute
"text" on this integer, it fails. At that point, self->data has been freed but
the reference isn't cleared. When treebuilder_dealloc is called by the garbage
collector, self->data is excessively decref'd and we get a segfault:

(gdb) run ./poc16.py
Traceback (most recent call last):
  File "./poc16.py", line 7, in <module>
    b.start("tag2", {})
AttributeError: 'int' object has no attribute 'text'

Program received signal SIGSEGV, Segmentation fault.
0x0000000000435122 in visit_decref (op=0x7ffff6d52380, data=0x0) at Modules/gcmodule.c:373
373     if (PyObject_IS_GC(op)) {
(gdb) print *op
$52 = {_ob_next = 0xdbdbdbdbdbdbdbdb, _ob_prev = 0xdbdbdbdbdbdbdbdb, ob_refcnt = 0xdbdbdbdbdbdbdbdb,
  ob_type = 0xdbdbdbdbdbdbdbdb}


Note that this issue exists in two places inside treebuilder_handle_start -- the
call to treebuilder_set_element_tail has the same problem and both should be
fixed.


Issue 7: use-after-free in treebuilder_handle_end

The same sort of issue also exists in treebuilder_handle_end and should be
fixed there as well.




All these issues were found in Python-3.5.2 and tested with --with-pydebug
enabled. I did not check the 2.7 branch, but some (though not all) of the
issues likely exist there as well.

----------
components: Extension Modules
messages: 273662
nosy: tehybel
priority: normal
severity: normal
status: open
title: multiple issues in _elementtree module
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27863>
_______________________________________

From report at bugs.python.org  Thu Aug 25 17:56:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Aug 2016 21:56:05 +0000
Subject: [New-bugs-announce] [issue27864] test_socket: unknown thread blocks
 forever on "AMD64 FreeBSD 9.x 3.x"
Message-ID: <1472162165.25.0.11856143467.issue27864@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

...
running: test_socket (778 sec)
running: test_socket (808 sec)
running: test_socket (838 sec)
running: test_socket (868 sec)
running: test_socket (898 sec)
0:17:29 [402/402/1] test_socket crashed
Timeout (0:15:00)!
Thread 0x0000000801807400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/threading.py", line 295 in wait
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/threading.py", line 551 in wait
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_socket.py", line 261 in _tearDown
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 603 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 648 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1810 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1844 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_socket.py", line 5385 in test_main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 164 in runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 119 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest_mp.py", line 71 in run_tests_slave
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 471 in _main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 464 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 526 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 46 in _main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 50 in <module>
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 193 in _run_module_as_main


Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/__main__.py", line 2, in <module>
    main()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 526, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 464, in main
    self._main(tests, kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 484, in _main
    self.run_tests()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 412, in run_tests
    run_tests_multiprocess(self)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest_mp.py", line 221, in run_tests_multiprocess
    raise Exception(msg)
Exception: Child error on test_socket: Exit code 1

----------
components: Tests
keywords: buildbot
messages: 273682
nosy: haypo, koobs
priority: normal
severity: normal
status: open
title: test_socket: unknown thread blocks forever on "AMD64 FreeBSD 9.x 3.x"
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27864>
_______________________________________

From report at bugs.python.org  Thu Aug 25 22:46:05 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 26 Aug 2016 02:46:05 +0000
Subject: [New-bugs-announce] [issue27865] WeakMethod does not support
 builtin methods
Message-ID: <1472179565.29.0.0988743337733.issue27865@psf.upfronthosting.co.za>


New submission from Antony Lee:

List subclasses can be weakref'd (as mentioned by the docs), but their methods cannot be wrapped by WeakMethod, even though this makes sense semantically:
```
In [25]: class L(list): pass

In [26]: weakref.WeakMethod(L().append)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-26-f6246b3b483e> in <module>()
----> 1 weakref.WeakMethod(L().append)

/usr/lib/python3.5/weakref.py in __new__(cls, meth, callback)
     47         except AttributeError:
     48             raise TypeError("argument should be a bound method, not {}"
---> 49                             .format(type(meth))) from None
     50         def _cb(arg):
     51             # The self-weakref trick is needed to avoid creating a reference

TypeError: argument should be a bound method, not <class 'builtin_function_or_method'>
```

----------
components: Library (Lib)
messages: 273688
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: WeakMethod does not support builtin methods
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27865>
_______________________________________

From report at bugs.python.org  Fri Aug 26 07:29:14 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Aug 2016 11:29:14 +0000
Subject: [New-bugs-announce] [issue27866] ssl: get list of enabled ciphers
Message-ID: <1472210954.34.0.734962882785.issue27866@psf.upfronthosting.co.za>


New submission from Christian Heimes:

SSLContext has a set_ciphers() method but no method to get the actual list of enabled ciphers. https://github.com/tiran/cpython/tree/feature/openssl_ciphers implements get_ciphers()

>>> import ssl, pprint
>>> ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
>>> ctx.set_ciphers('ECDHE+AESGCM:!ECDSA')
>>> pprint.pprint(ctx.get_ciphers())
[{'alg_bits': 256,
  'description': 'ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  '
                 'Enc=AESGCM(256) Mac=AEAD',
  'id': 50380848,
  'name': 'ECDHE-RSA-AES256-GCM-SHA384',
  'protocol': 'TLSv1/SSLv3',
  'strength_bits': 256},
 {'alg_bits': 128,
  'description': 'ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  '
                 'Enc=AESGCM(128) Mac=AEAD',
  'id': 50380847,
  'name': 'ECDHE-RSA-AES128-GCM-SHA256',
  'protocol': 'TLSv1/SSLv3',
  'strength_bits': 128}]

With OpenSSL 1.1 the dict will have more fields.

Both the return value and functionality is different to https://docs.python.org/3/library/ssl.html#ssl.SSLSocket.shared_ciphers .

----------
components: Library (Lib)
messages: 273703
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen
priority: normal
severity: normal
status: open
title: ssl: get list of enabled ciphers
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27866>
_______________________________________

From report at bugs.python.org  Fri Aug 26 11:51:25 2016
From: report at bugs.python.org (tehybel)
Date: Fri, 26 Aug 2016 15:51:25 +0000
Subject: [New-bugs-announce] [issue27867] various issues due to misuse of
 PySlice_GetIndicesEx
Message-ID: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za>


New submission from tehybel:

Here I will describe 6 issues with various core objects (bytearray, list) and
the array module.

Common to them all is that they arise due to a misuse of the function
PySlice_GetIndicesEx. 

This type of issue results in out-of-bounds array indexing which leads to memory
disclosure, use-after-frees or memory corruption, depending on the
circumstances.

For each issue I've attached a proof-of-concept script which either prints
leaked heap memory or segfaults on my machine (64-bit linux, --with-pydebug,
python 3.5.2).



Issue 1: out-of-bounds indexing when taking a bytearray's subscript

While taking the subscript of a bytearray, the function bytearray_subscript in
/Objects/bytearrayobject.c calls PySlice_GetIndicesEx to validate the given
indices. 

Some of these indices might be objects with an __index__ method, and thus
PySlice_GetIndicesEx could call back into python code.

If the evaluation of the indices modifies the bytearray, the indices might no
longer be safe, despite PySlice_GetIndicesEx saying so. 

Here is a PoC which lets us read out 64 bytes of uninitialized memory from the
heap:

---

class X:
    def __index__(self):
        b[:] = []
        return 1

b = bytearray(b"A"*0x1000)
print(b[0:64:X()])

---

Here's the result on my system:

$ ./python poc17.py
bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\xb0\xce\x86\x9ff\x7f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')



Issue 2: memory corruption in bytearray_ass_subscript

This issue is similar to the one above. The problem exists when assigning to a
bytearray via subscripting. The relevant function is bytearray_ass_subscript.
The relevant line is again the one calling PySlice_GetIndicesEx.

Here's a PoC which leads to memory corruption of the heap:

---

class X:
    def __index__(self):
        del b[0:0x10000]
        return 1
        
b = bytearray(b"A"*0x10000)
b[0:0x8000:X()] = bytearray(b"B"*0x8000)

---

Here's the result of running it:

(gdb) r poc20.py 
Program received signal SIGSEGV, Segmentation fault.
PyCFunction_NewEx (ml=0x8b4140 <textiowrapper_methods+128>, self=self at entry=0x7ffff7f0e898, 
    module=module at entry=0x0) at Objects/methodobject.c:31
31	        free_list = (PyCFunctionObject *)(op->m_self);
(gdb) p op
$13 = (PyCFunctionObject *) 0x4242424242424242





Issue 3: use-after-free when taking the subscript of a list

This issue is similar to the one above, but it occurs when taking the subscript
of a list rather than a bytearray. The relevant code is in list_subscript which
exists in /Objects/listobject.c. Here's a PoC:

---

class X:
    def __index__(self):
        b[:] = [1, 2, 3]
        return 2

b = [123]*0x1000
print(b[0:64:X()])

---

It results in a segfault here because of a use-after-free:

(gdb) run ./poc18.py 
Program received signal SIGSEGV, Segmentation fault.
0x0000000000483553 in list_subscript (self=0x7ffff6d53988, item=<optimized out>) at Objects/listobject.c:2441
2441	                Py_INCREF(it);
(gdb) p it
$2 = (PyObject *) 0xfbfbfbfbfbfbfbfb




Issue 4: use-after-free when assigning to a list via subscripting

The same type of issue exists in list_ass_subscript where we assign to the list
using a subscript. Here's a PoC which also results in a use-after-free:

---

class X:
    def __index__(self):
        b[:] = [1, 2, 3]
        return 2

b = [123]*0x1000
b[0:64:X()] = [0]*32

---

(gdb) r poc19.py 
Program received signal SIGSEGV, Segmentation fault.
0x0000000000483393 in list_ass_subscript (self=<optimized out>, item=<optimized out>, 
    value=<optimized out>) at Objects/listobject.c:2603
2603	                Py_DECREF(garbage[i]);
(gdb) p garbage[i]
$4 = (PyObject *) 0xfbfbfbfbfbfbfbfb




Issue 5: out-of-bounds indexing in array_subscr

Same type of issue. The problem is in the function array_subscr in
/Modules/arraymodule.c. 

Here's a PoC which leaks and prints uninitialized memory from the heap:

---

import array

class X:
    def __index__(self):
        del a[:]
        a.append(2)
        return 1

a = array.array("b")
for _ in range(0x10):
    a.append(1)

print(a[0:0x10:X()])

---

And the result:

$ ./python poc22.py
array('b', [2, -53, -53, -53, -5, -5, -5, -5, -5, -5, -5, -5, 0, 0, 0, 0])





Issue 6: out-of-bounds indexing in array_ass_subscr

Same type of issue, also in the array module. Here's a PoC which segfaults here:

---

import array

class X:
    def __index__(self):
        del a[:]
        return 1

a = array.array("b")
a.frombytes(b"A"*0x100)
del a[::X()]

---





How should these be fixed? 

I would suggest that in each instance we could add a check after calling
PySlice_GetIndicesEx. The check should validate that the "length" argument
passed to PySlice_GetIndicesEx did not change during the call.  But maybe there
is a better way?

(By the way: these issues might also exist in 2.7, I did not check.)

----------
components: Extension Modules, Interpreter Core
messages: 273708
nosy: tehybel
priority: normal
severity: normal
status: open
title: various issues due to misuse of PySlice_GetIndicesEx
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27867>
_______________________________________

From report at bugs.python.org  Fri Aug 26 13:56:35 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 26 Aug 2016 17:56:35 +0000
Subject: [New-bugs-announce] [issue27868] Unconditionally state when a build
 succeeds
Message-ID: <1472234195.78.0.0298954008611.issue27868@psf.upfronthosting.co.za>


New submission from Brett Cannon:

When setup.py succeeds at building but couldn't build some dependency it says "Python build finished successfully!" and then lists the modules that couldn't be built. But if you are able to actually build everything then nothing is printed to stdout. Due to the fact that getting everything to build takes so much effort, when I finally reached the nirvana that is all modules built I thought my build had actually failed thanks to nothing being printed to stdout.

It might be worth always printing out that the build succeeded no matter whether a extension module had issues being built or not.

----------
assignee: brett.cannon
messages: 273712
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Unconditionally state when a build succeeds
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27868>
_______________________________________

From report at bugs.python.org  Fri Aug 26 14:40:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 26 Aug 2016 18:40:37 +0000
Subject: [New-bugs-announce] [issue27869] test failures on Bash for Windows
Message-ID: <1472236837.41.0.811658562373.issue27869@psf.upfronthosting.co.za>


New submission from Brett Cannon:

test_logging and test_socket seem to hang, and then there are 35 failures:

    test_asyncio test_asyncore test_dbm_dumb test_dbm_gnu test_eintr
    test_epoll test_faulthandler test_fcntl test_ftplib test_gettext
    test_httpservers test_import test_largefile test_mailbox test_mmap
    test_multiprocessing_fork test_multiprocessing_forkserver
    test_multiprocessing_main_handling test_multiprocessing_spawn
    test_netrc test_os test_pathlib test_pep277 test_posix
    test_resource test_shutil test_signal test_socketserver test_stat
    test_subprocess test_tarfile test_time test_unicode_file
    test_wsgiref test_zipfile

----------
components: Library (Lib), Windows
messages: 273714
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test failures on Bash for Windows
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27869>
_______________________________________

From report at bugs.python.org  Fri Aug 26 15:12:23 2016
From: report at bugs.python.org (Alex Groce)
Date: Fri, 26 Aug 2016 19:12:23 +0000
Subject: [New-bugs-announce] [issue27870] Left shift of zero allocates memory
Message-ID: <1472238743.62.0.87785770674.issue27870@psf.upfronthosting.co.za>


New submission from Alex Groce:

Using a random testing system to compare Python long behavior to GMP (via gmpy2), I notice that in a low-memory situation (created by allocating many large integers in both Python and GMP), a left-shift of 0 by large number of bytes:

- returns 0 via gmpy2
- causes a memory error in Python, e.g.:

...
val4 = val3 << val4
val3: 0 (GMP) 0 (Python)
val4: 1459166279268040830 (GMP) 1459166279268040830 (Python)
[operation successful via GMP]
Python(4463,0x7fff7152c300) malloc: *** mach_vm_map(size=194555503902408704) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug


Auto-generated test is attached, though probably not needed to understand the issue.  File is not minimized, since I suspect most of the code is just to choke memory, and you probably need the right memory config to replay, but it shows the basic idea.

For more info, see https://github.com/agroce/tstl/tree/master/examples/gmpy2

----------
files: leftshiftalloc.py
messages: 273717
nosy: Alex Groce
priority: normal
severity: normal
status: open
title: Left shift of zero allocates memory
type: resource usage
versions: Python 2.7
Added file: https://bugs.python.org/file44236/leftshiftalloc.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27870>
_______________________________________

From report at bugs.python.org  Fri Aug 26 17:43:23 2016
From: report at bugs.python.org (Christian Kothe)
Date: Fri, 26 Aug 2016 21:43:23 +0000
Subject: [New-bugs-announce] [issue27871] ctypes docs must be more explicit
 about the type a func returns
Message-ID: <1472247803.52.0.0680824647216.issue27871@psf.upfronthosting.co.za>


New submission from Christian Kothe:

The ctypes documentation leaves an important detail very implicit, which can cause non-deterministic hard crashes when overlooked. The issue is that when you explicitly set the .restype of a function to c_void_p, the function returns not a c_void_p (like a newcomer might assume) but an int -- and when he/she passes that value into the next library function (which should have gotten a c_void_p), then they'll get a hard crash if that memory location lies outside the 32-bit range.

I take it that the implicit assumption in ctypes is that the data types that you get back from the library calls are native python types where applicable for convenience, and the restype (just like argtypes) only configures the marshaling layer. However, that's not very explicitly stated anywhere (except maybe between the lines).

----------
components: ctypes
messages: 273732
nosy: Christian Kothe
priority: normal
severity: normal
status: open
title: ctypes docs must be more explicit about the type a func returns
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27871>
_______________________________________

From report at bugs.python.org  Fri Aug 26 17:54:18 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 26 Aug 2016 21:54:18 +0000
Subject: [New-bugs-announce] [issue27872] Update os/os.path docs to mention
 path-like object support
Message-ID: <1472248458.14.0.534169668817.issue27872@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Now that PEP 519 support has been added to the os and os.path modules, the documentation needs to be appropriately updated to mention which functions support a "path-like object" (and in some cases a path-like object or an int for file descriptors).

----------
assignee: brett.cannon
components: Documentation
messages: 273738
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Update os/os.path docs to mention path-like object support
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27872>
_______________________________________

From report at bugs.python.org  Fri Aug 26 19:15:50 2016
From: report at bugs.python.org (Jason Yu)
Date: Fri, 26 Aug 2016 23:15:50 +0000
Subject: [New-bugs-announce] [issue27873] multiprocessing.pool.Pool.map
 should take more than one iterable
Message-ID: <1472253350.37.0.404019702525.issue27873@psf.upfronthosting.co.za>


New submission from Jason Yu:

Hello all, 

The official doc describes `Pool.map(func, iterable[, chunksize])` as "A parallel equivalent of the map() built-in function.". 

Since the function signature of `map` is `map(function, iterable, ...)`, I hereby suggest that `Pool.map` should change its function signature to `Pool.map(function, iterable, ... [, chunksize])`. This will bring true equivalent to these functions. 

Tell me what you think. 

Pool.map: https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.map 

map: https://docs.python.org/3/library/functions.html#map 

Jason

----------
components: Interpreter Core
messages: 273741
nosy: Jason Yu
priority: normal
severity: normal
status: open
title: multiprocessing.pool.Pool.map should take more than one iterable
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27873>
_______________________________________

From report at bugs.python.org  Sat Aug 27 03:16:24 2016
From: report at bugs.python.org (Joseph Shen)
Date: Sat, 27 Aug 2016 07:16:24 +0000
Subject: [New-bugs-announce] [issue27874] inconsistent sys.path behavior
 when using PythonXX.zip
Message-ID: <1472282184.54.0.596998789435.issue27874@psf.upfronthosting.co.za>


New submission from Joseph Shen:

Found a inconsistent sys.path result when python packed with it's library with zip package.

A. when NOT use zip package
   sys.path is base the python.exe's absolute path, result is 
        1. ABS_PATH\pythonXX.zip
        2. ABS_PATH\DLLs
        3. ABS_PATH\lib, 
        4. ABS_PATH
        5. ABS_PATH\lib\site-packages

B. when use zip package
   sys.path is base the relative path of call path, result is 
        1. ABS_PATH\pythonXX.zip
        2. RLT_PATH\DLLs
        3. RLT_PATH\lib, 
        4. ABS_PATH

this is not commonly expected for the `DLLs` and `lib`, I think
the result will still be absolute path for where the executable
located. 

I snapshot two pictures for this problem, please review this,
thanks.

----------
components: Windows
files: 2016-08-27_15-09-39.png
messages: 273763
nosy: Joseph.Shen, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: inconsistent sys.path behavior when using PythonXX.zip
type: behavior
versions: Python 3.5
Added file: https://bugs.python.org/file44238/2016-08-27_15-09-39.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27874>
_______________________________________

From report at bugs.python.org  Sat Aug 27 05:48:31 2016
From: report at bugs.python.org (Fabian Pietsch)
Date: Sat, 27 Aug 2016 09:48:31 +0000
Subject: [New-bugs-announce] [issue27875] Syslogs /usr/sbin/foo as /foo
 instead of as foo
Message-ID: <1472291311.49.0.485322574022.issue27875@psf.upfronthosting.co.za>


New submission from Fabian Pietsch:

When calling syslog.syslog() without calling syslog.openlog() before, openlog() gets called with no arguments. Documentation says: "The optional ident keyword argument is a string which is prepended to every message, and defaults to sys.argv[0] with leading
path components stripped." -- "35.13. syslog ? Unix syslog library routines"

It leaves the final slash in, though. This produces syslog output for /usr/sbin/foo with identifier "/foo" instead of "foo". When reading syslog unprepared, one can easily think that to be a bug in the specific python script at hand (which it's not), or a chroot to be involved (which it's not, usually). So I consider this a bug.

On freenode/#python I was referred to https://github.com/python/cpython/blob/master/Modules/syslogmodule.c#L98 for the code that does this.

This issue is forwarded from a minor bug report reported by me at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835577

A test script is attached, which, when called with absolute path, produces this in syslog:

  Aug 27 08:53:27 blackbox /test-syslog.py: Test from python!

The slash is misleading/wrong.

----------
files: test-syslog.py
messages: 273770
nosy: canvon
priority: normal
severity: normal
status: open
title: Syslogs /usr/sbin/foo as /foo instead of as foo
type: behavior
Added file: https://bugs.python.org/file44240/test-syslog.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27875>
_______________________________________

From report at bugs.python.org  Sat Aug 27 06:30:35 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Aug 2016 10:30:35 +0000
Subject: [New-bugs-announce] [issue27876] Add
 SSLContext.set_version_range(minver, maxver=None)
Message-ID: <1472293835.86.0.296775745483.issue27876@psf.upfronthosting.co.za>


New submission from Christian Heimes:

OpenSSL 1.1 has deprecated all version specific TLS/SSL methods in favor of auto-negotiation (formerly known as SSLv23). It also introduced two macros to set the minimal and maximum TLS version with SSL_CTX_set_min_proto_version() and SSL_CTX_set_max_proto_version(). The macros can be emulated for OpenSSL < 1.1 with reasonable effort.

I suggest that ssl.SSLContext introduces set_version_range(minver, maxver=None) method. It's less awkward to use than fiddling with modes and OP_NO_SSLv3.

----------
components: Extension Modules
messages: 273772
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen
priority: normal
severity: normal
status: open
title: Add SSLContext.set_version_range(minver, maxver=None)
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27876>
_______________________________________

From report at bugs.python.org  Sat Aug 27 09:42:09 2016
From: report at bugs.python.org (John Hagen)
Date: Sat, 27 Aug 2016 13:42:09 +0000
Subject: [New-bugs-announce] [issue27877] Add recipe for "valueless" Enums
 to docs
Message-ID: <1472305329.28.0.714722611618.issue27877@psf.upfronthosting.co.za>


New submission from John Hagen:

Many programming languages allow the developer to define a enum without specifying values when there would be no significance to those values.  Adding some kind of support in the stdlib itself was rejected due to the high degree of magic that would be needed: https://bugs.python.org/issue26988

I propose that a simple example be added to the enum docs that show a developer how to use a normal Python Enum to create this most common and basic enum (without values).

import enum

class Color(enum.Enum):
    red = object()
    green = object()
    blue = object()

object() returns a new unique value while conveying that that value should not be expected to be used in any meaningful way (unlike an integer value, which could be used to encode the Enum in some way).

There is no extra magic going on here, no new code that needs to be added to the stdlib, and no bare identifiers that could confuse linters.  For example, PyCharm already fully understands the above example and statically types it.

This example also allows the developer to omit the extra @enum.unique() boilerplate that is normally needed, since he or she cannot accidentally use the same integer value twice.

----------
assignee: docs at python
components: Documentation
messages: 273780
nosy: John Hagen, barry, docs at python, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: Add recipe for "valueless" Enums to docs
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27877>
_______________________________________

From report at bugs.python.org  Sat Aug 27 10:36:09 2016
From: report at bugs.python.org (mohammad aghanabi)
Date: Sat, 27 Aug 2016 14:36:09 +0000
Subject: [New-bugs-announce] [issue27878] Unicode word boundries
Message-ID: <1472308569.99.0.0993827433917.issue27878@psf.upfronthosting.co.za>


New submission from mohammad aghanabi:

According to [UAX #29](http://unicode.org/reports/tr29) - unicode word boundaries (rule WB5a), an apostrophe includes U+0027 ( ' ) APOSTROPHE and U+2019 ( ? ) RIGHT SINGLE QUOTATION MARK (curly apostrophe).

However regex module only implements U+0027 and the second kind (U+2019) is missing:

/* Break between apostrophe and vowels (French, Italian). */
/* WB5a */
if (pos_m1 >= 0 && char_at(state->text, pos_m1) == '\'' &&
    is_unicode_vowel(char_at(state->text, text_pos)))
        return TRUE;


[Source code](https://bitbucket.org/mrabarnett/mrab-regex/src/f21447bf288780d8dd9b1633820480484ce8f677/regex_3/regex/_regex.c?at=default&fileviewer=file-view-default#_regex.c-1657)

----------
components: Regular Expressions
messages: 273782
nosy: ezio.melotti, mohammad aghanabi, mrabarnett
priority: normal
severity: normal
status: open
title: Unicode word boundries
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>
<https://bugs.python.org/issue27878>
_______________________________________

From report at bugs.python.org  Sat Aug 27 14:17:12 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 27 Aug 2016 18:17:12 +0000
Subject: [New-bugs-announce] [issue27879] add os.syncfs()
Message-ID: <1472321832.99.0.609872620029.issue27879@psf.upfronthosting.co.za>


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

I mean http://linux.die.net/man/2/syncfs

----------
components: Library (Lib)
messages: 273790
nosy: mmarkk
priority: normal
severity: normal
status: open
title: add os.syncfs()
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27879>
_______________________________________

From report at bugs.python.org  Sat Aug 27 15:16:24 2016
From: report at bugs.python.org (Robert Pierce)
Date: Sat, 27 Aug 2016 19:16:24 +0000
Subject: [New-bugs-announce] [issue27880] cPickle fails on large objects
 (still - 2011 and counting)
Message-ID: <1472325384.28.0.119216785398.issue27880@psf.upfronthosting.co.za>


New submission from Robert Pierce:

cPickle fails on large objects, throwing a SystemError exception which is cryptic. 

The issue was fixed for pickle in python 3 back in 2011 (http://bugs.python.org/issue11564), but never addressed in 2.7.  It seems to be a recurring complaint (e.g., http://bugs.python.org/issue11872), but always seems to be closed without being fixed or explained why it cannot be fixed.

Test case from 2011 still fails:

>>> import cPickle; cPickle.dumps('a' * (2 ** 31),-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: error return without exception set

----------
components: Library (Lib)
messages: 273795
nosy: robert at smithpierce.net
priority: normal
severity: normal
status: open
title: cPickle fails on large objects (still - 2011 and counting)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27880>
_______________________________________

From report at bugs.python.org  Sat Aug 27 15:21:29 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Aug 2016 19:21:29 +0000
Subject: [New-bugs-announce] [issue27881] Fix possible bugs when setting
 sqlite3.Connection.isolation_level
Message-ID: <1472325689.42.0.337900232121.issue27881@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

This is a follow up of issue27861 and means to fix the second issue mentioned in it.

pysqlite_connection_set_isolation_level now does not check allowed values and when any part fails, it leaves the Connection object in an inconsistent state.

I'll write a patch trying to fix this tomorrow.

----------
components: Library (Lib)
messages: 273796
nosy: berker.peksag, serhiy.storchaka, tehybel, xiang.zhang
priority: normal
severity: normal
status: open
title: Fix possible bugs when setting sqlite3.Connection.isolation_level
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27881>
_______________________________________

From report at bugs.python.org  Sat Aug 27 23:38:06 2016
From: report at bugs.python.org (Richard)
Date: Sun, 28 Aug 2016 03:38:06 +0000
Subject: [New-bugs-announce] [issue27882] Python docs on 3.52 Math module
 lists math.log2 as function but it does not exist
Message-ID: <1472355486.42.0.293458330235.issue27882@psf.upfronthosting.co.za>


Changes by Richard <john3.16 at protonmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: PyRW, docs at python
priority: normal
severity: normal
status: open
title: Python docs on 3.52 Math module lists math.log2 as function but it does not exist
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27882>
_______________________________________

From report at bugs.python.org  Sun Aug 28 07:18:09 2016
From: report at bugs.python.org (Big Stone)
Date: Sun, 28 Aug 2016 11:18:09 +0000
Subject: [New-bugs-announce] [issue27883] sqlite-3.14.1 for Python_3.6.0b1 ?
Message-ID: <1472383089.76.0.501181258195.issue27883@psf.upfronthosting.co.za>


New submission from Big Stone:

Sqlite-3.14.1 includes a lot of fixes since sqlite-38.11, including some for windows ;-) . it would be nice to upgrade

----------
components: Windows
messages: 273821
nosy: Big Stone, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: sqlite-3.14.1 for Python_3.6.0b1 ?
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27883>
_______________________________________

From report at bugs.python.org  Sun Aug 28 10:53:14 2016
From: report at bugs.python.org (Matt Morrison)
Date: Sun, 28 Aug 2016 14:53:14 +0000
Subject: [New-bugs-announce] [issue27884] during 'make install',
 pre-existing site-packages residents are recompiled. Twice.
Message-ID: <1472395994.03.0.200605981398.issue27884@psf.upfronthosting.co.za>


New submission from Matt Morrison:

I've been building Python 3 from source on Linux for a long time (at least since 3.2 days), and I honestly can't remember if this has happened before 3.6 or not, which is why I'm only tagging this 3.6. 

Basically, when running 'make install' (after building either static or shared, I haven't been messing around with any other options except install prefix - $HOME) you'll start seeing messages like:

=====
Listing '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/__init__.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/anova_nistcertified.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/ar_panel.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/example_kernridge.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/gmm.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/kernridgeregress_class.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/ols_anova_original.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/onewaygls.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/penalized.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/predstd.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/runmnl.py'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/sympy_diff.py'...
Listing '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/tests'...
Compiling '/home/mattdmo/lib/python3.6/site-packages/statsmodels/sandbox/regression/tests/__init__.py'...
=====

and on and on and on. I usually don't pay much attention to them, but since I have nothing better to do I just stare idly at them and watch as all my third-party modules in 'site-packages' scroll by in alphabetical order very quickly. For the last few builds of 3.6, though, I've noticed that the modules get gone through twice. I have a pretty large number of modules (341, according to `ls | wc -l`), so it takes a while to go through them, and they're definitely being repeated.

Unfortunately, I don't know a whole lot about Makefiles or the internals of the installation process, so I don't have the slightest idea of where to begin even looking for the bug. But, I bet you ladies and gentlemen do :)

If it's necessary, I can rebuild and pipe all the output into a file for you to examine. Just let me know.

----------
components: Build, Extension Modules, Installation
messages: 273824
nosy: MattDMo
priority: normal
severity: normal
status: open
title: during 'make install', pre-existing site-packages residents are recompiled. Twice.
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27884>
_______________________________________

From report at bugs.python.org  Sun Aug 28 12:43:07 2016
From: report at bugs.python.org (Decorater)
Date: Sun, 28 Aug 2016 16:43:07 +0000
Subject: [New-bugs-announce] [issue27885] Add a Crypto++ Wrapper for when
 Someone needs to use Crypto++ things outside of C++, e.g. in Python Code
Message-ID: <1472402587.99.0.582453342387.issue27885@psf.upfronthosting.co.za>


New submission from Decorater:

So, I have Python Code that would be nice if the interpreter had a built in Crypto++ support. I am Suggesting for 3.6 to Add in this as it would be helpful for any Python Developer to do something like:

import cryptopp

And then doing the functiosn that Crpyto++ Provides for some needed and good Encryption Techniques that zlib lacks and hey the cool stuff is that Crypto++ Can be used after zlib is used so it can be beneficial to many people as it can save soem file sizes.

Also Crypto++ Seems to have some things that zlib has as well like Deflate, Adler32, CRC, etc. So that makes zlib not be the only thing to compute checksums.

Useful Links:
http://www.cryptopp.com/
https://github.com/weidai11/cryptopp
Hopefully something like this could be possible but I do not see why not as it was done for zlib. I have no idea if crypto++ is windows only though but it is worth a test to find out.

----------
components: Extension Modules, Library (Lib)
messages: 273830
nosy: Decorater
priority: normal
severity: normal
status: open
title: Add a Crypto++ Wrapper for when Someone needs to use Crypto++ things outside of C++, e.g. in Python Code
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27885>
_______________________________________

From report at bugs.python.org  Sun Aug 28 15:07:12 2016
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 28 Aug 2016 19:07:12 +0000
Subject: [New-bugs-announce] [issue27886] Docs: the difference between
 rename and replace is not obvious
Message-ID: <1472411232.42.0.47360960084.issue27886@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

Hi.

On reading the doc for pathlib I've stuck with `.rename()` and `.replace()` (https://docs.python.org/3/library/pathlib.html#pathlib.Path.rename).

What's the difference?

Going to pathlib's source code I've figured out that methods are use different functions from `os` module: `os.rename()` and `os.replace()`.

But the documentation for `os` module is not obvious too: 
the docs for both functions are almost equal from my perspective, the only significant difference is that `os.rename()` suggests to use `os.replace()` for cross-compatibility.

Could anybody explain the difference?

Also, at least the doc for `pathlib.Path.rename` worth to have a sentence like borrowed from `os.rename`: "If you want cross-platform overwriting of the destination, use replace()."

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 273836
nosy: asvetlov, docs at python, pitrou
priority: low
severity: normal
status: open
title: Docs: the difference between rename and replace is not obvious
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27886>
_______________________________________

From report at bugs.python.org  Mon Aug 29 06:54:40 2016
From: report at bugs.python.org (Aleksandar Petrovic)
Date: Mon, 29 Aug 2016 10:54:40 +0000
Subject: [New-bugs-announce] [issue27887] Installation failed
Message-ID: <1472468080.66.0.531510448894.issue27887@psf.upfronthosting.co.za>


New submission from Aleksandar Petrovic:

Hi, got the following error message when I was trying to install Python. Im using 

"Installation failed.

The installer could not install the software.

The installer could not install the software because there was no software to install."

----------
components: Macintosh
messages: 273852
nosy: Aleksandar Petrovic, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Installation failed
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27887>
_______________________________________

From report at bugs.python.org  Mon Aug 29 16:49:35 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 29 Aug 2016 20:49:35 +0000
Subject: [New-bugs-announce] [issue27888] Hide pip install/uninstall windows
 in setup
Message-ID: <1472503775.99.0.744395565983.issue27888@psf.upfronthosting.co.za>


New submission from Steve Dower:

The console window for pip that appears during setup prevents us from having a truly silent install.

This patch uses the CAQuietExec task from WiX, extracted and checked in directly (the binary blob is omitted from the patch), to run the pip install/uninstall.

It also makes the task non-vital, which will prevent uninstall from failing when pip cannot be removed.

----------
assignee: steve.dower
components: Windows
files: installer_1.diff
keywords: patch
messages: 273884
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Hide pip install/uninstall windows in setup
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file44257/installer_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27888>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:47:38 2016
From: report at bugs.python.org (Andre Merzky)
Date: Mon, 29 Aug 2016 22:47:38 +0000
Subject: [New-bugs-announce] [issue27889] ctypes interfers with signal
 handling
Message-ID: <1472510858.82.0.884835264582.issue27889@psf.upfronthosting.co.za>


New submission from Andre Merzky:

Summary:  A thread uses signals to the MainThread to signal an abnormal condition.  The main thread is expected to get that signal, invoke the signal handler, and raise an exception.  In combination with 'ctypes' calls, that does not happen.


Consider the following code:

------------------------------------------------
#!/usr/bin/env python

import multiprocessing as mp
import threading       as mt
import signal
import time
import os

# from uuid.py line 400
import ctypes, ctypes.util
lib = ctypes.CDLL(ctypes.util.find_library('uuid'))

def sigusr2_handler(signum, frame):
    raise RuntimeError('caught sigusr2')
signal.signal(signal.SIGUSR2, sigusr2_handler)

def sub(pid):
    time.sleep(1)
    os.kill(pid, signal.SIGUSR2)

try:
  # p = mp.Process(target=sub, args=[os.getpid()])
  # p.start()
    t = mt.Thread(target=sub, args=[os.getpid()])
    t.start()
    time.sleep(3)
except Exception as e:
    print 'except: %s' % e
else:
    print 'unexcepted'
finally:
  # p.join()
    t.join()
------------------------------------------------

With Python 2.7 I would expect the output:
------------------------------------------------
except: caught sigusr2
------------------------------------------------

but I get:
------------------------------------------------
Traceback (most recent call last):
  File "./bug.py", line 29, in <module>
    print 'unexcepted'
  File "./bug.py", line 13, in sigusr2_handler
    raise RuntimeError('caught sigusr2')
  File "./bug.py", line 29, in <module>
    print 'unexcepted'
  File "./bug.py", line 13, in sigusr2_handler
    raise RuntimeError('caught sigusr2')
RuntimeError: caught sigusr2
------------------------------------------------


most of the time.  The problem only happens when the 'ctypes.CDLL' line is enabled -- commenting it out results in the expected behavior.  That line is copied from uuid.py -- importing uuid.py triggers the same unexpected behavior, which is ultimately why I am stuck.

Note that the problem only occurs when a *thread* sends the signal -- it does *not* happen if the signal is sent by the main thread or by a different process (switch to the multiprocessing code path for confirmation).

Interestingly, the problem also disappears when a 'print' statement is added after the 'time.sleep(3)', which may (or may not) indicate a timing issue.

I would welcome any suggestion on how to further triage this.

----------
components: ctypes
messages: 273889
nosy: Andre Merzky
priority: normal
severity: normal
status: open
title: ctypes interfers with signal handling
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27889>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:34:04 2016
From: report at bugs.python.org (James Domingo)
Date: Tue, 30 Aug 2016 00:34:04 +0000
Subject: [New-bugs-announce] [issue27890] platform.release() incorrect in
 Python 3.5.2 on Windows 2008ServerR2
Message-ID: <1472517244.47.0.778989197753.issue27890@psf.upfronthosting.co.za>


New submission from James Domingo:

The platform.release() function in Python 3.5.1 returns the correct value on Windows 2008 Server R2:

  C:\Users\jdoe\Documents\Python>python-3.5.1-embed-amd64\python.exe
  Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AM
  D64)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> platform.release()
  '2008ServerR2'

However, the function in the latest release, Python 3.5.2, misidentifies the system as Windows 7:

  C:\Users\jdoe\Documents\Python>python-3.5.2-embed-amd64\python.exe
  Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AM
  D64)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> platform.release()
  '7'

----------
components: Library (Lib)
messages: 273890
nosy: James Domingo
priority: normal
severity: normal
status: open
title: platform.release() incorrect in Python 3.5.2 on Windows 2008ServerR2
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27890>
_______________________________________

From report at bugs.python.org  Mon Aug 29 21:46:59 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 30 Aug 2016 01:46:59 +0000
Subject: [New-bugs-announce] [issue27891] Consistently group and sort
 imports within idlelib modules.
Message-ID: <1472521619.5.0.761842088013.issue27891@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

PEP 8 suggests separately grouping stdlib, dependency, and local package imports.  Within idlelib, idlelib imports are treated as local package imports.  Tkinter is sometimes treated as a dependency, which makes its imports easy to notice, and I want to do this consistently.  It is conventional to sort imports within each group.  This is sometimes true now, sometimes not (even before the 3.6 renaming).

The possible danger of rearranging imports is that a line gets deleted and not pasted.  Rietveld's side-by-side diff should make this easy to detect.

This issue is about re-arranging the imports currently at the top of a file, and any module level imports that I notice elsewhere.  Dealing with delayed imports within functions and classed will be another issue, which will depend on this one.

----------
assignee: terry.reedy
components: IDLE
messages: 273892
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Consistently group and sort imports within idlelib modules.
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27891>
_______________________________________

From report at bugs.python.org  Mon Aug 29 21:54:22 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 30 Aug 2016 01:54:22 +0000
Subject: [New-bugs-announce] [issue27892] Idlelib: document or move delayed
 imports
Message-ID: <1472522062.64.0.203498764549.issue27892@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This issue depends and follows-up on #27891, consistently grouping and sorting imports in idlelib files.

PEP 8 (also) says 'all imports are put at the top of the file', though the 'consistency hobgloblin' rule allows for exceptions.  Possible reasons include making circular imports work, delaying side-effects, and significantly reducing initial import time of the containing module.   All are rare.

Idlelib currently has numerous exceptions, only a few of which have a documented reason.  The others might have a good reason, but may be holdovers from when 'import at top' was absent or not observed.  I propose to at least document the exceptions by putting comments at the top, in their sort location among other idlelib imports.  Examples: 

# from idlelib import module  # in EditorWindow
# from idlelib.other import SomeClass  # in EditorWindow

Doing this will make it possible to see at a glance all the idlelib imports in a module.

I will remove at least one redundant delayed import and move some when I am sure there is no reason not to.  I may ask original authors as to their reason for placing imports where they did.

Moving 'import X' from a function is easy and safe.  Moving an import from a class requires deleting 'self.' from all references, so is not safe without extra care.  At least for EditorWindow, I may leave this to when editing the class anyway.

----------
assignee: terry.reedy
components: IDLE
messages: 273893
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idlelib: document or move delayed imports
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27892>
_______________________________________

From report at bugs.python.org  Tue Aug 30 10:55:26 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 30 Aug 2016 14:55:26 +0000
Subject: [New-bugs-announce] [issue27893] BytesParser.parsebytes docstring
 fix
Message-ID: <1472568926.47.0.711981476695.issue27893@psf.upfronthosting.co.za>


Changes by Ville Skytt? <ville.skytta at iki.fi>:


----------
assignee: docs at python
components: Documentation
files: parser.patch
keywords: patch
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: BytesParser.parsebytes docstring fix
type: enhancement
Added file: http://bugs.python.org/file44270/parser.patch

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

From report at bugs.python.org  Tue Aug 30 11:28:58 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 30 Aug 2016 15:28:58 +0000
Subject: [New-bugs-announce] [issue27894] Fix to_addrs refs in smtplib docs
Message-ID: <1472570938.45.0.100584989236.issue27894@psf.upfronthosting.co.za>


Changes by Ville Skytt? <ville.skytta at iki.fi>:


----------
assignee: docs at python
components: Documentation
files: smtplib-doc.patch
keywords: patch
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Fix to_addrs refs in smtplib docs
type: enhancement
Added file: http://bugs.python.org/file44271/smtplib-doc.patch

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

From report at bugs.python.org  Tue Aug 30 11:44:26 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 30 Aug 2016 15:44:26 +0000
Subject: [New-bugs-announce] [issue27895] Spelling fixes
Message-ID: <1472571866.64.0.0406128913335.issue27895@psf.upfronthosting.co.za>


Changes by Ville Skytt? <ville.skytta at iki.fi>:


----------
assignee: docs at python
components: Documentation
files: spelling.patch
keywords: patch
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Spelling fixes
type: enhancement
Added file: http://bugs.python.org/file44272/spelling.patch

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

From report at bugs.python.org  Tue Aug 30 12:03:39 2016
From: report at bugs.python.org (Julien)
Date: Tue, 30 Aug 2016 16:03:39 +0000
Subject: [New-bugs-announce] [issue27896] Allow passing sphinx options to
 Doc/Makefile
Message-ID: <1472573019.01.0.777773652271.issue27896@psf.upfronthosting.co.za>


New submission from Julien:

Context: 

 - Providing french translation to docs.python.rg/fr/: http://bugs.python.org/issue26546
 - Simplifying my first proposition of docsbuild-scripts: https://github.com/python/docsbuild-scripts/pull/1

Goals:

 - Simplify my modifications of docsbuild-scripts to make it more robust
 - Avoid executing external (~untrusted) Makefile on docs.python.org servers

To achieve this, I need the ``Doc/Makefile`` to be sufficient to build internationalized versions by passing sphinx options to it, I'd like to call, typically:

    make autobuild-stable SPHINXOPTS='-D language=fr -D locale_dirs=./locale/'

Which work if `Doc/Makefile` don't erase but append to the `SPHINXOPTS` variable. Which is done by `allow_sphinxopts.diff`.

We may simplify it further by adding `locale_dirs` to `Doc/conf.py` which does not break the english build, but I'm not sure if it's of any interest.

We may abstract it further by accepting a new parameter like SPHINXLANG='fr', with a default of 'en', but in every case I think it's a good thing to allow passing arbitrary SPHINXOPTS so let's start with this?

----------
assignee: docs at python
components: Documentation
files: allow_sphinxopts.diff
keywords: patch
messages: 273921
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Allow passing sphinx options to Doc/Makefile
versions: Python 3.6
Added file: http://bugs.python.org/file44275/allow_sphinxopts.diff

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

From report at bugs.python.org  Tue Aug 30 12:22:28 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Aug 2016 16:22:28 +0000
Subject: [New-bugs-announce] [issue27897] Avoid possible crash in
 pysqlite_connection_create_collation
Message-ID: <1472574148.53.0.8247324722.issue27897@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

When supplied a custom string with upper returning a non-string, pysqlite_connection_create_collation will fail assertion and crash. Serhiy, I think we can use the same way in set_isolation_level to avoid this.

----------
components: Library (Lib)
files: create_collation.patch
keywords: patch
messages: 273927
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: Avoid possible crash in pysqlite_connection_create_collation
type: crash
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44276/create_collation.patch

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

From report at bugs.python.org  Tue Aug 30 12:27:50 2016
From: report at bugs.python.org (Steve Newcomb)
Date: Tue, 30 Aug 2016 16:27:50 +0000
Subject: [New-bugs-announce] [issue27898] regexp performance degradation
 between 2.7.6 and 2.7.12
Message-ID: <1472574470.7.0.512575721216.issue27898@psf.upfronthosting.co.za>


New submission from Steve Newcomb:

Our most regular-expression-processing-intensive Python 2.7 code takes 2.5x more execution time in 2.7.12 than it did in 2.7.6.  I discovered this after upgrading from Ubuntu 14.04 to Ubuntu 16.04.  Basically this code runs thousands of compiled regular expressions on thousands of texts.  Both the multiprocessing module and the re module are heavily used.

See attached profiler outputs, which look quite different in several respects.  I used the profiling module to profile the same Python code, processing the same data, using the same hardware, under both Ubuntu 14.04 (Python 2.7.6) and Ubuntu 16.04 (Python 2.7.12).  

It is striking, for example, that cPickle.load appears so prominently in the 2.7.12 profile -- a fact which appears to implicate the multiprocessing module somehow.  But I suspect that the re module is more likely the main source of the problem, because the execution times of other production steps -- steps that do not call the multiprocessing module -- also appear to be extended to a degree that is roughly proportional to the amount of regular expression processing done in those other steps.

I will happily provide any further information I can.  Any insights about this surprisingly severe performance degradation would be welcome.

----------
files: profiles_2.7.6_vs_2.7.12
messages: 273932
nosy: steve.newcomb
priority: normal
severity: normal
status: open
title: regexp performance degradation between 2.7.6 and 2.7.12
Added file: http://bugs.python.org/file44277/profiles_2.7.6_vs_2.7.12

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

From report at bugs.python.org  Tue Aug 30 13:18:25 2016
From: report at bugs.python.org (Israel Fruchter)
Date: Tue, 30 Aug 2016 17:18:25 +0000
Subject: [New-bugs-announce] [issue27899] Apostrophe is not replace with
 &apos; ElementTree.tostring (also in Element.write)
Message-ID: <1472577505.85.0.700751415342.issue27899@psf.upfronthosting.co.za>


New submission from Israel Fruchter:

Both on python2.7 and python3.4
>>> from xml.etree import cElementTree as ET
>>> text = '<end>its &gt; &lt; &amp; &apos;</end>'
>>> root = ET.fromstring(text.encode('utf-8'))
>>> ET.tostring(root, method="xml")
<end>its &gt; &lt; &amp; '</end>

I would expected to return the same as the input to be a complient XML 1.0

I would understand why for html it would return something diffrent, see:
http://stackoverflow.com/questions/2083754/why-shouldnt-apos-be-used-to-escape-single-quotes

as a workaround I had to path ElementTree:

from xml.etree.ElementTree import _escape_cdata ,_raise_serialization_error
from mock import patch

def _escape_cdata(text):
    # escape character data
    try:
        # it's worth avoiding do-nothing calls for strings that are
        # shorter than 500 character, or so.  assume that's, by far,
        # the most common case in most applications.
        if "&" in text:
            text = text.replace("&", "&amp;")
        if "<" in text:
            text = text.replace("<", "&lt;")
        if ">" in text:
            text = text.replace(">", "&gt;")
        if "'" in text:
            text = text.replace("'", "&apos;")
        return text
    except (TypeError, AttributeError):
        _raise_serialization_error(text)

from xml.etree import cElementTree as ET

text = '<end>its &gt; &lt; &amp; &apos;</end>'
root = ET.fromstring(text.encode('utf-8'))

with patch('xml.etree.ElementTree._escape_cdata', new=_escape_cdata):

    s = ET.tostring(root, encoding='unicode', method="xml")
print(s)

----------
components: XML
messages: 273937
nosy: fruch
priority: normal
severity: normal
status: open
title: Apostrophe is not replace with &apos; ElementTree.tostring (also in Element.write)
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Aug 30 14:16:32 2016
From: report at bugs.python.org (daniel hahler)
Date: Tue, 30 Aug 2016 18:16:32 +0000
Subject: [New-bugs-announce] [issue27900] ctypes fails to find ncurses via
 ncursesw on Arch Linux
Message-ID: <1472580992.67.0.653516742445.issue27900@psf.upfronthosting.co.za>


New submission from daniel hahler:

The following code fails on Arch Linux:

    import ctypes.util
    print(ctypes.util.find_library("ncurses"))

It first looks at "ldconfig -p" (via _findSoname_ldconfig), which only
contains:

    libncursesw.so.6 (libc6,x86-64) => /usr/lib/libncursesw.so.6
    libncursesw.so.6 (libc6) => /usr/lib32/libncursesw.so.6
    libncursesw.so (libc6,x86-64) => /usr/lib/libncursesw.so
    libncursesw.so (libc6) => /usr/lib32/libncursesw.so
    libncurses++w.so.6 (libc6,x86-64) => /usr/lib/libncurses++w.so.6
    libncurses++w.so (libc6,x86-64) => /usr/lib/libncurses++w.so

/usr/lib/libncurses.so exists, but as a text file:

    INPUT(-lncursesw)

Then "_findLib_gcc" is called, which tries to link a file, and then looks at
its output:

    % if type gcc >/dev/null 2>&1; then CC=gcc; elif type cc >/dev/null 2>&1; then CC=cc;else exit 10; fi;LANG=C LC_ALL=C $CC -Wl,-t -o /tmp/tmp1ysftojh 2>&1 -lncurses
    /usr/bin/ld: mode elf_x86_64                                                                                                                                                       
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/crt1.o
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/crti.o
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/crtbegin.o
    -lncursesw (/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/libncursesw.so)
    libgcc_s.so.1 (/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/libgcc_s.so.1)
    /usr/lib/libc.so.6
    (/usr/lib/libc_nonshared.a)elf-init.oS
    /usr/lib/ld-linux-x86-64.so.2
    /usr/lib/ld-linux-x86-64.so.2
    libgcc_s.so.1 (/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/libgcc_s.so.1)
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/crtend.o
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/crtn.o
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/crt1.o: In function `_start':
    (.text+0x20): undefined reference to `main'
    /usr/bin/ld: link errors found, deleting executable `/tmp/tmp1ysftojh'
    collect2: error: ld returned 1 exit status

I don't know if "ldconfig" could be made to display the "text symlink", but with the "cc"-method, it could look for an explicit "cannot find" error instead?!

    % if type gcc >/dev/null 2>&1; then CC=gcc; elif type cc >/dev/null 2>&1; then CC=cc;else exit 10; fi;LANG=C LC_ALL=C $CC -Wl,-t -o /tmp/tmp1ysftojh 2>&1 -lncursesxx
    /usr/bin/ld: mode elf_x86_64
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/crt1.o
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/crti.o
    /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/crtbegin.o
    libgcc_s.so.1 (/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/libgcc_s.so.1)
    /usr/bin/ld: cannot find -lncursesxx
    collect2: error: ld returned 1 exit status

The workaround is to also look for "ncursesw" explicitly.

I have noticed this with pyrepl, which uses it in https://bitbucket.org/pypy/pyrepl/src/9401662c4e6c11a4d66804361a7e7d09a1f379d7/pyrepl/_minimal_curses.py?at=default&fileviewer=file-view-default#_minimal_curses.py-19:26.

----------
components: ctypes
messages: 273947
nosy: blueyed
priority: normal
severity: normal
status: open
title: ctypes fails to find ncurses via ncursesw on Arch Linux
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug 30 15:26:21 2016
From: report at bugs.python.org (Anthony Flury)
Date: Tue, 30 Aug 2016 19:26:21 +0000
Subject: [New-bugs-announce] [issue27901] inspect.ismethod returns different
 results on the same basic code between Python2.7 Python3.5
Message-ID: <1472585181.25.0.672560198795.issue27901@psf.upfronthosting.co.za>


New submission from Anthony Flury:

Consider the following code in Python2.7 & Python3.5 

    import inspect
    
    class a(object):
         def m(self):
             pass

in Python 2.7 
    
    inspect.ismethod(a.m) returns True

in Python 3.5
 
    inspect.ismethod(a.m) returns False

Not sure which is `correct`, but I can see the Python3.5 result causing some issues with automatic code documenters. 

I have code which will break under Python3.5 with this - my code performs static analysis of code, detecting functions, classes, attributes, and also traversing the mro to find inherited methods etc. Amongst other things this code identifies methods on classes, without instantiating those classes.

This may simply require a documentation change to explain the difference on Py3.5 - rather than a code change.

----------
components: Library (Lib)
messages: 273955
nosy: anthony-flury
priority: normal
severity: normal
status: open
title: inspect.ismethod returns different results on the same basic code between Python2.7 Python3.5
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug 30 16:49:35 2016
From: report at bugs.python.org (Jaroslav)
Date: Tue, 30 Aug 2016 20:49:35 +0000
Subject: [New-bugs-announce] [issue27902] pstats.Stats: strip_dirs() method
 cannot handle file paths from different OS
Message-ID: <1472590175.77.0.992836532809.issue27902@psf.upfronthosting.co.za>


New submission from Jaroslav:

Setup
=====

profile data from machine
-------------------------
- Win 7 (64bit)
- Python 3.5.2 (32bit)

data analyzed on
----------------
- Lubuntu 16.04 (64bit) incl. Python 3

issue
-----
method strip_dirs() cannot extract the base name since it assumes the Unix-style file paths. not tested for opposite direction. no exception emitted.

comment
-------
1. optional argument controlling the used 'path' module can definitely help
2. documentation update will be welcome

----------
components: Windows
messages: 273964
nosy: Jaroslav, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pstats.Stats: strip_dirs() method cannot handle file paths from different OS
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug 30 17:19:38 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 30 Aug 2016 21:19:38 +0000
Subject: [New-bugs-announce] [issue27903] Avoid ResourceWarnings from
 platform._dist_try_harder
Message-ID: <1472591978.31.0.987771003839.issue27903@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Use opened files as context managers.

----------
components: Library (Lib)
files: platform-resourcewarning.patch
keywords: patch
messages: 273969
nosy: scop
priority: normal
severity: normal
status: open
title: Avoid ResourceWarnings from platform._dist_try_harder
type: enhancement
Added file: http://bugs.python.org/file44283/platform-resourcewarning.patch

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

From report at bugs.python.org  Tue Aug 30 17:35:23 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 30 Aug 2016 21:35:23 +0000
Subject: [New-bugs-announce] [issue27904] Let logging format more messages
 on demand
Message-ID: <1472592923.29.0.193316525032.issue27904@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Avoid some string formatting operations on disabled log levels.

----------
files: logging.patch
keywords: patch
messages: 273971
nosy: scop
priority: normal
severity: normal
status: open
title: Let logging format more messages on demand
type: performance
Added file: http://bugs.python.org/file44284/logging.patch

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

From report at bugs.python.org  Tue Aug 30 17:51:20 2016
From: report at bugs.python.org (Michael Lee)
Date: Tue, 30 Aug 2016 21:51:20 +0000
Subject: [New-bugs-announce] [issue27905] Add documentation for typing.Type
Message-ID: <1472593880.19.0.114422348142.issue27905@psf.upfronthosting.co.za>


New submission from Michael Lee:

This patch adds some documentation for typing.Type[C]. The content itself is mostly an abbreviated version of the description from PEP 484 -- let me know if the patch is too terse or needs more examples.

----------
assignee: docs at python
components: Documentation
files: document-type.patch
keywords: patch
messages: 273974
nosy: docs at python, gvanrossum, michael0x2a
priority: normal
severity: normal
status: open
title: Add documentation for typing.Type
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44285/document-type.patch

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

From report at bugs.python.org  Tue Aug 30 21:57:24 2016
From: report at bugs.python.org (kevinconway)
Date: Wed, 31 Aug 2016 01:57:24 +0000
Subject: [New-bugs-announce] [issue27906] Socket accept exhaustion during
 high TCP traffic
Message-ID: <1472608644.33.0.983787454696.issue27906@psf.upfronthosting.co.za>


New submission from kevinconway:

My organization noticed this issue after launching several asyncio services that would receive either a sustained high number of incoming connections or regular bursts of traffic. Our monitoring showed a loss of between 4% and 6% of all incoming requests. On the client side we see a socket read error "Connection reset by peer". On the asyncio side, with debug turned on, we see nothing.

After some more investigation we determined asyncio was not calling 'accept()' on the listening socket fast enough. To further test this we put together several hello-world type examples and put them under load. I've attached the project we used to test. Included are three docker files that will run the services under different configurations. One runs the service as an aiohttp service, the other uses the aiohttp worker behind gunicorn, and the third runs the aiohttp service with the proposed asyncio patch in place. For our testing we used 'wrk' to generate traffic and collect data on the OS/socket errors.

For anyone attempting to recreate our experiments, we ran a three test batteries against the service for each endpoint using:

wrk --duration 30s --timeout 10s --latency --threads 2 --connections 10 <URL>
wrk --duration 30s --timeout 10s --latency --threads 2 --connections 100 <URL>
wrk --duration 30s --timeout 10s --latency --threads 2 --connections 1000 <URL>

The endpoints most valuable for us to test were the ones that replicated some of our production logic:

<URL>/  # Hello World
<URL>/sleep?time=100  # Every request is delayed by 100 milliseconds and returns an HTML message.
<URL>/blocking/inband  # Every request performs a bcrypt with complexity 10 and performs the CPU blocking work on the event loop thread.

Our results varied based on the available CPU cycles, but we consistently recreate the socket read errors from production using the above tests.

Our proposed solution, attached as a patch file, is to put the socket.accept() call in a loop that is bounded by the listening socket's backlog. We use the backlog value as an upper bound to prevent the reverse situation of starving active coroutines while the event loop continues to accept new connections without yielding. With the proposed patch in place our loss rate disappeared.

For further comparison, we reviewed the socket accept logic in Twisted against which we ran similar tests and encountered no loss. We found that Twisted already runs the socket accept in a bounded loop to prevent this issue (https://github.com/twisted/twisted/blob/trunk/src/twisted/internet/tcp.py#L1028).

----------
components: asyncio
files: testservice.zip
messages: 273989
nosy: gvanrossum, haypo, kevinconway, yselivanov
priority: normal
severity: normal
status: open
title: Socket accept exhaustion during high TCP traffic
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44286/testservice.zip

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

From report at bugs.python.org  Wed Aug 31 02:41:26 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 31 Aug 2016 06:41:26 +0000
Subject: [New-bugs-announce] [issue27907] Misspelled variable in
 test_asyncio/test_events
Message-ID: <1472625686.63.0.686999719276.issue27907@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Simply renaming the variable breaks the test which is why it was left out of #27895, this one keeps the test working.

----------
files: reponse.patch
keywords: patch
messages: 274001
nosy: scop
priority: normal
severity: normal
status: open
title: Misspelled variable in test_asyncio/test_events
type: enhancement
Added file: http://bugs.python.org/file44291/reponse.patch

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

From report at bugs.python.org  Wed Aug 31 03:27:39 2016
From: report at bugs.python.org (Dima Tisnek)
Date: Wed, 31 Aug 2016 07:27:39 +0000
Subject: [New-bugs-announce] [issue27908] del _limbo[self] KeyError
Message-ID: <1472628459.0.0.615351058754.issue27908@psf.upfronthosting.co.za>


New submission from Dima Tisnek:

To reproduce:

```
import threading
import time


class U(threading.Thread):
    def run(self):
        time.sleep(1)
        if not x.ident:
            x.start()


x = U()
for u in [U() for i in range(10000)]: u.start()

time.sleep(10)
```

Chance to reproduce ~20% in my setup.
This script has a data race (check then act on x.ident).
I expected it to occasionally hit `RuntimeError: threads can only be started once`

Instead, I get:
```
Unhandled exception in thread started by <bound method Thread._bootstrap of <U(Thread-1, started 139798116361984)>>
Traceback (most recent call last):
  File "/usr/lib64/python3.5/threading.py", line 882, in _bootstrap
    self._bootstrap_inner()
  File "/usr/lib64/python3.5/threading.py", line 906, in _bootstrap_inner
    del _limbo[self]
KeyError: <U(Thread-1, started 139798116361984)>
```

----------
components: Library (Lib)
messages: 274005
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: del _limbo[self] KeyError
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 31 05:26:29 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Aug 2016 09:26:29 +0000
Subject: [New-bugs-announce] [issue27909] Py_INCREF(NULL) in
 _imp.create_builtin
Message-ID: <1472635589.59.0.774890497222.issue27909@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Just as the patch shows, when PyErr_Occurred() returns true mod is NULL, then Py_INCREF(mod) will crash. Replace it with Py_XINCREF.

----------
components: Interpreter Core
files: create_builtin.patch
keywords: patch
messages: 274007
nosy: brett.cannon, eric.snow, ncoghlan, xiang.zhang
priority: normal
severity: normal
status: open
title: Py_INCREF(NULL) in _imp.create_builtin
type: crash
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44292/create_builtin.patch

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

From report at bugs.python.org  Wed Aug 31 06:04:49 2016
From: report at bugs.python.org (Tomas Orsava)
Date: Wed, 31 Aug 2016 10:04:49 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue27910=5D_Doc/library/traceb?=
 =?utf-8?q?ack=2Erst_=E2=80=94_references_to_tuples_should_be_replaced_wit?=
 =?utf-8?q?h_new_FrameSummary_object?=
Message-ID: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>


New submission from Tomas Orsava:

In the documentation for the `traceback` module, the definitions of functions `extract_tb` [0], `format_list` [1] and classmethod `from_list` [2] mention the old style (4-)tuples that these functions used to return or accept.

Since Python 3.5, however, they return or accept a FrameSummary object instead of the 4-tuple, or a StackSummary object instead of a list of 4-tuples.

I'm including a patch that fixes these definitions to make them reflect the new reality.

[0] https://docs.python.org/3.6/library/traceback.html#traceback.extract_tb
[1] https://docs.python.org/3.6/library/traceback.html#traceback.format_list
[2] https://docs.python.org/3.6/library/traceback.html#traceback.StackSummary.from_list

----------
assignee: docs at python
components: Documentation
files: traceback-doc.patch
keywords: patch
messages: 274010
nosy: docs at python, torsava
priority: normal
severity: normal
status: open
title: Doc/library/traceback.rst ? references to tuples should be replaced with new FrameSummary object
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44293/traceback-doc.patch

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

From report at bugs.python.org  Wed Aug 31 07:22:37 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Aug 2016 11:22:37 +0000
Subject: [New-bugs-announce] [issue27911] Unnecessary error checks in
 exec_builtin_or_dynamic
Message-ID: <1472642557.88.0.0235891214723.issue27911@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The two PyErr_Occurred check in exec_builtin_or_dynamic are unnecessary. The PyModule_Check at the beginning of exec_builtin_or_dynamic has eliminated the possibility for PyModule_GetDef/State to fail.

----------
components: Interpreter Core
files: exec_built_or_dynamic.patch
keywords: patch
messages: 274015
nosy: brett.cannon, eric.snow, ncoghlan, xiang.zhang
priority: normal
severity: normal
status: open
title: Unnecessary error checks in exec_builtin_or_dynamic
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44294/exec_built_or_dynamic.patch

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

From report at bugs.python.org  Wed Aug 31 09:27:34 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 31 Aug 2016 13:27:34 +0000
Subject: [New-bugs-announce] [issue27912] Distutils should use warehouse for
 index
Message-ID: <1472650054.23.0.773027270179.issue27912@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

As pypi.python.org is quickly becoming deprecated and pypi.org is the new best recommendation for packages, I recommend that for Python 3.6, the default index should be pypi.org.

----------
components: Distutils
messages: 274017
nosy: dstufft, eric.araujo, jason.coombs
priority: normal
severity: normal
status: open
title: Distutils should use warehouse for index
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 31 10:37:05 2016
From: report at bugs.python.org (vincenzo gisondi)
Date: Wed, 31 Aug 2016 14:37:05 +0000
Subject: [New-bugs-announce] [issue27913] Difflib.ndiff (Problem on
 identification of changes as Diff Style)
Message-ID: <1472654225.41.0.864663754279.issue27913@psf.upfronthosting.co.za>


New submission from vincenzo gisondi:

I found an anomaly on identification of changes as Diff Style (^).

There are the tests that i done:

1) First Test (only one character is different)

>>> a = "Hello Vincenzo\n".splitlines(1)
>>> b = "Hello Vincenza\n".splitlines(1)
>>> a
['Hello Vincenzo\n']
>>> b
['Hello Vincenza\n']
>>> diff = difflib.ndiff(a,b)
>>> print(''.join(diff))
- Hello Vincenzo
?              ^
+ Hello Vincenza
?              ^


2) Second Test (two characters are differents)

>>> a = "Hello Vincenzo\n".splitlines(1)
>>> b = "Hello Vincensa\n".splitlines(1)
>>> a
['Hello Vincenzo\n']
>>> b
['Hello Vincensa\n']
>>> diff = difflib.ndiff(a,b)
>>> print(''.join(diff))
- Hello Vincenzo
?             ^^
+ Hello Vincensa
?             ^^

3) Third Test (three characters are differents)

>>> a = "Hello Vincenzo\n".splitlines(1)
>>> b = "Helto Bincenza\n".splitlines(1)
>>> a
['Hello Vincenzo\n']
>>> b
['Helto Bincenza\n']
>>> diff = difflib.ndiff(a,b)
>>> print(''.join(diff))
- Hello Vincenzo
?    ^  ^      ^
+ Helto Bincenza
?    ^  ^      ^

4) Fourth test (four characters are differents -> Anomaly)

>>> a = "Hello Vincenzo\n".splitlines(1)
>>> b = "Halto Bincenza\n".splitlines(1)
>>> a
['Hello Vincenzo\n']
>>> b
['Halto Bincenza\n']
>>> diff = difflib.ndiff(a,b)
>>> print(''.join(diff))
- Hello Vincenzo
+ Halto Bincenza

In this last test I expected 4 "^" characters as in previous tests, like this:

- Hello Vincenzo
?  ^ ^  ^      ^
+ Halto Bincenza
?  ^ ^  ^      ^

but I have a response completly different. This is a Bug or I did not understand something :)

Thank you very much for your support.

----------
components: Library (Lib)
messages: 274023
nosy: vincenzo gisondi
priority: normal
severity: normal
status: open
title: Difflib.ndiff (Problem on identification of changes as Diff Style)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 31 10:38:40 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Aug 2016 14:38:40 +0000
Subject: [New-bugs-announce] [issue27914] Incorrect comment in
 PyModule_ExcDef
Message-ID: <1472654320.9.0.438232353542.issue27914@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

There is a comment in PyModule_ExcDef:

    /* handled in PyModule_CreateFromSlots */

But there seems never exists PyModule_CreateFromSlots, I think PyModule_CreateFromSlots should be PyModule_FromDefAndSpec2.

----------
files: PyModule_ExcDef_comment.patch
keywords: patch
messages: 274024
nosy: ncoghlan, xiang.zhang
priority: normal
severity: normal
status: open
title: Incorrect comment in PyModule_ExcDef
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44299/PyModule_ExcDef_comment.patch

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

From report at bugs.python.org  Wed Aug 31 11:08:49 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 31 Aug 2016 15:08:49 +0000
Subject: [New-bugs-announce] [issue27915] Use 'ascii' instead of 'us-ascii'
 to bypass lookup machinery
Message-ID: <1472656129.69.0.589278825642.issue27915@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

https://docs.python.org/3/library/codecs.html#standard-encodings

There are a bunch of other us-ascii occurrences in the tree; this patch covers the ones that are not user visible in a way that could cause problems or changes in behavior.

----------
files: ascii.patch
keywords: patch
messages: 274028
nosy: scop
priority: normal
severity: normal
status: open
title: Use 'ascii' instead of 'us-ascii' to bypass lookup machinery
type: performance
Added file: http://bugs.python.org/file44300/ascii.patch

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

From report at bugs.python.org  Wed Aug 31 11:51:16 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 31 Aug 2016 15:51:16 +0000
Subject: [New-bugs-announce] [issue27916] Use time.monotonic instead of
 time.time where appropriate
Message-ID: <1472658676.29.0.976088579174.issue27916@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

For better immunity against system clock changes.

----------
files: monotonic.patch
keywords: patch
messages: 274036
nosy: scop
priority: normal
severity: normal
status: open
title: Use time.monotonic instead of time.time where appropriate
type: enhancement
Added file: http://bugs.python.org/file44304/monotonic.patch

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

From report at bugs.python.org  Wed Aug 31 13:23:02 2016
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 31 Aug 2016 17:23:02 +0000
Subject: [New-bugs-announce] [issue27917] Choose platform triplets for
 android builds
Message-ID: <1472664182.04.0.808044107664.issue27917@psf.upfronthosting.co.za>


New submission from Matthias Klose:

Following up to http://bugs.python.org/issue23968, I think we should choose different platform triplets for the android builds than we do for the linux builds.  Not sure which ones.

I saw the following gnu triplets used:

 - i686-linux-android
 - arm-linux-androidabi

Looking at the two cross compilers from the Ubuntu archive, I see that the arm compiler defines a __ANDROID__ macro, while the i686 compiler doesn't, so it might be difficult to select the correct platform triplet.

Could somebody check different compilers (clang as well) to see if this macro is defined?

<gcc|clang>  -E -dM - < /dev/null|grep -i android

Not sure which architectures else should be defined, but aarch64 comes to my mind as well.

----------
components: Build
messages: 274041
nosy: doko
priority: normal
severity: normal
status: open
title: Choose platform triplets for android builds

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

From report at bugs.python.org  Wed Aug 31 13:36:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 31 Aug 2016 17:36:42 +0000
Subject: [New-bugs-announce] [issue27918] Running test suites without gui
 but still having windows flash
Message-ID: <1472665002.34.0.0850471901825.issue27918@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

When I run test suites I find something interesting. Even if I don't enable gui resource there are still windows flashing. The two tests are test_idle and test_tk. I think the root cause is that they both use test.support.import_module with no reason and then root.update(in _is_gui_available) is called and windows flash. Comment out root.update windows are gone. Is this a must or can we find some way to suppress this?

----------
components: Tests
messages: 274045
nosy: ned.deily, xiang.zhang
priority: normal
severity: normal
status: open
title: Running test suites without gui but still having windows flash
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 31 15:06:14 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 31 Aug 2016 19:06:14 +0000
Subject: [New-bugs-announce] [issue27919] Deprecate and remove extra_path
 distribution kwarg
Message-ID: <1472670374.61.0.857588658064.issue27919@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

extra_path is implicated in [this failure](https://github.com/jaraco/rwt/issues/7) and in general in any attempt to install to a path in PYTHONPATH that's not in site-packages. For example:

$ python -m pip install -t foo newrelic
Collecting newrelic
Installing collected packages: newrelic
Successfully installed newrelic
$ ls foo
newrelic-2.68.0.50		newrelic-2.68.0.50.dist-info	newrelic.pth
$ PYTHONPATH=foo python -c "import newrelic"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'newrelic'


As a result, extra_path (undocumented per issue901727) causes disruption in tools like rwt, and gives the packager the ability to break the convention for installing the package, relying on .pth files which only work in select locations.

I suggest we deprecate extra_path.

----------
components: Distutils
messages: 274060
nosy: dstufft, eric.araujo, jason.coombs
priority: normal
severity: normal
status: open
title: Deprecate and remove extra_path distribution kwarg
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 31 15:35:50 2016
From: report at bugs.python.org (Divyansh Khattak)
Date: Wed, 31 Aug 2016 19:35:50 +0000
Subject: [New-bugs-announce] [issue27920] Embedding python in a shared
 library fails to import the Python module
Message-ID: <1472672150.5.0.175635801824.issue27920@psf.upfronthosting.co.za>


New submission from Divyansh Khattak:

I am having the same error as described by https://bugs.python.org/issue19153 and http://bugs.python.org/issue4434. My shared library is unable to import the Python module I created. I am attaching my C file which calls the python function Rough.py, whose code is written as under:
import math
def WallRough(*wss):
    size=len(wss)
   
    result=[0 for i in range(size)]
    for i in range(size):
       
        wss_mag=math.sqrt(wss[i][0]*wss[i][0]+wss[i][1]*wss[i][1]+wss[i][2]*wss[i][2])
       
        result[i]=1
    
    return result

----------
components: Build
files: pystack.c
messages: 274062
nosy: suzaku
priority: normal
severity: normal
status: open
title: Embedding python in a shared library fails to import the Python module
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file44305/pystack.c

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

From report at bugs.python.org  Wed Aug 31 19:49:40 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 31 Aug 2016 23:49:40 +0000
Subject: [New-bugs-announce] [issue27921] f-strings: do not allow backslashes
Message-ID: <1472687380.69.0.18258745604.issue27921@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

See https://mail.python.org/pipermail/python-dev/2016-August/145979.html for details.

PEP 498 is going to be changed to disallow backslashes inside braces (the expression portions of an f-string).

However, I can't get that change done in time for 3.6 beta 1. So, this bug will disallow any backslashes in f-strings. Before the next beta, I'll implement the correct behavior.

This is a breaking change: f-strings like f'\\t{3}' which worked in 3.6 alphas will not work in 3.6 beta 1, but will work in beta 2. f-strings like f'{\'x\'}' which worked in 3.6 alphas, will not work in any beta or release version of 3.6.

----------
assignee: eric.smith
components: Interpreter Core
messages: 274079
nosy: eric.smith, ned.deily
priority: release blocker
severity: normal
status: open
title: f-strings: do not allow backslashes
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug 31 20:33:36 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Sep 2016 00:33:36 +0000
Subject: [New-bugs-announce] [issue27922] Make IDLE tests less flashy
Message-ID: <1472690016.39.0.67314028817.issue27922@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This issue follows-up on #27732, which suppressed beeps during IDLE tests, I want to also suppress the flashing of tk widget boxes, which has become visually obnoxious with the increasing number of tests.

Adding root.withdraw() after root = Tk() solves the problem for all current tests.  For test_textview, this requires the fix of a bad cleanup call and addition of another.  It appears that the textview toplevels must be destroyed before the cleanup call to root.update_idletasks() or else they are made visible.  The idletasks call is needed to avoid '''can't invoke "event" command''' (even with all toplevels gone).

The backports will have fewer changes because there are fewer tests.

----------
assignee: terry.reedy
components: IDLE
files: flashy.diff
keywords: patch
messages: 274080
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Make IDLE tests less flashy
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44310/flashy.diff

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

From report at bugs.python.org  Wed Aug 31 20:56:19 2016
From: report at bugs.python.org (Elias Zamaria)
Date: Thu, 01 Sep 2016 00:56:19 +0000
Subject: [New-bugs-announce] [issue27923] PEP 467 -- Minor API improvements
 for binary sequences
Message-ID: <1472691379.75.0.669592694643.issue27923@psf.upfronthosting.co.za>


New submission from Elias Zamaria:

This is my attempt at implementing PEP 467.

I am not an expert in the details of the Python interpreter, and this is my first time working on a big project in C, so I am not sure if I am doing things in the most elegant or efficient way, but it seems to work fine, as far as I can tell.

I have added some tests for the new functionality. I am planning to work on changes to the documentation some time in the next few days.

I noticed a lot of places that are using the deprecated integer-argument bytes and bytearray constructors. I left most of them alone, although I changed a few of them to the zeros constructors to prevent certain tests from failing.

----------
components: Interpreter Core
files: pep467.patch
keywords: patch
messages: 274082
nosy: mikez302
priority: normal
severity: normal
status: open
title: PEP 467 -- Minor API improvements for binary sequences
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44312/pep467.patch

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

From report at bugs.python.org  Wed Aug 31 23:02:56 2016
From: report at bugs.python.org (John Mark Vandenberg)
Date: Thu, 01 Sep 2016 03:02:56 +0000
Subject: [New-bugs-announce] [issue27924] ensurepip raises TypeError after
 pip uninstall
Message-ID: <1472698976.68.0.784480763699.issue27924@psf.upfronthosting.co.za>


New submission from John Mark Vandenberg:

After uninstalling pip on Fedora 24, ensurepip get_records_to_pack returns None, causing rewheel.rewheel_from_record to raise TypeError: 'NoneType' object is not iterable.

While this is probably not a scenario that CPython supports directly, it would be nice if it handled it a bit better.

Presumably this is using the system python-pip 8.1.0, while there is another pip present, and it is uninstalling both pip 7.1.2 and 8.1.0 at the same time.

$ sudo pip uninstall pip
Uninstalling pip-7.1.2:
  /usr/bin/pip
  /usr/bin/pip2
  /usr/bin/pip2.7
  /usr/lib/python2.7/site-packages/pip-7.1.2.dist-info/DESCRIPTION.rst
  /usr/lib/python2.7/site-packages/pip-7.1.2.dist-info/METADATA
  /usr/lib/python2.7/site-packages/pip-7.1.2.dist-info/RECORD
  /usr/lib/python2.7/site-packages/pip-7.1.2.dist-info/WHEEL
  /usr/lib/python2.7/site-packages/pip-7.1.2.dist-info/entry_points.txt
  /usr/lib/python2.7/site-packages/pip-7.1.2.dist-info/metadata.json
  /usr/lib/python2.7/site-packages/pip-7.1.2.dist-info/pbr.json
  /usr/lib/python2.7/site-packages/pip-7.1.2.dist-info/top_level.txt
  /usr/lib/python2.7/site-packages/pip/__init__.py
  /usr/lib/python2.7/site-packages/pip/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/__main__.py
  /usr/lib/python2.7/site-packages/pip/__main__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/_markerlib/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/_markerlib/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/_markerlib/markers.py
  /usr/lib/python2.7/site-packages/pip/_vendor/_markerlib/markers.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/adapter.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/adapter.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/cache.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/cache.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/caches/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/caches/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/caches/file_cache.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/caches/file_cache.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/caches/redis_cache.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/caches/redis_cache.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/compat.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/compat.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/controller.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/controller.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/filewrapper.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/filewrapper.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/heuristics.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/heuristics.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/serialize.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/serialize.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/wrapper.py
  /usr/lib/python2.7/site-packages/pip/_vendor/cachecontrol/wrapper.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/ansi.py
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/ansi.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/ansitowin32.py
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/ansitowin32.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/initialise.py
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/initialise.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/win32.py
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/win32.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/winterm.py
  /usr/lib/python2.7/site-packages/pip/_vendor/colorama/winterm.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/misc.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/misc.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/shutil.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/shutil.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/sysconfig.cfg
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/sysconfig.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/sysconfig.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/tarfile.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/_backport/tarfile.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/compat.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/compat.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/database.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/database.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/index.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/index.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/locators.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/locators.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/manifest.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/manifest.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/markers.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/markers.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/metadata.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/metadata.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/resources.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/resources.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/scripts.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/scripts.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/t32.exe
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/t64.exe
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/util.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/util.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/version.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/version.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/w32.exe
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/w64.exe
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/wheel.py
  /usr/lib/python2.7/site-packages/pip/_vendor/distlib/wheel.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/constants.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/constants.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/_base.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/_base.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/alphabeticalattributes.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/alphabeticalattributes.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/inject_meta_charset.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/inject_meta_charset.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/lint.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/lint.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/optionaltags.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/optionaltags.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/sanitizer.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/sanitizer.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/whitespace.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/filters/whitespace.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/html5parser.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/html5parser.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/ihatexml.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/ihatexml.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/inputstream.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/inputstream.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/sanitizer.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/sanitizer.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/serializer/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/serializer/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/serializer/htmlserializer.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/serializer/htmlserializer.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/tokenizer.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/tokenizer.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treeadapters/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treeadapters/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treeadapters/sax.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treeadapters/sax.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/_base.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/_base.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/dom.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/dom.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/etree.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/etree.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/etree_lxml.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treebuilders/etree_lxml.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/_base.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/_base.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/dom.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/dom.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/etree.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/etree.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/genshistream.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/genshistream.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/lxmletree.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/lxmletree.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/pulldom.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/treewalkers/pulldom.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/trie/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/trie/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/trie/_base.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/trie/_base.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/trie/datrie.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/trie/datrie.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/trie/py.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/trie/py.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/utils.py
  /usr/lib/python2.7/site-packages/pip/_vendor/html5lib/utils.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/ipaddress.py
  /usr/lib/python2.7/site-packages/pip/_vendor/ipaddress.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/linklockfile.py
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/linklockfile.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/mkdirlockfile.py
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/mkdirlockfile.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/pidlockfile.py
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/pidlockfile.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/sqlitelockfile.py
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/sqlitelockfile.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/symlinklockfile.py
  /usr/lib/python2.7/site-packages/pip/_vendor/lockfile/symlinklockfile.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/__about__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/__about__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/_compat.py
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/_compat.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/_structures.py
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/_structures.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/specifiers.py
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/specifiers.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/version.py
  /usr/lib/python2.7/site-packages/pip/_vendor/packaging/version.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/pkg_resources/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/bar.py
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/bar.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/counter.py
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/counter.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/helpers.py
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/helpers.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/spinner.py
  /usr/lib/python2.7/site-packages/pip/_vendor/progress/spinner.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/re-vendor.py
  /usr/lib/python2.7/site-packages/pip/_vendor/re-vendor.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/adapters.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/adapters.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/api.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/api.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/auth.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/auth.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/cacert.pem
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/certs.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/certs.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/compat.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/compat.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/cookies.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/cookies.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/exceptions.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/exceptions.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/hooks.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/hooks.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/models.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/models.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/big5freq.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/big5freq.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/big5prober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/big5prober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/chardetect.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/chardetect.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/chardistribution.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/chardistribution.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/charsetgroupprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/charsetgroupprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/charsetprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/charsetprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/codingstatemachine.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/codingstatemachine.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/compat.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/compat.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/constants.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/constants.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/cp949prober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/cp949prober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/escprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/escprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/escsm.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/escsm.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/eucjpprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/eucjpprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/euckrfreq.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/euckrfreq.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/euckrprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/euckrprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/euctwfreq.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/euctwfreq.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/euctwprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/euctwprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/gb2312freq.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/gb2312freq.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/gb2312prober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/gb2312prober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/hebrewprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/hebrewprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/jisfreq.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/jisfreq.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/jpcntx.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/jpcntx.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langbulgarianmodel.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langbulgarianmodel.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langcyrillicmodel.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langcyrillicmodel.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langgreekmodel.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langgreekmodel.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langhebrewmodel.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langhebrewmodel.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langhungarianmodel.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langhungarianmodel.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langthaimodel.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/langthaimodel.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/latin1prober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/latin1prober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/mbcharsetprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/mbcharsetprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/mbcsgroupprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/mbcsgroupprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/mbcssm.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/mbcssm.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/sbcharsetprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/sbcharsetprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/sbcsgroupprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/sbcsgroupprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/sjisprober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/sjisprober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/universaldetector.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/universaldetector.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/utf8prober.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/chardet/utf8prober.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/_collections.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/_collections.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/connection.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/connection.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/connectionpool.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/connectionpool.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/contrib/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/contrib/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/contrib/ntlmpool.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/contrib/ntlmpool.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/exceptions.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/exceptions.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/fields.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/fields.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/filepost.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/filepost.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/ordered_dict.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/ordered_dict.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/six.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/six.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/ssl_match_hostname/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/ssl_match_hostname/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/ssl_match_hostname/_implementation.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/packages/ssl_match_hostname/_implementation.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/poolmanager.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/poolmanager.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/request.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/request.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/response.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/response.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/__init__.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/connection.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/connection.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/request.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/request.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/response.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/response.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/retry.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/retry.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/timeout.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/timeout.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/url.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/url.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/sessions.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/sessions.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/status_codes.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/status_codes.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/structures.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/structures.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/utils.py
  /usr/lib/python2.7/site-packages/pip/_vendor/requests/utils.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/retrying.py
  /usr/lib/python2.7/site-packages/pip/_vendor/retrying.pyc
  /usr/lib/python2.7/site-packages/pip/_vendor/six.py
  /usr/lib/python2.7/site-packages/pip/_vendor/six.pyc
  /usr/lib/python2.7/site-packages/pip/basecommand.py
  /usr/lib/python2.7/site-packages/pip/basecommand.pyc
  /usr/lib/python2.7/site-packages/pip/baseparser.py
  /usr/lib/python2.7/site-packages/pip/baseparser.pyc
  /usr/lib/python2.7/site-packages/pip/cmdoptions.py
  /usr/lib/python2.7/site-packages/pip/cmdoptions.pyc
  /usr/lib/python2.7/site-packages/pip/commands/__init__.py
  /usr/lib/python2.7/site-packages/pip/commands/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/commands/completion.py
  /usr/lib/python2.7/site-packages/pip/commands/completion.pyc
  /usr/lib/python2.7/site-packages/pip/commands/freeze.py
  /usr/lib/python2.7/site-packages/pip/commands/freeze.pyc
  /usr/lib/python2.7/site-packages/pip/commands/help.py
  /usr/lib/python2.7/site-packages/pip/commands/help.pyc
  /usr/lib/python2.7/site-packages/pip/commands/install.py
  /usr/lib/python2.7/site-packages/pip/commands/install.pyc
  /usr/lib/python2.7/site-packages/pip/commands/list.py
  /usr/lib/python2.7/site-packages/pip/commands/list.pyc
  /usr/lib/python2.7/site-packages/pip/commands/search.py
  /usr/lib/python2.7/site-packages/pip/commands/search.pyc
  /usr/lib/python2.7/site-packages/pip/commands/show.py
  /usr/lib/python2.7/site-packages/pip/commands/show.pyc
  /usr/lib/python2.7/site-packages/pip/commands/uninstall.py
  /usr/lib/python2.7/site-packages/pip/commands/uninstall.pyc
  /usr/lib/python2.7/site-packages/pip/commands/wheel.py
  /usr/lib/python2.7/site-packages/pip/commands/wheel.pyc
  /usr/lib/python2.7/site-packages/pip/compat/__init__.py
  /usr/lib/python2.7/site-packages/pip/compat/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/compat/dictconfig.py
  /usr/lib/python2.7/site-packages/pip/compat/dictconfig.pyc
  /usr/lib/python2.7/site-packages/pip/download.py
  /usr/lib/python2.7/site-packages/pip/download.pyc
  /usr/lib/python2.7/site-packages/pip/exceptions.py
  /usr/lib/python2.7/site-packages/pip/exceptions.pyc
  /usr/lib/python2.7/site-packages/pip/index.py
  /usr/lib/python2.7/site-packages/pip/index.pyc
  /usr/lib/python2.7/site-packages/pip/locations.py
  /usr/lib/python2.7/site-packages/pip/locations.pyc
  /usr/lib/python2.7/site-packages/pip/models/__init__.py
  /usr/lib/python2.7/site-packages/pip/models/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/models/index.py
  /usr/lib/python2.7/site-packages/pip/models/index.pyc
  /usr/lib/python2.7/site-packages/pip/operations/__init__.py
  /usr/lib/python2.7/site-packages/pip/operations/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/operations/freeze.py
  /usr/lib/python2.7/site-packages/pip/operations/freeze.pyc
  /usr/lib/python2.7/site-packages/pip/pep425tags.py
  /usr/lib/python2.7/site-packages/pip/pep425tags.pyc
  /usr/lib/python2.7/site-packages/pip/req/__init__.py
  /usr/lib/python2.7/site-packages/pip/req/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/req/req_file.py
  /usr/lib/python2.7/site-packages/pip/req/req_file.pyc
  /usr/lib/python2.7/site-packages/pip/req/req_install.py
  /usr/lib/python2.7/site-packages/pip/req/req_install.pyc
  /usr/lib/python2.7/site-packages/pip/req/req_set.py
  /usr/lib/python2.7/site-packages/pip/req/req_set.pyc
  /usr/lib/python2.7/site-packages/pip/req/req_uninstall.py
  /usr/lib/python2.7/site-packages/pip/req/req_uninstall.pyc
  /usr/lib/python2.7/site-packages/pip/status_codes.py
  /usr/lib/python2.7/site-packages/pip/status_codes.pyc
  /usr/lib/python2.7/site-packages/pip/utils/__init__.py
  /usr/lib/python2.7/site-packages/pip/utils/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/utils/appdirs.py
  /usr/lib/python2.7/site-packages/pip/utils/appdirs.pyc
  /usr/lib/python2.7/site-packages/pip/utils/build.py
  /usr/lib/python2.7/site-packages/pip/utils/build.pyc
  /usr/lib/python2.7/site-packages/pip/utils/deprecation.py
  /usr/lib/python2.7/site-packages/pip/utils/deprecation.pyc
  /usr/lib/python2.7/site-packages/pip/utils/filesystem.py
  /usr/lib/python2.7/site-packages/pip/utils/filesystem.pyc
  /usr/lib/python2.7/site-packages/pip/utils/logging.py
  /usr/lib/python2.7/site-packages/pip/utils/logging.pyc
  /usr/lib/python2.7/site-packages/pip/utils/outdated.py
  /usr/lib/python2.7/site-packages/pip/utils/outdated.pyc
  /usr/lib/python2.7/site-packages/pip/utils/ui.py
  /usr/lib/python2.7/site-packages/pip/utils/ui.pyc
  /usr/lib/python2.7/site-packages/pip/vcs/__init__.py
  /usr/lib/python2.7/site-packages/pip/vcs/__init__.pyc
  /usr/lib/python2.7/site-packages/pip/vcs/bazaar.py
  /usr/lib/python2.7/site-packages/pip/vcs/bazaar.pyc
  /usr/lib/python2.7/site-packages/pip/vcs/git.py
  /usr/lib/python2.7/site-packages/pip/vcs/git.pyc
  /usr/lib/python2.7/site-packages/pip/vcs/mercurial.py
  /usr/lib/python2.7/site-packages/pip/vcs/mercurial.pyc
  /usr/lib/python2.7/site-packages/pip/vcs/subversion.py
  /usr/lib/python2.7/site-packages/pip/vcs/subversion.pyc
  /usr/lib/python2.7/site-packages/pip/wheel.py
  /usr/lib/python2.7/site-packages/pip/wheel.pyc
Proceed (y/n)? y
  Successfully uninstalled pip-7.1.2
You are using pip version 8.1.0, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

$ sudo python -m pip uninstall pip
/bin/python: No module named pip

$ sudo python -m ensurepip
Traceback (most recent call last):
  File "/usr/lib64/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/usr/lib64/python2.7/ensurepip/__main__.py", line 4, in <module>
    ensurepip._main()
  File "/usr/lib64/python2.7/ensurepip/__init__.py", line 248, in _main
    default_pip=args.default_pip,
  File "/usr/lib64/python2.7/ensurepip/__init__.py", line 110, in bootstrap
    new_whl = rewheel.rewheel_from_record(dr, rewheel_dir)
  File "/usr/lib64/python2.7/ensurepip/rewheel/__init__.py", line 75, in rewheel_from_record
    to_write, to_omit = get_records_to_pack(site_dir, record_relpath)
TypeError: 'NoneType' object is not iterable

$ python --version
Python 2.7.12
$ dnf info python-pip
Installed Packages
Name        : python-pip
Arch        : noarch
Epoch       : 0
Version     : 8.0.2
Release     : 1.fc24
Size        : 7.1 M
Repo        : @System
Summary     : A tool for installing and managing Python packages
URL         : http://www.pip-installer.org
License     : MIT
Description : Pip is a replacement for `easy_install
            : <http://peak.telecommunity.com/DevCenter/EasyInstall>`_.  It uses mostly the
            : same techniques for finding packages, so packages that were made
            : easy_installable should be pip-installable as well.

----------
components: Library (Lib)
messages: 274089
nosy: jayvdb
priority: normal
severity: normal
status: open
title: ensurepip raises TypeError after pip uninstall
type: crash
versions: Python 2.7

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