From report at bugs.python.org  Mon Jul  1 02:30:30 2019
From: report at bugs.python.org (aeros167)
Date: Mon, 01 Jul 2019 06:30:30 +0000
Subject: [New-bugs-announce] [issue37462] Default starting directory for
 os.walk()
Message-ID: <1561962630.68.0.390698602335.issue37462@roundup.psfhosted.org>


New submission from aeros167 <aeros167 at gmail.com>:

As a quality of life enhancement, it would beneficial to set a default starting directory for os.walk() to use when one is not specified. I would suggest for this to be the system's current working directory. 

The implementation would be rather straightforward, and should not cause any compatibility issues. In the function definition for walk in os.py, it would simply need to be changed from "def walk(top, topdown=True, onerror=None, followlinks=False)" to "def walk(top=".", topdown=True, onerror=None, followlinks=False)".

As a separate topic but relevant to os.walk(), the current name of the positional argument which specifies the starting directory is currently called "top". However, a more descriptive word for the argument would probably be "root", "dir", "directory", or "start". The term "top" is quite generic and is not used to describe a filesystem position. 

Personally, I'm the most in favor of "root" as it describes the highest parent node of a tree, and provides an accurate description of its purpose.  However, I will hold off on adding a PR for this change until some feedback is added, as it is not essential to the initial issue.

Changing the name of argument could cause potential compatibility issues if the name is specified when using os.walk(), such as in "os.walk(top="dirpath")". However, doing so would be significantly unconventional. In the majority of common use cases, os.walk() only uses the first argument, so there is no need to specify the keyword. Even when more than one is used, usually the first argument is specified by position rather than keyword.

----------
components: Library (Lib)
messages: 346961
nosy: aeros167
priority: normal
severity: normal
status: open
title: Default starting directory for os.walk()
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37462>
_______________________________________

From report at bugs.python.org  Mon Jul  1 02:47:04 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 01 Jul 2019 06:47:04 +0000
Subject: [New-bugs-announce] [issue37463] socket.inet_aton IP parsing issue
 in ssl.match_hostname
Message-ID: <1561963624.13.0.490304493984.issue37463@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

inet_aton accepts trailing characterrs after a valid IP (
https://bugzilla.redhat.com/show_bug.cgi?id=1347549). This, in combination with its use inside ssl.match_hostname, allows the following code to work when it should fail:

import ssl
cert = {'subjectAltName': (('IP Address', '1.1.1.1'),)}
ssl.match_hostname(cert, '1.1.1.1 ; this should not work but does')


The bug was initially found by Dominik Czarnota and reported by Paul Kehrer.

The issue was introduced in commit aef1283ba428e33397d87cee3c54a5110861552d / bpo-32819. Only 3.7 and newer are affected. It's a potential security bug although low severity. For one Python 3.7 and newer no longer use ssl.match_hostname() to verify hostnames and IP addresses of a certificate. Matching is performed by OpenSSL.

----------
assignee: christian.heimes
components: SSL
keywords: 3.7regression
messages: 346964
nosy: alex, christian.heimes, dstufft, janssen, lukasz.langa, ned.deily
priority: release blocker
severity: normal
stage: needs patch
status: open
title: socket.inet_aton IP parsing issue in ssl.match_hostname
type: security
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37463>
_______________________________________

From report at bugs.python.org  Mon Jul  1 04:19:39 2019
From: report at bugs.python.org (Chandan Kumar)
Date: Mon, 01 Jul 2019 08:19:39 +0000
Subject: [New-bugs-announce] [issue37464] multiple comparison
Message-ID: <1561969179.72.0.936663483495.issue37464@roundup.psfhosted.org>


New submission from Chandan Kumar <chandankumar948 at gmail.com>:

a=1.0
b=0.0
c=0.0
if (a> d and b):
     print('hi')
else:
     print("bye")

its going to else part
a=1.0
b=0.1
c=0.2
then its going to if part
a==1.0
b=0
c=0.1
then again its going to else part

----------
assignee: docs at python
components: Documentation
messages: 346972
nosy: Chandan, docs at python
priority: normal
severity: normal
status: open
title: multiple comparison
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37464>
_______________________________________

From report at bugs.python.org  Mon Jul  1 04:20:20 2019
From: report at bugs.python.org (Enrico Zini)
Date: Mon, 01 Jul 2019 08:20:20 +0000
Subject: [New-bugs-announce] [issue37465] Incorrect documentation for `s#`
 arguments in C API argument parsing
Message-ID: <1561969220.64.0.698927964651.issue37465@roundup.psfhosted.org>


New submission from Enrico Zini <enrico at enricozini.org>:

In https://docs.python.org/3.9/c-api/arg.html, in the documentation for parsing argument, there is:

     s# (str, read-only bytes-like object) [const char *, int or Py_ssize_t]

In my amd64 system, `Py_ssize_t` is a different type than `int`, and passing a `Py_ssize_t` causes undefine behaviour.

I assume this has been switched to an `int` in the API, and that thisinstance of the documentation has not been updated accordingly. At the bottom of the page in the documentation of `Py_BuildValue`, `s#` is correctly documented as using an `int` and no `Py_ssize_t`, for example.

----------
assignee: docs at python
components: Documentation
messages: 346974
nosy: docs at python, enrico
priority: normal
severity: normal
status: open
title: Incorrect documentation for `s#` arguments in C API argument parsing
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37465>
_______________________________________

From report at bugs.python.org  Mon Jul  1 05:35:33 2019
From: report at bugs.python.org (myungsekyo)
Date: Mon, 01 Jul 2019 09:35:33 +0000
Subject: [New-bugs-announce] [issue37466] Move casting prompt after its
 validation in _raw_input()
Message-ID: <1561973733.3.0.964071328037.issue37466@roundup.psfhosted.org>


New submission from myungsekyo <myungsekyo at gmail.com>:

I think it is more efficient to cast `variable prompt` into string after its validation in _raw_input().
Because If it is None or empty string then it is not used. 

```
import timeit

MAX = 10000000


start = timeit.default_timer()
for i in range(MAX):
    _raw_input()

end = timeit.default_timer()

print('estimated : {}'.format(end - start))

```
I tested on 10 millions inputs with above code.
and the result is as follows.

Before:
    estimated : 5.060587857999053
    estimated : 5.0425375679988065
    estimated : 4.850400277999142
    estimated : 4.888060468998447
    estimated : 4.849542597999971
    estimated : 4.822679259999859
    estimated : 5.053791769001691
    estimated : 4.914149145999545
    estimated : 4.9584080040003755
    estimated : 4.944711199001176

After:
    estimated : 4.014042392998817
    estimated : 3.987057284997718
    estimated : 4.081281360999128
    estimated : 4.06813505899845
    estimated : 4.040622504999192
    estimated : 4.1239150339970365
    estimated : 4.174400065003283
    estimated : 4.015272281998477
    estimated : 4.034917910001241
    estimated : 4.08582956799728

----------
components: IO
messages: 346986
nosy: myungsekyo
priority: normal
severity: normal
status: open
title: Move casting prompt after its validation in _raw_input()
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37466>
_______________________________________

From report at bugs.python.org  Mon Jul  1 05:49:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Jul 2019 09:49:11 +0000
Subject: [New-bugs-announce] [issue37467] print_exception() crash when lxml
 4.2.5 raises a parser error
Message-ID: <1561974551.02.0.598899276375.issue37467@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Using attached sf.py and sf.xml, I can crash Python. lxml builds a fake traceback to inject the XML filename the XML line number where the parsing error occurs. The problem is that the filename is a bytes object, whereas print_exception() expects the filename to be a Unicode string.

Attached PR fix the crash.

Fedora bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1665490


Example:

$ python3 sf.py
<lxml.etree._ElementTree object at 0x7f7d0f8abd08>
Traceback (most recent call last):
  File "sf.py", line 6, in <module>
    xml2 = etree.parse("sf.xml")
  File "src/lxml/etree.pyx", line 3426, in lxml.etree.parse
  File "src/lxml/parser.pxi", line 1840, in lxml.etree._parseDocument
  File "src/lxml/parser.pxi", line 1866, in lxml.etree._parseDocumentFromURL
  File "src/lxml/parser.pxi", line 1770, in lxml.etree._parseDocFromFile
  File "src/lxml/parser.pxi", line 1163, in lxml.etree._BaseParser._parseDocFromFile
  File "src/lxml/parser.pxi", line 601, in lxml.etree._ParserContext._handleParseResultDoc
  File "src/lxml/parser.pxi", line 711, in lxml.etree._handleParseResult
  File "src/lxml/parser.pxi", line 651, in lxml.etree._raiseParseError
Segmentation fault (core dumped)


(gdb) frame 6
#6  0x00007ffff7c85898 in print_exception (value=None, f=<_io.TextIOWrapper at remote 0x7fffea910708>)
    at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c:753
753	/usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c: No such file or directory.
(gdb) l
748	in /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c
(gdb) p filename
$1 = b'sf.xml'
(gdb) p *filename
$2 = {
  ob_refcnt = 2, 
  ob_type = 0x7ffff7db5da0 <PyBytes_Type>
}


Extract of print_exception():

        PyObject *message, *filename, *text;
        int lineno, offset;
        if (!parse_syntax_error(value, &message, &filename,
                                &lineno, &offset, &text))
            PyErr_Clear();
        else {
            PyObject *line;

            Py_DECREF(value);
            value = message;

            line = PyUnicode_FromFormat("  File \"%S\", line %d\n",   // <====== HERE
                                          filename, lineno);
            Py_DECREF(filename);


More gdb traceback:

Program received signal SIGSEGV, Segmentation fault.
find_maxchar_surrogates (num_surrogates=<synthetic pointer>, maxchar=<synthetic pointer>, 
    end=0xfffffffffffffffd <error: Cannot access memory at address 0xfffffffffffffffd>, begin=0x1 <error: Cannot access memory at address 0x1>)
    at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:1660
1660	/usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c: No such file or directory.
Missing separate debuginfos, use: dnf debuginfo-install abrt-libs-2.12.0-2.fc30.x86_64 augeas-libs-1.12.0-1.fc30.x86_64 bzip2-libs-1.0.6-29.fc30.x86_64 dbus-libs-1.12.16-1.fc30.x86_64 elfutils-libelf-0.176-3.fc30.x86_64 elfutils-libs-0.176-3.fc30.x86_64 expat-2.2.6-2.fc30.x86_64 glib2-2.60.4-1.fc30.x86_64 libacl-2.2.53-3.fc30.x86_64 libcap-2.26-5.fc30.x86_64 libdb-5.3.28-37.fc30.x86_64 libffi-3.1-19.fc30.x86_64 libgcc-9.1.1-1.fc30.x86_64 libgcrypt-1.8.4-3.fc30.x86_64 libgpg-error-1.33-2.fc30.x86_64 libmount-2.33.2-1.fc30.x86_64 libreport-2.10.0-3.fc30.x86_64 libselinux-2.9-1.fc30.x86_64 libstdc++-9.1.1-1.fc30.x86_64 libtar-1.2.20-17.fc30.x86_64 libtool-ltdl-2.4.6-29.fc30.x86_64 libuuid-2.33.2-1.fc30.x86_64 libxcrypt-4.4.6-2.fc30.x86_64 libxml2-2.9.9-2.fc30.x86_64 libxslt-1.1.33-1.fc30.x86_64 libzstd-1.4.0-1.fc30.x86_64 lz4-libs-1.8.3-2.fc30.x86_64 pcre-8.43-2.fc30.x86_64 popt-1.16-17.fc30.x86_64 python3-abrt-2.12.0-2.fc30.x86_64 python3-dbus-1.2.8-5.fc30.x86_64 python3-libreport-2.10.0-3.fc30.x86_64 python3-lxml-4.2.5-2.fc30.x86_64 python3-systemd-234-8.fc30.x86_64 python3-xmlsec-1.3.3-5.fc30.x86_64 rpm-libs-4.14.2.1-4.fc30.1.x86_64 systemd-libs-241-8.git9ef65cb.fc30.x86_64 xmlsec1-1.2.27-2.fc30.x86_64 xmlsec1-openssl-1.2.27-2.fc30.x86_64 xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64
(gdb) where
#0  0x00007ffff7c321ad in find_maxchar_surrogates
    (num_surrogates=<synthetic pointer>, maxchar=<synthetic pointer>, end=0xfffffffffffffffd <error: Cannot access memory at address 0xfffffffffffffffd>, begin=0x1 <error: Cannot access memory at address 0x1>) at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:1660
#1  0x00007ffff7c321ad in _PyUnicode_Ready (unicode=b'sf.xml') at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:1699
#2  0x00007ffff7afad8e in unicode_fromformat_write_str (precision=-1, width=-1, str=<optimized out>, writer=0x7fffffffcb20)
    at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:2596
#3  0x00007ffff7afad8e in unicode_fromformat_arg (vargs=0x7fffffffcb80, f=<optimized out>, writer=0x7fffffffcb20)
    at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:2807
#4  0x00007ffff7afad8e in PyUnicode_FromFormatV (format=<optimized out>, vargs=<optimized out>)
    at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:2914
#5  0x00007ffff7b82a99 in PyUnicode_FromFormat (format=format at entry=0x7ffff7c9b045 "  File \"%U\", line %d\n")
    at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:2966
#6  0x00007ffff7c85898 in print_exception (value=None, f=<_io.TextIOWrapper at remote 0x7fffea910708>)
    at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c:753
#7  0x00007ffff7c85898 in print_exception_recursive
    (f=<_io.TextIOWrapper at remote 0x7fffea910708>, value=<XMLSyntaxError(error_log=<lxml.etree._ListErrorLog at remote 0x7fffe9fe3598>, code=1) at remote 0x7fffea046828>, seen=<optimized out>) at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c:901
#8  0x00007ffff7c8b8bb in PyErr_Display
    (exception=<optimized out>, value=<XMLSyntaxError(error_log=<lxml.etree._ListErrorLog at remote 0x7fffe9fe3598>, code=1) at remote 0x7fffea046828>, tb=<optimized out>) at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c:935
#9  0x00007ffff7c8b93c in sys_excepthook (self=<optimized out>, args=<optimized out>) at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/sysmodule.c:332
(...)

----------
files: sf.py
messages: 346988
nosy: vstinner
priority: normal
severity: normal
status: open
title: print_exception() crash when lxml 4.2.5 raises a parser error
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48449/sf.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37467>
_______________________________________

From report at bugs.python.org  Mon Jul  1 08:37:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Jul 2019 12:37:49 +0000
Subject: [New-bugs-announce] [issue37468] Don't install wininst*.exe on
 non-Windows platforms
Message-ID: <1561984669.65.0.392603753819.issue37468@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

bdist_wininst only works on Windows: see bpo-10945 and commit 72cd653c4ed7a4f8f8fb06ac364b08a97085a2b5. So $PREFIX/lib/python3.9/distutils/command/wininst-*.exe are useless on Linux (for example).

Attached PR modify "make install" to not longer install wininst-*.exe files.

I propose to only modify Python 3.9. Even if bdist_wininst only works on Windows on Python 3.*, I don't feel the need to modify other branches.

I also started a "Deprecate bdist_wininst" discussion on the Packaging list:
https://discuss.python.org/t/deprecate-bdist-wininst/1929

--

Currently, I get these .exe files:

$ find /opt/py39dbg/ -name "*.exe"
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui-64.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui-32.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli-64.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli-32.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/w64.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/w32.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/t64.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/t32.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-10.0-amd64.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-10.0.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-14.0-amd64.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-14.0.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-6.0.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-7.1.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-8.0.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-9.0-amd64.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-9.0.exe

site-packages/setuptools/ and site-packages/pip/ are out of the scope of this issue.


With my PR:

vstinner at apu$ find /opt/py39dbg/ -name "*.exe"
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui-64.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui-32.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli-64.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli-32.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/w64.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/w32.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/t64.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/t32.exe

/opt/py39dbg/lib/python3.9/distutils/command/wininst-*.exe files are gone.


--


wininst-*.exe files are created from PC/bdist_wininst/ program.

October 2018, there was a discussion about the license of these files:
https://mail.python.org/pipermail/python-dev/2018-October/155507.html

The Fedora package of Python 3.7 already explicitly removes these .exe files:

* https://bugzilla.redhat.com/show_bug.cgi?id=525469
* https://src.fedoraproject.org/rpms/python3/c/1092d478f540ba9d510316205eca201e5c5d07e9?branch=master
* https://bugzilla.redhat.com/show_bug.cgi?id=1426250
* https://bugzilla.redhat.com/show_bug.cgi?id=1426257

----------
components: Library (Lib)
messages: 347010
nosy: vstinner
priority: normal
severity: normal
status: open
title: Don't install wininst*.exe on non-Windows platforms
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37468>
_______________________________________

From report at bugs.python.org  Mon Jul  1 09:41:45 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 01 Jul 2019 13:41:45 +0000
Subject: [New-bugs-announce] [issue37469] Make it explicit that logging
 QueueHandler / QueueListener accepts a SimpleQueue.
Message-ID: <1561988505.1.0.589194187819.issue37469@roundup.psfhosted.org>


New submission from Martijn Pieters <mj at python.org>:

The implementation of the logging.handler.QueueHandler and logging.handler.QueueListener does not make use of the task tracking API of queues (queue.task_done(), queue.join()) nor does it care if the queue is unbounded (queue.full(), catching the Full exception).

As such, it can work just as well with the new queue.SimpleQueue implementation (new in 3.7, see https://docs.python.org/3/library/queue.html#queue.SimpleQueue), which is fast and lightweight, implemented in C.

Can the documentation be updated to make this option explicit?

----------
assignee: docs at python
components: Documentation
messages: 347017
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: Make it explicit that logging QueueHandler / QueueListener accepts a SimpleQueue.
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37469>
_______________________________________

From report at bugs.python.org  Mon Jul  1 09:42:59 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 01 Jul 2019 13:42:59 +0000
Subject: [New-bugs-announce] [issue37470] Make it explicit what happens when
 using a bounded queue with QueueHandler
Message-ID: <1561988579.69.0.0525548005438.issue37470@roundup.psfhosted.org>


New submission from Martijn Pieters <mj at python.org>:

The documentation doesn't make it explicit what happens if you use a bounded queue together with logging.handlers.QueueHandler.

If the queue is bounded in size and attempts are made to add logrecords faster than a queue listener removes them, then the resulting `queue.Full` exception is passed to `handler.handleError()` and that usually means the record is simply dropped (see https://docs.python.org/3/library/logging.html#logging.Handler.handleError).

That may be the desired behaviour, but making it explicit is always better.

----------
assignee: docs at python
components: Documentation
messages: 347018
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: Make it explicit what happens when using a bounded queue with QueueHandler
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37470>
_______________________________________

From report at bugs.python.org  Mon Jul  1 10:22:37 2019
From: report at bugs.python.org (David CARLIER)
Date: Mon, 01 Jul 2019 14:22:37 +0000
Subject: [New-bugs-announce] [issue37471] mmap module, adding new constant
Message-ID: <1561990957.19.0.830363147421.issue37471@roundup.psfhosted.org>


Change by David CARLIER <devnexen at gmail.com>:


----------
components: Extension Modules, FreeBSD
nosy: devnexen, koobs
priority: normal
pull_requests: 14329
severity: normal
status: open
title: mmap module, adding new constant
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37471>
_______________________________________

From report at bugs.python.org  Mon Jul  1 11:17:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Jul 2019 15:17:59 +0000
Subject: [New-bugs-announce] [issue37472] Remove Lib/test/outstanding_bugs.py
Message-ID: <1561994279.69.0.729318109917.issue37472@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Lib/test/outstanding_bugs.py was created by:

commit c4e2a9b70ac49cdd8bcc9ca60afac20162f84f24
Author: Georg Brandl <georg at python.org>
Date:   Sun Jan 8 14:32:19 2006 +0000

    Add a test file (which isn't run by regrtest) for bugs which
    aren't fixed yet.
    
    Includes a first test (for compiler).

and has not been touched since:


commit bdce938af2af03b2eb0d0e4731f1b8c4b965eaf5
Author: Zachary Ware <zachary.ware at gmail.com>
Date:   Fri Dec 20 13:25:07 2013 -0600

    Update test.outstanding_bugs.py

diff --git a/Lib/test/outstanding_bugs.py b/Lib/test/outstanding_bugs.py
index 0849ee5885..7e527a6706 100644
--- a/Lib/test/outstanding_bugs.py
+++ b/Lib/test/outstanding_bugs.py
@@ -10,79 +10,9 @@ import unittest
 from test import support
 
 #
-# One test case for outstanding bugs at the moment:
+# No test cases for outstanding bugs at the moment.
 #
(...)


I propose to remove this file. We don't manage "outstanding bugs" this way anymore.

----------
components: Tests
messages: 347031
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove Lib/test/outstanding_bugs.py
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37472>
_______________________________________

From report at bugs.python.org  Mon Jul  1 11:24:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Jul 2019 15:24:52 +0000
Subject: [New-bugs-announce] [issue37473] importlib: Remove libregrtest
 hack: "We import importlib *ASAP* in order to test #15386"
Message-ID: <1561994692.63.0.367663564424.issue37473@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Lib/test/regrtest.py starts with:

# We import importlib *ASAP* in order to test #15386
import importlib

If there is a bug to test, would it be possible to write a dedicated test, rather than putting the test... in the code of the test runner?

Code added by bpo-15386:

commit be7e49fd820318509cd8b4dbde479c552f74ef62
Author: Nick Coghlan <ncoghlan at gmail.com>
Date:   Fri Jul 20 23:40:09 2012 +1000

    Close #15386: There was a loophole that meant importlib.machinery and imp would sometimes reference an uninitialised copy of importlib._bootstrap

(...)

diff --git a/Lib/runpy.py b/Lib/runpy.py
index d612727c6f..39c0e9f7dd 100644
--- a/Lib/runpy.py
+++ b/Lib/runpy.py
@@ -12,8 +12,8 @@ importers when locating support scripts as well as when importing modules.
 
 import os
 import sys
+import importlib.machinery # importlib first so we can test #15386 via -m
 import imp
-import importlib.machinery
 from pkgutil import read_code, get_loader, get_importer
 
 __all__ = [
diff --git a/Lib/test/regrtest.py b/Lib/test/regrtest.py
index 28655f0e65..3c8359aca1 100755
--- a/Lib/test/regrtest.py
+++ b/Lib/test/regrtest.py
@@ -165,6 +165,9 @@ example, to run all the tests except for the gui tests, give the
 option '-uall,-gui'.
 """
 
+# We import importlib *ASAP* in order to test #15386
+import importlib
+
 import builtins
 import faulthandler
 import getopt
diff --git a/Lib/test/test_import.py b/Lib/test/test_import.py
index 89ec8dcedc..51b52c7e0b 100644
--- a/Lib/test/test_import.py
+++ b/Lib/test/test_import.py
@@ -1,8 +1,9 @@
+# We import importlib *ASAP* in order to test #15386
+import importlib
 import builtins
 import imp
 from importlib.test.import_ import test_suite as importlib_import_test_suite
 from importlib.test.import_ import util as importlib_util
-import importlib
 import marshal
 import os
 import platform

----------
components: Tests
messages: 347032
nosy: brett.cannon, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: importlib: Remove libregrtest hack: "We import importlib *ASAP* in order to test #15386"
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37473>
_______________________________________

From report at bugs.python.org  Mon Jul  1 13:39:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Jul 2019 17:39:03 +0000
Subject: [New-bugs-announce] [issue37474] Should Py_Initialize() control the
 floating point mode?
Message-ID: <1562002743.95.0.49076601863.issue37474@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Just after calling _PyRuntime_Initialize(), Py_Main() calls:

    /* 754 requires that FP exceptions run in "no stop" mode by default,
     * and until C vendors implement C99's ways to control FP exceptions,
     * Python requires non-stop mode.  Alas, some platforms enable FP
     * exceptions by default.  Here we disable them.
     */
#ifdef __FreeBSD__
    fedisableexcept(FE_OVERFLOW);
#endif

It's done before calling Py_Initialize(). So applications embedding Python don't call it. But "customized Python" which call the new Py_RunMain() with Py_InititializeFromConfig() will not call it neither.

I would like to know if this setup code should be moved into Py_Initialize()? Especially into the new PyConfig API:
https://docs.python.org/dev/c-api/init_config.html

PyConfig got 2 flags to control parameters which affect the whole process:

* configure_c_stdio
* configure_locale

What is the behavior on FreeBSD when fedisableexcept(FE_OVERFLOW) is not called?

Note: I'm not sure why this call is only needed on FreeBSD, but not on macOS, OpenBSD or NetBSD (operating systems close to FreeBSD).

----------
components: Interpreter Core
messages: 347048
nosy: lemburg, mark.dickinson, stutzbach, vstinner
priority: normal
severity: normal
status: open
title: Should Py_Initialize() control the floating point mode?
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37474>
_______________________________________

From report at bugs.python.org  Mon Jul  1 14:01:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Jul 2019 18:01:48 +0000
Subject: [New-bugs-announce] [issue37475] What is
 urllib.request.urlcleanup() function?
Message-ID: <1562004108.37.0.0869622537038.issue37475@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

While working on bpo-37421 "Some tests leak temporary files", I had to write PR 14529 fix: test_urllib urlretrieve() tests now explicitly call urlcleanup() to remove temporary files.

If urlretrieve() caller forgets to remove the temporary file, the "temporary" file is left in the temporary directory, until this directory is cleared which may happen soon (next reboot?) or not.

When ContentTooShortError is raised, the temporary file is left in the temporary directory: the caller must call urlcleanup() explicitly. It sounds like a bug to me.

Is it really a good API if urlcleanup() must be called explicitly? I dislike having a "separated" function for the cleanup, whereas Python could rely on object lifetime to do the cleanup.

Should we deprecate this API in favor of a better urllib API?

----------
components: Library (Lib)
messages: 347056
nosy: vstinner, xtreak
priority: normal
severity: normal
status: open
title: What is urllib.request.urlcleanup() function?
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37475>
_______________________________________

From report at bugs.python.org  Mon Jul  1 14:29:52 2019
From: report at bugs.python.org (hai shi)
Date: Mon, 01 Jul 2019 18:29:52 +0000
Subject: [New-bugs-announce] [issue37476] Adding a unit test of unicode in
 test_unicode.py
Message-ID: <1562005792.78.0.882905794815.issue37476@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

As title, Adding a unit test of unicode in test_unicode.py.

----------
components: Tests
messages: 347059
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Adding a unit test of unicode in test_unicode.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37476>
_______________________________________

From report at bugs.python.org  Mon Jul  1 16:35:15 2019
From: report at bugs.python.org (Erik Aronesty)
Date: Mon, 01 Jul 2019 20:35:15 +0000
Subject: [New-bugs-announce] [issue37477] NamedTemporaryFile can hang on
 windows
Message-ID: <1562013315.01.0.238177593391.issue37477@roundup.psfhosted.org>


New submission from Erik Aronesty <erik at q32.com>:

Depending on the user's permissions, this code can hang, instead of raising an exception:

    from tempfile import NamedTemporaryFile
    NamedTemporaryFile(dir="/")

The problamatic code is in tempfile.py:

When encountering a "[Errno 13] Permission denied: '/tmpmcupmo_g'", the current code uses _os.access(dir, _os.W_OK) in two places to check if access is allowed to write to the directory.

On windows, _os.access does not check if the user has permission to write to the folder, it only checks if the folder is read-only (and it doesn't even do a good job at that).

So the temp file creator loops for a rather long time, and consumes a massive amount of system resources, because os.TMP_MAX on modern windows versions is 2147483647.

This article explains how to check if a directory can-write without trying to write to it:

http://blog.aaronballman.com/2011/08/how-to-check-access-rights/

Alternatively, a more careful check of the winerror return value from the open call *might* be sufficient.

----------
messages: 347073
nosy: earonesty
priority: normal
severity: normal
status: open
title: NamedTemporaryFile can hang on windows
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37477>
_______________________________________

From report at bugs.python.org  Mon Jul  1 18:40:23 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 01 Jul 2019 22:40:23 +0000
Subject: [New-bugs-announce] [issue37478] Docs: Method os.chdir() does not
 mention errors that can be raised
Message-ID: <1562020823.14.0.307493016752.issue37478@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

In the section describing the functionality of os.chdir(), there is no mention of possible errors that can be raised. This differentiates significantly from the sections of other methods, such as os.is_dir():

"This method can raise :exc:`OSError`, such as :exc:`PermissionError`, but :exc:`FileNotFoundError` is caught and not raised."

For the purpose of consistency and providing additional useful information, I would suggest doing the same for os.chdir(). os.chdir() differs from os.is_dir() by directly raising the OSErrors FileNotFoundError and NotADirectoryError rather than handling them. I would suggest the addition of the following in os.chdir()'s section:

"This method can raise :exc:`OSError`, such as exc:`FileNotFoundError` if the *path* does not lead to a valid file or exc:`NotADirectoryError` if the file specified is not a valid directory."

or a less verbose alternative:

"This method can raise :exc:`OSError`, such as exc:`FileNotFoundError` and exc:`NotADirectoryError`."

If a user is reading the documentation, they might naturally assume that os.chdir() catches the FileNotFoundError, similar to the behavior in os.is_dir(). Also, the NotADirectoryError is not explicitly mentioned anywhere else on the "os.rst" page. If it were to be mentioned anywhere, os.chdir() would probably be the most relevant location to do so.

Also, as a general question, what exactly is the standard for mentioning errors in the method sections for the Python documentation? For the purposes of clarity, I think it would be quite useful to explicitly mention errors, and a brief description of situations which raise them. If the behavior of the errors is consistent across of a group of methods, it can instead be mentioned in the header section. 

However, if the behavior not consistent, such as in this case, I think it is useful to briefly mention how the method deviates. It also seems useful to mention the error at least once if it is not explicitly mentioned elsewhere on the page, even if the parent is mentioned, such as with NotADirectoryError and OSError. This seems to be particularly important to do for the docs in a language such as Python, as it does not require the raise-able/throw-able errors to be mentioned in the code. 

I have already created a branch in my local fork of the cpython repository which implements this change, but I'll await feedback before submitting the PR.

----------
assignee: docs at python
components: Documentation
messages: 347080
nosy: aeros167, docs at python
priority: normal
severity: normal
status: open
title: Docs: Method os.chdir() does not mention errors that can be raised
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37478>
_______________________________________

From report at bugs.python.org  Mon Jul  1 19:24:11 2019
From: report at bugs.python.org (Jason Curtis)
Date: Mon, 01 Jul 2019 23:24:11 +0000
Subject: [New-bugs-announce] [issue37479] IntEnum f-string behavior can't be
 overridden
Message-ID: <1562023451.58.0.339794314518.issue37479@roundup.psfhosted.org>


New submission from Jason Curtis <thatneat at gmail.com>:

Combining int and Enum, as with enum.IntEnum results in a class where __str__ cannot be effectively overridden. For example:


from enum import IntEnum

class myIntEnum(IntEnum):
    x = 1
    
    def __str__(self):
        return 'aaaaAAAa'
    
f'{myIntEnum.x}, {str(myIntEnum.x)}'


Expected output:
'aaaaAAAa, aaaaAAAa'

Actual output:
'1, aaaaAAAa'

Overriding __str__ in this way works as expected if the inherited classes are int or Enum individually. However, it does not work when inheriting (int, Enum) or when inheriting (intEnum).

Presumably this is a side effect of Enum's mixin behavior documented at https://docs.python.org/3/library/enum.html#others and it is possibly related to https://bugs.python.org/issue18264 .

----------
components: Library (Lib)
messages: 347089
nosy: Jason Curtis
priority: normal
severity: normal
status: open
title: IntEnum f-string behavior can't be overridden
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37479>
_______________________________________

From report at bugs.python.org  Mon Jul  1 23:03:56 2019
From: report at bugs.python.org (Zach Valenta)
Date: Tue, 02 Jul 2019 03:03:56 +0000
Subject: [New-bugs-announce] [issue37480] add ptpython to list of alternate
 interpreters
Message-ID: <1562036636.74.0.198372246702.issue37480@roundup.psfhosted.org>


New submission from Zach Valenta <zjv5002 at gmail.com>:

Referring to the last paragraph of chapter 14 of the tutorial on interactive interpreters: 

https://docs.python.org/3/tutorial/interactive.html#alternatives-to-the-interactive-interpreter

Despite personally using bpython, ptpython seems both mature and popular enough to merit inclusion in the docs. Plus, bpython recommends them :)

----------
assignee: docs at python
components: Documentation
messages: 347099
nosy: docs at python, zjayv
priority: normal
severity: normal
status: open
title: add ptpython to list of alternate interpreters
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37480>
_______________________________________

From report at bugs.python.org  Tue Jul  2 07:05:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Jul 2019 11:05:55 +0000
Subject: [New-bugs-announce] [issue37481] Deprecate bdist_wininstr: use
 bdist_wheel instead
Message-ID: <1562065555.11.0.674555433239.issue37481@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

According to the following "Deprecate bdist_wininst" discussion, bdist_wininst can be deprecated:
https://discuss.python.org/t/deprecate-bdist-wininst/1929

bdist_wininst uses the mbcs encoding which is only available on Windows. There is bpo-10945 open for 8 years to suggest to use UTF-8 or use the Unicode (wide character) flavor of the Windows API to support running bdist_wininst on non-Windows platforms and to be able to distribute binaries which don?t depend on the ANSI code page.

I propose to deprecate it in Python 3.9, because of bpo-10945 issue. I don't propose to plan bdist_wininst removal yet.

As an user, it?s annoying to have to run a GUI to install something, whereas pip can install dependencies using wheel packages in a command line interface, transparently, without bugging the user with dialog boxes.

When I look at numpy or Cython: they don?t distribute .exe installers, but binary wheel packages for Windows. I understood the wheel packages is the recommended way to distribute binaries on Windows, and so that bdist_wininst is kind of deprecated.

Donald Stufft wrote:

"For what it?s worth, PyPI doesn?t even allow you to upload bdist_wininst (See PEP 527 2) anymore, so if you?re looking at PyPI to determine usage, you?re going to get no usage whatsoever for anything recent.

I don?t have any idea if other people are still using bdist_wininst and distributing them through some other mechanism."

Paul Ganssle wrote:

"From my perspective, nearly all direct invocations of setup.py are currently or are eventually heading for deprecation. PEP 517 doesn?t provide hooks to generate anything other than sdist or wheel, so basically all commands not actually triggered (directly or indirectly) by calling a PEP 517 front-end are suspect."


Attached PR deprecates bdist_wininst.


See also the related issue bpo-37468 "Don't install wininst*.exe on non-Windows platforms". bdist_wininst only works on Windows: see bpo-10945 and commit 72cd653c4ed7a4f8f8fb06ac364b08a97085a2b5.

----------
components: Library (Lib)
messages: 347131
nosy: vstinner
priority: normal
severity: normal
status: open
title: Deprecate bdist_wininstr: use bdist_wheel instead
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37481>
_______________________________________

From report at bugs.python.org  Tue Jul  2 07:51:15 2019
From: report at bugs.python.org (B Siemerink)
Date: Tue, 02 Jul 2019 11:51:15 +0000
Subject: [New-bugs-announce] [issue37482] Email header fails with both
 encoded words and special chars
Message-ID: <1562068275.57.0.247896906946.issue37482@roundup.psfhosted.org>


New submission from B Siemerink <b.siemerink at redforts.com>:

Special characters in email headers are normally put within double quotes. However, encoded words (=?charset?x?...?=) are not allowed withing double quotes. When the header contains a word with special characters and another word that must be encoded, the first one must also be encoded.

In the next example, The From header is quoted and therefore the comma is allowed; in the To header, the comma is not within quotes and not encoded, which is not allowed and rejected.

From: "Foo Bar, France" <foo at example.com>
To: Foo Bar, =?utf-8?q?Espa=C3=B1a?= <foo at example.com>

----------
components: email
files: email_header_test.py
messages: 347136
nosy: barry, bsiem, r.david.murray
priority: normal
severity: normal
status: open
title: Email header fails with both encoded words and special chars
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48452/email_header_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37482>
_______________________________________

From report at bugs.python.org  Tue Jul  2 08:14:43 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 02 Jul 2019 12:14:43 +0000
Subject: [New-bugs-announce] [issue37483] Add PyObject_CallOneArg()
Message-ID: <1562069683.82.0.624448792444.issue37483@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

As discussed in https://mail.python.org/archives/list/capi-sig at python.org/thread/X6HJOEX6RRFLNKAQSQR6HLD7K4QZ4OTZ/ it would be convenient to have a function PyObject_CallOneArg() for making calls with exactly 1 positional argument and no keyword arguments. Such calls are very common. This would be analogous to PyObject_CallNoArgs().

----------
components: Interpreter Core
messages: 347138
nosy: jdemeyer, vstinner
priority: normal
severity: normal
status: open
title: Add PyObject_CallOneArg()
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37483>
_______________________________________

From report at bugs.python.org  Tue Jul  2 08:22:05 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 02 Jul 2019 12:22:05 +0000
Subject: [New-bugs-announce] [issue37484] Use PY_VECTORCALL_ARGUMENTS_OFFSET
 for __exit__
Message-ID: <1562070125.47.0.376343884146.issue37484@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

35% of all cases where methods are called without PY_VECTORCALL_ARGUMENT_OFFSET and taking at least 1 argument (positional or keyword) are calls to __exit__

So we should really optimize __exit__

----------
components: Interpreter Core
messages: 347139
nosy: inada.naoki, jdemeyer
priority: normal
severity: normal
status: open
title: Use PY_VECTORCALL_ARGUMENTS_OFFSET for __exit__
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37484>
_______________________________________

From report at bugs.python.org  Tue Jul  2 09:44:03 2019
From: report at bugs.python.org (Colin)
Date: Tue, 02 Jul 2019 13:44:03 +0000
Subject: [New-bugs-announce] [issue37485] dataclass __foo__ methods
 inheritance is not working
Message-ID: <1562075043.32.0.192151434344.issue37485@roundup.psfhosted.org>


New submission from Colin <colin.bounouar at gmail.com>:

Hi,

When using inheritance with dataclass, "standard" instance methods that are provided with a default behavior thanks to dataclass are not overridable using inheritance.

Please see the sample below (or the attached file):

import dataclasses


@dataclasses.dataclass
class A:
    def __eq__(self, other):
        return True


@dataclasses.dataclass
class B(A):
    pass


print(A() == 1) # Returns True as expected
print(B() == 1) # Returns False instead of True as expected via inheritance


Thanks again

----------
components: Library (Lib)
files: inheritance_dataclass_issue.py
messages: 347142
nosy: colin-b
priority: normal
severity: normal
status: open
title: dataclass __foo__ methods inheritance is not working
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48453/inheritance_dataclass_issue.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37485>
_______________________________________

From report at bugs.python.org  Tue Jul  2 10:35:48 2019
From: report at bugs.python.org (adrien.pierre.horgnies@gmail.com)
Date: Tue, 02 Jul 2019 14:35:48 +0000
Subject: [New-bugs-announce] [issue37486] pathlib.Path('.').parent is itself
 rather than parent
Message-ID: <1562078148.03.0.333359330818.issue37486@roundup.psfhosted.org>


New submission from adrien.pierre.horgnies at gmail.com <adrien.pierre.horgnies at gmail.com>:

Tested with CPython 3.7.3

```
from pathlib import Path

p = Path('.')

assert p == p.parent # should fail but it does not
```

I expect Path('.').parent to be Path('..')

I searched issues and did not find any similar issue but maybe I didn't search well enough because I would be surprised that I'd be the first one to be bugged by this issue.

I didn't test newer version of Python as I couldn't find a package or wasn't comfortable enough to build it myself.

----------
components: Library (Lib)
messages: 347143
nosy: adrien.pierre.horgnies at gmail.com
priority: normal
severity: normal
status: open
title: pathlib.Path('.').parent is itself rather than parent
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37486>
_______________________________________

From report at bugs.python.org  Tue Jul  2 10:49:41 2019
From: report at bugs.python.org (=?utf-8?b?5p2o5piG5LuR?=)
Date: Tue, 02 Jul 2019 14:49:41 +0000
Subject: [New-bugs-announce] [issue37487] PyList_GetItem() document
 regarding index
Message-ID: <1562078981.78.0.204113489649.issue37487@roundup.psfhosted.org>


New submission from ??? <yangkunlun at gmail.com>:

The document of this function (PyList_GetItem()) says: "Return the object at position index in the list pointed to by list. The position must be **positive**,". However test shows the correct position index should be from 0 to len(list)-1. The claim of index **must be positive** is inaccurate and confusing.

----------
assignee: docs at python
components: Documentation
messages: 347144
nosy: docs at python, ???
priority: normal
severity: normal
status: open
title: PyList_GetItem() document regarding index
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37487>
_______________________________________

From report at bugs.python.org  Tue Jul  2 12:01:38 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 02 Jul 2019 16:01:38 +0000
Subject: [New-bugs-announce] [issue37488] Document the "gotcha" behaviors in
 utcnow() and utcfromtimestamp()
Message-ID: <1562083298.89.0.799843667155.issue37488@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

Between Python 2 and Python 3, the meaning of a naive datetime underwent a subtle change. Previously a naive datetime was mostly treated as an abstract datetime in the same way a unitless number is treated as an abstract quantity (this is reflected in the current datetime documentation). In Python 3, though, it became more concrete in the sense that rather than just throwing an error whenever you try to do an operation that requires knowing the absolute datetime (e.g. convert between time zones, convert to timestamp, etc), certain operations will succeed with the assumption that naive times represent system local times. This makes `utcnow()` and `utcfromtimestamp()` dangerous, because they create a naive datetime as if the naive datetime represents UTC, but this context is then lost and if you ever use one of these "aware-only" operations (.astimezone, .timestamp, etc), you'll get an unexpected answer.

For example, see this script, executed this with `TZ=America/New_York` on a machine with IANA data installed:

    >>> from datetime import datetime
    >>> dt = datetime.utcfromtimestamp(0)
    >>> dt
    datetime.datetime(1970, 1, 1, 0, 0)
    >>> dt.timestamp()
    18000

This happens because EST is 18000s behind UTC, and `.timestamp()` gives a number of seconds after UTC (a concrete, not an abstract time). You get the same gotchas with `utcnow()`.

I'm not sure if actually deprecating `utcnow` and `utcfromtimestamp` is worth it at the moment, but we can definitely start by adding a warning box to `utcnow()` and `utcfromtimestamp()` suggesting that you use the timezone-aware versions of these instead. We may also want to adjust the opening phrasing for the "naive objects" portion of the datetime documentation as well (https://docs.python.org/3.7/library/datetime.html), to reflect the fact that naive datetimes are no longer purely abstract quantities.

----------
assignee: docs at python
components: Documentation
messages: 347148
nosy: belopolsky, docs at python, p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: Document the "gotcha" behaviors in utcnow() and utcfromtimestamp()
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37488>
_______________________________________

From report at bugs.python.org  Tue Jul  2 23:12:31 2019
From: report at bugs.python.org (liugang)
Date: Wed, 03 Jul 2019 03:12:31 +0000
Subject: [New-bugs-announce] [issue37489] pickling instance which inherited
 from Exception with keyword only parameter
Message-ID: <1562123551.66.0.0575103279234.issue37489@roundup.psfhosted.org>


New submission from liugang <liugang93 at 163.com>:

-- code 1
import pickle

class MyException():
    def __init__(self, desc, *, item):
        super().__init__()
        self.desc = desc
        self.item = item

    def __getnewargs_ex__(self):
        print('called in {}.__getnewargs_ex__'.format(self.__class__.__name__))
        return (self.desc,), self.__dict__

e = MyException('testing', item='cpu')
s = pickle.dumps(e, protocol=-1)

x = pickle.loads(s)


-- code 2
import pickle

class MyException(Exception):
    def __init__(self, desc, *, item):
        super().__init__()
        self.desc = desc
        self.item = item

    def __getnewargs_ex__(self):
        print('called in {}.__getnewargs_ex__'.format(self.__class__.__name__))
        return (self.desc,), self.__dict__

e = MyException('testing', item='cpu')
s = pickle.dumps(e, protocol=-1)

x = pickle.loads(s)

in code 1, the class is inherted from object, __getnewargs_ex__ is called and the returned args, kwargs are passed to __new__/__init__ to construct object when pickling.

in code 2, the class is inherted from Exception, __getnewargs_ex__ is not called, and rasie an exception of "TypeError: __init__() missing 1 required positional argument: 'desc'"

I think this is not python issue, it should be the right behavior of Exception. I want to known why it is, and how to implement the logic in code 2 (passing keyword only parameter to __new__/__init__ when pickling for class inherted from Exception)

----------
components: Library (Lib)
messages: 347178
nosy: liugang93
priority: normal
severity: normal
status: open
title: pickling instance which inherited from Exception with keyword only parameter
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37489>
_______________________________________

From report at bugs.python.org  Wed Jul  3 01:01:35 2019
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 03 Jul 2019 05:01:35 +0000
Subject: [New-bugs-announce] [issue37490] poor documentation for .startswith,
 .endswith
Message-ID: <1562130095.71.0.839529776545.issue37490@roundup.psfhosted.org>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

The documentation is reasonably clear regarding the first parameter, which can be a string or a tuple of strings to match at the start or end of a string.

However, the other two parameters are much less clear in their effect.

text = "Now the day is over"
text.startswith('the', 2, 8)

Does it produce True because 'w the' is at the beginning of the text[2:] ? Maybe. Or because there is an ending position, must it fail because it doesn't match all of text[2:8] ?

text.startswith('day', 8, 10)

Does this produce True because everything in day matches text[8:10] or must it always produce false for any value of text because the match is never as long as the prefix string?

text.startswith(('day', 'month', 'year'), 8, 12)

Can this ever match day or month, because it is comparing to text[8:12], or can only year match because of the start and end?

Is there a difference between the following:

text.startswith(('day', 'month', 'year'), 8, 12)
text[8:12].startswith(('day', 'month', 'year'))

If no difference, why does startswith even need the extra two parameters? Maybe only in performance?

If no difference, why doesn't the documentation describe it that way, so that it could be far clearer?

If there is a difference, what is the difference?

Similar questions for endswith.

----------
messages: 347179
nosy: v+python
priority: normal
severity: normal
status: open
title: poor documentation for .startswith, .endswith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37490>
_______________________________________

From report at bugs.python.org  Wed Jul  3 04:19:31 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Wed, 03 Jul 2019 08:19:31 +0000
Subject: [New-bugs-announce] [issue37491] IndexError in
 get_bare_quoted_string
Message-ID: <1562141971.16.0.876863205208.issue37491@roundup.psfhosted.org>


New submission from Abhilash Raj <raj.abhilash1 at gmail.com>:

from email.parser import BytesParser, Parser
from email.policy import default

payload = 'Content-Type:x;\x1b*="\'G\'\\"""""'
msg = Parser(policy=default).parsestr(payload)
print(msg.get('content-type'))


When trying to review PR for BPO 37461, I found another bug where an IndexError
is raised if there aren't closing quote characters in the input message:

Suggested patch:

@@ -1191,7 +1192,7 @@ def get_bare_quoted_string(value):
             "expected '\"' but found '{}'".format(value))
     bare_quoted_string = BareQuotedString()
     value = value[1:]
-    if value[0] == '"':
+    if value and value[0] == '"':
         token, value = get_qcontent(value)
         bare_quoted_string.append(token)
     while value and value[0] != '"':

----------
components: email
messages: 347190
nosy: barry, maxking, r.david.murray
priority: normal
severity: normal
status: open
title: IndexError in get_bare_quoted_string
type: crash
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37491>
_______________________________________

From report at bugs.python.org  Wed Jul  3 06:12:20 2019
From: report at bugs.python.org (jpic)
Date: Wed, 03 Jul 2019 10:12:20 +0000
Subject: [New-bugs-announce] [issue37492] should email.utils.parseaddr treat
 a@b. as invalid email ?
Message-ID: <1562148740.76.0.680982453684.issue37492@roundup.psfhosted.org>


New submission from jpic <jpic at yourlabs.org>:

Following up bpo-34155[0] PR#13079[1], which changes:

    >>> parseaddr('a at malicious@good')

>From returning:

    ('', 'a at malicious')

To return:

    ('', '')

As such, parseaddr behaves more like documented:

email.utils.parseaddr(address)
Parse address ? which should be the value of some address-containing field such as To or Cc ? into its constituent realname and email address parts. Returns a tuple of that information, unless the parse fails, in which case a 2-tuple of ('', '') is returned.

The pull request discussion suggested that it would be good to open a new bpo to discuss changing the following behaviour:

    parseaddr('a at b.')

>From returning:

    ('', 'a at b.')

To return a tuple of empty strings as well.

We have not found RFC to back up that `a at b.` was not a valid email, however RFC 1034 states that dots separate labels:

    When a user needs to type a domain name, the length of each label is
    omitted and the labels are separated by dots (".").

As such, my understanding is that a valid domain must not end with a dot.

[0] https://bugs.python.org/issue34155
[1] https://github.com/python/cpython/pull/13079

----------
components: email
messages: 347207
nosy: barry, jpic, r.david.murray
priority: normal
severity: normal
status: open
title: should email.utils.parseaddr treat a at b. as invalid email ?
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37492>
_______________________________________

From report at bugs.python.org  Wed Jul  3 09:39:24 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 03 Jul 2019 13:39:24 +0000
Subject: [New-bugs-announce] [issue37493] Use _PyObject_CallNoArg() in a few
 more places
Message-ID: <1562161164.42.0.425095405728.issue37493@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

Try to use _PyObject_CallNoArg in all places where a function is called without arguments.

----------
components: Interpreter Core
messages: 347230
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: Use _PyObject_CallNoArg() in a few more places
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37493>
_______________________________________

From report at bugs.python.org  Wed Jul  3 11:53:59 2019
From: report at bugs.python.org (Fourcade)
Date: Wed, 03 Jul 2019 15:53:59 +0000
Subject: [New-bugs-announce] [issue37494] Call asyncio Future in scope
Message-ID: <1562169239.78.0.569979789065.issue37494@roundup.psfhosted.org>


New submission from Fourcade <robinf95 at yahoo.fr>:

I'm trying to get the progession of my asyncIO Futures. For some reason, I can't get value updates inside any other scope.

For example:

```
import concurrent.futures
import time
import asyncio
import random

def get_progress(futures):
    return sum([f.done() for f in futures])

def long_task(t):
    time.sleep(1.5)
    return t

loop = asyncio.get_event_loop()
executor = concurrent.futures.ProcessPoolExecutor(max_workers=4)
inputs = ['a', 'b', 'c', 'd', 'e', 'f', 'g']
futures_ = [loop.run_in_executor(executor, long_task, i) for i in inputs]

for i in range(5):
    time.sleep(1)
    print(get_progress(futures_))
```

It prints only 0. However, if I run this inside a terminal and call get_progress(futures_) it prints 7 as expected.

Am I missing something here ?

----------
components: asyncio
messages: 347232
nosy: RobinFrcd, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Call asyncio Future in scope
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37494>
_______________________________________

From hobsonlane at gmail.com  Wed Jul  3 15:36:26 2019
From: hobsonlane at gmail.com (Hobson Lane)
Date: Wed, 3 Jul 2019 12:36:26 -0700
Subject: [New-bugs-announce] [issue34896] Unable to install Python 3.5
In-Reply-To: <1538671933.56.0.545547206417.issue34896@psf.upfronthosting.co.za>
References: <1538671933.56.0.545547206417.issue34896@psf.upfronthosting.co.za>
Message-ID: <CACZ_DofhiS1Pn_itBVT10RU77tdcYXrsRdtMX9DkVL90nz4Cag@mail.gmail.com>

I'd suggest using Anaconda to install python and all python packages that
you need. Once you have Anaconda installed you can type `conda install
django` and that should work. Also I'd suggest sticking with the lastest
version of python (3.7) that installs with anaconda rather than using
python 3.5. Django (and other packages) may not be compatible with python
3.5.
--Hobson



On Thu, Oct 4, 2018 at 9:52 AM Ruchir Jha <report at bugs.python.org> wrote:

>
> New submission from Ruchir Jha <ruchirkjha at gmail.com>:
>
> Hi, I was trying to install Danjo to work on Python. However it was not
> working fine hence I uninstalled the version 3.5 which I installed and
> tried to install it again as the earlier version was used for Anaconda.
> However even after multiple attempts to install Python its throws and error
> 0x80070643 fatal error during python installation. I have restarted the
> system and have also cleared the cache. I am working under strict deaadline
> hence an urgent help will be highly appreciated
>
> ----------
> components: Installation
> files: Python 3.5.0rc3 (64-bit)_20181004220550_000_core_JustForMe.log
> messages: 327067
> nosy: ruchirjha
> priority: normal
> severity: normal
> status: open
> title: Unable to install Python 3.5
> type: crash
> versions: Python 3.5
> Added file: https://bugs.python.org/file47849/Python 3.5.0rc3
> (64-bit)_20181004220550_000_core_JustForMe.log
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34896>
> _______________________________________
> _______________________________________________
> New-bugs-announce mailing list
> New-bugs-announce at python.org
> https://mail.python.org/mailman/listinfo/new-bugs-announce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20190703/16e18923/attachment.html>

From report at bugs.python.org  Wed Jul  3 17:54:34 2019
From: report at bugs.python.org (Dominik Czarnota)
Date: Wed, 03 Jul 2019 21:54:34 +0000
Subject: [New-bugs-announce] [issue37495] socket.inet_aton parsing issue on
 some libc versions
Message-ID: <1562190874.32.0.352639947279.issue37495@roundup.psfhosted.org>


New submission from Dominik Czarnota <dominik.b.czarnota at gmail.com>:

The socket.inet_aton Python function uses libc's inet_aton function. This, on some implementations, for example the latest GNU C Library (glibc 2.29 as of today), accepts whitespace with trailing characters after a valid IP.

An example can be seen below:
```
In [1]: import socket

In [2]: socket.inet_aton('1.1.1.1 this shall not pass')
Out[2]: b'\x01\x01\x01\x01'

In [3]: socket.inet_aton('1.1.1.1this shall not pass')
---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
----> 1 socket.inet_aton('1.1.1.1this shall not pass')

OSError: illegal IP address string passed to inet_aton
```

The problem is, some users might use this function to also validate whether a given host or ip string is valid, especially taking into account Python's "ask for forgiveness and not permission" motto (or a coding style?).

This will introduce security vulnerabilities, like command injections, if it is used with insecure os.system or subprocess.* functions. For example, an ip of "1.1.1.1 ; whoami" will result in returning an output of both ping and whoami commands.
```
def do_ping(request):
    """This is an insecure example, DO NOT REUSE THIS CODE"""
    ip = request['ip']

    # Try to parse as ipv4 and save to db as just 4 bytes
    try:
       ip_bytes = socket.inet_aton(ip)
    except OSError:
       return 'IP is not a valid IPv4.'

    save_ping_request_to_db(ip_bytes)

    return subprocess.check_output('ping -c1 %s' % ip, shell=True)  # an ip of "1.1.1.1 ; whomai" triggers a command injection vulnerability here
```

An initial report sent with this issue contains an example and potential security issue in ssl builtin module which has been already fixed (https://bugs.python.org/issue37463).
The socket.inet_aton function is also used in requests library utility functions, which I am also going to report just after sending this issue.


It is also worth mentioning that the inet_aton documentation - https://docs.python.org/3/library/socket.html#socket.inet_aton - states that the validation depends on the underlying implementation:
> inet_aton() also accepts strings with less than three dots; see the Unix manual page inet(3) for details.
> If the IPv4 address string passed to this function is invalid, OSError will be raised. Note that exactly what is valid depends on the underlying C implementation of inet_aton().

Which is nice but:
1. The inet(3) doesn't say that inet_aton shouldn't be used to validate whether the input is and only is an IP address or that it accepts trailing whitespace with garbage.
It only states that "inet_aton() returns nonzero if the address is valid, zero if not". I added the relevant "DESCRIPTION" part from my `man 3 inet` on an Ubuntu 18.04.1 LTS host at the end.

2. The help(socket.inet_aton) doesn't forewarn about it. For example IPython users might miss the docs and just read the help from the shell:
> Help on built-in function inet_aton in module _socket:
> 
> inet_aton(...)
>     inet_aton(string) -> bytes giving packed 32-bit IP representation
> 
>     Convert an IP address in string format (123.45.67.89) to the 32-bit packed
>     binary format used in low-level network functions.

3. "If the IPv4 address string passed to this function is invalid, OSError will be raised." vs "Note that exactly what is valid depends on (...)" is weird since "1.1.1.1 blabla" string *is just not a valid IPv4 address string*.


Ideally, the problem should be fixed on the libc side, but I don't know if it is going to be. The first comment from a similar issue on glibc bugtracker - https://sourceware.org/bugzilla/show_bug.cgi?id=20018 - states:
> For historic reasons, inet_addr and inet_aton accept trailing garbage.  Some parsers rely on this (for example, libresolv when it parses ?nameserver? directives in /etc/resolv.conf).
> 
> (...)
> 
> We should add a check for trailing garbage and relegate the old behavior to a compatibility symbol.

However I am not sure if it won't be fixed or if it was simply forgotten during fixing the linked issue as it probably wasn't reported as a separate one.

Because of that I think Python should add an additional validation of inet_aton input: raise a validation error when the input contains a whitespace.

In case this solution would be rejected because of a need/want to be consistent with C's inet_aton, we should add a security warning that using this function to validate IP addresses is dangerous on some libc version, along with a description/example what exactly is wrong with it.


--- man 3 inet, the relevant description part below ---
DESCRIPTION
       inet_aton() converts the Internet host address cp from the IPv4 numbers-and-dots notation into binary form (in network byte order) and stores it in the struc?
       ture that inp points to.  inet_aton() returns nonzero if the address is valid, zero if not.  The address supplied in cp can have one of the following forms:

       a.b.c.d   Each of the four numeric parts specifies a byte of the address; the bytes are assigned in left-to-right order to produce the binary address.

       a.b.c     Parts a and b specify the first two bytes of the binary address.  Part c is interpreted as a 16-bit value that defines the rightmost  two  bytes  of
                 the binary address.  This notation is suitable for specifying (outmoded) Class B network addresses.

       a.b       Part a specifies the first byte of the binary address.  Part b is interpreted as a 24-bit value that defines the rightmost three bytes of the binary
                 address.  This notation is suitable for specifying (outmoded) Class A network addresses.

       a         The value a is interpreted as a 32-bit value that is stored directly into the binary address without any byte rearrangement.

       In all of the above forms, components of the dotted address can be specified in decimal, octal (with a  leading  0),  or  hexadecimal,  with  a  leading  0X).
       Addresses  in  any  of  these forms are collectively termed IPV4 numbers-and-dots notation.  The form that uses exactly four decimal numbers is referred to as
       IPv4 dotted-decimal notation (or sometimes: IPv4 dotted-quad notation).

       inet_aton() returns 1 if the supplied string was successfully interpreted, or 0 if the string is invalid (errno is not set on error).
---

----------
components: Library (Lib)
messages: 347243
nosy: Dominik Czarnota
priority: normal
severity: normal
status: open
title: socket.inet_aton parsing issue on some libc versions
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37495>
_______________________________________

From report at bugs.python.org  Wed Jul  3 19:45:26 2019
From: report at bugs.python.org (Eric Snow)
Date: Wed, 03 Jul 2019 23:45:26 +0000
Subject: [New-bugs-announce] [issue37496] Support annotations in signature
 strings.
Message-ID: <1562197526.36.0.0415942737779.issue37496@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

In early 2014 (3.3), when argument clinic was added, we added support for turning func.__text_signature__ into an inspect.Signature object.  However, at that time we did not add support for annotations (see the nested "parse_name()" in _signature_fromstr().  Annotations should be supported.

I'd expect that PEP 563 (Postponed Evaluation of Annotations) could be leveraged.

----------
components: Library (Lib)
messages: 347247
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Support annotations in signature strings.
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37496>
_______________________________________

From report at bugs.python.org  Wed Jul  3 20:11:26 2019
From: report at bugs.python.org (Eric Snow)
Date: Thu, 04 Jul 2019 00:11:26 +0000
Subject: [New-bugs-announce] [issue37497] Add inspect.Signature.from_text().
Message-ID: <1562199086.77.0.800086984204.issue37497@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

In early 2014 (3.3), when argument clinic was added, we added support for turning func.__text_signature__ into an inspect.Signature object.  However, the functionality to convert a string into a Signature was never exposed publicly.  Here's a patch to do so.

Note that inspect.signature() will also support taking a string.

----------
assignee: eric.snow
components: Library (Lib)
messages: 347250
nosy: eric.snow
priority: normal
pull_requests: 14398
severity: normal
stage: needs patch
status: open
title: Add inspect.Signature.from_text().
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37497>
_______________________________________

From report at bugs.python.org  Thu Jul  4 15:11:53 2019
From: report at bugs.python.org (neonene)
Date: Thu, 04 Jul 2019 19:11:53 +0000
Subject: [New-bugs-announce] [issue37498] request.urlopen(), memory leak?
Message-ID: <1562267513.1.0.161837527387.issue37498@roundup.psfhosted.org>


New submission from neonene <nicesalmon at gmail.com>:

Python3.8.0a4,b1,b2(x64,x32)
Python3.7.4rc1,rc2 (x64,x32)
In Windows7 SP1(x64), memory usage keep increasing by the following code.
---
from urllib import request
from time import sleep
while True:
    req = request.Request('https://www.python.org/')
    request.urlopen(req)
    sleep(1)
---
Sorry, I'm not sure why.

----------
components: Windows
messages: 347293
nosy: neonene, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: request.urlopen(), memory leak?
type: resource usage
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37498>
_______________________________________

From report at bugs.python.org  Thu Jul  4 16:29:24 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 04 Jul 2019 20:29:24 +0000
Subject: [New-bugs-announce] [issue37499] test_gdb.test_pycfunction should
 use dedicated test functions
Message-ID: <1562272164.16.0.880170642341.issue37499@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

Currently, `test_pycfunction` picks a few built-in functions with various calling conventions to exercise all the relevant code paths:

        for py_name, py_args, c_name, expected_frame_number in (
            ('gmtime', '', 'time_gmtime', 1),  # METH_VARARGS
            ('len', '[]', 'builtin_len', 2),  # METH_O
            ...

See: https://github.com/python/cpython/blob/2f19e82fbe98ce86bcd98a176328af2808b678e8/Lib/test/test_gdb.py#L851

These calling conventions are not a guaranteed part of the interface, and as such these tests are fragile (as we saw in GH-14311, when converting the time module to use Argument Clinic changed gmtime from METH_VARARGS to METH_FASTCALL). Per Victor's suggestion in GH-14330, I think we should expose a few test functions in the `testcapi` module as exemplars of their respective calling conventions and use those, rather than arbitrary builtins.

----------
components: Tests
messages: 347295
nosy: p-ganssle, vstinner
priority: low
severity: normal
stage: needs patch
status: open
title: test_gdb.test_pycfunction should use dedicated test functions
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37499>
_______________________________________

From report at bugs.python.org  Thu Jul  4 23:02:39 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 05 Jul 2019 03:02:39 +0000
Subject: [New-bugs-announce] [issue37500] 3.8.0b2 no longer optimizes away
 "if 0:" ?
Message-ID: <1562295759.87.0.390556054321.issue37500@roundup.psfhosted.org>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

CPython 3.8.0b2 behaves differently than previous releases: it no longer optimizes away "if 0:" branches.  This is something that has been done since at least 2.4.  It was done in 3.8.0b1, but no longer is.

Was this a purposeful change? Why? It seems like 3.8 is adding more optimizations, why was this removed?

Test code (/tmp/no0.py):

import dis
import sys

print(sys.version)

def with_if_0():
    print(1)
    if 0:
        print(2)
    print(3)

dis.dis(with_if_0)


$ /usr/local/pythonz/pythons/CPython-3.8.0b2/bin/python3.8 /tmp/no0.py
3.8.0b2 (default, Jul  4 2019, 22:38:04)
[Clang 10.0.0 (clang-1000.10.44.4)]
  7           0 LOAD_GLOBAL              0 (print)
              2 LOAD_CONST               1 (1)
              4 CALL_FUNCTION            1
              6 POP_TOP

  8           8 LOAD_CONST               2 (0)
             10 POP_JUMP_IF_FALSE       20

  9          12 LOAD_GLOBAL              0 (print)
             14 LOAD_CONST               3 (2)
             16 CALL_FUNCTION            1
             18 POP_TOP

 10     >>   20 LOAD_GLOBAL              0 (print)
             22 LOAD_CONST               4 (3)
             24 CALL_FUNCTION            1
             26 POP_TOP
             28 LOAD_CONST               0 (None)
             30 RETURN_VALUE

$ /usr/local/pythonz/pythons/CPython-3.8.0b1/bin/python3.8 /tmp/no0.py
3.8.0b1 (default, Jun  4 2019, 21:21:14)
[Clang 10.0.0 (clang-1000.10.44.4)]
  7           0 LOAD_GLOBAL              0 (print)
              2 LOAD_CONST               1 (1)
              4 CALL_FUNCTION            1
              6 POP_TOP

 10           8 LOAD_GLOBAL              0 (print)
             10 LOAD_CONST               4 (3)
             12 CALL_FUNCTION            1
             14 POP_TOP
             16 LOAD_CONST               0 (None)
             18 RETURN_VALUE

$ python3.7 /tmp/no0.py
3.7.3 (default, Apr 10 2019, 10:27:53)
[Clang 10.0.0 (clang-1000.10.44.4)]
  7           0 LOAD_GLOBAL              0 (print)
              2 LOAD_CONST               1 (1)
              4 CALL_FUNCTION            1
              6 POP_TOP

 10           8 LOAD_GLOBAL              0 (print)
             10 LOAD_CONST               2 (3)
             12 CALL_FUNCTION            1
             14 POP_TOP
             16 LOAD_CONST               0 (None)
             18 RETURN_VALUE

$ python2.7 /tmp/no0.py
2.7.14 (default, Oct  4 2017, 09:45:53)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]
  7           0 LOAD_CONST               1 (1)
              3 PRINT_ITEM
              4 PRINT_NEWLINE

 10           5 LOAD_CONST               2 (3)
              8 PRINT_ITEM
              9 PRINT_NEWLINE
             10 LOAD_CONST               0 (None)
             13 RETURN_VALUE

$ python2.4 /tmp/no0.py
2.4.6 (#1, Jun 18 2016, 17:49:14)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
  7           0 LOAD_CONST               1 (1)
              3 PRINT_ITEM
              4 PRINT_NEWLINE

 10           5 LOAD_CONST               2 (3)
              8 PRINT_ITEM
              9 PRINT_NEWLINE
             10 LOAD_CONST               0 (None)
             13 RETURN_VALUE

----------
keywords: 3.8regression
messages: 347296
nosy: nedbat
priority: normal
severity: normal
status: open
title: 3.8.0b2 no longer optimizes away "if 0:" ?
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37500>
_______________________________________

From report at bugs.python.org  Thu Jul  4 23:30:04 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 05 Jul 2019 03:30:04 +0000
Subject: [New-bugs-announce] [issue37501] Test failures when CPython is
 built without docstrings
Message-ID: <1562297404.15.0.705525533072.issue37501@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

test_coroutines, test_dataclasses, test_idle, test_importlib, test_module, and test_pydoc fail when CPython is built without docstrings. 

It seems that most of the failures occur simply because the test.support.requires_docstrings decorator is missing for some tests.

See also bpo-17041.

----------
components: Tests
files: test_failures_without_docstrings.txt
messages: 347298
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Test failures when CPython is built without docstrings
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48456/test_failures_without_docstrings.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37501>
_______________________________________

From report at bugs.python.org  Thu Jul  4 23:33:15 2019
From: report at bugs.python.org (Markus Mohrhard)
Date: Fri, 05 Jul 2019 03:33:15 +0000
Subject: [New-bugs-announce] [issue37502] Pure Python pickle module should
 not depend on _pickle.PickleBuffer
Message-ID: <1562297595.0.0.947701314803.issue37502@roundup.psfhosted.org>


New submission from Markus Mohrhard <markusm at dug.com>:

The following piece of code

import pickle
pickle.loads(pickle.dumps(1, protocol=pickle.HIGHEST_PROTOCOL), buffers=None)

fails with "TypeError: 'NoneType' object is not iterable"

The corresponding PEP (https://www.python.org/dev/peps/pep-0574/) specifies that buffer=None is the default but the C implementation does not check for Py_None.

The PR contains a test for this case that fails without the fix.

----------
components: Library (Lib)
messages: 347299
nosy: Markus Mohrhard
priority: normal
severity: normal
status: open
title: Pure Python pickle module should not depend on _pickle.PickleBuffer
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37502>
_______________________________________

From report at bugs.python.org  Fri Jul  5 04:20:39 2019
From: report at bugs.python.org (Marco Dickert)
Date: Fri, 05 Jul 2019 08:20:39 +0000
Subject: [New-bugs-announce] [issue37503] Queue.join(): Broken example in
 documentation
Message-ID: <1562314839.12.0.185461077472.issue37503@roundup.psfhosted.org>


New submission from Marco Dickert <marco at misterunknown.de>:

I guess I found a bug in the documented Queue.join() example [1].

The problem is the break condition for the while loop of the worker. If the item is None, the loop breaks, but the worker never calls item.task_done(). Thus the q.join() statement never returns, because the last task (None) remains unfinished.

This should solve the issue:

```
if item is None:
  item.task_done()
  break
```

[1] https://docs.python.org/3/library/queue.html#queue.Queue.join

----------
assignee: docs at python
components: Documentation
messages: 347310
nosy: docs at python, misterunknown
priority: normal
severity: normal
status: open
title: Queue.join(): Broken example in documentation
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37503>
_______________________________________

From report at bugs.python.org  Fri Jul  5 05:49:15 2019
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 05 Jul 2019 09:49:15 +0000
Subject: [New-bugs-announce] [issue37504] 3.8 b2 now requires sphinx2,
 but only has documented 1.8
Message-ID: <1562320155.27.0.39785501395.issue37504@roundup.psfhosted.org>


New submission from Matthias Klose <doko at debian.org>:

3.8 b2 now requires sphinx2 (according to SilentGhost on IRC), but only has documented 1.8. I'm aware of issue #36007, the last time that the requirements were bumped.

So again, the dependencies were bumped without documenting, and why do we require the latest sphinx again?

It's difficult to provide the documentation as a Linux distro when you always have to provide the latest build tools.  Please compare that to other projects that are usually fine to build with any doxygen, texinfo, or whatever doc tool.

Any hint where the new dependency was introduced, and probably can be backed out?

The actuall error is:
writing... 
Exception occurred:
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 567, in __getitem__
    return self.attributes[key]
KeyError: 'cols'



# Sphinx version: 1.8.4
# Python version: 3.7.3 (CPython)
# Docutils version: 0.14 
# Jinja2 version: 2.10
# Last messages:
#   distutils/sourcedist
#   distutils/builtdist
#   distutils/examples
#   distutils/extending
#   distutils/commandref
#   distutils/apiref
#   install/index
#   
#   resolving references...
#   writing...
# Loaded extensions:
#   sphinx.ext.mathjax (1.8.4) from /usr/lib/python3/dist-packages/sphinx/ext/mathjax.py
#   alabaster (0.7.8) from /usr/lib/python3/dist-packages/alabaster/__init__.py
#   sphinx.ext.coverage (1.8.4) from /usr/lib/python3/dist-packages/sphinx/ext/coverage.py
#   sphinx.ext.doctest (1.8.4) from /usr/lib/python3/dist-packages/sphinx/ext/doctest.py
#   pyspecific (1.0) from /home/packages/python/3.8/python3.8-3.8.0~b2/Doc/tools/extensions/pyspecific.py
#   c_annotations (1.0) from /home/packages/python/3.8/python3.8-3.8.0~b2/Doc/tools/extensions/c_annotations.py
#   escape4chm (1.0) from /home/packages/python/3.8/python3.8-3.8.0~b2/Doc/tools/extensions/escape4chm.py
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 304, in build_main
    app.build(args.force_all, filenames)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 341, in build
    self.builder.build_update()
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 342, in build_update
    self.build(['__all__'], to_build)
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 412, in build
    self.write(docnames, list(updated_docnames), method)
  File "/usr/lib/python3/dist-packages/sphinx/builders/texinfo.py", line 187, in write
    docwriter.write(doctree, destination)
  File "/usr/lib/python3/dist-packages/docutils/writers/__init__.py", line 80, in write
    self.translate()
  File "/usr/lib/python3/dist-packages/sphinx/writers/texinfo.py", line 139, in translate
    self.document.walkabout(visitor)
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 174, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 174, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 174, in walkabout
    if child.walkabout(visitor):
  [Previous line repeated 9 more times]
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 166, in walkabout
    visitor.dispatch_visit(self)
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 1882, in dispatch_visit
    return method(node)
  File "/usr/lib/python3/dist-packages/sphinx/writers/texinfo.py", line 1126, in visit_tgroup
    self.n_cols = node['cols']
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 567, in __getitem__
    return self.attributes[key]
KeyError: 'cols'

----------
assignee: docs at python
components: Documentation
messages: 347322
nosy: docs at python, doko
priority: normal
severity: normal
status: open
title: 3.8 b2 now requires sphinx2, but only has documented 1.8
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37504>
_______________________________________

From report at bugs.python.org  Fri Jul  5 08:07:59 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 05 Jul 2019 12:07:59 +0000
Subject: [New-bugs-announce] [issue37505] Early auditing broken
Message-ID: <1562328479.24.0.514484433383.issue37505@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

I think that commit 838f26402de82640698c38ea9d2be65c6cf780d6 / bpo-36710 broke auditing for early events. I'm no longer seeing early events like cpython.PyInterpreterState_New. The first event is an import event without interpreter state.

----------
components: Interpreter Core
messages: 347334
nosy: christian.heimes, steve.dower, vstinner
priority: normal
severity: normal
status: open
title: Early auditing broken
type: security
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37505>
_______________________________________

From report at bugs.python.org  Fri Jul  5 10:01:48 2019
From: report at bugs.python.org (Holly)
Date: Fri, 05 Jul 2019 14:01:48 +0000
Subject: [New-bugs-announce] [issue37506] os.mkdir creates invalid folder
 when path string has trailing space and slash
Message-ID: <1562335308.56.0.146479172275.issue37506@roundup.psfhosted.org>


New submission from Holly <hollyrobertsgb at gmail.com>:

If we use os.mkdir to create a folder as follows:
    os.mkdir("C:/test /")
Then we successfully create a folder with name "test ". This folder can be accessed normally, but it cannot be renamed or deleted. Instead we get the following error message:
    Could not find this item
    This is no longer located in C:\. Verify the item's location and try again.
I used Python 3.7.3 (64 bit) and Windows 1809

Obviously this is down to how windows doesn't handle paths particularly nicely, so it's not really python's fault. However even if it's decided that python shouldn't handle this then it would be better for an exception to be thrown rather than creating a corrupt folder.

Note: We can delete the folder by using the Long UNC path, eg. rd "\\?\C:\test "

----------
components: IO
messages: 347346
nosy: hollyroberts
priority: normal
severity: normal
status: open
title: os.mkdir creates invalid folder when path string has trailing space and slash
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37506>
_______________________________________

From report at bugs.python.org  Fri Jul  5 10:22:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 05 Jul 2019 14:22:18 +0000
Subject: [New-bugs-announce] [issue37507] multiprocessing: Add a stop()
 method to ForkServer
Message-ID: <1562336538.11.0.898279442139.issue37507@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

While working on bpo-37421, I fixed multiprocessing tests to explicitly call _run_finaliers(), so temporary directories are removed:

New changeset 039fb49c185570ab7b02f13fbdc51c859cfd831e by Victor Stinner in branch 'master':
bpo-37421: multiprocessing tests call _run_finalizers() (GH-14527)
https://github.com/python/cpython/commit/039fb49c185570ab7b02f13fbdc51c859cfd831e

Problem: some tests started to fail when run more than once, which happens using ./python -m test -R 3:3 (hunt reference leaks). So I made a first change:

New changeset 9d40554e0da09a44a8547f3f3a2b9dedfeaf7928 by Victor Stinner in branch 'master':
bpo-37421: Fix multiprocessing get_temp_dir() finalizer (GH-14572)
https://github.com/python/cpython/commit/9d40554e0da09a44a8547f3f3a2b9dedfeaf7928

But I also had to explicitly stop the ForkServer:

New changeset 9d40554e0da09a44a8547f3f3a2b9dedfeaf7928 by Victor Stinner in branch 'master':
bpo-37421: Fix multiprocessing get_temp_dir() finalizer (GH-14572)
https://github.com/python/cpython/commit/9d40554e0da09a44a8547f3f3a2b9dedfeaf7928


I propose to add a public ForkServer.stop() method to stop the server. The method would block until the server stops. The server doesn't track its children, so if there are running child processes, they will continue to run after stop() completes. Child processes are tracked by APIs like multiprocessing Pool.

I dislike relying on implicit resource management. I prefer to handle them explicitly, to ensure that errors are properly reported if something goes wrong. Implicit resource management rely on Python destructor which may be called very late during Python finalization, while other modules are already cleaned up, and so some function may fail silently (the machineny to report issues is broken as well).


In short, I propose to rename the new _stop() method as stop() and document it properly :-)

----------
components: Library (Lib)
messages: 347351
nosy: davin, pablogsal, pitrou, vstinner
priority: normal
severity: normal
status: open
title: multiprocessing: Add a stop() method to ForkServer
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37507>
_______________________________________

From report at bugs.python.org  Fri Jul  5 11:14:10 2019
From: report at bugs.python.org (hai shi)
Date: Fri, 05 Jul 2019 15:14:10 +0000
Subject: [New-bugs-announce] [issue37508] A wrong return type in memory.rst
Message-ID: <1562339650.89.0.898406342739.issue37508@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

the result should be a bytes object in #L70 in https://github.com/python/cpython/blob/master/Doc/c-api/memory.rst

----------
assignee: docs at python
components: Documentation
messages: 347356
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: A wrong return type in memory.rst

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37508>
_______________________________________

From report at bugs.python.org  Fri Jul  5 13:50:39 2019
From: report at bugs.python.org (YoSTEALTH)
Date: Fri, 05 Jul 2019 17:50:39 +0000
Subject: [New-bugs-announce] [issue37509] OSError preadv()
Message-ID: <1562349039.72.0.211859672318.issue37509@roundup.psfhosted.org>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

import os
import ctypes

# Stdlib
# ------
def test_preadv_stdlib(path):
    fd = os.open(path, os.O_RDWR | os.O_CREAT)
    buffer = bytearray(10)
    buffers = [buffer]
    try:
        length = os.preadv(fd, buffers, 0, os.RWF_NOWAIT)
        # OSError: [Errno 95] Operation not supported
        print('length:', length)
        print('buffer:', buffer)
    finally:
        os.close(fd)


# Cyptes Libc
# -----------
class iovec(ctypes.Structure):
    _fields_ = [('iov_base', ctypes.c_char_p), ('iov_len', ctypes.c_size_t)]


libc = ctypes.CDLL('libc.so.6')


def test_preadv_libc(path):
    fd = os.open(path, os.O_RDWR | os.O_CREAT)
    buffer = bytes(10)
    buffers = (iovec*1)()
    buffers[0].iov_base = buffer
    buffers[0].iov_len = 10
    try:
        length = libc.preadv2(fd, buffers, len(buffers), 0, os.RWF_NOWAIT)
        print('length:', length)  # length: -1
        print('buffer:', buffer)  # buffer: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
    finally:
        os.close(fd)


# Test Run
# --------
def test():
    path = '/dev/shm/test-preadv-in-ram-file'

    # Test-1 stdlib implementation
    try:
        test_preadv_stdlib(path)  # OSError: [Errno 95] Operation not supported
    except OSError:
        print('OSError is raised. This should not raise OSError')

    # Test-2 custom ctype `libc` implementation
    test_preadv_libc(path)


if __name__ == '__main__':
    test()


This code is just to demonstrate working vs receiving an OSError in this specific usage.

System:   Linux 4.19.56-1-MANJARO
Python:   3.8.0b2

When the file in question is stored in ram ('/dev/shm') stdlib implementation raises an OSError while libc version does not.

----------
messages: 347364
nosy: YoSTEALTH, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: OSError preadv()
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37509>
_______________________________________

From report at bugs.python.org  Fri Jul  5 16:45:30 2019
From: report at bugs.python.org (Jorge L. Martinez)
Date: Fri, 05 Jul 2019 20:45:30 +0000
Subject: [New-bugs-announce] [issue37510] argparse removing more "--" than
 it should
Message-ID: <1562359530.82.0.205006034858.issue37510@roundup.psfhosted.org>


New submission from Jorge L. Martinez <jol at fastmail.com>:

$ python -c '
import argparse
p = argparse.ArgumentParser()
p.add_argument("first_arg")
p.add_argument("args", nargs="*")
r = p.parse_args(["foo", "--", "bar", "--", "baz", "--", "zap"])
print(r.first_arg + " " + " ".join(r.args))
'                        

returns:

foo bar baz -- zap

when I think it should return:

foo bar -- baz -- zap

----------
components: Library (Lib)
messages: 347378
nosy: jol
priority: normal
severity: normal
status: open
title: argparse removing more "--" than it should
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37510>
_______________________________________

From report at bugs.python.org  Fri Jul  5 16:51:43 2019
From: report at bugs.python.org (David Carlier)
Date: Fri, 05 Jul 2019 20:51:43 +0000
Subject: [New-bugs-announce] [issue37511] mmap module add OpenBSD
 MADV_CONCEAL flag
Message-ID: <1562359903.85.0.72937349499.issue37511@roundup.psfhosted.org>


Change by David Carlier <dcarlier at afilias.info>:


----------
nosy: David Carlier
priority: normal
pull_requests: 14424
severity: normal
status: open
title: mmap module add OpenBSD MADV_CONCEAL flag
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37511>
_______________________________________

From report at bugs.python.org  Fri Jul  5 17:33:18 2019
From: report at bugs.python.org (Dmitriy)
Date: Fri, 05 Jul 2019 21:33:18 +0000
Subject: [New-bugs-announce] [issue37512] Error in the documentation about
 string concatenation
Message-ID: <1562362398.93.0.443192979272.issue37512@roundup.psfhosted.org>


New submission from Dmitriy <mironovd at icloud.com>:

There is an error in documentation about string concatenation:

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

---
Common Sequence Operations
[...]
6. Concatenating immutable sequences always results in a new object. This means that building up a sequence by repeated concatenation will have a quadratic runtime cost in the total sequence length. To get a linear runtime cost, you must switch to one of the alternatives below:

- if concatenating str objects, you can build a list and use str.join() at the end or else write to an io.StringIO instance and retrieve its value when complete
---

It is not true for str objects anymore. Example using timeit module shows that time grows linearly:
>>> timeit('a+="a"', setup='a=""', number=10000)
0.0005754000012530014
>>> timeit('a+="a"', setup='a=""', number=100000)
0.005819800004246645

But for bytes it is still right:
>>> timeit('a+=b"a"', setup='a=b""', number=10000)
0.0017669000080786645
>>> timeit('a+=b"a"', setup='a=b""', number=100000)
0.20758410000416916

----------
assignee: docs at python
components: Documentation
messages: 347390
nosy: dmitriym, docs at python
priority: normal
severity: normal
status: open
title: Error in the documentation about string concatenation
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37512>
_______________________________________

From report at bugs.python.org  Sat Jul  6 00:28:06 2019
From: report at bugs.python.org (hai shi)
Date: Sat, 06 Jul 2019 04:28:06 +0000
Subject: [New-bugs-announce] [issue37513] Fix a type error in ctypes.rst
Message-ID: <1562387286.6.0.643530884918.issue37513@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

Python 3.9.0a0 (heads/master-dirty:80097e0, Jul  6 2019, 02:14:54)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> class POINT(Structure):
...     _fields_ = [("x", c_int),
...                 ("y", c_int)]
...
>>> POINT(1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: too many initializers

and the init function in:
https://github.com/python/cpython/blob/master/Modules/_ctypes/_ctypes.c#L4335

----------
assignee: docs at python
components: Documentation
messages: 347419
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: Fix a type error in ctypes.rst

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37513>
_______________________________________

From report at bugs.python.org  Sat Jul  6 09:23:10 2019
From: report at bugs.python.org (=?utf-8?q?Lanteri_J=C3=A9r=C3=B4me?=)
Date: Sat, 06 Jul 2019 13:23:10 +0000
Subject: [New-bugs-announce] [issue37514] french translation Spelling
 mistake on datetime python's library documentation online
Message-ID: <1562419390.4.0.81704201562.issue37514@roundup.psfhosted.org>


New submission from Lanteri J?r?me <jerome.archlinux at gmail.com>:

"Un objet avis? est utilis? pour repr?sent? un moment"
corrected should be:
"Un objet avis? est utilis? pour repr?senter un moment"

Comment for help French translator:
Vous pouvez tester en rempla?ant le verbe suspect? par un verbe du troisi?me groupe, tel que "faire":
"Un objet avis? est utilis? pour faire..." (?a fonctionne, il n'est pas conjugu?, par ce que on ne pourrait pas dire: "Un objet avis? est utilis? pour fait..."). C'est une astuce facile ? retenir.

----------
assignee: docs at python
components: Documentation
messages: 347432
nosy: docs at python, jerome_l
priority: normal
severity: normal
status: open
title: french translation Spelling mistake on datetime python's library documentation online
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37514>
_______________________________________

From report at bugs.python.org  Sat Jul  6 13:04:53 2019
From: report at bugs.python.org (Carsten)
Date: Sat, 06 Jul 2019 17:04:53 +0000
Subject: [New-bugs-announce] [issue37515] `open("aux.txt",
 "w")` fails unexpectedly with FileNotFoundError on Windows
Message-ID: <1562432693.47.0.818477599166.issue37515@roundup.psfhosted.org>


New submission from Carsten <carsten.knoll at posteo.de>:

I maintain a package which includes a package named "aux.py".
I could not install it on my windows machine via pip and others had the same problem also with windows.

I tracked down the problem to `io.open`. On my Windows 7 System with Python 3.7.1 from Anaconda, the following statements all result in a FileNotFoundError:

open("aux", "w")
open("Aux", "w")
open("AUX", "w")
open("aux.py", "w")
open("aux.py", "wb")
open("aux.txt", "w")


On the other hand the following commands work as expected:

open("aaux", "w")
open("AUX1.txt", "w")
open("aux2.py", "w")

etc.


Can anybody confirm this?


On Linux (I could not reproduce the problem.)

----------
components: IO
files: bug.png
messages: 347436
nosy: CarK
priority: normal
severity: normal
status: open
title: `open("aux.txt", "w")` fails unexpectedly with FileNotFoundError on Windows
versions: Python 3.7
Added file: https://bugs.python.org/file48459/bug.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37515>
_______________________________________

From report at bugs.python.org  Sat Jul  6 16:54:24 2019
From: report at bugs.python.org (Gordon R. Burgess)
Date: Sat, 06 Jul 2019 20:54:24 +0000
Subject: [New-bugs-announce] [issue37516] buid error - test_asyncio fails
 during make
Message-ID: <1562446464.35.0.966251927477.issue37516@roundup.psfhosted.org>


New submission from Gordon R. Burgess <gordon at parasamgate.com>:

0:02:03 load avg: 3.08 [ 26/423] test_asyncio
Unknown child process pid 30234, will report returncode 255
Child watcher got an unexpected pid: 30234
Traceback (most recent call last):
  File "/home/gordon/Images/Python/Python-3.8.0b2/Lib/asyncio/unix_events.py", line 1213, in _do_waitpid
    loop, callback, args = self._callbacks.pop(pid)
KeyError: 30234

(first issue I've logged here, so thanks for your patience!  This system is Debian 9.9 - a 3.7 make was running at the same time but had completed all of the tests before I kicked 3.8 off)

----------
components: Installation
messages: 347443
nosy: gburgess
priority: normal
severity: normal
status: open
title: buid error - test_asyncio fails during make
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37516>
_______________________________________

From report at bugs.python.org  Sat Jul  6 20:00:34 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 07 Jul 2019 00:00:34 +0000
Subject: [New-bugs-announce] [issue37517] Improve error messages for Windows
 reserved file names
Message-ID: <1562457634.89.0.989040753976.issue37517@roundup.psfhosted.org>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

See #37515.

Perhaps Windows builds can check for reserved file names and give a more descriptive error message in the event of IO error?

(Eryksun also mentions two reserved names which Microsoft apparently does not document: "CONIN$" and "CONOUT$".)

----------
components: Windows
messages: 347456
nosy: CarK, SilentGhost, eryksun, paul.moore, steve.dower, steven.daprano, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Improve error messages for Windows reserved file names
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37517>
_______________________________________

From report at bugs.python.org  Sat Jul  6 22:43:59 2019
From: report at bugs.python.org (Willie Lopez)
Date: Sun, 07 Jul 2019 02:43:59 +0000
Subject: [New-bugs-announce] [issue37518] Python-2.7.16 fails to build with
 --enable-shared
Message-ID: <1562467439.87.0.798383157729.issue37518@roundup.psfhosted.org>


New submission from Willie Lopez <willie.lopez at yahoo.com>:

When building Python-2.7.16 on CentOS-7.4, building with --enable-shared through ./configure will cause Python to fail its build without errors and will install python-2.7.5, the wrong version. If Python is built without --enable-shared, other compilations that need Python will fail with the cryptic error in the following. Recompiling the app such as Apache will continue fail even when explicitly defining -fPIC in CFLAGS. However, trying to build Python with the shared flag appears to succeed, but in fact it fails and installs Python-2.7.5, the wrong version. 

/bin/ld: /usr/local/lib/libz.a(crc32.o): relocation R_X86_64_32 against .rodata' can not be used when making a shared object; recompile with -fPIC 

I have tried to build manually build Python with the following:
./buildconf (with and without running buildconf)
CFLAGS='-fPIC -g -O2' ./configure --prefix=$HOME/tools 
make
make altinstall %{buildroot}%{prefix} 

What am I missing? What am I doing wrong in the build?

----------
components: Build
messages: 347461
nosy: lopez at ucar.edu
priority: normal
severity: normal
status: open
title: Python-2.7.16 fails to build with --enable-shared
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37518>
_______________________________________

From report at bugs.python.org  Sun Jul  7 08:30:52 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 07 Jul 2019 12:30:52 +0000
Subject: [New-bugs-announce] [issue37519] Three inconsistent module
 attributes
Message-ID: <1562502652.41.0.952456238618.issue37519@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

Analysis
========

In the next two sections showing the module attributes and corresponding spec attributes of imported modules and run modules, we notice the following rule (which is in accordance with this `PEP 451 section <https://www.python.org/dev/peps/pep-0451/#attributes>`_):

    If a *spec* attribute is either ``None``, ``'built-in'`` or ``'frozen'``, then the corresponding *module* attribute is not set.

However we also notice three exceptions to this rule, that I think are unintended inconsistencies that should be corrected:

- ``module.__file__ is None`` (instead of being not set) for imported namespace packages;
- ``module.__cached__ is None`` (instead of being not set) for non-package modules run from the file system and run from standard input;
- ``module.__package__ is None`` (instead of being ``''``) for non-package modules run from the file system and run from standard input.

The first exception was introduced recently (26 February 2018) by this `pull request <https://github.com/python/cpython/pull/5481>`_, which changed the ``module.__spec__.origin`` attribute from ``namespace`` to ``None`` (which I agree with as it avoids conflicting non-namespace-package modules named ``namespace`` with namespace packages) and the ``module.__file__`` attribute from being unset to ``None`` (which I disagree with as it introduces an inconsistency and contradicts PEP 451).

Environment: CPython 3.7, MacOS 10.14.


Imported modules
================

Running the following code::

    import module

    print("MODULE")

    for attr in ["__name__", "__file__", "__cached__", "__path__", "__package__", "__loader__"]:
        print(f"{attr}:", repr(getattr(module, attr, "not set")))

    print("SPEC")

    if hasattr(module, "__spec__"):
        if module.__spec__ is None:
            print("__spec__:", repr(module.__spec__))
        else:
            for attr in ["name", "origin", "cached", "submodule_search_locations", "parent", "loader"]:
                print(f"__spec__.{attr}:", repr(getattr(module.__spec__, attr)))
    else:
        print("__spec__: not set")

where ``module`` refers to:

- a non-package module (e.g., ``pathlib``);
- a regular package (e.g., ``json``);
- a namespace package;
- a built-in module (e.g., ``time``);
- a frozen module (e.g., ``_frozen_importlib_external``)

prints the following module attributes and corresponding spec attributes of the imported ``module``:

- for a non-package module:

| MODULE
| __name__: 'pathlib'
| __file__: '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pathlib.py'
| __cached__: '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/__pycache__/pathlib.cpython-37.pyc'
| __path__: 'not set'
| __package__: ''
| __loader__: <_frozen_importlib_external.SourceFileLoader object at 0x1018896d8>
| SPEC
| __spec__.name: 'pathlib'
| __spec__.origin: '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pathlib.py'
| __spec__.cached: '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/__pycache__/pathlib.cpython-37.pyc'
| __spec__.submodule_search_locations: None
| __spec__.parent: ''
| __spec__.loader: <_frozen_importlib_external.SourceFileLoader object at 0x1018896d8>

- for a regular package:

| MODULE
| __name__: 'json'
| __file__: '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/__init__.py'
| __cached__: '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/__pycache__/__init__.cpython-37.pyc'
| __path__: ['/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json']
| __package__: 'json'
| __loader__: <_frozen_importlib_external.SourceFileLoader object at 0x10f9aa6d8>
| SPEC
| __spec__.name: 'json'
| __spec__.origin: '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/__init__.py'
| __spec__.cached: '/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/__pycache__/__init__.cpython-37.pyc'
| __spec__.submodule_search_locations: ['/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json']
| __spec__.parent: 'json'
| __spec__.loader: <_frozen_importlib_external.SourceFileLoader object at 0x10f9aa6d8>

- for a namespace package:

| MODULE
| __name__: 'foobar'
| __file__: None
| __cached__: 'not set'
| __path__: _NamespacePath(['/Users/maggyero/foobar'])
| __package__: 'foobar'
| __loader__: <_frozen_importlib_external._NamespaceLoader object at 0x1074564a8>
| SPEC
| __spec__.name: 'foobar'
| __spec__.origin: None
| __spec__.cached: None
| __spec__.submodule_search_locations: _NamespacePath(['/Users/maggyero/foobar'])
| __spec__.parent: 'foobar'
| __spec__.loader: <_frozen_importlib_external._NamespaceLoader object at 0x1074564a8>

- for a built-in module:

| MODULE
| __name__: 'time'
| __file__: 'not set'
| __cached__: 'not set'
| __path__: 'not set'
| __package__: ''
| __loader__: <class '_frozen_importlib.BuiltinImporter'>
| SPEC
| __spec__.name: 'time'
| __spec__.origin: 'built-in'
| __spec__.cached: None
| __spec__.submodule_search_locations: None
| __spec__.parent: ''
| __spec__.loader: <class '_frozen_importlib.BuiltinImporter'>

- for a frozen module:

| MODULE
| __name__: '_frozen_importlib_external'
| __file__: 'not set'
| __cached__: 'not set'
| __path__: 'not set'
| __package__: ''
| __loader__: <class '_frozen_importlib.FrozenImporter'>
| SPEC
| __spec__.name: '_frozen_importlib_external'
| __spec__.origin: 'frozen'
| __spec__.cached: None
| __spec__.submodule_search_locations: None
| __spec__.parent: ''
| __spec__.loader: <class '_frozen_importlib.FrozenImporter'>


Run modules
===========

Putting the following code::

    import sys

    print("MODULE")

    for attr in ["__name__", "__file__", "__cached__", "__path__", "__package__", "__loader__"]:
        print(f"{attr}:", repr(getattr(sys.modules[__name__], attr, "not set")))

    print("SPEC")

    if hasattr(sys.modules[__name__], "__spec__"):
        if sys.modules[__name__].__spec__ is None:
            print("__spec__:", repr(sys.modules[__name__].__spec__))
        else:
            for attr in ["name", "origin", "cached", "submodule_search_locations", "parent", "loader"]:
                print(f"__spec__.{attr}:", repr(getattr(sys.modules[__name__].__spec__, attr)))
    else:
        print("__spec__: not set")

in:

- a module.py file for getting a ``module`` non-package module;
- a __main__.py file in a module directory with an __init__.py file for getting a ``module`` regular package;
- a __main__.py file in a module directory without an __init__.py file for getting a ``module`` namespace package

and running the code:

- from the file system (``python3 module.py`` for a non-package module, ``python3 module/`` for a package module);
- from standard input (``cat module.py | python3`` for a non-package module);
- from the module namespace (``python3 -m module``)

prints the following module attributes and corresponding spec attributes of the run ``module``:

- for a non-package module:

| $ python3 module.py
| MODULE
| __name__: '__main__'
| __file__: 'module.py'
| __cached__: None
| __path__: 'not set'
| __package__: None
| __loader__: <_frozen_importlib_external.SourceFileLoader object at 0x1051970b8>
| SPEC
| __spec__: None
|
| $ cat module.py | python3
| MODULE
| __name__: '__main__'
| __file__: '<stdin>'
| __cached__: None
| __path__: 'not set'
| __package__: None
| __loader__: <class '_frozen_importlib.BuiltinImporter'>
| SPEC
| __spec__: None
|
| $ python3 -m module
| MODULE
| __name__: '__main__'
| __file__: '/Users/maggyero/module.py'
| __cached__: '/Users/maggyero/__pycache__/module.cpython-37.pyc'
| __path__: 'not set'
| __package__: ''
| __loader__: <_frozen_importlib_external.SourceFileLoader object at 0x1056b16d8>
| SPEC
| __spec__.name: 'module'
| __spec__.origin: '/Users/maggyero/module.py'
| __spec__.cached: '/Users/maggyero/__pycache__/module.cpython-37.pyc'
| __spec__.submodule_search_locations: None
| __spec__.parent: ''
| __spec__.loader: <_frozen_importlib_external.SourceFileLoader object at 0x1056b16d8>

- for a regular package:

| $ python3 module/
| MODULE
| __name__: '__main__'
| __file__: 'module/__main__.py'
| __cached__: 'module/__pycache__/__main__.cpython-37.pyc'
| __path__: 'not set'
| __package__: ''
| __loader__: <_frozen_importlib_external.SourceFileLoader object at 0x10826a550>
| SPEC
| __spec__.name: '__main__'
| __spec__.origin: 'module/__main__.py'
| __spec__.cached: 'module/__pycache__/__main__.cpython-37.pyc'
| __spec__.submodule_search_locations: None
| __spec__.parent: ''
| __spec__.loader: <_frozen_importlib_external.SourceFileLoader object at 0x10826a550>
|
| $ python3 -m module
| MODULE
| __name__: '__main__'
| __file__: '/Users/maggyero/module/__main__.py'
| __cached__: '/Users/maggyero/module/__pycache__/__main__.cpython-37.pyc'
| __path__: 'not set'
| __package__: 'module'
| __loader__: <_frozen_importlib_external.SourceFileLoader object at 0x10832d278>
| SPEC
| __spec__.name: 'module.__main__'
| __spec__.origin: '/Users/maggyero/module/__main__.py'
| __spec__.cached: '/Users/maggyero/module/__pycache__/__main__.cpython-37.pyc'
| __spec__.submodule_search_locations: None
| __spec__.parent: 'module'
| __spec__.loader: <_frozen_importlib_external.SourceFileLoader object at 0x10832d278>

- for a namespace package:

| $ python3 module/
| MODULE
| __name__: '__main__'
| __file__: 'module/__main__.py'
| __cached__: 'module/__pycache__/__main__.cpython-37.pyc'
| __path__: 'not set'
| __package__: ''
| __loader__: <_frozen_importlib_external.SourceFileLoader object at 0x107a06518>
| SPEC
| __spec__.name: '__main__'
| __spec__.origin: 'module/__main__.py'
| __spec__.cached: 'module/__pycache__/__main__.cpython-37.pyc'
| __spec__.submodule_search_locations: None
| __spec__.parent: ''
| __spec__.loader: <_frozen_importlib_external.SourceFileLoader object at 0x107a06518>
|
| $ python3 -m module
| MODULE
| __name__: '__main__'
| __file__: '/Users/maggyero/module/__main__.py'
| __cached__: '/Users/maggyero/module/__pycache__/__main__.cpython-37.pyc'
| __path__: 'not set'
| __package__: 'module'
| __loader__: <_frozen_importlib_external.SourceFileLoader object at 0x10fb69240>
| SPEC
| __spec__.name: 'module.__main__'
| __spec__.origin: '/Users/maggyero/module/__main__.py'
| __spec__.cached: '/Users/maggyero/module/__pycache__/__main__.cpython-37.pyc'
| __spec__.submodule_search_locations: None
| __spec__.parent: 'module'
| __spec__.loader: <_frozen_importlib_external.SourceFileLoader object at 0x10fb69240>

----------
components: Interpreter Core, Library (Lib)
messages: 347470
nosy: barry, eric.smith, maggyero, ncoghlan
priority: normal
severity: normal
status: open
title: Three inconsistent module attributes
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37519>
_______________________________________

From report at bugs.python.org  Sun Jul  7 16:54:03 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Jul 2019 20:54:03 +0000
Subject: [New-bugs-announce] [issue37520] zipfile.Path.parent returns
 incorrect value (same as self) for directory ref
Message-ID: <1562532843.64.0.14097351238.issue37520@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Originally reported in https://github.com/jaraco/zipp/issues/7, the parent of a Path object referencing a directory is returning the incorrect result:

cpython master $ docker run -it python:rc-buster                                                                                             
Python 3.8.0b1 (default, Jun 27 2019, 22:38:51) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
>>> import io
>>> zf = zipfile.ZipFile(io.BytesIO(), 'w')
>>> p = zipfile.Path(zf)
>>> p.joinpath('missing/').parent
Path(None, 'missing/')
>>> p.joinpath('missing/').parent.at
'missing/'

The expected value is '' as the parent of a single-level directory is the parent directory.

----------
components: Library (Lib)
messages: 347479
nosy: jaraco
priority: normal
severity: normal
status: open
title: zipfile.Path.parent returns incorrect value (same as self) for directory ref
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37520>
_______________________________________

From report at bugs.python.org  Sun Jul  7 20:52:26 2019
From: report at bugs.python.org (Benjamin Mintz)
Date: Mon, 08 Jul 2019 00:52:26 +0000
Subject: [New-bugs-announce] [issue37521] importlib.util.module_from_spec
 return value is not the same as in sys.modules
Message-ID: <1562547146.83.0.540334530677.issue37521@roundup.psfhosted.org>


New submission from Benjamin Mintz <benjabean1 at gmail.com>:

unzip the attached zip file and run main.py

expected output:

True
<module 'testext.sub' (namespace)>

actual output:
False
<module 'testext.sub' (namespace)>

So what?
If you follow these directions, https://docs.python.org/3.7/library/importlib.html#checking-if-a-module-can-be-imported , you will put a stale reference in sys.modules even though a fresh reference is already there. If you use that code on a package with a subpackage, the subpackage will not be set as an attribute on the package.

----------
components: Library (Lib)
files: importsfucked.zip
messages: 347482
nosy: bmintz
priority: normal
severity: normal
status: open
title: importlib.util.module_from_spec return value is not the same as in sys.modules
versions: Python 3.7
Added file: https://bugs.python.org/file48460/importsfucked.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37521>
_______________________________________

From report at bugs.python.org  Mon Jul  8 08:00:09 2019
From: report at bugs.python.org (MeiK)
Date: Mon, 08 Jul 2019 12:00:09 +0000
Subject: [New-bugs-announce] [issue37522] http.cookies.SimpleCookie doesn't
 seem to be parsed using regulars
Message-ID: <1562587209.99.0.655930628175.issue37522@roundup.psfhosted.org>


New submission from MeiK <meik2333 at gmail.com>:

In Python's built-in SimpleCookie[1], regular expressions are used to parse cookies, which seems to be a non-standard way.

I looked at the RFC documentation related to cookie resolution: rfc2109[2] and rfc6265[3], the former has been replaced by the latter. These documents stipulate that cookies should be split with a semicolon, just like http.cookiejar.parse_ns_headers[4].

But if we use the approach described in the documentation, then there will be a set of tests that fail[5].

Current:
>>> print(SimpleCookie('keebler="E=mc2; L=\\"Loves\\"; fudge=\\012;"?))
Set-Cookie: keebler="E=mc2; L=\"Loves\"; fudge=\012;"

Modified:
>>> print(SimpleCookie('keebler="E=mc2; L=\\"Loves\\"; fudge=\\012;"?))
Set-Cookie: keebler="E=mc2

Is this a bug? Should it be modified?

English is not my native language; please excuse typing errors.

[1]: https://github.com/python/cpython/blob/master/Lib/http/cookies.py#L536
[2]: https://www.ietf.org/rfc/rfc2109.txt
[3]: https://www.ietf.org/rfc/rfc6265.txt
[4]: https://github.com/python/cpython/blob/master/Lib/http/cookiejar.py#L453
[5]: https://github.com/python/cpython/blob/master/Lib/test/test_http_cookies.py#L19

----------
components: Extension Modules
messages: 347494
nosy: MeiK
priority: normal
severity: normal
status: open
title: http.cookies.SimpleCookie doesn't seem to be parsed using regulars
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37522>
_______________________________________

From report at bugs.python.org  Tue Jul  9 03:06:51 2019
From: report at bugs.python.org (Daniel Hillier)
Date: Tue, 09 Jul 2019 07:06:51 +0000
Subject: [New-bugs-announce] [issue37523] zipfile: Raise ValueError for i/o
 operations on closed zipfile.ZipExtFile
Message-ID: <1562656011.62.0.508019848995.issue37523@roundup.psfhosted.org>


New submission from Daniel Hillier <daniel.hillier at gmail.com>:

After closing a file object opened from a ZipFile, attempting i/o operations raises AttributeError because the underlying fd has been set to None. We should be raising ValueErrors consistent with io.FileIO behaviour.

Similar inconsistencies exist for the following operations on a closed ZipExtFile:
- seek
- seekable
- read
- readable
- tell

----------
components: Library (Lib)
messages: 347524
nosy: dhillier
priority: normal
severity: normal
status: open
title: zipfile: Raise ValueError for i/o operations on closed zipfile.ZipExtFile
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37523>
_______________________________________

From report at bugs.python.org  Tue Jul  9 05:20:18 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Jul 2019 09:20:18 +0000
Subject: [New-bugs-announce] [issue37524] IDLE error on closing 3.8+ debug
 build
Message-ID: <1562664018.55.0.0863283493597.issue37524@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In Win Command Prompt, in master repository or 3.8 worktree with 32 bit debug build:

F:\dev\3x>python
Running Debug|Win32 interpreter...
Python 3.9.0a0 (heads/master:110a47c4f4, Jul  9 2019, 01:31:55) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()
***Exits okay***

F:\dev\3x>python -m idlelib
Running Debug|Win32 interpreter...
Exception ignored in: <idlelib.run.PseudoInputFile object at 0x053F5710>
Traceback (most recent call last):
  File "F:\dev\3x\lib\idlelib\run.py", line 488, in close
  File "F:\dev\3x\lib\idlelib\pyshell.py", line 1017, in close
  File "F:\dev\3x\lib\idlelib\editor.py", line 1019, in close
  File "F:\dev\3x\lib\idlelib\outwin.py", line 94, in maybesave
  File "F:\dev\3x\lib\idlelib\editor.py", line 952, in get_saved
AttributeError: 'NoneType' object has no attribute 'get_saved'

Same in 3.8 worktree, not in 3.7 worktree, not with installed 64 bit, non-debug 3.8.0b2

----------
assignee: terry.reedy
components: IDLE
messages: 347530
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE error on closing 3.8+ debug build
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37524>
_______________________________________

From report at bugs.python.org  Tue Jul  9 05:36:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Jul 2019 09:36:10 +0000
Subject: [New-bugs-announce] [issue37525] test_ssl:
 test_pha_required_nocert() logs ResourceWarning
Message-ID: <1562664970.92.0.231614914384.issue37525@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

vstinner at apu$ ./python -u -m test test_ssl -v -m test_pha_required_nocert
== CPython 3.9.0a0 (heads/master:110a47c4f4, Jul 8 2019, 23:52:00) [GCC 9.1.1 20190503 (Red Hat 9.1.1-1)]
== Linux-5.1.15-300.fc30.x86_64-x86_64-with-glibc2.29 little-endian
== cwd: /home/vstinner/python/master/build/test_python_24211
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.70 [1/1] test_ssl
test_ssl: testing with 'OpenSSL 1.1.1c FIPS  28 May 2019' (1, 1, 1, 3, 15)
          under 'Linux-5.1.15-300.fc30.x86_64-x86_64-with-glibc2.29'
          HAS_SNI = True
          OP_ALL = 0x80000054
          OP_NO_TLSv1_1 = 0x10000000
test_pha_required_nocert (test.test_ssl.TestPostHandshakeAuth) ... Exception in thread Thread-2:
Traceback (most recent call last):
  File "/home/vstinner/python/master/Lib/test/test_ssl.py", line 2299, in run
    msg = self.read()
  File "/home/vstinner/python/master/Lib/test/test_ssl.py", line 2276, in read
    return self.sslconn.read()
  File "/home/vstinner/python/master/Lib/ssl.py", line 1101, in read
    return self._sslobj.read(len)
ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2560)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/vstinner/python/master/Lib/threading.py", line 938, in _bootstrap_inner
    self.run()
  File "/home/vstinner/python/master/Lib/test/test_ssl.py", line 2385, in run
    raise ssl.SSLError('tlsv13 alert certificate required')
ssl.SSLError: ('tlsv13 alert certificate required',)
/home/vstinner/python/master/Lib/threading.py:938: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 54611), raddr=('127.0.0.1', 56442)>
  self.run()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
ok

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

Ran 1 test in 0.028s

OK

== Tests result: SUCCESS ==

1 test OK.

Total duration: 178 ms
Tests result: SUCCESS


More verbose output from Refleak buildbot:
https://buildbot.python.org/all/#/builders/189/builds/87

0:00:19 load avg: 4.17 [ 40/419] test_ssl passed
beginning 6 repetitions
123456
Exception in thread Thread-242:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2299, in run
    msg = self.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2276, in read
    return self.sslconn.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/ssl.py", line 1101, in read
    return self._sslobj.read(len)
ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2560)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py", line 938, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2385, in run
    raise ssl.SSLError('tlsv13 alert certificate required')
ssl.SSLError: ('tlsv13 alert certificate required',)
/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py:938: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 59465), raddr=('127.0.0.1', 40888)>
  self.run()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
.Exception in thread Thread-492:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2299, in run
    msg = self.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2276, in read
    return self.sslconn.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/ssl.py", line 1101, in read
    return self._sslobj.read(len)
ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2560)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py", line 938, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2385, in run
    raise ssl.SSLError('tlsv13 alert certificate required')
ssl.SSLError: ('tlsv13 alert certificate required',)
/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py:938: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 60255), raddr=('127.0.0.1', 47488)>
  self.run()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
.Exception in thread Thread-742:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2299, in run
    msg = self.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2276, in read
    return self.sslconn.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/ssl.py", line 1101, in read
    return self._sslobj.read(len)
ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2560)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py", line 938, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2385, in run
    raise ssl.SSLError('tlsv13 alert certificate required')
ssl.SSLError: ('tlsv13 alert certificate required',)
/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py:938: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 42085), raddr=('127.0.0.1', 33886)>
  self.run()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
.Exception in thread Thread-992:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2299, in run
    msg = self.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2276, in read
    return self.sslconn.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/ssl.py", line 1101, in read
    return self._sslobj.read(len)
ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2560)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py", line 938, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2385, in run
    raise ssl.SSLError('tlsv13 alert certificate required')
ssl.SSLError: ('tlsv13 alert certificate required',)
/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py:938: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 51799), raddr=('127.0.0.1', 46198)>
  self.run()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
.Exception in thread Thread-1242:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2299, in run
    msg = self.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2276, in read
    return self.sslconn.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/ssl.py", line 1101, in read
    return self._sslobj.read(len)
ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2560)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py", line 938, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2385, in run
    raise ssl.SSLError('tlsv13 alert certificate required')
ssl.SSLError: ('tlsv13 alert certificate required',)
/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py:938: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 37723), raddr=('127.0.0.1', 52182)>
  self.run()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
.Exception in thread Thread-1492:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2299, in run
    msg = self.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2276, in read
    return self.sslconn.read()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/ssl.py", line 1101, in read
    return self._sslobj.read(len)
ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:2560)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py", line 938, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/test/test_ssl.py", line 2385, in run
    raise ssl.SSLError('tlsv13 alert certificate required')
ssl.SSLError: ('tlsv13 alert certificate required',)
/home/buildbot/buildarea/3.x.cstratak-fedora.refleak/build/Lib/threading.py:938: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 51575), raddr=('127.0.0.1', 37214)>
  self.run()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
.

----------
components: Tests
messages: 347532
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_ssl: test_pha_required_nocert() logs ResourceWarning
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37525>
_______________________________________

From report at bugs.python.org  Tue Jul  9 06:26:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Jul 2019 10:26:30 +0000
Subject: [New-bugs-announce] [issue37526] Add
 support.catch_threading_exception()
Message-ID: <1562667990.77.0.0421401641462.issue37526@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

bpo-1230540 added threading.excepthook() to handle "uncaught exceptions raised by Thread.run()".

I propose to add support.catch_threading_exception(): context manager to ease catching these exceptions.

Attached PR implements it.

----------
components: Tests
messages: 347540
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add support.catch_threading_exception()
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37526>
_______________________________________

From report at bugs.python.org  Tue Jul  9 06:32:25 2019
From: report at bugs.python.org (Dschoni)
Date: Tue, 09 Jul 2019 10:32:25 +0000
Subject: [New-bugs-announce] [issue37527] Timestamp conversion on windows
 fails with timestamps close to EPOCH
Message-ID: <1562668345.09.0.775729583969.issue37527@roundup.psfhosted.org>


New submission from Dschoni <python at dschoni.de>:

A long description of the issue can be found on SO here: https://stackoverflow.com/questions/56931738/python-crash-on-windows-with-a-datetime-close-to-the-epoch?noredirect=1#comment100413591_56931738

TL;DR:

This fails on windows:

from datetime import datetime
datetime.fromtimestamp(1).timestamp()

----------
components: Windows
messages: 347541
nosy: Dschoni, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Timestamp conversion on windows fails with timestamps close to EPOCH
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37527>
_______________________________________

From report at bugs.python.org  Tue Jul  9 07:34:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Jul 2019 11:34:17 +0000
Subject: [New-bugs-announce] [issue37528] test_tarfile:
 test_extractall_symlinks() fails on Windows with: [WinError 206] The
 filename or extension is too long
Message-ID: <1562672057.8.0.696699034391.issue37528@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

AMD64 Windows8.1 Non-Debug 3.x:
https://buildbot.python.org/all/#/builders/12/builds/2862

FAIL: test_extractall_symlinks (test.test_tarfile.Bz2WriteTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_tarfile.py", line 1312, in test_extractall_symlinks
    tar.extractall(path=tempdir)
FileNotFoundError: [WinError 206] The filename or extension is too long: 'D:\\buildarea\\3.x.ware-win81-release.nondebug\\build\\build\\test_python_3164\\test_python_worker_5512\\@test_5512_tmp-tardir\\testsymlinks\\buildarea\\3.x.ware-win81-release.nondebug\\build\\build\\test_python_3164\\test_python_worker_5512\\@test_5512_tmp-tardir'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\test\test_tarfile.py", line 1314, in test_extractall_symlinks
    self.fail("extractall failed with symlinked files")
AssertionError: extractall failed with symlinked files


Extract of pythoninfo:

windows.RtlAreLongPathsEnabled: <function not available>

RtlAreLongPathsEnabled() is not available on Windows 8.1. I don't know if long paths support is enabled or not on this buildbot (I guess that no, it isn't).

I'm not sure why the test started to fail.

----------
components: Tests
messages: 347549
nosy: vstinner, zach.ware
priority: normal
severity: normal
status: open
title: test_tarfile: test_extractall_symlinks() fails on Windows with: [WinError 206] The filename or extension is too long
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37528>
_______________________________________

From report at bugs.python.org  Tue Jul  9 09:59:21 2019
From: report at bugs.python.org (disconnect3d)
Date: Tue, 09 Jul 2019 13:59:21 +0000
Subject: [New-bugs-announce] [issue37529] Mimetype module duplicates
Message-ID: <1562680761.15.0.288138014947.issue37529@roundup.psfhosted.org>


New submission from disconnect3d <dominik.b.czarnota at gmail.com>:

The mimetype builtin module allows users to guess extension for a given mimetype through the `mimetypes.guess_extension` function.

Default mimetypes are stored in `types_map` and `_types_map_default` dictionaries that maps extensions to mimetypes. Those dictionaries are created by `_default_mime_types` function in `cpython/Lib/mimetypes.py`.

If a given extension have more than one mimetype, this information is lost.
This happens currently for ".bmp" extension in CPython's codebase.

This can be seen in the linked code below:
https://github.com/python/cpython/blob/110a47c4f42cf4db88edc1876899fff8f05190fb/Lib/mimetypes.py#L490-L502

Here is an example in an interactive IPython session:
```
In [1]: import mimetypes

In [2]: mimetypes.guess_extension('image/bmp')
Out[2]: '.bmp'

In [3]: mimetypes.guess_extension('image/x-ms-bmp')

In [4]:
```

The issue has been found by using Semmle's LGTM: https://lgtm.com/projects/g/python/cpython/snapshot/d099f261c762ac81042e47b530d279f932d89e09/files/Lib/mimetypes.py?sort=name&dir=ASC&mode=heatmap


PS / offtopic / loud thinking: Maybe there should be a debug build of CPython that would detect such key overwrites during dicts initialisation and warn about them?

----------
components: Library (Lib)
messages: 347562
nosy: Dominik Czarnota
priority: normal
severity: normal
status: open
title: Mimetype module duplicates
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37529>
_______________________________________

From report at bugs.python.org  Tue Jul  9 13:44:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Jul 2019 17:44:47 +0000
Subject: [New-bugs-announce] [issue37530] IDLE: simplify, optimize,
 and clean up code context
Message-ID: <1562694287.35.0.507911055212.issue37530@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Issue for Tal's PR 14675, dependency of #33610.

1. Only create CodeContext instances for "real" editors windows, but not e.g. shell or output windows.

- Previously, were created but never activated because menu item deactivated.  This is even better.

2. Remove configuration update Tk event fired every second, by having the editor window ask its code context widget to update when necessary, i.e. upon font or highlighting updates.

3. When code context isn't being shown, avoid having a Tk event fired every 100ms to check whether the code context needs to be updated.

4. Use the editor window's getlineno() method where applicable.

5. Fix a bare except:.

----------
assignee: terry.reedy
components: IDLE
messages: 347568
nosy: cheryl.sabella, taleinat, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE: simplify, optimize, and clean up code context
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37530>
_______________________________________

From report at bugs.python.org  Tue Jul  9 15:34:22 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 09 Jul 2019 19:34:22 +0000
Subject: [New-bugs-announce] [issue37531] Fix regrtest timeout for
 subprocesses: regrtest -jN --timeout=SECONDS
Message-ID: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

Reported by Victor Stinner.

regrtest has a --timeout parameter which calls
faulthandler.dump_traceback_later(timeout), but sometimes it's not
enough to kill a test. regrtest should kill a worker process if it
runs longer than --timeout seconds.

* https://bugs.python.org/issue37313 : test_concurrent_futures ran for
25 hours whereas regrtest was run using --timeout 900
* regrtest ran for 4 days whereas it was run with --timeout=900:
https://mail.python.org/pipermail/python-buildbots/2019-June/000285.html

----------
messages: 347576
nosy: nanjekyejoannah, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37531>
_______________________________________

From report at bugs.python.org  Tue Jul  9 17:20:46 2019
From: report at bugs.python.org (Yun Li)
Date: Tue, 09 Jul 2019 21:20:46 +0000
Subject: [New-bugs-announce] [issue37532] email.header.make_header() doesn't
 work if any `ascii` code is out of range(128)
Message-ID: <1562707246.84.0.835768356919.issue37532@roundup.psfhosted.org>


New submission from Yun Li <yunlee10 at gmail.com>:

email.header.make_header() doesn't work if any `ascii` code is out of range(128)

For example 

>>> header = "Your booking at Voyager Int'l Hostel,=?UTF-8?B?IFBhbmFtw6EgQ2l0eQ==?=,   Panam?- Casco Antiguo"

>>> decode_header(header)
[(b"Your booking at Voyager Int'l Hostel,", None), (b' Panam\xc3\xa1 City', 'utf-8'), (b',   Panam\xe1- Casco Antiguo', None)]

>>> make_header(decode_header(header))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/email/header.py", line 174, in make_header
    h.append(s, charset)
  File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/email/header.py", line 295, in append
    s = s.decode(input_charset, errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 9: ordinal not in range(128)

----------
components: email
messages: 347577
nosy: barry, r.david.murray, yunlee
priority: normal
severity: normal
status: open
title: email.header.make_header() doesn't work if any `ascii` code is out of range(128)
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37532>
_______________________________________

From report at bugs.python.org  Tue Jul  9 17:30:38 2019
From: report at bugs.python.org (mike lojkovic)
Date: Tue, 09 Jul 2019 21:30:38 +0000
Subject: [New-bugs-announce] [issue37533] Possible Unicode handling issue in
 python.
Message-ID: <1562707838.13.0.896835317177.issue37533@roundup.psfhosted.org>


New submission from mike lojkovic <mikelojkovic at gmail.com>:

Encode error on character '\u2193' was suggested by a tribler developer might indicate a problem with python's handling of unicdoe in specific cases.

https://github.com/Tribler/tribler/issues/4666

----------
components: Unicode
messages: 347578
nosy: ezio.melotti, mike lojkovic, vstinner
priority: normal
severity: normal
status: open
title: Possible Unicode  handling issue in python.
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37533>
_______________________________________

From report at bugs.python.org  Tue Jul  9 19:26:51 2019
From: report at bugs.python.org (Henry Harutyunyan)
Date: Tue, 09 Jul 2019 23:26:51 +0000
Subject: [New-bugs-announce] [issue37534] In minidom module ability to add
 Standalone Document Declaraion is missing while generating XML documents
Message-ID: <1562714811.12.0.95150258791.issue37534@roundup.psfhosted.org>


New submission from Henry Harutyunyan <henryharutyunyan at gmail.com>:

Though the Standalone Document Declaration in XML Declaration is optional and the default value of "no" is assumed in case it's omitted, in certain cases it makes sense to change the value to indicate the absence of external markup declarations. It's a part of W3C recommendation on XML (https://www.w3.org/TR/xml/#sec-prolog-dtd).
Though minidom module allows to modify the encoding declaration if needed, the same is not true for standalone declaration.
As I've recently came up with an issue while generating XML documents with the module I suggest adding the ability to add and modify the declaration.

----------
components: XML
messages: 347583
nosy: hharutyunyan
priority: normal
severity: normal
status: open
title: In minidom module ability to add Standalone Document Declaraion is missing while generating XML documents
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37534>
_______________________________________

From report at bugs.python.org  Tue Jul  9 23:57:44 2019
From: report at bugs.python.org (Dean)
Date: Wed, 10 Jul 2019 03:57:44 +0000
Subject: [New-bugs-announce] [issue37535] Client SSLSocket with
 select.select() always returns readable with OpenSSL 1.1.1
Message-ID: <1562731064.9.0.934832826159.issue37535@roundup.psfhosted.org>


New submission from Dean <scaram at gmail.com>:

Hi, I've come across an issue with OpenSSL 1.1.1, when a client socket wrapped using ssl.wrap_socket() is used in select.select() its always returning ready for reading even though there appears to be nothing to read.

To reproduce:
0. Extract files from attached zip
1. Run server.py
2. Run client.py

I expect client.py to print "Nothing to read" and then b'\x00\x01\x02\x03', which it does with Python 2.7.14, 3.6.8 and 3.7.3 and OpenSSL 1.0.1f and 1.1.0g. 

With OpenSSL 1.1.1 it prints 'Pending: 0' and blocks on the sock.recv(1) call.

Thanks!

----------
assignee: christian.heimes
components: SSL
files: ssl_select.zip
messages: 347595
nosy: christian.heimes, ddddaaaa
priority: normal
severity: normal
status: open
title: Client SSLSocket with select.select() always returns readable with OpenSSL 1.1.1
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48464/ssl_select.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37535>
_______________________________________

From report at bugs.python.org  Wed Jul 10 01:07:40 2019
From: report at bugs.python.org (Ryan McCampbell)
Date: Wed, 10 Jul 2019 05:07:40 +0000
Subject: [New-bugs-announce] [issue37536] ctypes.create_string_buffer fails
 on windows with non-BMP characters
Message-ID: <1562735260.22.0.463850120288.issue37536@roundup.psfhosted.org>


New submission from Ryan McCampbell <rmccampbell7 at gmail.com>:

The ctypes.create_string_buffer function uses the length of the string to create the buffer if no size is provided. Since windows wide chars are UTF-16 the buffer may actually need to be larger to store surrogate pairs. This code crashes on windows:

>>> create_unicode_buffer('\U00010000\U00010000')
ValueError: string too long

----------
messages: 347600
nosy: rmccampbell7
priority: normal
severity: normal
status: open
title: ctypes.create_string_buffer fails on windows with non-BMP characters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37536>
_______________________________________

From report at bugs.python.org  Wed Jul 10 02:27:59 2019
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 10 Jul 2019 06:27:59 +0000
Subject: [New-bugs-announce] [issue37537] Compute allocated blocks in
 _Py_GetAllocatedBlocks()
Message-ID: <1562740079.69.0.103809665288.issue37537@roundup.psfhosted.org>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

This is a small but measurable optimization for _PyObject_Malloc and _PyObject_Free.  It slows down _Py_GetAllocatedBlocks a bit but I think that's a price worth paying.

----------
components: Interpreter Core
messages: 347602
nosy: nascheme
priority: normal
severity: normal
status: open
title: Compute allocated blocks in _Py_GetAllocatedBlocks()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37537>
_______________________________________

From report at bugs.python.org  Wed Jul 10 02:58:30 2019
From: report at bugs.python.org (Daniel Hillier)
Date: Wed, 10 Jul 2019 06:58:30 +0000
Subject: [New-bugs-announce] [issue37538] Refactor zipfile to ease
 subclassing and enhancement
Message-ID: <1562741910.34.0.615692848434.issue37538@roundup.psfhosted.org>


New submission from Daniel Hillier <daniel.hillier at gmail.com>:

I've written https://github.com/danifus/pyzipper which incorporates a
refactor of zipfile.py in order to support winzip AES encryption. I don't
intend to include the crypto code but I would like to incorporate the
refactor to help others subclass and extend the objects found in zipfile.py


For a longer description of the general approach I've taken to the refactor,
see the python-ideas thread:
https://mail.python.org/archives/list/python-ideas at python.org/thread/QCKHI5JYMKOPMIF6Q2NI7JIFHV6KO746/#QCKHI5JYMKOPMIF6Q2NI7JIFHV6KO746

----------
components: Library (Lib)
messages: 347604
nosy: dhillier
priority: normal
severity: normal
status: open
title: Refactor zipfile to ease subclassing and enhancement
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37538>
_______________________________________

From report at bugs.python.org  Wed Jul 10 03:45:49 2019
From: report at bugs.python.org (Matej Cepl)
Date: Wed, 10 Jul 2019 07:45:49 +0000
Subject: [New-bugs-announce] [issue37539] CheckCommitCursorReset regression
 sqlite3 test fails with old sqlite3
Message-ID: <1562744749.11.0.451053951717.issue37539@roundup.psfhosted.org>


New submission from Matej Cepl <mcepl at cepl.eu>:

When building Python 2.7.16 on very old SUSE Enterprise Linux (SLE-11), with gcc 4.3, sqlite3 3.6.4, CheckCommitCursorReset fails with:

test test_sqlite failed -- Traceback (most recent call last):
  File "/usr/src/packages/BUILD/Python-2.7.16/Lib/sqlite3/test/regression.py", line 338, in CheckCommitCursorReset
    con.commit()
OperationalError: cannot commit transaction - SQL statements in progress

It seems to me the problem is that the select from https://github.com/python/cpython/blob/master/Lib/sqlite3/test/regression.py#L353 is still open, while we run con.commit(). It should be probably better to store output of that enumerate somewhere and work on that variable instead.

----------
components: Library (Lib)
files: log.txt
messages: 347606
nosy: mcepl
priority: normal
severity: normal
status: open
title: CheckCommitCursorReset regression sqlite3 test fails with old sqlite3
versions: Python 2.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48465/log.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37539>
_______________________________________

From report at bugs.python.org  Wed Jul 10 04:06:51 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 10 Jul 2019 08:06:51 +0000
Subject: [New-bugs-announce] [issue37540] vectorcall: keyword names must be
 strings
Message-ID: <1562746011.67.0.0539270871483.issue37540@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

Keyword names in calls are expected to be strings, however it's currently not clear who should enforce/check this.

I suggest to fix this for vectorcall/METH_FASTCALL and specify that it's the caller's job to make sure that keyword names are strings (str subclasses are allowed).

----------
components: Interpreter Core
messages: 347608
nosy: Mark.Shannon, jdemeyer, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: vectorcall: keyword names must be strings
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37540>
_______________________________________

From report at bugs.python.org  Wed Jul 10 05:02:54 2019
From: report at bugs.python.org (Saba Kauser)
Date: Wed, 10 Jul 2019 09:02:54 +0000
Subject: [New-bugs-announce] [issue37541] get_python_lib() returns incorrect
 path for site-packages
Message-ID: <1562749374.67.0.365304267455.issue37541@roundup.psfhosted.org>


New submission from Saba Kauser <skauseribmdb at gmail.com>:

HI,
I am using get_python_lib() to copy certain data files to site-pacakges location while installation of package ibm_db. I am using this function to execute a command as well on one of the shared library @package install location.
So far, I have faced issue with this function in:
virtual env, anaconda python and with pip cache enabled. 

The source can be found at: https://github.com/ibmdb/python-ibmdb/blob/master/IBM_DB/ibm_db/setup.py#L242

When I run through debugger for python setup.py build command, I can see following:
(Pdb) p data_files
[('C:\\Users\\skauser\\Anaconda\\Lib\\site-packages', ['./README.md']), ('C:\\Users\\skauser\\Anaconda\\Lib\\site-packages', ['./CHANGES']), ('C:\\Users\\skauser\\Anaconda\\Lib\\site-packages', ['./LICENSE']), ('C:\\Users\\skauser\\Anaconda\\Lib\\site-packages', ['./config.py.sample'])]

However, in "python setup.py install", this folder structure is created:
C:\Users\skauser\Anaconda\Lib\site-packages\users\skauser\appdata\local\programs\python\python37\Lib and no data files are copied.

If I do : "pip install ." from source directory,
The data_files are copied under "c:\users\skauser\anaconda\lib\site-packages\users\skauser\anaconda\lib\site-packages" when the expectation is to have the files copied under "c:\users\skauser\anaconda\lib\site-packages".

Can you please look into this. 
Although this is not a serious problem for platforms other than mac, But on MAC, I am using this same function get_python_lib()to execute a system command and without this working properly, MAC users are unable to use the python ibm_db driver.

This is blocking! Please help.

----------
components: Distutils
messages: 347612
nosy: dstufft, eric.araujo, sabakauser
priority: normal
severity: normal
status: open
title: get_python_lib() returns incorrect path for site-packages
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37541>
_______________________________________

From report at bugs.python.org  Wed Jul 10 06:51:03 2019
From: report at bugs.python.org (Andy Papageorgiou)
Date: Wed, 10 Jul 2019 10:51:03 +0000
Subject: [New-bugs-announce] [issue37542] UDP sendto() sends duplicate
 packets
Message-ID: <1562755863.69.0.759157701288.issue37542@roundup.psfhosted.org>


New submission from Andy Papageorgiou <andy.papageorgiou at gmail.com>:

Wireshark reports two identical back to back packets sent for each sendto(), timing between packets is between 2 and 10us.

Note this is on a point to point ethernet (just 1 cable, no switches, routers or anything else in between) to an embedded platform (Zynq ARM) from an intel i7 Window 10 laptop from 2018. The python code is running on the laptop.

python code:
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as s:
    s.bind(('', 5704))
    while(more_to_send == TRUE)
        <code to populate bytes_to_send>
        s.sendto(bytes_to_send, (HOST, UDP_PORT))
        data = s.recv(1024)

Wireshark log.
43204	80.146000	192.168.1.20	192.168.1.10	UDP	566	5704 ? 5604 Len=524 (payload)
43205	80.146003	192.168.1.20	192.168.1.10	UDP	566	5704 ? 5604 Len=524 (duplicate at payload time + 3us)
43206	80.149112	192.168.1.10	192.168.1.20	UDP	48	5604 ? 5704 Len=6 (ack)
43207	80.149306	192.168.1.20	192.168.1.10	UDP	566	5704 ? 5604 Len=524 (payload)
43208	80.149311	192.168.1.20	192.168.1.10	UDP	566	5704 ? 5604 Len=524 (duplicate at payload time +5us)

I am suspicious this is an artefact of the point to point link.

----------
components: Library (Lib)
messages: 347614
nosy: Andy Papageorgiou
priority: normal
severity: normal
status: open
title: UDP sendto() sends duplicate packets
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37542>
_______________________________________

From report at bugs.python.org  Wed Jul 10 06:59:54 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 10 Jul 2019 10:59:54 +0000
Subject: [New-bugs-announce] [issue37543] Optimize pymalloc for non PGO build
Message-ID: <1562756394.12.0.431999649056.issue37543@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

When PGO is not used, compilers don't know which part is hot.

So gcc failed to inline hot code in pymalloc_alloc and pymalloc_free
into _PyObject_Malloc and _PyObject_Free.  For example, only this code is inlined into _PyObject_Malloc.

    if (nbytes == 0) {
        return 0;
    }
    if (nbytes > SMALL_REQUEST_THRESHOLD) {
        return 0;
    }

But the hottest part is taking memory block from freelist in the pool.
To optimize it,

* make pymalloc_alloc and pymalloc_free inline functions
* Split code for rare / slow paths out to new functions

In PR 14674, pymalloc is now as fast as mimalloc in spectral_norm benchmark.

  $ ./python bm_spectral_norm.py --compare-to=./python-master
  python-master: ..................... 199 ms +- 1 ms
  python: ..................... 176 ms +- 1 ms

  Mean +- std dev: [python-master] 199 ms +- 1 ms -> [python] 176 ms +- 1 ms: 1.13x faster (-11%)

----------
components: Interpreter Core
messages: 347615
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Optimize pymalloc for non PGO build
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37543>
_______________________________________

From report at bugs.python.org  Wed Jul 10 07:17:58 2019
From: report at bugs.python.org (Jarek Zgoda)
Date: Wed, 10 Jul 2019 11:17:58 +0000
Subject: [New-bugs-announce] [issue37544] Multiple test failures during build
Message-ID: <1562757478.69.0.905991720528.issue37544@roundup.psfhosted.org>


New submission from Jarek Zgoda <jarek.zgoda at gmail.com>:

I'm trying to build Python-3.7.4 from release tarball.

Configure line: ./configure --prefix=/opt/python-3.7.4 --disable-shared  --enable-optimizations

System: Ubuntu 18.04.2 amd64, 4.15.0-54-generic #58-Ubuntu SMP

Build fails.

----------
components: Build
files: pgo_task_log.txt
messages: 347616
nosy: Jarek Zgoda
priority: normal
severity: normal
status: open
title: Multiple test failures during build
versions: Python 3.7
Added file: https://bugs.python.org/file48466/pgo_task_log.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37544>
_______________________________________

From report at bugs.python.org  Wed Jul 10 07:54:30 2019
From: report at bugs.python.org (Nathan Oyama)
Date: Wed, 10 Jul 2019 11:54:30 +0000
Subject: [New-bugs-announce] [issue37545] Argparse Tutorial - unreasonable
 operators
Message-ID: <1562759670.76.0.736461636286.issue37545@roundup.psfhosted.org>


New submission from Nathan Oyama <nathan.oyama at berkeley.edu>:

In "Python 3.7 Documentation > Python HOWTOs > Argparse Tutorial" (https://docs.python.org/3.7/howto/argparse.html), search this page for

elif args.verbosity >= 1:

The operator ">=" should read "==" because args.verbosity cannot be 2 or greater after the if statement.

You would find the original codes unreasonable until you go through "if args.verbosity >= 1:".

----------
assignee: docs at python
components: Documentation
messages: 347617
nosy: Culip, docs at python
priority: normal
severity: normal
status: open
title: Argparse Tutorial - unreasonable operators
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37545>
_______________________________________

From report at bugs.python.org  Wed Jul 10 08:05:11 2019
From: report at bugs.python.org (dave)
Date: Wed, 10 Jul 2019 12:05:11 +0000
Subject: [New-bugs-announce] [issue37546] colors in ttk treeview tags are
 ignored
Message-ID: <1562760311.49.0.967129869118.issue37546@roundup.psfhosted.org>


New submission from dave <dave9000 at cheapnet.it>:

The following example code fails in Python 3.7.3 64 bit (both lines are displayed in black).
It works correctly in 3.7.2 and earlier.

import tkinter as tk
import tkinter.ttk as ttk

root = tk.Tk()

ttk.Label(root, text='This is a RED label', foreground='red').pack()

tree = ttk.Treeview(root)
tree.tag_configure('RED_TAG', foreground='red', font=('arial', 12))
tree.insert('', tk.END, text='Black line')
tree.insert('', tk.END, text='Red line', tag='RED_TAG')
tree.pack()

root.mainloop()

----------
components: Tkinter
messages: 347618
nosy: dave9000
priority: normal
severity: normal
status: open
title: colors in ttk treeview tags are ignored
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37546>
_______________________________________

From report at bugs.python.org  Wed Jul 10 08:06:19 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 10 Jul 2019 12:06:19 +0000
Subject: [New-bugs-announce] [issue37547] Add _PyObject_CallMethodOneArg()
Message-ID: <1562760379.8.0.22654038416.issue37547@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

We already have

_PyObject_CallNoArg()
_PyObject_CallOneArg()
_PyObject_CallMethodNoArgs()

so it makes sense to also add

_PyObject_CallMethodOneArg()

----------
components: Interpreter Core
messages: 347619
nosy: inada.naoki, jdemeyer, vstinner
priority: normal
severity: normal
status: open
title: Add _PyObject_CallMethodOneArg()
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37547>
_______________________________________

From report at bugs.python.org  Wed Jul 10 08:32:52 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Jul 2019 12:32:52 +0000
Subject: [New-bugs-announce] [issue37548] Document range of atan,
 acos and asin
Message-ID: <1562761972.12.0.588698954565.issue37548@roundup.psfhosted.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

A small nice-to-have: it would be good to document the range of the inverse trigonometric functions `math.atan`, `math.asin` and `math.acos`, in both the docstrings and the built documentation.

There are standard "principal values" for each of these inverses, and Python is using these standard values, but that may not be obvious to a user.

----------
assignee: docs at python
components: Documentation
messages: 347620
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Document range of atan, acos and asin
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37548>
_______________________________________

From report at bugs.python.org  Wed Jul 10 13:52:05 2019
From: report at bugs.python.org (DaveB)
Date: Wed, 10 Jul 2019 17:52:05 +0000
Subject: [New-bugs-announce] [issue37549] os.dup() fails for standard
 streams on Windows 7
Message-ID: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org>


New submission from DaveB <junkmail4dave at gmail.com>:

os.dup(fd) generates an OSError for standard streams (0: stdin, 1: stdout, 2: stderr) on Windows 7.  Works as expected on Windows 10.

Working backwards we found the issue first appears in Python 3.7.4rc1 and 3.8.0b2 on Windows 7.  Earlier releases work as expected.

>>> import os
>>> os.dup(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [WinError 87] The parameter is incorrect
>>>

----------
components: Extension Modules
messages: 347627
nosy: daveb
priority: normal
severity: normal
status: open
title: os.dup() fails for standard streams on Windows 7
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37549>
_______________________________________

From report at bugs.python.org  Wed Jul 10 14:24:04 2019
From: report at bugs.python.org (Bane Banane)
Date: Wed, 10 Jul 2019 18:24:04 +0000
Subject: [New-bugs-announce] [issue37550] SSL Pip Error
Message-ID: <1562783044.13.0.555415202194.issue37550@roundup.psfhosted.org>


New submission from Bane Banane <mamnju21 at gmail.com>:

Python PIP SSL module is not avaible when i start:
pip install <mypackagename>

----------
assignee: christian.heimes
components: SSL
messages: 347630
nosy: Bane Banane, christian.heimes
priority: normal
severity: normal
status: open
title: SSL Pip Error
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37550>
_______________________________________

From report at bugs.python.org  Wed Jul 10 15:12:06 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 10 Jul 2019 19:12:06 +0000
Subject: [New-bugs-announce] [issue37551] IDLE: Quitting with a new,
 unsaved editor window causes an exception
Message-ID: <1562785926.2.0.442729400594.issue37551@roundup.psfhosted.org>


New submission from Tal Einat <taleinat at gmail.com>:

Observed on macOS 10.14.5 with Python 3.8 from python.org, and with latest master branch.

Reproduction:
1. Open IDLE
2. "New File" (Cmd-Shift-n on macOS)
3. Quit using Cmd-q ("Quit Python" from the menu doesn't cause this!)

The exception traceback:
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/tkinter/__init__.py", line 1883, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/multicall.py", line 176, in handler
    r = l[i](event)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/filelist.py", line 54, in close_all_callback
    reply = edit.close()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/editor.py", line 1021, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/pyshell.py", line 312, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/editor.py", line 1025, in _close
    if self.io.filename:
AttributeError: 'NoneType' object has no attribute 'filename'

----------
assignee: terry.reedy
components: IDLE
messages: 347636
nosy: taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Quitting with a new, unsaved editor window causes an exception
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37551>
_______________________________________

From report at bugs.python.org  Wed Jul 10 16:23:27 2019
From: report at bugs.python.org (Paul Monson)
Date: Wed, 10 Jul 2019 20:23:27 +0000
Subject: [New-bugs-announce] [issue37552] [Windows] strptime/strftime return
 invalid results with UCRT version 17763.615
Message-ID: <1562790207.54.0.930380586709.issue37552@roundup.psfhosted.org>


New submission from Paul Monson <paulmons at gmail.com>:

strptime/strftime return invalid results when using UCRT version 17763.615

----------
components: Tests, Windows
messages: 347638
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] strptime/strftime return invalid results with UCRT version 17763.615
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37552>
_______________________________________

From report at bugs.python.org  Wed Jul 10 19:54:25 2019
From: report at bugs.python.org (Paul Monson)
Date: Wed, 10 Jul 2019 23:54:25 +0000
Subject: [New-bugs-announce] [issue37553] SendfileUsingSendTest tests
 timeout too short for Windows ARM32
Message-ID: <1562802865.66.0.679596534727.issue37553@roundup.psfhosted.org>


New submission from Paul Monson <paulmons at gmail.com>:

2 seconds doesn't seem to be a long enough timeout for os.sendfile tests on Windows ARM32

----------
components: Tests, Windows
messages: 347643
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: SendfileUsingSendTest tests timeout too short for Windows ARM32
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37553>
_______________________________________

From report at bugs.python.org  Wed Jul 10 22:09:44 2019
From: report at bugs.python.org (Roy Wellington)
Date: Thu, 11 Jul 2019 02:09:44 +0000
Subject: [New-bugs-announce] [issue37554] Typo in os.rename docs
Message-ID: <1562810984.17.0.614327905754.issue37554@roundup.psfhosted.org>


New submission from Roy Wellington <cactus_hugged at yahoo.com>:

The documentation for os.rename (e.g., here, https://docs.python.org/3/library/os.html#os.rename but also for 3.8 and 3.9) currently reads,

> On Unix, if src is a file and dst is a directory or vice-versa, anq:q IsADirectoryError or a NotADirectoryError will be raised respectively.

That "anq:q" should probably be just "an"; it appears someone tried to quit vim ;-)

----------
assignee: docs at python
components: Documentation
messages: 347647
nosy: docs at python, roy.wellington
priority: normal
severity: normal
status: open
title: Typo in os.rename docs
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37554>
_______________________________________

From report at bugs.python.org  Thu Jul 11 01:12:04 2019
From: report at bugs.python.org (Elizabeth Uselton)
Date: Thu, 11 Jul 2019 05:12:04 +0000
Subject: [New-bugs-announce] [issue37555] _CallList.__contains__ doesn't
 always respect ANY.
Message-ID: <1562821924.84.0.134272462767.issue37555@roundup.psfhosted.org>


New submission from Elizabeth Uselton <elizabeth.uselton at gmail.com>:

I have a test that goes something like:

```
@patch('a.place.to.patch')
def test_a_thing_calls_what_it_should(self, my_mock):
    # Set up logic here
    my_mock.assert_has_calls([
        call(
            ANY,
            Decimal('20')
        ),
        call(
            ANY,
            Decimal('10')
        )
    ])```

Which fails, where my_mock.call_args_list looks like 

```
[(<A Django Model>, Decimal('20')), (<A Django Model>, Decimal('10'))]
```

This seems like wrong behavior. ANY should be happy to be compared to anything, even a Django object. Doing some digging, I found that on line 340 of cpython/Lib/unittest/mock.py _CallList is overriding __contains__ and comparing each item in the tuples with what I'd passed in to assert_has_calls on the right, which means that instead of using ANY.__eq__, it's calling the Django model's __eq__ with ANY as an argument. Django first checks if the thing it's comparing to is another Django model, and returns False if not. So, <DjangoModel> == ANY is False, but ANY == <DjangoModel> is True. I know that this could also be considered a bug with Django, and I plan to file one with them too, but I don't see any downside to improving the mock library to be more defensive in honoring ANY over any other custom class's overridden __eq__ method.

----------
components: Tests
messages: 347652
nosy: Elizabeth Uselton
priority: normal
severity: normal
status: open
title: _CallList.__contains__ doesn't always respect ANY.
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37555>
_______________________________________

From report at bugs.python.org  Thu Jul 11 01:18:00 2019
From: report at bugs.python.org (Steve Barnes)
Date: Thu, 11 Jul 2019 05:18:00 +0000
Subject: [New-bugs-announce] [issue37556] Launcher help does not mention
 configuration options
Message-ID: <1562822280.29.0.253272841298.issue37556@roundup.psfhosted.org>


New submission from Steve Barnes <GadgetSteve at hotmail.com>:

py[w] --help on Windows launchers do not currently mention the options to configure versions used - just state latest.

This leads some people to struggle with things like testing beta versions, etc. as they end up defaulting to the beta which is undesirable.

----------
components: Demos and Tools
messages: 347653
nosy: Steve Barnes
priority: normal
severity: normal
status: open
title: Launcher help does not mention configuration options
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37556>
_______________________________________

From report at bugs.python.org  Thu Jul 11 02:49:39 2019
From: report at bugs.python.org (Kishore)
Date: Thu, 11 Jul 2019 06:49:39 +0000
Subject: [New-bugs-announce] [issue37557] Example snippets for simpler
 functions/methods
Message-ID: <1562827779.24.0.52309043258.issue37557@roundup.psfhosted.org>


New submission from Kishore <kishore.vancheeshwaran at gmail.com>:

Is there a reason why many (not all) of the simpler methods lack example snippets?

Snippets which are present:

1. https://docs.python.org/3/library/stdtypes.html#str.rstrip
2. https://docs.python.org/3/library/stdtypes.html#str.strip

Snippets which are not present:

1. https://docs.python.org/3/library/stdtypes.html#str.lower
2. https://docs.python.org/3/library/stdtypes.html#str.upper
3. https://docs.python.org/3/library/stdtypes.html#str.isupper

Is there any recommendation against adding concise example snippets for all methods?

I am of the opinion that short examples are more easier to read and visually skim through, than reading the description. I was hoping I could add example snippets to the simpler methods if anyone does not have any objection towards it.

----------
assignee: docs at python
components: Documentation
messages: 347656
nosy: docs at python, kishvanchee
priority: normal
severity: normal
status: open
title: Example snippets for simpler functions/methods
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37557>
_______________________________________

From report at bugs.python.org  Thu Jul 11 04:33:10 2019
From: report at bugs.python.org (Jakub Kulik)
Date: Thu, 11 Jul 2019 08:33:10 +0000
Subject: [New-bugs-announce] [issue37558] Shared memory tests are failing
 due to double slashes
Message-ID: <1562833990.12.0.316941845993.issue37558@roundup.psfhosted.org>


New submission from Jakub Kulik <kulikjak at gmail.com>:

Hi,

with the addition of shared memory into Python 3.8, we now have three tests failing on Solaris, namely `test_multiprocessing_fork`, `test_multiprocessing_forkserver` and `test_multiprocessing_spawn`. All of them fail in the same way:

======================================================================
ERROR: test_shared_memory_cleaned_after_process_termination (test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../Python-3.8.0b2/Lib/test/_test_multiprocessing.py", line 4013, in test_shared_memory_cleaned_after_process_termination
    smm = shared_memory.SharedMemory(name, create=False)
  File ".../Python-3.8.0b2/Lib/multiprocessing/shared_memory.py", line 100, in __init__
    self._fd = _posixshmem.shm_open(
OSError: [Errno 22] Invalid argument: '//psm_5c1b5800'

The reason for this, in my opinion, is that the test suite is accessing private `sm._name` instead of the normalized `sm.name`. Returned value already has one slash prepended, and another one is prepended SharedMemory init is called, resulting in double slashes, which is incorrect.

Change to `sm.name` fixes this problem.

----------
components: Tests
messages: 347662
nosy: kulikjak
priority: normal
severity: normal
status: open
title: Shared memory tests are failing due to double slashes
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37558>
_______________________________________

From report at bugs.python.org  Thu Jul 11 06:00:19 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 11 Jul 2019 10:00:19 +0000
Subject: [New-bugs-announce] [issue37559] IDLE: Scrolling issues with code
 context shown
Message-ID: <1562839219.15.0.3914256467.issue37559@roundup.psfhosted.org>


New submission from Tal Einat <taleinat at gmail.com>:

With code context shown, scrolling a window by dragging the scrollbar causes the scrollbar's tab to "jump around" and sometimes some "flashing" visual artifacts.

The "flashing" appears to occur only before the screen is resized for the first time, in which case the entire window is resized whenever the number of context lines changes during scrolling.

See attached animated screen capture.

Reproduced on latest versions of Win10 and macOS.

See also PR GH-14030, adding line numbers, which makes this more likely to occur for users.

----------
assignee: terry.reedy
components: IDLE
files: code-context-scolling-compressed.gif
messages: 347666
nosy: cheryl.sabella, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Scrolling issues with code context shown
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48469/code-context-scolling-compressed.gif

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37559>
_______________________________________

From report at bugs.python.org  Thu Jul 11 06:02:14 2019
From: report at bugs.python.org (=?utf-8?q?Stefanik_G=C3=A1bor?=)
Date: Thu, 11 Jul 2019 10:02:14 +0000
Subject: [New-bugs-announce] [issue37560] with cgi.FieldStorage(...) fails
 on cleanup with AttributeError, missing try/except in __exit__
Message-ID: <1562839334.01.0.637880829238.issue37560@roundup.psfhosted.org>


New submission from Stefanik G?bor <netrolller.3d at gmail.com>:

cgi.FieldStorage has this for its __del__ method:

    def __del__(self):
        try:
            self.file.close()
        except AttributeError:
            pass

By contrast, __exit__ is missing the exception handler:

    def __exit__(self, *args):
        self.file.close()

Because self.file isn't populated in every instance of the FieldStorage class, this can cause FieldStorage to fail with AttributeError when used in a with statement.

----------
components: Library (Lib)
messages: 347667
nosy: Stefanik G?bor
priority: normal
severity: normal
status: open
title: with cgi.FieldStorage(...) fails on cleanup with AttributeError, missing try/except in __exit__
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37560>
_______________________________________

From report at bugs.python.org  Thu Jul 11 06:30:50 2019
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 11 Jul 2019 10:30:50 +0000
Subject: [New-bugs-announce] [issue37561] the _sysconfigdata name should not
 encode MACHDEP and PLATFORM_TRIPLET
Message-ID: <1562841050.62.0.437512426388.issue37561@roundup.psfhosted.org>


New submission from Matthias Klose <doko at debian.org>:

so issue28046 decided to encode both MACHDEP and PLATFORM_TRIPLET/MULTIARCH in the _sysconfigdata name.  Unfortunately on KFreeBSD MACHDEP includes the kernel version, so you end up with a changing MACHDEP.  The _sysconfigdata name should only encode the MULTIARCH triplet, and if that's not define, the MACHDEP.  Working on a fix.

----------
messages: 347670
nosy: doko
priority: normal
severity: normal
status: open
title: the _sysconfigdata name should not encode MACHDEP and PLATFORM_TRIPLET
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37561>
_______________________________________

From report at bugs.python.org  Thu Jul 11 07:26:56 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 11 Jul 2019 11:26:56 +0000
Subject: [New-bugs-announce] [issue37562] PEP 590 implementation introduced
 a performance regression
Message-ID: <1562844416.61.0.409622240812.issue37562@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Many functions are significantly slower after commit aacc77fbd77640a8f03638216fa09372cc21673d was applied:

aacc77fbd77640a8f03638216fa09372cc21673d is the first bad commit
commit aacc77fbd77640a8f03638216fa09372cc21673d
Author: Jeroen Demeyer <J.Demeyer at UGent.be>
Date:   Wed May 29 20:31:52 2019 +0200

    bpo-36974: implement PEP 590 (GH-13185)


    Co-authored-by: Jeroen Demeyer <J.Demeyer at UGent.be>
    Co-authored-by: Mark Shannon <mark at hotpy.org>


Experiment in 3.8 
-----------------

./python -m perf timeit -s '_len=len' '_len("hello")'
.....................
Mean +- std dev: 157 ns +- 3 ns


Experiment in parent of aacc77fbd77640a8f03638216fa09372cc21673d
----------------------------------------------------------------

python -m perf timeit -s '_len=len' '_len("hello")'
.....................
Mean +- std dev: 133 ns +- 3 ns


The same regression happens consistently in many other functions (hex, len, deque methods....)

----------
components: Interpreter Core
keywords: 3.8regression
messages: 347672
nosy: Mark.Shannon, jdemeyer, pablogsal, petr.viktorin, rhettinger
priority: high
severity: normal
status: open
title: PEP 590 implementation introduced a performance regression
type: performance
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37562>
_______________________________________

From report at bugs.python.org  Thu Jul 11 10:14:34 2019
From: report at bugs.python.org (Jonathan)
Date: Thu, 11 Jul 2019 14:14:34 +0000
Subject: [New-bugs-announce] [issue37563] Documentation - default for
 StreamHandler
Message-ID: <1562854474.19.0.0872282470861.issue37563@roundup.psfhosted.org>


New submission from Jonathan <bugreports at lightpear.com>:

https://docs.python.org/2/library/logging.handlers.html
https://docs.python.org/3/library/logging.handlers.html

Both say:

"""class logging.StreamHandler(stream=None)

Returns a new instance of the StreamHandler class. If stream is specified, the instance will use it for logging output; otherwise, sys.stderr will be used."""

Surely that means from an user perspective that the default is actually `sys.stderr`, not `None`?

----------
assignee: docs at python
components: Documentation
messages: 347677
nosy: docs at python, jonathan-lp
priority: normal
severity: normal
status: open
title: Documentation - default for StreamHandler
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37563>
_______________________________________

From report at bugs.python.org  Thu Jul 11 11:10:32 2019
From: report at bugs.python.org (Zach Beniash)
Date: Thu, 11 Jul 2019 15:10:32 +0000
Subject: [New-bugs-announce] [issue37564] ArgumentParser should support bool
 type according to truth values
Message-ID: <1562857832.91.0.995710130518.issue37564@roundup.psfhosted.org>


New submission from Zach Beniash <zbeniash at gmail.com>:

Today when using argparse.ArgumentParser it seems that the bool type is not supported in a logical way.
Foe example:
-------------------------------------
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--mybool", type=bool)
parsed_args = parser.parse(["--mybool", "False"])
--------------------------------------
parsed_args.my_bool evaluates to True

Instead we should expect to evaluate False here.

----------
components: Library (Lib)
messages: 347686
nosy: Zach Beniash
priority: normal
severity: normal
status: open
title: ArgumentParser should support bool type according to truth values
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37564>
_______________________________________

From report at bugs.python.org  Thu Jul 11 11:12:51 2019
From: report at bugs.python.org (Michelle Johnson)
Date: Thu, 11 Jul 2019 15:12:51 +0000
Subject: [New-bugs-announce] [issue37565] test_faulthandler failure
Message-ID: <1562857971.79.0.0137287316017.issue37565@roundup.psfhosted.org>


New submission from Michelle Johnson <jshelly at umich.edu>:

CentOS 7.6, running Linux gl-build.arc-ts.umich.edu 3.10.0-957.10.1.el7.x86_64 #1 SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 on Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz.

Using gcc 8.2.0 compiled from source to build python 3.7.4 from source, make test fails with the following errors:

```
0:00:22 load avg: 3.12 [402/416/1] test_faulthandler failed
test test_faulthandler failed -- Traceback (most recent call last):
  File "/tmp/shellysw/build/Python-3.7.4/Lib/test/test_faulthandler.py", line 724, in test_register_chain
    self.check_register(chain=True)
  File "/tmp/shellysw/build/Python-3.7.4/Lib/test/test_faulthandler.py", line 702, in check_register
    self.assertEqual(exitcode, 0)
AssertionError: -11 != 0
```

I found a similar error reported in RedHat bugzilla (1687171) and tried running the script provided by Victor Stinner, and this closed issue on GitHub seems like it might be related?
#32 because of the Skylake chipset.

Script:
```
import faulthandler, signal, os

def handler(signum, frame):
    handler.called = True
handler.called = False

faulthandler.enable()

signum = signal.SIGUSR1
signal.signal(signum, handler)
faulthandler.register(signum, chain=True)
os.kill(os.getpid(), signum)
print("called", handler.called)
```

It produced a segmentation fault. I also ran that script using the python 3.6.6 binary that came installed with centos and it also produced a segmentation fault as well.

----------
components: Build, Tests
messages: 347688
nosy: jshelly
priority: normal
severity: normal
status: open
title: test_faulthandler failure
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37565>
_______________________________________

From report at bugs.python.org  Thu Jul 11 13:21:31 2019
From: report at bugs.python.org (hai shi)
Date: Thu, 11 Jul 2019 17:21:31 +0000
Subject: [New-bugs-announce] [issue37566] Remove redudant code in socket.py
Message-ID: <1562865691.95.0.427308376748.issue37566@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

Looks like the _realsocket in socket.py is redudnat. But I am not sure somebody would use it or not.

REF: https://github.com/python/cpython/blob/master/Lib/socket.py#L107

----------
components: Library (Lib)
messages: 347692
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Remove redudant code in socket.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37566>
_______________________________________

From report at bugs.python.org  Thu Jul 11 14:51:37 2019
From: report at bugs.python.org (Mike Lovelace)
Date: Thu, 11 Jul 2019 18:51:37 +0000
Subject: [New-bugs-announce] [issue37567] Python compiles empty bytecode
 files when out of virtual memory on windows
Message-ID: <1562871097.59.0.916925581077.issue37567@roundup.psfhosted.org>


New submission from Mike Lovelace <google.mike at thelovelaces.ca>:

On a system under heavy load last night Windows ran out of virtual memory, and it appears that python interpreted that as the pyc files did not exist and attempted to recreate them. In recreating them, it created essentially empty files, which caused further attempts to use the service to fail with 500 errors.

----------
files: urllib_RENAME.pyc
messages: 347701
nosy: Mike Lovelace
priority: normal
severity: normal
status: open
title: Python compiles empty bytecode files when out of virtual memory on windows
type: compile error
versions: Python 2.7
Added file: https://bugs.python.org/file48471/urllib_RENAME.pyc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37567>
_______________________________________

From report at bugs.python.org  Thu Jul 11 15:34:49 2019
From: report at bugs.python.org (kolia)
Date: Thu, 11 Jul 2019 19:34:49 +0000
Subject: [New-bugs-announce] [issue37568] Misleading UnBoundLocalError on
 assignment to closure variable
Message-ID: <1562873689.17.0.696922314347.issue37568@roundup.psfhosted.org>


New submission from kolia <kolia.sadeghi at gmail.com>:

def outer(a):   
    def inner():
      print(a)  
      a = 43    
    return inner
                
t = outer(42)   
                
print(t())      


Outputs:

~/Documents/repro.py in inner()                                   
      1 def outer(a):                                             
      2     def inner():                                          
----> 3       print(a)                                            
      4       a = 43                                              
      5     return inner                                          
                                                                  
UnboundLocalError: local variable 'a' referenced before assignment


This is misleading, since `a` is actually in scope on line 3. What is making it fail is the assignment on line 4, since `a` has not been declared `nonlocal`.

Instead, the error should point to line 4 and report an illegal assignment to a read-only closure variable.

----------
components: Interpreter Core
messages: 347703
nosy: kolia
priority: normal
severity: normal
status: open
title: Misleading UnBoundLocalError on assignment to closure variable
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37568>
_______________________________________

From report at bugs.python.org  Thu Jul 11 17:04:39 2019
From: report at bugs.python.org (David)
Date: Thu, 11 Jul 2019 21:04:39 +0000
Subject: [New-bugs-announce] [issue37569] Complete your registration to
 Python tracker
In-Reply-To: <20190711205905.A319B52B1FA@bugs.ams1.psf.io>
Message-ID: <BN6PR14MB1267F753583C3F440BC32486D2F30@BN6PR14MB1267.namprd14.prod.outlook.com>


New submission from David <davedrouin at hotmail.com>:

Here is the link to register.
________________________________
From: report=bugs.python.org at roundup.psfhosted.org <report=bugs.python.org at roundup.psfhosted.org> on behalf of Python tracker <report at bugs.python.org>
Sent: Thursday, July 11, 2019 8:59 PM
To: davedrouin at hotmail.com
Subject: Complete your registration to Python tracker

To complete your registration of the user "ddrouin" with
Python tracker, please visit the following URL:

https://bugs.python.org/?@action=confrego&otk=yx0D8CJvzNqeUY0usWJfgG0vnPc7HsWM

----------
messages: 347708
nosy: ddrouin
priority: normal
severity: normal
status: open
title: Complete your registration to Python tracker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37569>
_______________________________________

From report at bugs.python.org  Thu Jul 11 22:28:51 2019
From: report at bugs.python.org (Suzumizaki)
Date: Fri, 12 Jul 2019 02:28:51 +0000
Subject: [New-bugs-announce] [issue37570] `distutils.util.byte_compile`
 fails indirect byte compiling with non-ASCII full-path.
Message-ID: <1562898531.08.0.918115667827.issue37570@roundup.psfhosted.org>


New submission from Suzumizaki <suzumizaki at free.japandesign.ne.jp>:

`distutils.util.byte_compile` fails _indirect_ byte compiling when the
full-path of the .py file contains non-ASCII characters.

Because there is the project (cx_Freeze) which directly uses
`distutils.util.byte_compile`, the problem would happen while installing it
under the non-ASCII path.

Fortunately, it is easy to fix.
 
Ofcourse, the files included in external libraries should be named ASCII only,
but `distutils.util.byte_compile` makes and uses full path of them. I learned
many of libraries uses setuptools instead of distutils, but please consider
the following situations:

1) The case that venv creates the virtual environment under or with
   non-ASCII named folder.
2) And special cases of 1), on Windows, the name of end-users OFTEN be
   composed with non-ASCII characters, this means including theirs
   Documents, Desktop, or Downloads etc.

The more they are not professional,they make easily the situation above.

----------
components: Distutils
files: batch.diff
keywords: patch
messages: 347718
nosy: Suzumizaki, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: `distutils.util.byte_compile` fails indirect byte compiling with non-ASCII full-path.
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48472/batch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37570>
_______________________________________

From report at bugs.python.org  Fri Jul 12 03:40:49 2019
From: report at bugs.python.org (Reuben Thomas)
Date: Fri, 12 Jul 2019 07:40:49 +0000
Subject: [New-bugs-announce] [issue37571] Incorrect use of c_char_p in
 example code
Message-ID: <1562917249.5.0.829310494906.issue37571@roundup.psfhosted.org>


New submission from Reuben Thomas <rrt at sc3d.org>:

The CTypes documentation has this example:

>>> s = c_char_p()
>>> s.value = "abc def ghi"
>>> s.value
'abc def ghi'
>>> s.value is s.value
False
>>>

It appears not to have been updated since Python 2: in Python 3, you can't assign a str to a c_char_p. If one tries the example code above, one gets:

>>> s = c_char_p()
>>> s.value = "abc def ghi"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: bytes or integer address expected instead of str instance

Using a bytes works:

>>> s = c_char_p()
>>> s.value = b"abc def ghi"
>>> s.value
b'abc def ghi'
>>> s.value is s.value
False
>>>

Hence adding the two "b"s is an obvious fix.

Note that the similar example with c_wchar_p does work fine with str.

----------
assignee: docs at python
components: Documentation
messages: 347725
nosy: docs at python, rrt
priority: normal
severity: normal
status: open
title: Incorrect use of c_char_p in example code
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37571>
_______________________________________

From report at bugs.python.org  Fri Jul 12 08:44:01 2019
From: report at bugs.python.org (famu xu)
Date: Fri, 12 Jul 2019 12:44:01 +0000
Subject: [New-bugs-announce] [issue37572] email lib bug
Message-ID: <1562935441.75.0.460848575163.issue37572@roundup.psfhosted.org>


New submission from famu xu <qhsoft at gmail.com>:

file: email\_header_value_parser.py

line : encoded_part = part.fold(policy=policy)[:-1] # strip nl
modify to: encoded_part = part.fold(policy=policy)[:-2] # strip nl

because the nl is "\r\n"

----------
components: email
messages: 347740
nosy: barry, famu xu, r.david.murray
priority: normal
severity: normal
status: open
title: email lib bug
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37572>
_______________________________________

From report at bugs.python.org  Fri Jul 12 08:57:35 2019
From: report at bugs.python.org (Jakub Kulik)
Date: Fri, 12 Jul 2019 12:57:35 +0000
Subject: [New-bugs-announce] [issue37573] asyncio: freeze when using
 MultiLoopChildWatcher on Solaris
Message-ID: <1562936255.66.0.924337077063.issue37573@roundup.psfhosted.org>


New submission from Jakub Kulik <kulikjak at gmail.com>:

Hi,

since the 3.8.0b2 test_asyncio freezes in test_subprocess when MultiLoopChildWatcher is being used as a watcher (new in b2). All other watchers are working as expected. This is all on Solaris.

I tried to find out the reason for these issues and it seems that awaited coroutines never end (there are many tests with this problem - I tested it on test_cancel_make_subprocess_transport_exec). I found out that commenting out `signal.siginterrupt(signal.SIGCHLD, False)` in `attach_loop` method of MultiLoopChildWatcher seems to fix the issue, however, I don't understand this enough to see why that should be a problem...

I can provide more information if necessary.

----------
components: Library (Lib)
messages: 347743
nosy: kulikjak
priority: normal
severity: normal
status: open
title: asyncio: freeze when using MultiLoopChildWatcher on Solaris
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37573>
_______________________________________

From report at bugs.python.org  Fri Jul 12 14:16:31 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 12 Jul 2019 18:16:31 +0000
Subject: [New-bugs-announce] [issue37574] Mention spec_from_loader() in
 Finder.find_spec() docs.
Message-ID: <1562955391.43.0.163221688475.issue37574@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

When writing an importer, the finder (either MetaPathFinder or PathEntryFinder) must implement `find_spec()`.  A useful tool for that is the existing `spec_from_loader()`. [1]  The docs for `MetaPathFinder.find_spec()` and `PathEntryFinder.find_spec()` should mention it.


[1] (https://docs.python.org/3/library/importlib.html#importlib.util.spec_from_loader

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 347750
nosy: docs at python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Mention spec_from_loader() in Finder.find_spec() docs.
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37574>
_______________________________________

From report at bugs.python.org  Fri Jul 12 16:50:07 2019
From: report at bugs.python.org (Srikanth)
Date: Fri, 12 Jul 2019 20:50:07 +0000
Subject: [New-bugs-announce] [issue37575] Python Documentation on strings (
 section 3.1.2.)
Message-ID: <1562964607.44.0.971161139684.issue37575@roundup.psfhosted.org>


New submission from Srikanth <s4srikanth at gmail.com>:

In section 3.1.2 of the python documentation, its mentioned as below:

Two or more string literals (i.e. the ones enclosed between quotes) next to each other are automatically concatenated.
This feature is particularly useful when you want to break long strings:
This only works with two literals though, not with variables or expressions:

However, the concatination operation works on variables and expressions also.
Please find the below python code snippet and the output:

Python Code:
-------------
s1='Hello'
s2=' World '
s3=' How are you ? '
print(s1, s2, "\n", s3, "\n")
print('---------------------------')
print('Long time ' 'No see mate ')
print("Hope ", 'All is ' "good")
print('---------------------------')
print(s1, 'World'," !!")
print((s1+s2+s3)*2," there ?")


Output:
--------
Hello  World                                                                                                          
  How are you ?                                                                                                       
                                                                                                                      
---------------------------                                                                                           
Long time No see mate                                                                                                 
Hope  All is good                                                                                                     
---------------------------                                                                                           
Hello World  !!                                                                                                       
Hello World  How are you ? Hello World  How are you ?   there ?

----------
assignee: docs at python
components: Documentation
files: Python_Docs_3.1.2_String_Concatination.py
messages: 347754
nosy: Deshpande, docs at python
priority: normal
severity: normal
status: open
title: Python Documentation on strings ( section 3.1.2.)
type: resource usage
Added file: https://bugs.python.org/file48474/Python_Docs_3.1.2_String_Concatination.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37575>
_______________________________________

From report at bugs.python.org  Fri Jul 12 17:13:13 2019
From: report at bugs.python.org (Scott Sturdivant)
Date: Fri, 12 Jul 2019 21:13:13 +0000
Subject: [New-bugs-announce] [issue37576] SSL Malloc Error w/OpenSSL
 1.1.1c-fips & FIPS_mode_set(1)
Message-ID: <1562965993.74.0.405648137897.issue37576@roundup.psfhosted.org>


New submission from Scott Sturdivant <scott.sturdivant at gmail.com>:

Using Py3{5,6,7} and OpenSSL 1.1.1b-fips, I have not encountered this error.  Once OpenSSL has been upgraded to 1.1.1c-fips, the SSL Malloc Error rears its ugly head.

Setup:

Fedora 30 has openssl-fips by default.

Install cryptography with 'pip install cryptography --no-binary=cryptography' so that it can link against your system openssl that is fips enabled.

To verify:

With openssl 1.1.1.b-fips, the following works:

>>> import urllib.request
>>> with urllib.request.urlopen('http://python.org/') as response:
...    html = response.read()
...
>>> from cryptography.hazmat.backends.openssl.backend import backend
>>> backend._lib.FIPS_mode_set(1)
1
>>> with urllib.request.urlopen('http://python.org/') as response:
...    html = response.read()
...

With openssl 1.1.1c-fips, an error is now raised:

>>> import urllib.request
>>> with urllib.request.urlopen('http://python.org/') as response:
...    html = response.read()
...
>>> from cryptography.hazmat.backends.openssl.backend import backend
>>> backend._lib.FIPS_mode_set(1)
1
>>> with urllib.request.urlopen('http://python.org/') as response:
...    html = response.read()
...
Traceback (most recent call last):
  File "/usr/lib64/python3.7/urllib/request.py", line 1317, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/lib64/python3.7/http/client.py", line 1244, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib64/python3.7/http/client.py", line 1290, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.7/http/client.py", line 1239, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib64/python3.7/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/usr/lib64/python3.7/http/client.py", line 966, in send
    self.connect()
  File "/usr/lib64/python3.7/http/client.py", line 1407, in connect
    server_hostname=server_hostname)
  File "/usr/lib64/python3.7/ssl.py", line 412, in wrap_socket
    session=session
  File "/usr/lib64/python3.7/ssl.py", line 853, in _create
    self.do_handshake()
  File "/usr/lib64/python3.7/ssl.py", line 1117, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL] malloc failure (_ssl.c:1056)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.7/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib64/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib64/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib64/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib64/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib64/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib64/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/lib64/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/lib64/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib64/python3.7/urllib/request.py", line 1360, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "/usr/lib64/python3.7/urllib/request.py", line 1319, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [SSL] malloc failure (_ssl.c:1056)>
>>>

----------
assignee: christian.heimes
components: SSL
messages: 347755
nosy: Scott Sturdivant, christian.heimes
priority: normal
severity: normal
status: open
title: SSL Malloc Error w/OpenSSL 1.1.1c-fips & FIPS_mode_set(1)
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37576>
_______________________________________

From report at bugs.python.org  Fri Jul 12 21:52:11 2019
From: report at bugs.python.org (=?utf-8?q?Luis_Alejandro_Mart=C3=ADnez_Faneyth?=)
Date: Sat, 13 Jul 2019 01:52:11 +0000
Subject: [New-bugs-announce] [issue37577] ModuleNotFoundError: No module
 named '_sysconfigdata__linux_x86_64-linux-gnu'
Message-ID: <1562982731.24.0.816575023926.issue37577@roundup.psfhosted.org>


New submission from Luis Alejandro Mart?nez Faneyth <martinez.faneyth at gmail.com>:

Hello everyone,

I've been building some minimal python docker images for a while and a few days ago an error popped out in my CI when building python 3.8 on debian sid. The error happens when trying to install pip with the usual:

curl -fsSL https://bootstrap.pypa.io/get-pip.py | python3.8 - setuptools

The message:

ERROR: Exception:
Traceback (most recent call last):
  File "/tmp/tmprv6tur0m/pip.zip/pip/_internal/cli/base_command.py", line 178, in main
    status = self.run(options, args)
  File "/tmp/tmprv6tur0m/pip.zip/pip/_internal/commands/install.py", line 405, in run
    installed = install_given_reqs(
  File "/tmp/tmprv6tur0m/pip.zip/pip/_internal/req/__init__.py", line 54, in install_given_reqs
    requirement.install(
  File "/tmp/tmprv6tur0m/pip.zip/pip/_internal/req/req_install.py", line 919, in install
    self.move_wheel_files(
  File "/tmp/tmprv6tur0m/pip.zip/pip/_internal/req/req_install.py", line 440, in move_wheel_files
    move_wheel_files(
  File "/tmp/tmprv6tur0m/pip.zip/pip/_internal/wheel.py", line 318, in move_wheel_files
    scheme = distutils_scheme(
  File "/tmp/tmprv6tur0m/pip.zip/pip/_internal/locations.py", line 180, in distutils_scheme
    i.finalize_options()
  File "/usr/lib/python3.8/distutils/command/install.py", line 306, in finalize_options
    (prefix, exec_prefix) = get_config_vars('prefix', 'exec_prefix')
  File "/usr/lib/python3.8/distutils/sysconfig.py", line 501, in get_config_vars
    func()
  File "/usr/lib/python3.8/distutils/sysconfig.py", line 461, in _init_posix
    _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
ModuleNotFoundError: No module named '_sysconfigdata__linux_x86_64-linux-gnu'


You can check the full CI output[0] or the building script if you need to[1].

I've checked for similar bugs and I found #28046 but I don't know if this is related or not.

Thanks for the great work and I'm looking forward to help you fix this issue.

Luis

[0]https://travis-ci.org/LuisAlejandro/dockershelf/jobs/557990064
[1]https://github.com/LuisAlejandro/dockershelf/blob/master/python/build-image.sh

----------
messages: 347765
nosy: luisalejandro
priority: normal
severity: normal
status: open
title: ModuleNotFoundError: No module named '_sysconfigdata__linux_x86_64-linux-gnu'
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37577>
_______________________________________

From report at bugs.python.org  Fri Jul 12 22:23:53 2019
From: report at bugs.python.org (Kalev Maricq)
Date: Sat, 13 Jul 2019 02:23:53 +0000
Subject: [New-bugs-announce] [issue37578] Change Glob: Allow Recursion for
 Hidden Files
Message-ID: <1562984633.23.0.0355519865943.issue37578@roundup.psfhosted.org>


New submission from Kalev Maricq <kalevtheolive at hotmail.com>:

First, sorry if this isn't in the correct place or correctly labeled. I'm new to this platform.  Feel free to edit this (if that's even possible on this platform). 

In the glob.py module, _ishidden(pattern) is used to determine whether to show hidden files and folders by checking if pattern[0]=='.'.  It also uses _isrecursive(pattern) to determine whether to perform a recursive search by checking whether the pattern=='**'.  As a result, one cannot perform a recursive search which shows hidden folders and files, since '**'[0]!='.'.  

Suggestion: Alter _isrecursive to return '**' in pattern to allow for this.

----------
messages: 347767
nosy: k64
priority: normal
severity: normal
status: open
title: Change Glob: Allow Recursion for Hidden Files
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37578>
_______________________________________

From report at bugs.python.org  Sat Jul 13 01:25:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 13 Jul 2019 05:25:41 +0000
Subject: [New-bugs-announce] [issue37579] Difference in equality check
 between C and Python implementation for datetime module's timedelta and
 time
Message-ID: <1562995541.72.0.689612631399.issue37579@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

As reported by Serhiy on https://bugs.python.org/issue37555#msg347733 there is a difference in __eq__ definition in datetime module's C and Python implementation for timedelta and time. When the other in __eq__ is not of the same type NotImplemented is not returned in Python implementation like C causing equality to behave differently.

Difference in C implementation and Python implementation for datetime.timedelta.__eq__

https://github.com/python/cpython/blob/c8e7146de257930ea8d0d4aa74b3a64fcaa79d4b/Modules/_datetimemodule.c#L2152

static PyObject *
delta_richcompare(PyObject *self, PyObject *other, int op)
{
    if (PyDelta_Check(other)) {
        int diff = delta_cmp(self, other);
        return diff_to_bool(diff, op);
    }
    else {
        Py_RETURN_NOTIMPLEMENTED;
    }
}


https://github.com/python/cpython/blob/c8e7146de257930ea8d0d4aa74b3a64fcaa79d4b/Lib/datetime.py#L732

def __eq__(self, other):
    if isinstance(other, timedelta):
        return self._cmp(other) == 0
    else:
        return False


I will add a PR for this with test.

----------
components: Library (Lib)
messages: 347773
nosy: belopolsky, p-ganssle, serhiy.storchaka, xtreak
priority: normal
severity: normal
status: open
title: Difference in equality check between C and Python implementation for datetime module's timedelta and time
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37579>
_______________________________________

From report at bugs.python.org  Sat Jul 13 01:49:45 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 13 Jul 2019 05:49:45 +0000
Subject: [New-bugs-announce] [issue37580] Markup typo in http.cookiejar doc
Message-ID: <1562996985.21.0.0323221925238.issue37580@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

CookieJar.add_cookie_header in Doc/library/http.cookiejar.rst contains the below statement where .. is present that causes the markup to not link to the correct docs. The fix would be to remove extra dot in the docs and verify the rendered doc page.

https://docs.python.org/3/library/http.cookiejar.html#http.cookiejar.CookieJar.add_cookie_header

The *request* object (usually a :class:`urllib.request..Request` instance)

Marking this as easy for first time contributors who have not made a PR.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 347775
nosy: docs at python, xtreak
priority: normal
severity: normal
stage: needs patch
status: open
title: Markup typo in http.cookiejar doc
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37580>
_______________________________________

From report at bugs.python.org  Sat Jul 13 02:42:51 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 13 Jul 2019 06:42:51 +0000
Subject: [New-bugs-announce] [issue37581] Docs: Improve phrasing of flush
 argument for print()
Message-ID: <1563000171.75.0.259144303863.issue37581@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

Currently in the documentation for print() (https://docs.python.org/3/library/functions.html#print), the phrasing for the flush argument is:

Whether output is buffered is usually determined by file, but if the flush keyword argument is true, the stream is forcibly flushed.

For the sake of clarity, I would recommend changing it to one of the following:

1) Whether or not output is buffered is usually determined by *file*, but if the *flush* keyword argument is true, the stream is forcibly flushed.

2) Whether or not output is buffered is usually determined by *file*. However, if the *flush* keyword argument is true, the stream is forcibly flushed.

3) Output buffering is usually determined by *file*. However, if the *flush* keyword argument is true, the stream is forcibly flushed.

4) Output buffering is usually determined by *file*. However, if *flush* is true, the stream is forcibly flushed.

Each of the options are ordered in difference from the original, with one being the closest. The first couple options simply attempt improve the readability without changing the message itself significantly.

In the third option, "output is buffered" is replaced by "output buffering", which is a commonly used programming term for what is being described. 

The fourth option removes "keyword argument" after *flush*, since it was not mentioned for *file* (which is also a keyword argument). Users can simply look at the function arguments to see that it's a keyword argument. Explicitly specifying this seems like it might be in partial violation of https://devguide.python.org/documenting/#economy-of-expression and https://devguide.python.org/documenting/#audience.

I'll be submitting a PR to attach to this issue soon. Let me know if this change is helpful, and if so, which option (or variation) provides the most concise and helpful explanation to users.

----------
messages: 347778
nosy: aeros167, eric.araujo, ezio.melotti, mdk, willingc
priority: normal
severity: normal
status: open
title: Docs: Improve phrasing of flush argument for print()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37581>
_______________________________________

From report at bugs.python.org  Sat Jul 13 02:50:47 2019
From: report at bugs.python.org (dai dai)
Date: Sat, 13 Jul 2019 06:50:47 +0000
Subject: [New-bugs-announce] [issue37582] can you add this new feature about
 grammar?
Message-ID: <1563000647.96.0.457672921362.issue37582@roundup.psfhosted.org>


New submission from dai dai <daidai4269 at gmail.com>:

>> a = 1
>> b = 2
>> a, b += 1, 2
2  3

----------
messages: 347779
nosy: dai dai
priority: normal
severity: normal
status: open
title: can you add this new feature about grammar?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37582>
_______________________________________

From report at bugs.python.org  Sat Jul 13 04:34:31 2019
From: report at bugs.python.org (hai shi)
Date: Sat, 13 Jul 2019 08:34:31 +0000
Subject: [New-bugs-announce] [issue37583] Got a 113 error when running the
 test_socket
Message-ID: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

When I run test_socket.py, I got a error. Looks it's a problem of security group.
My env: a vm of centos
May be I need add `EHOSTUNREACH` in support.get_socket_conn_refused_errs()?

======================================================================
FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shihai/workspace/cpython/Lib/test/test_socket.py", line 4961, in test_create_connection
    self.assertIn(cm.exception.errno, expected_errnos)
AssertionError: 113 not found in [111, 101, 99, 97]

----------------------------------------------------------------------
Ran 814 tests in 25.929s

FAILED (failures=1, errors=117, skipped=197)

----------
components: Tests
messages: 347786
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Got a 113 error when running the test_socket

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37583>
_______________________________________

From report at bugs.python.org  Sat Jul 13 06:13:57 2019
From: report at bugs.python.org (Dimiter Naydenov)
Date: Sat, 13 Jul 2019 10:13:57 +0000
Subject: [New-bugs-announce] [issue37584] Multiple test failures with
 OSError: [Errno 84] Invalid or incomplete multibyte or wide character on
 ZFS with utf8only=on
Message-ID: <1563012837.05.0.658851590788.issue37584@roundup.psfhosted.org>


New submission from Dimiter Naydenov <dimiter at naydenov.net>:

I'm running Ubuntu 19.04 on a ZFS mirrored pool, where my home partition is configured with 'utf8only=on' attribute. I've cloned cpython and after running the tests, as described in devguide.python.org, I have 11 test failures:

== Tests result: FAILURE ==

389 tests OK.

11 tests failed:
    test_cmd_line_script test_httpservers test_imp test_import
    test_ntpath test_os test_posixpath test_socket test_unicode_file
    test_unicode_file_functions test_zipimport

I've been looking for similar or matching reported issues, but could not find one. I'm on the EuroPython 2019 CPython sprint and we'll be looking into this with the help of some of the core devs.

----------
components: Tests, Unicode
files: cpython_test_output.log
messages: 347794
nosy: benjamin.peterson, dimitern, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Multiple test failures with OSError: [Errno 84] Invalid or incomplete multibyte or wide character on ZFS with utf8only=on
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48475/cpython_test_output.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37584>
_______________________________________

From report at bugs.python.org  Sat Jul 13 07:58:48 2019
From: report at bugs.python.org (Kristian Klette)
Date: Sat, 13 Jul 2019 11:58:48 +0000
Subject: [New-bugs-announce] [issue37585] Comparing PyDictValues does not
 give expected results
Message-ID: <1563019128.62.0.639495498673.issue37585@roundup.psfhosted.org>


New submission from Kristian Klette <klette at klette.us>:

As a user, I expect to be able to compare the different parts a `dict`
in the same manner.

Currently, `PyDictValues` does not implement the `dictview_richcompare`, causing the `__eq__` to always return false, even if the values are identical.


```
my_dict = {'foo': 'bar'}
dict_copy = my_dict.copy()
other_dict = {'foo': 'bar', 'bar': 1234}

assert my_dict.keys() == my_dict.keys()
assert my_dict.keys() == dict_copy.keys()
assert my_dict.keys() != other_dict.keys()

assert my_dict.items() == my_dict.items()
assert my_dict.items() == dict_copy.items()
assert my_dict.items() != other_dict.items()

assert my_dict.values() == my_dict.values()
assert my_dict.values() == dict_copy.values()
assert my_dict.values() != other_dict.values()

```

----------
components: Library (Lib)
messages: 347806
nosy: Kristian Klette
priority: normal
severity: normal
status: open
title: Comparing PyDictValues does not give expected results
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37585>
_______________________________________

From report at bugs.python.org  Sat Jul 13 09:27:37 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 13 Jul 2019 13:27:37 +0000
Subject: [New-bugs-announce] [issue37586] macOS: posix_spawn(...,
 setsid=True)
Message-ID: <1563024457.33.0.250849204696.issue37586@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The Xcode 11 beta introduced a definition for POSIX_SPAWN_SETSID, but that flag is only supported on macOS 10.15 (also beta), not on earlier versions.

Because of this the testsuite will have failures when you build using Xcode 11 on macOS 10.14. 

I'm not sure what the best way to patch this is, but lean toward a fix that detects the use of setsid=True on macOS 10.14 or earlier and then fails. Possibly as part of a larger effort to start supporting building on macOS "latest" and running on older versions.

Marked as low priority for now, Xcode 11 is in beta and not used to build release binaries.

----------
assignee: ronaldoussoren
components: macOS
messages: 347816
nosy: ned.deily, ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: macOS: posix_spawn(..., setsid=True)
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37586>
_______________________________________

From report at bugs.python.org  Sat Jul 13 10:42:02 2019
From: report at bugs.python.org (Marco Paolini)
Date: Sat, 13 Jul 2019 14:42:02 +0000
Subject: [New-bugs-announce] [issue37587] JSON loads performance improvement
 for long strings
Message-ID: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org>


New submission from Marco Paolini <markopaolini at gmail.com>:

I analysed the performance of json.loads in one production workload we have.

Spy-py tells me the majority of time is spent into C json module (see events.svg)

Digging deeper, linux perf tells me hottest loop (where 20%+ of the time is spent) in _json.scanstring_unicode, in this loop:

189:   movzx  eax,BYTE PTR [rbp+rbx*1+0x0]
       mov    DWORD PTR [rsp+0x44],eax
       cmp    eax,0x22
       je     22f
       cmp    eax,0x5c
       je     22f
       test   r13d,r13d
       je     180
       cmp    eax,0x1f

which is related to this code in Modules/_json.c


        /* Find the end of the string or the next escape */
        Py_UCS4 c = 0;
        for (next = end; next < len; next++) {
            c = PyUnicode_READ(kind, buf, next);
            if (c == '"' || c == '\\') {
                break;
            }
            else if (strict && c <= 0x1f) {
                raise_errmsg("Invalid control character at", pystr, next);
                goto bail;
            }
        }

Two optimisations can be done:

1. remove the mov entirely. It is not needed inside the loop and it is only needed later, outside the loop to access the variable
2. switch around the strict check (in the second if) because strict defaults to 1 so it will likely pass the test, while the likelyness of finding an invalid character is lower

Running the pyperformance json_loads benchmark I get:

+------------+----------------------+-----------------------------+
| Benchmark  | vanilla-pyperf-pgo38 | patched-pyperf-pgo38        |
+============+======================+=============================+
| json_loads | 54.9 us              | 53.9 us: 1.02x faster (-2%) |
+------------+----------------------+-----------------------------+


A micro benchmark on a 1MB long json string gives better results:

python -m pyperf timeit -s "import json; x = json.dumps({'k': '1' * 2 ** 20})" "json.loads(x)"

+-----------+------------+-----------------------------+
| Benchmark | vanilla-1m | patched-1m                  |
+===========+============+=============================+
| timeit    | 2.62 ms    | 2.39 ms: 1.10x faster (-9%) |
+-----------+------------+-----------------------------+

----------
components: Library (Lib)
files: events.svg
messages: 347832
nosy: christian.heimes, mpaolini, pablogsal
priority: normal
severity: normal
status: open
title: JSON loads performance improvement for long strings
type: performance
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48476/events.svg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37587>
_______________________________________

From report at bugs.python.org  Sat Jul 13 13:53:56 2019
From: report at bugs.python.org (Phil Thompson)
Date: Sat, 13 Jul 2019 17:53:56 +0000
Subject: [New-bugs-announce] [issue37588] Py_DEPRECATED and unavoidable
 warnings
Message-ID: <1563040436.19.0.276806879722.issue37588@roundup.psfhosted.org>


New submission from Phil Thompson <phil at riverbankcomputing.com>:

I have a number of static PyTypeObject declarations. In order to avoid compiler warnings about missing field initialisers I always provide explicit 0 values for unused fields (protected by #if PY_HEX_VERSION >= ...). However with v3.8b2 this triggers new warnings from Py_DEPRECATED because of the initialiser for tp_print.

I would like some way of locally suppressing Py_DEPRECATED. The attached trivial patch would do this by allowing me to define a null Py_DEPRECATED before including Python.h.

----------
components: Interpreter Core
files: pyport.h.diff
keywords: patch
messages: 347848
nosy: philthompson10
priority: normal
severity: normal
status: open
title: Py_DEPRECATED and unavoidable warnings
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48478/pyport.h.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37588>
_______________________________________

From report at bugs.python.org  Sun Jul 14 02:53:07 2019
From: report at bugs.python.org (Vemake)
Date: Sun, 14 Jul 2019 06:53:07 +0000
Subject: [New-bugs-announce] [issue37589] Missing dependences in the Makefile
Message-ID: <1563087187.08.0.733315200631.issue37589@roundup.psfhosted.org>


New submission from Vemake <vemakereporter at gmail.com>:

We use a tool to detect 138 dependence issues in the Makefile. Most of them are missing of c source files and header files. 

Those issues can cause incorrect results when we want to do incremental build and parallel build.

For example, any changes in "Include/typeslots.h" will not cause "Modules/atexitmodule.o" to be rebuilt, which is incorrect.

I've fixed all of them in the github PR:
https://github.com/python/cpython/pull/14758

I've tested it on my computer and the fixed version works as expected.

----------
components: Build
messages: 347866
nosy: vemakereporter
priority: normal
pull_requests: 14554
severity: normal
status: open
title: Missing dependences in the Makefile
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37589>
_______________________________________

From report at bugs.python.org  Sun Jul 14 04:05:24 2019
From: report at bugs.python.org (hai shi)
Date: Sun, 14 Jul 2019 08:05:24 +0000
Subject: [New-bugs-announce] [issue37590] Remove redundant docs of
 PyEval_EvalFrameEx
Message-ID: <1563091524.9.0.285341984232.issue37590@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

PyEval_EvalFrameEx have been updated. so remove redundant info in https://github.com/python/cpython/blob/master/Python/ceval.c#L733-L738

----------
assignee: docs at python
components: Documentation
messages: 347874
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: Remove redundant docs of PyEval_EvalFrameEx

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37590>
_______________________________________

From report at bugs.python.org  Sun Jul 14 08:19:30 2019
From: report at bugs.python.org (Martin Bammer)
Date: Sun, 14 Jul 2019 12:19:30 +0000
Subject: [New-bugs-announce] [issue37591] test_concurrent_future failed
Message-ID: <1563106770.47.0.449024295444.issue37591@roundup.psfhosted.org>


New submission from Martin Bammer <mrbm74 at gmail.com>:

When building Python 3.7.4 from source on Ubuntu 18.10 I'm getting the following error:

0:04:38 load avg: 2.40 [ 78/416] test_complex
0:04:39 load avg: 2.40 [ 79/416] test_concurrent_futures

Traceback:
 Thread 0x00007f936b7fe700 (most recent call first):
  File "/media/Daten/src/Python-3.7.4/Lib/threading.py", line 296 in wait
  File "/media/Daten/src/Python-3.7.4/Lib/multiprocessing/queues.py", line 224 in _feed
  File "/media/Daten/src/Python-3.7.4/Lib/threading.py", line 870 in run
  File "/media/Daten/src/Python-3.7.4/Lib/threading.py", line 926 in _bootstrap_inner
  File "/media/Daten/src/Python-3.7.4/Lib/threading.py", line 890 in _bootstrap

Thread 0x00007f93487fc700 (most recent call first):
  File "/media/Daten/src/Python-3.7.4/Lib/selectors.py", line 415 in select
  File "/media/Daten/src/Python-3.7.4/Lib/multiprocessing/connection.py", line 920 in wait
  File "/media/Daten/src/Python-3.7.4/Lib/concurrent/futures/process.py", line 361 in _queue_management_worker
  File "/media/Daten/src/Python-3.7.4/Lib/threading.py", line 870 in run
  File "/media/Daten/src/Python-3.7.4/Lib/threading.py", line 926 in _bootstrap_inner
  File "/media/Daten/src/Python-3.7.4/Lib/threading.py", line 890 in _bootstrap

Current thread 0x00007f9396eb5140 (most recent call first):
  File "/media/Daten/src/Python-3.7.4/Lib/test/test_concurrent_futures.py", line 917 in _fail_on_deadlock
  File "/media/Daten/src/Python-3.7.4/Lib/test/test_concurrent_futures.py", line 978 in test_crash
  File "/media/Daten/src/Python-3.7.4/Lib/unittest/case.py", line 628 in run
  File "/media/Daten/src/Python-3.7.4/Lib/unittest/case.py", line 676 in __call__
  File "/media/Daten/src/Python-3.7.4/Lib/unittest/suite.py", line 122 in run
  File "/media/Daten/src/Python-3.7.4/Lib/unittest/suite.py", line 84 in __call__
  File "/media/Daten/src/Python-3.7.4/Lib/unittest/suite.py", line 122 in run
  File "/media/Daten/src/Python-3.7.4/Lib/unittest/suite.py", line 84 in __call__
  File "/media/Daten/src/Python-3.7.4/Lib/unittest/suite.py", line 122 in run
  File "/media/Daten/src/Python-3.7.4/Lib/unittest/suite.py", line 84 in __call__
  File "/media/Daten/src/Python-3.7.4/Lib/test/support/testresult.py", line 162 in run
  File "/media/Daten/src/Python-3.7.4/Lib/test/support/__init__.py", line 1915 in _run_suite
  File "/media/Daten/src/Python-3.7.4/Lib/test/support/__init__.py", line 2011 in run_unittest
  File "/media/Daten/src/Python-3.7.4/Lib/test/test_concurrent_futures.py", line 1245 in test_main
  File "/media/Daten/src/Python-3.7.4/Lib/test/support/__init__.py", line 2143 in decorator
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/runtest.py", line 228 in _runtest_inner2
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/runtest.py", line 264 in _runtest_inner
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/runtest.py", line 149 in _runtest
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/runtest.py", line 187 in runtest
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/main.py", line 390 in run_tests_sequential
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/main.py", line 488 in run_tests
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/main.py", line 642 in _main
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/main.py", line 588 in main
  File "/media/Daten/src/Python-3.7.4/Lib/test/libregrtest/main.py", line 663 in main
  File "/media/Daten/src/Python-3.7.4/Lib/test/regrtest.py", line 46 in _main
  File "/media/Daten/src/Python-3.7.4/Lib/test/regrtest.py", line 50 in <module>
  File "/media/Daten/src/Python-3.7.4/Lib/runpy.py", line 85 in _run_code
  File "/media/Daten/src/Python-3.7.4/Lib/runpy.py", line 193 in _run_module_as_main

test test_concurrent_futures failed
0:07:27 load avg: 2.55 [ 80/416] test_configparser -- test_concurrent_futures failed in 2 min 47 sec
0:07:29 load avg: 2.75 [ 81/416] test_contains


Commands executed for the build:

./configure --enable-optimizations --prefix=/opt/python-3.7.4
make -j8

----------
components: Build
messages: 347908
nosy: Martin Bammer
priority: normal
severity: normal
status: open
title: test_concurrent_future failed
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37591>
_______________________________________

From report at bugs.python.org  Sun Jul 14 10:18:09 2019
From: report at bugs.python.org (Carl Bordum Hansen)
Date: Sun, 14 Jul 2019 14:18:09 +0000
Subject: [New-bugs-announce] [issue37592] sysconfig should not rely on
 sys.version
Message-ID: <1563113889.28.0.678925745587.issue37592@roundup.psfhosted.org>


New submission from Carl Bordum Hansen <carl at bordum.dk>:

I found this FIXME and replaced it with code that follows the git tags naming scheme.

----------
components: Library (Lib)
messages: 347916
nosy: carlbordum, tarek
priority: normal
severity: normal
status: open
title: sysconfig should not rely on sys.version
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37592>
_______________________________________

From report at bugs.python.org  Sun Jul 14 14:55:37 2019
From: report at bugs.python.org (Benjamin S Wolf)
Date: Sun, 14 Jul 2019 18:55:37 +0000
Subject: [New-bugs-announce] [issue37593] ast.arguments has confusing
 args/posonlyargs ordering
Message-ID: <1563130537.16.0.669672983776.issue37593@roundup.psfhosted.org>


New submission from Benjamin S Wolf <jokeserver at gmail.com>:

Positional-only arguments come before position-or-keyword arguments.

    def f(pos1, pos2, /, pos_or_kwd, *, kwd1, kwd2):

However, the posonlyargs are defined to come after args in the AST:

    arguments = (arg* args, arg* posonlyargs, arg? vararg, arg* kwonlyargs,
                 expr* kw_defaults, arg? kwarg, expr* defaults)

which results in confusing ast.dump output because they share defaults:

>>> r = ast.parse('lambda a=1,/,b=2:a+b', mode='eval')
>>> ast.dump(r.body.args)
"arguments(
    args=[arg(arg='b', annotation=None, type_comment=None)],
    posonlyargs=[arg(arg='a', annotation=None, type_comment=None)],
    vararg=None, kwonlyargs=[], kw_defaults=[], kwarg=None,
    defaults=[Constant(value=1, kind=None), Constant(value=2, kind=None)])"
[manually prettified]

Note how the ordering is 'args b', then 'posonlyargs a', but the defaults are still 1 then 2. This can be confusing to someone building an ast.arguments using keywords because the elements in 'defaults' have to be supplied in a specific order, but the keyword args 'args' and 'posonlyargs' do not, or to someone building an ast.arguments using positional arguments (because, maybe ironically, they're not keyword-only arguments) because 'posonlyargs' and 'args' must be supplied in a different order than the ordering of elements in 'defaults' would imply.

Potential solutions:
 1. Swap posonlyargs and args.
 2. Add a separate pos_defaults list.

----------
messages: 347932
nosy: Benjamin.S.Wolf
priority: normal
severity: normal
status: open
title: ast.arguments has confusing args/posonlyargs ordering
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37593>
_______________________________________

From report at bugs.python.org  Sun Jul 14 15:27:30 2019
From: report at bugs.python.org (brent s.)
Date: Sun, 14 Jul 2019 19:27:30 +0000
Subject: [New-bugs-announce] [issue37594] re does not honor matching
 trailing multiple periods
Message-ID: <1563132450.99.0.557456146194.issue37594@roundup.psfhosted.org>


New submission from brent s. <brent.saner at gmail.com>:

(Sorry for the title; not quite sure how to summarize this)

SO! Have I got an interesting one for you.

ISSUE:
In release 3.7.3 (and possibly later), the re module, if one has a string e.g. 'a.b.', a pattern such as '\.*$' will successfully *match* any number of multiple trailing periods. HOWEVER, when attempting to substitute those with actual character(s), it chokes. See attached poc.py

NOTES:
- This *is a regression* from 2.6.6, 2.7.16, and 3.6.7 (other releases were not tested). This behaviour does not occur on those versions.

----------
components: Library (Lib)
files: example.py
messages: 347933
nosy: bsaner
priority: normal
severity: normal
status: open
title: re does not honor matching trailing multiple periods
versions: Python 3.7
Added file: https://bugs.python.org/file48481/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37594>
_______________________________________

From report at bugs.python.org  Sun Jul 14 21:46:39 2019
From: report at bugs.python.org (Kal Sze)
Date: Mon, 15 Jul 2019 01:46:39 +0000
Subject: [New-bugs-announce] [issue37595] Python 3.7.4 does not build on
 Raspbian Buster
Message-ID: <1563155199.46.0.613653313897.issue37595@roundup.psfhosted.org>


New submission from Kal Sze <swordangel at gmail.com>:

Like the title says.

Tried building with these `configure` options:

    --enable-optimizations \
    --with-lto \
    --enable-shared \
    --enable-loadable-sqlite-extensions \
    --enable-ipv6 \
    --with-system-expat \
    --with-system-ffi \
    --with-system-libmpdec \
    --with-doc-strings \
    --with-pymalloc \
    --with-c-locale-coercion \
    --with-ensurepip=upgrade

And `CFLAGS="-O3 -march=native"`

But got this error message:

```
/usr/bin/ld: ./libpython3.7m.so: undefined reference to `__gcov_pow2_profiler_atomic'
/usr/bin/ld: ./libpython3.7m.so: undefined reference to `__gcov_average_profiler_atomic'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:733: Programs/_testembed] Error 1
make[3]: Leaving directory '/tmp/python-build.20190712163526.2762/Python-3.7.4'
make[2]: *** [Makefile:521: build_all_generate_profile] Error 2
make[2]: Leaving directory '/tmp/python-build.20190712163526.2762/Python-3.7.4'
make[1]: *** [Makefile:497: profile-gen-stamp] Error 2
make[1]: Leaving directory '/tmp/python-build.20190712163526.2762/Python-3.7.4'
make: *** [Makefile:509: profile-run-stamp] Error 2
```

----------
components: Build
files: python-build.20190711104717.24526.log
messages: 347948
nosy: kal.sze
priority: normal
severity: normal
status: open
title: Python 3.7.4 does not build on Raspbian Buster
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file48482/python-build.20190711104717.24526.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37595>
_______________________________________

From report at bugs.python.org  Mon Jul 15 11:05:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jul 2019 15:05:11 +0000
Subject: [New-bugs-announce] [issue37596] Reproducible pyc: frozenset is not
 serialized in a deterministic order
Message-ID: <1563203111.95.0.786255267379.issue37596@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

See bpo-29708 meta issue and https://reproducible-builds.org/ for reproducible builds.

pyc files are not fully reproducible yet: frozenset items are not serialized in a deterministic order

One solution would be to modify marshal to sort frozenset items before serializing them. The issue is how to handle items which cannot be compared. Example:

>>> l=[float("nan"), b'bytes', 'unicode']
>>> l.sort()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '<' not supported between instances of 'bytes' and 'float'

One workaround for types which cannot be compared is to use the type name in the key used to compare items:

>>> l.sort(key=lambda x: (type(x).__name__, x))
>>> l
[b'bytes', nan, 'unicode']

Note: comparison between bytes and str raises a BytesWarning exception when using python3 -bb.

Second problem: how to handle exceptions when comparison raises an error anyway?


Another solution would be to use the PYTHONHASHSEED environment variable. For example, if SOURCE_DATE_EPOCH is set, PYTHONHASHSEED would be set to 0. This option is not my favorite because it disables a security fix against denial of service on dict and set:
https://python-security.readthedocs.io/vuln/hash-dos.html

--

Previous discussions on reproducible frozenset:

* https://mail.python.org/pipermail/python-dev/2018-July/154604.html
* https://bugs.python.org/issue34093#msg321523

See also bpo-34093: "Reproducible pyc: FLAG_REF is not stable" and PEP 552 "Deterministic pycs".

----------
components: Interpreter Core
messages: 347969
nosy: vstinner
priority: normal
severity: normal
status: open
title: Reproducible pyc: frozenset is not serialized in a deterministic order
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37596>
_______________________________________

From report at bugs.python.org  Mon Jul 15 12:34:23 2019
From: report at bugs.python.org (Julien Palard)
Date: Mon, 15 Jul 2019 16:34:23 +0000
Subject: [New-bugs-announce] [issue37597] audit event table breaks PDF
 sphinx build
Message-ID: <1563208463.4.0.49055543405.issue37597@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

The following commit:

    44f91c388a6f4da9ed3300df32ca290b8aa104ea
    bpo-37390: Add audit event table to documentations (GH-14406)

    Also updates some (unreleased) event names to be consistent with the others.

breaks PDF builds.

Reproductible using:

    (cd Doc; sphinx-build -b latex -d build/doctrees -D latex_elements.papersize=a4 -D latex_engine=xelatex -D latex_elements.inputenc= -D latex_elements.fontenc=\\\\usepackage{xeCJK} -Ea -A daily=1 -A switchers=1  . build/latex)

The exception raised is "NoUri", I patched sphinx [1] to add a few info, so it is a "sphinx.errors.NoUri: c-api/code".



[1]: https://github.com/sphinx-doc/sphinx/pull/6583/files

----------
messages: 347980
nosy: christian.heimes, mdk, steve.dower
priority: normal
severity: normal
status: open
title: audit event table breaks PDF sphinx build

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37597>
_______________________________________

From report at bugs.python.org  Mon Jul 15 13:11:21 2019
From: report at bugs.python.org (Andrew Carter)
Date: Mon, 15 Jul 2019 17:11:21 +0000
Subject: [New-bugs-announce] [issue37598] Don't use _ as a function name in
 logging documentation cookbook
Message-ID: <1563210681.88.0.786597036054.issue37598@roundup.psfhosted.org>


New submission from Andrew Carter <andrewcarter1992 at gmail.com>:

Current docs link: https://docs.python.org/3/howto/logging-cookbook.html#implementing-structured-logging

GitHub commit link: https://github.com/python/cpython/commit/4b88d6c6642450240a9dc22e6efbdc69baf890dd

The suggestion is that for structured logging, a StructuredMessage class should be created with a __str__ method defined and then assigned to an _ variable and used as a logging formatter.

As the _ variable is commonly used as a "skip variable" and it has other meanings inside the Python interactive shell - I recommend that this example is changed to one that maybe just defines a simple wrapper function.

I'm happy to create a PR for this - but only if there's agreement that it's worthwhile and will get merged if suitable.

Thanks,

Andrew

----------
assignee: docs at python
components: Documentation
messages: 347984
nosy: AndrewCarterUK, docs at python
priority: normal
severity: normal
status: open
title: Don't use _ as a function name in logging documentation cookbook
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37598>
_______________________________________

From report at bugs.python.org  Mon Jul 15 16:39:43 2019
From: report at bugs.python.org (sgal)
Date: Mon, 15 Jul 2019 20:39:43 +0000
Subject: [New-bugs-announce] [issue37599] Remove a vague statement in
 documentation of Integer Objects
Message-ID: <1563223183.58.0.391676175993.issue37599@roundup.psfhosted.org>


New submission from sgal <chromezh at outlook.com>:

In current Python document (3.7 - 3.9) there is such statement in documentation of Integer Objects:

The current implementation keeps an array of integer objects for all integers between ``-5`` and ``256``, when you create an int in that range you actually just get back a reference to the existing object. So it should be possible to change the value of ``1``.  I suspect the behaviour of Python in this case is undefined. :-)

The last sentence is vague. It is irresponsible to write "I suspect" in documentation. And as the statements ahead has already clarified the sense that this is "a current implementation", the last sentence should be removed.

----------
assignee: docs at python
components: Documentation
messages: 347990
nosy: docs at python, sgal
priority: normal
severity: normal
status: open
title: Remove a vague statement in documentation of Integer Objects
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37599>
_______________________________________

From report at bugs.python.org  Mon Jul 15 17:08:09 2019
From: report at bugs.python.org (wesinator)
Date: Mon, 15 Jul 2019 21:08:09 +0000
Subject: [New-bugs-announce] [issue37600] sched_getaffinity() is missing -
 module 'os' has no attribute 'sched_getaffinity'
Message-ID: <1563224889.65.0.0527195323011.issue37600@roundup.psfhosted.org>


New submission from wesinator <13hurdw at gmail.com>:

Python 3.7.4 macOS 10.14.5 (homebrew) 

According to https://docs.python.org/3/library/os.html#os.cpu_count , there is a method `os.sched_getaffinity()` (https://docs.python.org/3/library/os.html#os.sched_getaffinity)

Code to reproduce :
 - 
```
import os
len(os.sched_getaffinity(0))
```


Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'os' has no attribute 'sched_getaffinity'

----------
components: Library (Lib)
messages: 347991
nosy: wesinator
priority: normal
severity: normal
status: open
title: sched_getaffinity() is missing - module 'os' has no attribute 'sched_getaffinity'
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37600>
_______________________________________

From report at bugs.python.org  Mon Jul 15 20:15:38 2019
From: report at bugs.python.org (Kevin Teague)
Date: Tue, 16 Jul 2019 00:15:38 +0000
Subject: [New-bugs-announce] [issue37601] shutil.make_archive does not
 follow symlinks for zip archives
Message-ID: <1563236138.18.0.17460405679.issue37601@roundup.psfhosted.org>


New submission from Kevin Teague <kevin.t.waterbear.cloud at gmail.com>:

Zip archives created with shutil.make_archive will not follow symlinks.

The shutil._make_zipfile uses os.walk:

    for dirpath, dirnames, filenames in os.walk(base_dir)

os.walk has the followlinks parameter:

    for dirpath, dirnames, filenames in os.walk(base_dir, followlinks=True)

Setting followlinks to True will include symlinks in a zip archive.

Could a followlinks parameter be added to shutil.make_archive?

----------
components: Library (Lib)
messages: 347996
nosy: Kevin Teague
priority: normal
severity: normal
status: open
title: shutil.make_archive does not follow symlinks for zip archives
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37601>
_______________________________________

From report at bugs.python.org  Tue Jul 16 01:30:27 2019
From: report at bugs.python.org (=?utf-8?b?5b6Q6Z2W?=)
Date: Tue, 16 Jul 2019 05:30:27 +0000
Subject: [New-bugs-announce] [issue37602] nonzero fixer problem
Message-ID: <1563255027.06.0.811777029402.issue37602@roundup.psfhosted.org>


New submission from ?? <shiyuchongf at gmail.com>:

An easy problem.
It seems like nonzero fixer can only fix definition, not usage. nonzero fixer cannot fix problems like below:
 a = 1
 a.__nonzero__()
And there are no cases of __nonzero__() usage in test cases from test_fixers.py.(all cases test only definition rename)
It might not be a bug, since in DOC it just says "rename", not "convert". (If it is not a bug, the doc must be considered to be kinds of confusing and should add additional description.)but adding this automatic transformation is really useful in my current work, so at least an optional fixer is needed for 2to3.
A fixer of __oct__(),__hex__() to oct(),hex() is also in need, but 2to3 lacks such fixer.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 348002
nosy: shiyuchong
priority: normal
severity: normal
status: open
title: nonzero fixer problem
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37602>
_______________________________________

From report at bugs.python.org  Tue Jul 16 05:52:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jul 2019 09:52:21 +0000
Subject: [New-bugs-announce] [issue37603] parsetok(): Assertion
 `(intptr_t)(int)(a - line_start) == (a - line_start)' failed,
 when running get-pip.py
Message-ID: <1563270741.47.0.416934432776.issue37603@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

bpo-16806 introduced a regression with the following change:

commit 995d9b92979768125ced4da3a56f755bcdf80f6e (refs/bisect/bad)
Author: Anthony Sottile <asottile at umich.edu>
Date:   Sat Jan 12 20:05:13 2019 -0800

    bpo-16806: Fix `lineno` and `col_offset` for multi-line string tokens (GH-10021)

get-pip.py does now crash:

$ ./python get-pip.py --help
python: Parser/parsetok.c:266: parsetok: Assertion `(intptr_t)(int)(a - line_start) == (a - line_start)' failed.
Aborted (core dumped)

Python 3.8 is also affected.

get-pip.py comes from: https://bootstrap.pypa.io/get-pip.py

Reproducing depends if REALLOC() returns a new pointer, see below.

I attached get-pip2.py: simplified version which crash when using "./python get-pip2.py --help". If it doesn't crash, duplicate lines to make the file larger.

--

The root issue seems to be that tok->multi_line_start isn't updated on REALLOC() in tok_nextc():

                newbuf = (char *)PyMem_REALLOC(newbuf,
                                               newsize);
                if (newbuf == NULL) {
                    tok->done = E_NOMEM;
                    tok->cur = tok->inp;
                    return EOF;
                }
                tok->buf = newbuf;
                tok->cur = tok->buf + cur;
                tok->line_start = tok->cur;

I guess that multi_line_start should also be updated there?

                tok->multi_line_start = tok->cur;

----------
components: Interpreter Core
keywords: 3.8regression
messages: 348008
nosy: lukasz.langa, vstinner
priority: release blocker
severity: normal
status: open
title: parsetok(): Assertion `(intptr_t)(int)(a - line_start) == (a - line_start)' failed, when running get-pip.py
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37603>
_______________________________________

From report at bugs.python.org  Tue Jul 16 09:24:57 2019
From: report at bugs.python.org (Thomas Grainger)
Date: Tue, 16 Jul 2019 13:24:57 +0000
Subject: [New-bugs-announce] [issue37604] warnings should use a ContextVar
 to manage filters/registry
Message-ID: <1563283497.67.0.626244687635.issue37604@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

this would allow ``warnings.catch_warnings`` to be threadsafe

----------
messages: 348015
nosy: graingert
priority: normal
severity: normal
status: open
title: warnings should use a ContextVar to manage filters/registry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37604>
_______________________________________

From report at bugs.python.org  Tue Jul 16 11:49:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 16 Jul 2019 15:49:35 +0000
Subject: [New-bugs-announce] [issue37605] CI should not depend on gmane
 response
Message-ID: <1563292175.7.0.185090199306.issue37605@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

On Travis, 'Documentation tests' passing is apparently required.  Line 23 of nntplib.rst is ">>> s = NNTP('news.gmane.org')"  I use gmane and occasional failures to respond are routine.  Being able to merge should not depend on this external site.

In addition to a real failure, the following happen on PR 14675 earlier today.

https://travis-ci.org/python/cpython/jobs/559289634

Warning, treated as error:
**********************************************************************
File "library/nntplib.rst", line ?, in default
Failed example:
    s = NNTP('news.gmane.org')
Exception raised:
    Traceback (most recent call last):
      File "/home/travis/build/python/cpython/Lib/doctest.py", line 1328, in __run
        exec(compile(example.source, filename, "single",
      File "<doctest default[0]>", line 1, in <module>
        s = NNTP('news.gmane.org')
      File "/home/travis/build/python/cpython/Lib/nntplib.py", line 1050, in __init__
        _NNTPBase.__init__(self, file, host,
      File "/home/travis/build/python/cpython/Lib/nntplib.py", line 331, in __init__
        self.welcome = self._getresp()
      File "/home/travis/build/python/cpython/Lib/nntplib.py", line 456, in _getresp
        raise NNTPTemporaryError(resp)
    nntplib.NNTPTemporaryError: 400 load at 16.59, try later

Try later is what I do.  This exception should somehow be skipped.  I don't know anything about Travis and doctest tests and how flakey doctests are supposed to be handled. If nothing else, put the whole example is a try-except block?

>>> try:  # News sites can fail to respond.
...     s = NNTP('news.gmane.org')
...     ...
... except: # If site failure, try later.
...     pass

Since output varies, I presume output checking is suppressed.

----------
components: Tests
messages: 348023
nosy: pablogsal, terry.reedy, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: CI should not depend on gmane response
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37605>
_______________________________________

From report at bugs.python.org  Tue Jul 16 12:23:04 2019
From: report at bugs.python.org (hai shi)
Date: Tue, 16 Jul 2019 16:23:04 +0000
Subject: [New-bugs-announce] [issue37606] Improve test_dtrace.py
Message-ID: <1563294184.02.0.420310265228.issue37606@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

$ ./python -m unittest test.test_dtrace
ssssE
======================================================================
ERROR: setUpClass (test.test_dtrace.TraceTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shihai/workspace/cpython/Lib/test/test_dtrace.py", line 110, in setUpClass
    self.backend.assert_usable()
AttributeError: 'NoneType' object has no attribute 'assert_usable'

----------------------------------------------------------------------
Ran 0 tests in 0.008s

FAILED (errors=1, skipped=4)

----------
components: Tests
messages: 348029
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Improve test_dtrace.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37606>
_______________________________________

From report at bugs.python.org  Tue Jul 16 12:56:43 2019
From: report at bugs.python.org (wesinator)
Date: Tue, 16 Jul 2019 16:56:43 +0000
Subject: [New-bugs-announce] [issue37607] segfault running code in jupyter
 on macOS 10.14.5 - crashed on child side of fork pre-exec
Message-ID: <1563296203.64.0.981111226039.issue37607@roundup.psfhosted.org>


New submission from wesinator <13hurdw at gmail.com>:

python 3.7.4 (homebrew) macOS 10.14.5
16 GB DDR4

segfault encountered when running test code in jupyter. 

Application Specific Information:
crashed on child side of fork pre-exec

I'm not in a position to share the code unfortunately, but I can say it was running multiple iterations of subprocess.Popen() within a multiprocessing Pool using os.cpu_count() / 2 number of processes (in this case 12/2 = 6). 


macOS .crash dump file attached

----------
components: macOS
files: Python_2019-07-16-123850_MacBook-Pro.crash
messages: 348032
nosy: ned.deily, ronaldoussoren, wesinator
priority: normal
severity: normal
status: open
title: segfault running code in jupyter on macOS 10.14.5 - crashed on child side of fork pre-exec
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48487/Python_2019-07-16-123850_MacBook-Pro.crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37607>
_______________________________________

From report at bugs.python.org  Wed Jul 17 06:23:49 2019
From: report at bugs.python.org (=?utf-8?b?5b6Q6Z2W?=)
Date: Wed, 17 Jul 2019 10:23:49 +0000
Subject: [New-bugs-announce] [issue37608] _thread: acquire_lock,
 release_lock still in use while declared to be "gone" in
 Documentation
Message-ID: <1563359029.55.0.364710956162.issue37608@roundup.psfhosted.org>


New submission from ?? <shiyuchongf at gmail.com>:

In https://docs.python.org/3/whatsnew/3.0.html#library-changes Documentation, it said "Cleanup of the thread module: acquire_lock() and release_lock() are gone; use acquire() and release() instead."
But in 3.7, I can still find 
{"acquire_lock", (PyCFunction)(void(*)(void))lock_PyThread_acquire_lock,
     METH_VARARGS | METH_KEYWORDS, acquire_doc},
in _threadmodule.c line 217, which defined this function. And in my code ,these functions work, without any warning or error.
So maybe the Documentation should be changed, or the support of these functions should be removed, or at least add a warning.
It has no effect on code, but truly confusing and waste me an hour to search for why.

----------
assignee: docs at python
components: Documentation
messages: 348053
nosy: docs at python, shiyuchong
priority: normal
severity: normal
status: open
title: _thread: acquire_lock,release_lock still in use while declared to be "gone" in Documentation
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37608>
_______________________________________

From report at bugs.python.org  Wed Jul 17 07:26:34 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 17 Jul 2019 11:26:34 +0000
Subject: [New-bugs-announce] [issue37609] support "UNC" device paths in
 ntpath.splitdrive
Message-ID: <1563362794.09.0.456380769613.issue37609@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

Windows Python includes UNC shares such as "//server/spam" in its definition of a drive. This is natural because Windows supports setting a UNC path as the working directory and handles the share component as the working drive when resolving rooted paths such as "/eggs". For the sake of generality when working with \\?\ extended paths, Python should expand its definition of a UNC drive to include "UNC" device paths.

A practical example is calling glob.glob with a "//?/UNC" device path.

    >>> import os, sys, glob
    >>> sys.addaudithook(lambda s,a: print('#', a[0]) if s == 'glob.glob' else None)

regular UNC path:

    >>> glob.glob('//localhost/C$/Sys*')
    # //localhost/C$/Sys*
    ['//localhost/C$/System Volume Information']

"UNC" device path:

    >>> glob.glob('//?/UNC/localhost/C$/Sys*')
    # //?/UNC/localhost/C$/Sys*
    # //?/UNC/localhost/C$
    # //?/UNC/localhost
    # //?/UNC/
    []

Since the magic character "?" is in the path (IMO, the drive should be excluded from this check, but that's a separate issue), the internal function glob._iglob calls itself recursively until it reaches the base case of dirname == pathname, where dirname is from os.path.split(pathname). The problem here is that ntpath.split doesn't stop at the proper base case of "//?/UNC/localhost/C$". This is due to ntpath.splitdrive. For example:

    >>> os.path.splitdrive('//?/UNC/localhost/C$/Sys*')
    ('//?/UNC', '/localhost/C$/Sys*')

    >>> os.path.splitdrive('//./UNC/localhost/C$/Sys*')
    ('//./UNC', '/localhost/C$/Sys*')

The results should be "//?/UNC/localhost/C$" and "//./UNC/localhost/C$". 

In other cases, returning a device as the drive is fine, if not exactly meaningful (e.g. "//./NUL"). I don't think this needs to change.

----------
components: Library (Lib), Windows
messages: 348055
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: support "UNC" device paths in ntpath.splitdrive
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37609>
_______________________________________

From report at bugs.python.org  Wed Jul 17 13:26:10 2019
From: report at bugs.python.org (Mariatta)
Date: Wed, 17 Jul 2019 17:26:10 +0000
Subject: [New-bugs-announce] [issue37610] Improve "Python Usage and Setup"
 documentation re: Editors & IDE
Message-ID: <1563384370.32.0.18026893098.issue37610@roundup.psfhosted.org>


New submission from Mariatta <mariatta at python.org>:

The Python Usage and Setup documentation lists how to use Python in different environments: 
1. command line
2. Unix
3. Windows
4. MacOS

Under "Unix" environment there is a section for Editors and IDE, which actually links to external links like https://wiki.python.org/moin/PythonEditors that has more comprehensive list of editors across various platforms.

It would be great if the Editors & IDE section is not tied to the "Unix environment" section, which might got skipped if the reader is a Windows or Mac user. There are IDEs and Editors for those platforms too!

----------
assignee: docs at python
components: Documentation
messages: 348074
nosy: Mariatta, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve "Python  Usage and Setup" documentation re: Editors & IDE
type: enhancement
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37610>
_______________________________________

From report at bugs.python.org  Wed Jul 17 13:42:36 2019
From: report at bugs.python.org (Mariatta)
Date: Wed, 17 Jul 2019 17:42:36 +0000
Subject: [New-bugs-announce] [issue37611] Improve the "Dealing with Bugs"
 documentation, include guidelines on how to report bugs
Message-ID: <1563385356.62.0.425073313065.issue37611@roundup.psfhosted.org>


New submission from Mariatta <mariatta at python.org>:

On the left of docs.python.org, is a link to "Report a Bug", which takes you to "Dealing with Bugs" section (https://docs.python.org/3/bugs.html)

One of the first few paragraphs of the page is telling people that documentation bugs can be reported at the bug tracker, or if they're short on time, it can be emailed to docs at python.org. 

The next section is talking about "using issue tracker", and at the very bottom are two links to external resources about how to report bugs effectively and bug reporting guidelines.

1. It would be great if the guidelines are at the top, instead of the bottom.

2. It would be great if we provide our own set of guidelines, instead of linking to external resources.

I think the guidelines are especially important for people who opted to write an email instead of creating an issue in bpo. In bpo, user is kinda restricted/reminded to select a specific type/component, but writing email can be more freeform. The better email they write, the easier it is for us to respond to them.

----------
assignee: docs at python
components: Documentation
messages: 348077
nosy: Mariatta, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve the "Dealing with Bugs" documentation, include guidelines on how to report bugs
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37611>
_______________________________________

From report at bugs.python.org  Wed Jul 17 19:04:55 2019
From: report at bugs.python.org (Jo Henke)
Date: Wed, 17 Jul 2019 23:04:55 +0000
Subject: [New-bugs-announce] [issue37612] os.link(...,
 follow_symlinks=True) broken on Linux
Message-ID: <1563404695.9.0.284402565462.issue37612@roundup.psfhosted.org>


New submission from Jo Henke <free.software at gmx.com>:

Regarding link() POSIX states (https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html):

  "If path1 names a symbolic link, it is implementation-defined whether link() follows the symbolic link, or creates a new link to the symbolic link itself."

In Linux, link() does _not_ follow symlinks (http://man7.org/linux/man-pages/man2/link.2.html):

  "By default, linkat(), does not dereference oldpath if it is a symbolic link (like link())."

But Python 3 assumes the opposite to be always the case:

  https://github.com/python/cpython/blob/8cb65d1381b027f0b09ee36bfed7f35bb4dec9a9/Modules/posixmodule.c#L3517

...which suits e.g. NetBSD (https://netbsd.gw.com/cgi-bin/man-cgi?link+2):

  "When operating on a symlink, link() resolves the symlink and creates a hard link on the target."


Therefore, I recommend to always call linkat(), if the platform provides it. That's the modern superset of link() with clearly defined behavior.


Here are some commands to reproduce the issue on Linux (should hard link 'file' -> 'link', but tries '/tmp/symlink' -> 'link'):

~$ : >file
~$ ln -s "$PWD/file" /tmp/symlink
~$ strace -e link,linkat python -c 'import os; os.link("/tmp/symlink", "link", follow_symlinks=True)'
link("/tmp/symlink", "link")            = -1 EXDEV (Cross-device link)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 18] Cross-device link: '/tmp/symlink' -> 'link'
+++ exited with 1 +++


For comparison, calling linkat() without AT_SYMLINK_FOLLOW results in the same error:

~$ strace -e link,linkat python -c 'import os; os.link("/tmp/symlink", "link", follow_symlinks=False)'
linkat(AT_FDCWD, "/tmp/symlink", AT_FDCWD, "link", 0) = -1 EXDEV (Cross-device link)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 18] Cross-device link: '/tmp/symlink' -> 'link'
+++ exited with 1 +++


Currently, the only way to call linkat() with AT_SYMLINK_FOLLOW from Python, is to provide a directory file descriptor != AT_FDCWD:

~$ strace -e link,linkat python -c 'import os; d=os.open(".", 0); os.link("/tmp/symlink", "link", dst_dir_fd=d, follow_symlinks=True)'
linkat(AT_FDCWD, "/tmp/symlink", 3, "link", AT_SYMLINK_FOLLOW) = 0
+++ exited with 0 +++

----------
components: Library (Lib)
messages: 348086
nosy: jo-he
priority: normal
severity: normal
status: open
title: os.link(..., follow_symlinks=True) broken on Linux
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37612>
_______________________________________

From report at bugs.python.org  Wed Jul 17 19:38:54 2019
From: report at bugs.python.org (Giovanni Cappellotto)
Date: Wed, 17 Jul 2019 23:38:54 +0000
Subject: [New-bugs-announce] [issue37613] Fix broken "Back to top" link in
 www.python.org (mobile)
Message-ID: <1563406734.28.0.0957616376882.issue37613@roundup.psfhosted.org>


New submission from Giovanni Cappellotto <potomak84 at gmail.com>:

The mobile version of https://www.python.org/ has a "Back to top" link at the bottom of every page that should scroll the page back to the top, but it doesn't work in Chrome for Android.

Note: it works with Safari on iOS.

----------
assignee: docs at python
components: Documentation
messages: 348087
nosy: docs at python, potomak
priority: normal
severity: normal
status: open
title: Fix broken "Back to top" link in www.python.org (mobile)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37613>
_______________________________________

From report at bugs.python.org  Thu Jul 18 00:40:49 2019
From: report at bugs.python.org (Colby Reeves)
Date: Thu, 18 Jul 2019 04:40:49 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue37614=5D_Pasteing_?=
 =?utf-8?q?=F0=9F=8C=B9into_idle_makes_it_crash?=
Message-ID: <1563424849.97.0.321788763811.issue37614@roundup.psfhosted.org>


New submission from Colby Reeves <reeves.colby.lee at gmail.com>:

Like the title says pasting ? (or U+1F339) into IDLE makes IDLE instantaneously crash.

----------
assignee: terry.reedy
components: IDLE
messages: 348095
nosy: Colby Reeves, terry.reedy
priority: normal
severity: normal
status: open
title: Pasteing ?into idle makes it crash
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37614>
_______________________________________

From report at bugs.python.org  Thu Jul 18 01:03:15 2019
From: report at bugs.python.org (Varun Agrawal)
Date: Thu, 18 Jul 2019 05:03:15 +0000
Subject: [New-bugs-announce] [issue37615] json - make load and dump work
 with filenames and path-like objects
Message-ID: <1563426195.91.0.749324402695.issue37615@roundup.psfhosted.org>


New submission from Varun Agrawal <varagrawal at gmail.com>:

Currently, json.load and json.dump take file pointers, aka file-like objects which have support for `.write()` and `.read()`. This necessitates the following pattern of code on a regular basis:

```
with open(filename) as f:
    o = json.load(f)
...
with open(filename, 'w') as f:
    json.dump(o, f)
```

While this is a fair pattern to live by, it would be nice for programmers to pass in the filename directly and let the functions handle opening and closing the file.

The way to do this would be to have a simple check if `fp` is a path-like object or a file-like object, and set up a context manager accordingly (using contextlib).
The original `load()` and `dump()` code definition can then be placed inside the context manager, which should make testing painless.

There might be an argument for this not being in alignment with duck-typing, but the overall benefits of this approach along with the ease afforded to programmers should make for a strong argument.

----------
components: Library (Lib)
messages: 348097
nosy: varunagrawal
priority: normal
severity: normal
status: open
title: json - make load and dump work with filenames and path-like objects
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37615>
_______________________________________

From report at bugs.python.org  Thu Jul 18 02:40:35 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 18 Jul 2019 06:40:35 +0000
Subject: [New-bugs-announce] [issue37616] [3.10 prep] zip path incorrect
Message-ID: <1563432035.85.0.841643784863.issue37616@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

In an effort to try and fix some of the ecosystem before python3.10 (or 4.0) is a thing, I figured I'd set up a build where the version is bumped and see what's broken.

If you're interested in reproducing my findings, I've included a build that's installable in ubuntu in this PPA: https://launchpad.net/~asottile/+archive/ubuntu/python3.10

It's mostly based on this patch: https://github.com/asottile/python3.10/blob/ubuntu/bionic/debian/patches/0029-pretend-3.10.patch

while tracking down why pip doesn't work, I've encountered the following from doing this:

$ python3.10 -c 'import sys; print(sys.path)'
['', '/usr/lib/python31.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/usr/lib/python3/dist-packages']


notably, the second `sys.path` entry appears incorrect and should probably be `/usr/lib/python310.zip`

this should be an easy fix:

https://github.com/python/cpython/blob/1b3892243433da7eae7f5f3a4f98f13d309c8926/Modules/getpath.c#L1019-L1028

----------
messages: 348100
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: [3.10 prep] zip path incorrect
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37616>
_______________________________________

From report at bugs.python.org  Thu Jul 18 02:41:34 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 18 Jul 2019 06:41:34 +0000
Subject: [New-bugs-announce] [issue37617] [3.10 prep] site.py uses
 `sys.version[:3]`
Message-ID: <1563432094.73.0.116899779699.issue37617@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

In an effort to try and fix some of the ecosystem before python3.10 (or 4.0) is a thing, I figured I'd set up a build where the version is bumped and see what's broken.

If you're interested in reproducing my findings, I've included a build that's installable in ubuntu in this PPA: https://launchpad.net/~asottile/+archive/ubuntu/python3.10

It's mostly based on this patch: https://github.com/asottile/python3.10/blob/ubuntu/bionic/debian/patches/0029-pretend-3.10.patch

while tracking down why pip doesn't work, I've encountered the following from doing this:

$ python3.10 -c 'import sys; print(sys.path)'
['', '/usr/lib/python31.zip', '/usr/lib/python3.10', '/usr/lib/python3.10/lib-dynload', '/usr/lib/python3/dist-packages']


this notably is missing the versioned site-packages / dist-packages directory

----------
messages: 348101
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: [3.10 prep] site.py uses `sys.version[:3]`
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37617>
_______________________________________

From report at bugs.python.org  Thu Jul 18 03:42:29 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 18 Jul 2019 07:42:29 +0000
Subject: [New-bugs-announce] [issue37618] Docs: Code example locations in
 stdtypes
Message-ID: <1563435749.25.0.657684993159.issue37618@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

In the docs for the module stdtypes, the code example for several commonly used functions are in the bytearray section instead of the str section, where new users are far more likely to look. The new users are much more likely to benefit from seeing examples of these functions. A few examples of this include: islower(), isupper(), and istitle(). Since the functionality is very similar for functions such as str.islower() and bytearray.islower(), it doesn't seem necessary to include separate examples for each. With that in mind, here's a couple of potential solutions:

1) Move the location of the code examples to the str equivalent. This would require only removing the 'b' notation proceeding the strings. A link to the str equivalent could be potentially provided.

2) Provide a reference link to equivalent bytearray function in the str function's summary. This would be a bit easier since the code examples would not have to me modified or moved. However, for reasons stated above, it seems to make a bit more sense to have the examples be in the str functions rather than in the bytearray functions.

I can start working on a PR to address this, but I'll wait on some feedback first.

----------
assignee: docs at python
components: Documentation
messages: 348104
nosy: aeros167, docs at python
priority: normal
severity: normal
status: open
title: Docs: Code example locations in stdtypes
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37618>
_______________________________________

From report at bugs.python.org  Thu Jul 18 05:04:18 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 18 Jul 2019 09:04:18 +0000
Subject: [New-bugs-announce] [issue37619] update_one_slot() should not
 ignore wrapper descriptors for wrong type
Message-ID: <1563440658.46.0.882912152625.issue37619@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

>>> class S(str):
...     __eq__ = int.__eq__
>>> S() == S()
True

The expectation is that this raises an exception because int.__eq__() is called on S instances.

----------
components: Interpreter Core
messages: 348108
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: update_one_slot() should not ignore wrapper descriptors for wrong type
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37619>
_______________________________________

From report at bugs.python.org  Thu Jul 18 09:59:00 2019
From: report at bugs.python.org (Harry Coin)
Date: Thu, 18 Jul 2019 13:59:00 +0000
Subject: [New-bugs-announce] [issue37620] str.split(sep=None, maxsplit=-1,
 any=False)
Message-ID: <1563458340.3.0.354346385459.issue37620@roundup.psfhosted.org>


New submission from Harry Coin <hgcoin at gmail.com>:

When first I read the str.split documentation I parsed it to mean
'ab\t cd ef'.split(sep=' \t') --> ['ab','cd','ef']
Especially as the given example in the docs with the <> would have led to the given result read the way I read it.

I suggest adding a parameter 'any=False' which by default gives the current behavior.  But when True treats each character in the sep string as a delimiter and eliminates any combination of them from the resulting list.

The use cases are many, for example parsing the /etc/hosts file where we see an address, some white space that could be any combination of \t and ' ' followed by more text. 

One could imagine 'abc  \tdef, hgi,jlk'.split(', \t',any=True) -> ['abc','def','hgi','jlk'] being used quite often.

----------
components: Library (Lib)
messages: 348116
nosy: hcoin
priority: normal
severity: normal
status: open
title: str.split(sep=None, maxsplit=-1,any=False)
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37620>
_______________________________________

From report at bugs.python.org  Thu Jul 18 10:13:50 2019
From: report at bugs.python.org (=?utf-8?q?Dominik_Miedzi=C5=84ski?=)
Date: Thu, 18 Jul 2019 14:13:50 +0000
Subject: [New-bugs-announce] [issue37621] Line continuation of blank line
 emits NEWLINE
Message-ID: <1563459230.52.0.916101188848.issue37621@roundup.psfhosted.org>


New submission from Dominik Miedzi?ski <dominik at mdzn.pl>:

Both C and Python tokenizers emit NEWLINE tokens on continued blank lines. Because of this it is possible to emit repeated NEWLINEs, which some tools don't expect to happen.

I've attached example source file which is tokenized into 3 NEWLINE tokens in a row.

----------
components: Interpreter Core
files: linecont.py
messages: 348117
nosy: miedzinski
priority: normal
severity: normal
status: open
title: Line continuation of blank line emits NEWLINE
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48488/linecont.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37621>
_______________________________________

From report at bugs.python.org  Thu Jul 18 10:44:19 2019
From: report at bugs.python.org (Dodain)
Date: Thu, 18 Jul 2019 14:44:19 +0000
Subject: [New-bugs-announce] [issue37622] Signature of SHA256 HMAC digest
 not matching with the signature of jwt library
Message-ID: <1563461059.89.0.239374018192.issue37622@roundup.psfhosted.org>


New submission from Dodain <moizimtiaz1 at gmail.com>:

The signature (SHA256 of HMAC Digest) calculated using hmac library doesn't match the signature calculated using jwt library. The singature calculated using JWT is the right signature.

The signature with JWT library is VXG8L0SEY3wo5hdAznbvxWXDbhNtuOd7PaZOhzZn_HQ

Whereas the signature with hmac library is 
SHR3SSe+8+X8eBw/H+CUc6f5KyXmuONfprdttjeQrwQ=


Since only one file can bu attached so I am inlining the code for finding jwt signature with jwt library. The code for HMAC library is attached. 

import jwt
public = "1234"
print (public)
print jwt.encode({"login":"admin"}, key=public, algorithm='HS256')

----------
components: Library (Lib)
files: sign_with_hmac_library.py
messages: 348119
nosy: dodain
priority: normal
severity: normal
status: open
title: Signature of SHA256 HMAC digest not matching with the signature of jwt library
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file48489/sign_with_hmac_library.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37622>
_______________________________________

From report at bugs.python.org  Thu Jul 18 15:07:23 2019
From: report at bugs.python.org (Andrew Yurisich)
Date: Thu, 18 Jul 2019 19:07:23 +0000
Subject: [New-bugs-announce] [issue37623] namedtuple integration for
 importlib.abc.Loader
Message-ID: <1563476843.29.0.0326918684988.issue37623@roundup.psfhosted.org>


New submission from Andrew Yurisich <andrew.yurisich at nbx.com>:

I wanted to return a namedtuple from a concrete implementation of an importlib.abc.Loader base class, and wasn't able to provide a __spec__ property on the underlying class behind the namedtuple. All return values from importlib.abc.Loader#create_module need to have a __spec__ property set.

Similar to the namedtuple optional argument 'module', I'd like to be able to pass in a 'spec', and add this value to result.__spec__ before returning the final result.

----------
components: Library (Lib)
messages: 348124
nosy: Andrew Yurisich
priority: normal
severity: normal
status: open
title: namedtuple integration for importlib.abc.Loader
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37623>
_______________________________________

From report at bugs.python.org  Thu Jul 18 16:51:27 2019
From: report at bugs.python.org (Ted Whalen)
Date: Thu, 18 Jul 2019 20:51:27 +0000
Subject: [New-bugs-announce] [issue37624] random.choices has unexpected
 behavior with negative weights
Message-ID: <1563483087.67.0.502160957711.issue37624@roundup.psfhosted.org>


New submission from Ted Whalen <tewhalen at gmail.com>:

The behavior of random.choices when negative weights are provided is unexpected. While giving a negative weight for one value is probably bad, it's really unfortunate that providing a negative weight for one value affects the probability of selecting an adjacent value.

Throwing a ValueError exception when there was a use of negative weights was considered in #31689, but at that time, there wasn't an example provided that failed silently.

Note below that providing a weight of -1 for 'c' causes both 'c' and 'd' to drop out of the results.

Python 3.7.2 (default, Jan 13 2019, 12:50:01)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import Counter
>>> from random import choices
>>> Counter(choices("abcdefg", weights=(1,1,-1,1,1,1,1), k=10000))
Counter({'f': 2040, 'a': 2019, 'e': 2017, 'g': 2009, 'b': 1915})

----------
components: Library (Lib)
messages: 348128
nosy: Ted Whalen
priority: normal
severity: normal
status: open
title: random.choices has unexpected behavior with negative weights
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37624>
_______________________________________

From report at bugs.python.org  Thu Jul 18 17:55:14 2019
From: report at bugs.python.org (Daniel)
Date: Thu, 18 Jul 2019 21:55:14 +0000
Subject: [New-bugs-announce] [issue37625] Class variable is still accessible
 after class instance has been overwritten out
Message-ID: <1563486914.84.0.86753245558.issue37625@roundup.psfhosted.org>


New submission from Daniel <dan+pythonbug at moird.com>:

Not sure if this is the desired behavior but wanted to bring it up anyways.
When you have a class and have a variable in like:
class TestClass(object):
    variable = []

then you run it through a loop like:
for num in range(10):
    test = TestClass()
    test.variable.append(num)

even if you assign another variable to it or none like:
test = "blah"
test = None

then reassign the class:
test = TestClass()
print(test.variable)

will return all the numbers in the list.
also doesn't seem to matter if garbage collection was manually ran.

Attached is a small example code.
This was found on Macos and tested with both python 3.7 and 2.7 Subsequently same on ubuntu with python 3.5 and python 2.7

----------
components: Interpreter Core
files: variabletest.py
messages: 348130
nosy: moird
priority: normal
severity: normal
status: open
title: Class variable is still accessible after class instance has been overwritten out
type: behavior
versions: Python 2.7, Python 3.5, Python 3.7
Added file: https://bugs.python.org/file48490/variabletest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37625>
_______________________________________

From report at bugs.python.org  Thu Jul 18 23:39:04 2019
From: report at bugs.python.org (=?utf-8?b?5b6Q6Z2W?=)
Date: Fri, 19 Jul 2019 03:39:04 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue37626=5D_Documentation?=
 =?utf-8?q?=EF=BC=9Aconflict_between_docs?=
Message-ID: <1563507544.78.0.459809991855.issue37626@roundup.psfhosted.org>


Change by ?? <shiyuchongf at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, shiyuchong
priority: normal
severity: normal
status: open
title: Documentation?conflict between docs
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37626>
_______________________________________

From report at bugs.python.org  Fri Jul 19 03:26:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 19 Jul 2019 07:26:51 +0000
Subject: [New-bugs-announce] [issue37627] Minor improvements to IDLE's "Run
 Customized"
Message-ID: <1563521211.07.0.510212499932.issue37627@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Today, I did some user testing for the 3.8 beta when teaching the argparse module.  The new "Run Customized" option needs two usability tweaks.  1) Move the menu option up by one so that the regular F5 "run" is last -- learners we having a hard time finding and mouse targeting the more commonly used regular "run" option.  2)  The text input widget should be pre-populated with the most recently run command-line.  This makes it easier to test variants of the same command rather retyping it on every invocation.  Even more desirable would be to have a multi-command history, but in the absence of that an editable single command history would suffice.

----------
assignee: terry.reedy
components: IDLE
messages: 348149
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: Minor improvements to IDLE's "Run Customized"
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37627>
_______________________________________

From report at bugs.python.org  Fri Jul 19 03:32:32 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 19 Jul 2019 07:32:32 +0000
Subject: [New-bugs-announce] [issue37628] IDLE Font Sample distracting and
 too large
Message-ID: <1563521552.15.0.28406404437.issue37628@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The "font sample" bar on the General tab in Preferences is problematio.  With some font sizes, it grows so large that there is no way to mouse downward to click "accept".  Making the window smaller and perhaps only showing one or two samples would be a big win.

Also consider having the window off by default and having a button to turn make it visible.  I've need seen a single user benefit from this garish display.

----------
assignee: terry.reedy
components: IDLE
messages: 348150
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE Font Sample distracting and too large
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37628>
_______________________________________

From report at bugs.python.org  Fri Jul 19 05:50:28 2019
From: report at bugs.python.org (Pierre Chopin)
Date: Fri, 19 Jul 2019 09:50:28 +0000
Subject: [New-bugs-announce] [issue37629] Imghdr doesnt recognise some jpeg
Message-ID: <1563529828.49.0.547849955653.issue37629@roundup.psfhosted.org>


New submission from Pierre Chopin <pierre.chopin at chaintrust.io>:

the imghdr library only checks for the presence of (b'JFIF', b'Exif') in the header, which is excluding some valid JPEG file. This is an example of not recognised ile

----------
files: e2006bd7-51d7-4554-9738-ea13207fd104.jpg
messages: 348161
nosy: pchopin
priority: normal
severity: normal
status: open
title: Imghdr doesnt recognise some jpeg
versions: Python 3.7
Added file: https://bugs.python.org/file48491/e2006bd7-51d7-4554-9738-ea13207fd104.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37629>
_______________________________________

From report at bugs.python.org  Fri Jul 19 07:30:56 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Jul 2019 11:30:56 +0000
Subject: [New-bugs-announce] [issue37630] Investigate replacing SHA3 code
 with OpenSSL
Message-ID: <1563535856.49.0.726904541971.issue37630@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

Recent OpenSSL comes with SHA3. Now that Python is going to drop support for old OpenSSL, we can consider to use OpenSSL's SHA3 and drop the reference implementation from Python.

For variable length SHAKE API, OpenSSL added EVP_MD_CTRL_XOF_LEN and EVP_DigestFinalXOF().

----------
assignee: christian.heimes
components: Extension Modules
messages: 348165
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
status: open
title: Investigate replacing SHA3 code with OpenSSL
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37630>
_______________________________________

From report at bugs.python.org  Fri Jul 19 07:49:12 2019
From: report at bugs.python.org (Marcel Plch)
Date: Fri, 19 Jul 2019 11:49:12 +0000
Subject: [New-bugs-announce] [issue37631] EXTRA_CFLAGS get overrided by
 CFLAGS_NODIST
Message-ID: <1563536952.58.0.764226132067.issue37631@roundup.psfhosted.org>


New submission from Marcel Plch <mplch at redhat.com>:

Problem:
If you want to override CFLAGS by setting EXTRA_CFLAGS, they may have no effect if there are contrary flags in the CFLAGS_NODIST variable.

How to reproduce:
make CFLAGS_NODIST="-O2" EXTRA_CFLAGS="-Og"

If you look at GCC arguments, there is -O2 present *after* the -Og flag. This means -Og gets ignored.

----------
components: Build
messages: 348168
nosy: Dormouse759
priority: normal
severity: normal
status: open
title: EXTRA_CFLAGS get overrided by CFLAGS_NODIST
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37631>
_______________________________________

From report at bugs.python.org  Fri Jul 19 11:28:48 2019
From: report at bugs.python.org (=?utf-8?q?=C3=81kos_Tompos?=)
Date: Fri, 19 Jul 2019 15:28:48 +0000
Subject: [New-bugs-announce] [issue37632] generator expression doesn't find
 subclass
Message-ID: <1563550128.64.0.536864236908.issue37632@roundup.psfhosted.org>


New submission from ?kos Tompos <akos.brain at gmail.com>:

The following code does work on python 2.7 but fails on python 3.7. The code seems correct.

class A:
    class B:
        def __init__(self, param):
            self.param = param
        
    l = [B(i) for i in range(10)]

The result on:
3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit (AMD64)]

Traceback (most recent call last):
  File "test.py", line 6, in <module>
    class A:
  File "test.py", line 11, in A
    l = [B(i) for i in range(10)]
  File "test.py", line 11, in <listcomp>
    l = [B(i) for i in range(10)]
NameError: name 'B' is not defined

B can be accessed if not inside a generator expression

----------
messages: 348181
nosy: ?kos Tompos
priority: normal
severity: normal
status: open
title: generator expression doesn't find subclass
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37632>
_______________________________________

From report at bugs.python.org  Fri Jul 19 16:36:46 2019
From: report at bugs.python.org (PyScripter)
Date: Fri, 19 Jul 2019 20:36:46 +0000
Subject: [New-bugs-announce] [issue37633] Py_CompileString and
 PyParser_SimpleParseString not exported in python38.dll
Message-ID: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org>


New submission from PyScripter <pyscripter at gmail.com>:

Py_CompileString and PyParser_SimpleParseString and possibly other related functions are not exported in Python 3.8 b2 DLL.  This is unintentional, not documented and unnecessarily breaks backward compatibility.

Issue 37189 was similar and related to PyRun_String.  This was fixed in Python 3.8b2. Please provide fixes to the above two functions as well.  

To confirm the error:
>>> import ctypes
>>> api = ctypes.pythonapi
>>> hasattr(api, "PyParser_SimpleParseString")
False
>>> hasattr(api2, "Py_CompileString")
False

----------
components: Windows
messages: 348198
nosy: paul.moore, pyscripter, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Py_CompileString and PyParser_SimpleParseString not exported in python38.dll
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37633>
_______________________________________

From report at bugs.python.org  Fri Jul 19 19:02:26 2019
From: report at bugs.python.org (daniel hahler)
Date: Fri, 19 Jul 2019 23:02:26 +0000
Subject: [New-bugs-announce] [issue37634] doc: "module" of a warning might
 be its filename
Message-ID: <1563577346.06.0.11337043317.issue37634@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

With e.g. DeprecationWarnings for "invalid escape sequence" the "module" part is the file name (with ".py" removed), because it calls PyErr_WarnExplicitObject directly:
https://github.com/python/cpython/blob/3cba3d3c55f230a59174a0dfcafb1d4685269e60/Python/ast.c#L4668-L4692

While this properly cannot be fixed to have the module name (yet), it should at least be documented then.

With `warnings.warn` the module is set via `setup_context` (https://github.com/python/cpython/blob/3cba3d3c55f230a59174a0dfcafb1d4685269e60/Python/_warnings.c#L932-L933).

This conflicts with https://github.com/python/cpython/pull/9358 (issue34624), which enables the documented behavior to not escape the pattern there.

----------
components: Library (Lib)
messages: 348201
nosy: blueyed
priority: normal
severity: normal
status: open
title: doc: "module" of a warning might be its filename
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37634>
_______________________________________

From report at bugs.python.org  Sat Jul 20 00:00:23 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 20 Jul 2019 04:00:23 +0000
Subject: [New-bugs-announce] [issue37635] Using constant for whence arg in
 seek()
Message-ID: <1563595223.34.0.142119222061.issue37635@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

In Python 3.1, three constants were added to the IO module to be used for the whence argument of seek():

    SEEK_SET or 0 ? start of the stream
    SEEK_CUR or 1 ? current stream position
    SEEK_END or 2 ? end of the stream

However, there are at least 102 occurrences across CPython where the integer values are used instead. This only includes instances when a value for the whence arg is explicitly specified. All of the occurrences can be easily found with the usage of git grep:

git grep -E "seek\(-?[0-9]+, [0-2]\)"

This doesn't affect functionality in any way, but it would result in significant readability improvement if these were all replaced with constants. The only requirement would be importing IO or manually specifying the value of constants. 

For simplicity, I would probably start with anything that directly involves IO. The largest number of occurrences are in Lib/test/test_io, so that probably would be the best place to begin. Also, this module already imports io anyways, so it would be a straightforward find and replace. 

It would also be quite useful to make this change in the documentation, in Doc/tutorial/inputoutput there are 4 occurrences. If anything, anyone less familiar with the IO module in general would be the most likely to benefit from this change so modifying the tutorial would likely be the most useful change for the majority of users.

As a single example of what I'm talking about, here's line 334 of Lib/test/test_io:

self.assertEqual(f.seek(-1, 1), 5)

I would propose changing it to:

self.assertEqual(f.seek(-1, io.SEEK_CUR), 5)

----------
components: IO
messages: 348207
nosy: aeros167, benjamin.peterson, stutzbach
priority: normal
severity: normal
status: open
title: Using constant for whence arg in seek()
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37635>
_______________________________________

From report at bugs.python.org  Sat Jul 20 08:45:55 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Jul 2019 12:45:55 +0000
Subject: [New-bugs-announce] [issue37636] Deprecate slicing and ordering
 operations on sys.version
Message-ID: <1563626755.13.0.11799518747.issue37636@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

At the core dev sprints in 2017 (IIRC), Ezio and I were talking about some of the potential issues with 3.10, and one of them was folks attempting to manipulate sys.version with string operations rather than using the already decomposed sys.version info.

Anthony Sottile has recently been experimenting with a Python build patched to report itself as 3.10 to see what breaks, and indicated that many of the failures were due to that kind of problem (in particular: writing "sys.version[:3]" instead of "'{}.{}'.format(sys.version_info[:2])")

One possible remedy that Ezio and I discussed was the idea of an "OpaqueString" type that presented as a string, but raised an error if you tried any operations that assumed it could be meaningfully decomposed character-by-character.

This would probably need to be a string subclass for compatibility, and would need a transitional variant that only emitted deprecation warnings rather than failing outright.

----------
messages: 348213
nosy: ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate slicing and ordering operations on sys.version
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37636>
_______________________________________

From report at bugs.python.org  Sat Jul 20 14:11:38 2019
From: report at bugs.python.org (Benedikt Bieringer)
Date: Sat, 20 Jul 2019 18:11:38 +0000
Subject: [New-bugs-announce] [issue37637] multiprocessing numpy.ndarray not
 transmitted properly
Message-ID: <1563646298.52.0.224679939244.issue37637@roundup.psfhosted.org>


New submission from Benedikt Bieringer <2xB.coding at wwu.de>:

The following code demonstrates the issue:

import numpy as np
from multiprocessing import Pipe
p1, p2 = Pipe()
arr = np.zeros((3, 5, 6), dtype=np.uint8)
p2.send_bytes(arr)
pm = p1.recv_bytes()
print(pm)

Only 3 bytes are transmitted for this array which obviously consists of more than 3 bytes.

----------
components: Library (Lib)
messages: 348218
nosy: 2xB
priority: normal
severity: normal
status: open
title: multiprocessing numpy.ndarray not transmitted properly
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37637>
_______________________________________

From report at bugs.python.org  Sat Jul 20 21:55:19 2019
From: report at bugs.python.org (Tianming Zhuang)
Date: Sun, 21 Jul 2019 01:55:19 +0000
Subject: [New-bugs-announce] [issue37638] Having issues following build
 instructions
Message-ID: <1563674119.01.0.389894987814.issue37638@roundup.psfhosted.org>


New submission from Tianming Zhuang <abstract.wolf at gmail.com>:

Hi there. This is my first time trying to build python from source. I am following in structions here:
https://devguide.python.org/setup/#setup

I notice that after I build, I don't get a success message like the example shown:
https://gist.github.com/tmzhuang/aacc6bf798f28ed8b673af1be009a49f

(ie. I don't see "Python build finished successfully!")

The actual python binary is built. Running "./python -m test" runs until "test_socket" which repeated for around 3 hours (after which I killed it with ^C).

"uname -a": Linux jupiter-arch 5.2.1-arch1-1-ARCH #1 SMP PREEMPT Sun Jul 14 14:52:52 UTC 2019 x86_64 GNU/Linux

----------
components: Build
messages: 348225
nosy: Tianming Zhuang
priority: normal
severity: normal
status: open
title: Having issues following build instructions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37638>
_______________________________________

From report at bugs.python.org  Sun Jul 21 02:28:22 2019
From: report at bugs.python.org (Aymeric Augustin)
Date: Sun, 21 Jul 2019 06:28:22 +0000
Subject: [New-bugs-announce] [issue37639] What happened to
 StreamReaderProtocol?
Message-ID: <1563690502.8.0.178021194251.issue37639@roundup.psfhosted.org>


New submission from Aymeric Augustin <aymeric.augustin at m4x.org>:

`StreamReaderProtocol` was a public API from Python 3.4 to 3.6:

- https://docs.python.org/3.4/library/asyncio-stream.html?highlight=streamreaderprotocol#streamreaderprotocol
- https://docs.python.org/3.5/library/asyncio-stream.html?highlight=streamreaderprotocol#streamreaderprotocol
- https://docs.python.org/3.6/library/asyncio-stream.html?highlight=streamreaderprotocol#streamreaderprotocol

In Python 3.7, it vanished from the documentation. I couldn't find which commit made that change and why.

- https://docs.python.org/3.7/search.html?q=streamreaderprotocol&check_keywords=yes&area=default

Apparently it's deprecated in Python 3.8 as a side effect of https://bugs.python.org/issue36889.

Unfortunately, that ticket says nothing about `StreamReaderProtocol` and how to replace it. The documentation added when fixing that ticket doesn't say anything about `StreamReaderProtocol` either.

It would be less difficult to swallow the rate of API churn in asyncio if there were at least a few words about why it's happening and what concrete benefits it brings to users.

I can understand the need to change APIs, even public APIs. However, when there's zero information in tickets, commit messages and documentations, I don't know why change is happening and how I'm supposed to adapt my code. That's stressful. If what I'm doing is deprecated, probably it's a bad idea, but I can't know why?

I'm sure you aren't trying to convince me to avoid stream utilities in asyncio and write my own buffering. However, that's the result you're getting :-/ Providing a quick explanation of deprecations / removals of public APIs would help.

(Somewhat related: https://bugs.python.org/issue24885)

----------
components: asyncio
messages: 348226
nosy: asvetlov, aymeric.augustin, yselivanov
priority: normal
severity: normal
status: open
title: What happened to StreamReaderProtocol?
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37639>
_______________________________________

From report at bugs.python.org  Sun Jul 21 05:17:08 2019
From: report at bugs.python.org (hoang nguyen)
Date: Sun, 21 Jul 2019 09:17:08 +0000
Subject: [New-bugs-announce] [issue37640] telnetlib crash in Python3 while
 receiving un-printable characters from server
Message-ID: <1563700628.04.0.824275375582.issue37640@roundup.psfhosted.org>


New submission from hoang nguyen <hoangcntt13 at gmail.com>:

```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/site-packages/Pwn/Pwn.py", line 209, in io
    self.con.interact()
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/telnetlib.py", line 553, in interact
    sys.stdout.write(text.decode('ascii'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 41: ordinal not in range(128)
```
crash detail

set up a netcat server:
```
cat /dev/urandom | nc -l 127.0.0.1 8888
```

test.py
```
import telnetlib

tn = telnetlib.Telnet('127.0.0.1', 8888)
tn.interact()
```

----------
components: Library (Lib)
files: test.py
messages: 348233
nosy: hoang nguyen
priority: normal
severity: normal
status: open
title: telnetlib crash in Python3 while receiving un-printable characters from server
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file48494/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37640>
_______________________________________

From report at bugs.python.org  Sun Jul 21 07:07:21 2019
From: report at bugs.python.org (Bill Collins)
Date: Sun, 21 Jul 2019 11:07:21 +0000
Subject: [New-bugs-announce] [issue37641] Embeddable distribution pyc
 filenames show build machine location
Message-ID: <1563707241.42.0.696780467352.issue37641@roundup.psfhosted.org>


New submission from Bill Collins <bilbocollins at gmail.com>:

pyc files within the embeddable zip are compiled with their filename as the temporary directory in which they are compiled. Thus, stack traces will appear as (e.g.) D:\obj\windows-release\37win32_Release\msi_python\zip_win32\image.py, which is a little surprising and not obvious that it's actually from email/mime/image.py.

We currently work around this by updating the pyc files before shipping to be relative paths to Lib/; however, fixing this upstream would appear to be as simple as passing through the dest from _write_to_zip to _py_temp_compile (https://github.com/python/cpython/blob/21a92f8cda525d25a165b773fbe1bfffd303a000/PC/layout/main.py#L302) to be passed into _compile_one_py

----------
components: Build, Installation, Windows
messages: 348235
nosy: Bill Collins, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embeddable distribution pyc filenames show build machine location
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37641>
_______________________________________

From report at bugs.python.org  Sun Jul 21 07:41:24 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Sun, 21 Jul 2019 11:41:24 +0000
Subject: [New-bugs-announce] [issue37642] timezone allows no offset from
 range (23:59, 24:00)
Message-ID: <1563709284.19.0.651842013894.issue37642@roundup.psfhosted.org>


New submission from J?rn Heissler <launchpad at joern.heissler.de>:

https://bugs.python.org/issue5288 changed datetime.timezone to accept sub-minute offsets.

The C implementation allows offsets from range (23:59, 24:00) while the python implementation does not:

# C
>>> timezone(timedelta(seconds=86399))
datetime.timezone(datetime.timedelta(seconds=86399))

# Python
>>> timezone(timedelta(seconds=86399))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "cpython/Lib/datetime.py", line 2194, in __new__
    raise ValueError("offset must be a timedelta "
ValueError: offset must be a timedelta strictly between -timedelta(hours=24) and timedelta(hours=24).

This is because _maxoffset is defined as timedelta(hours=23, minutes=59)

Second issue: The (undocumented) "min" and "max" attributes (both C and python) show 23:59
even though the C implementation can get closer to 24:00.
Should this be changed to timezone(timedelta(seconds=86399, microseconds=999999))?


(Same applies to the minimums)

----------
components: Library (Lib)
messages: 348237
nosy: joernheissler
priority: normal
severity: normal
status: open
title: timezone allows no offset from range (23:59, 24:00)
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37642>
_______________________________________

From report at bugs.python.org  Sun Jul 21 08:07:04 2019
From: report at bugs.python.org (=?utf-8?b?0JDRgNGC0YPRgCDQk9GA0LjQs9C+0YDRjNC10LI=?=)
Date: Sun, 21 Jul 2019 12:07:04 +0000
Subject: [New-bugs-announce] [issue37643] Except clause
Message-ID: <1563710824.55.0.978874845715.issue37643@roundup.psfhosted.org>


New submission from ????? ????????? <agsci2017 at gmail.com>:

Is is possible to add to Python the following syntax (keyword 'except'):
[1, 2, 3, 4, 5] except [2]
>>> [1, 3, 4, 5]

----------
messages: 348238
nosy: ????? ?????????
priority: normal
severity: normal
status: open
title: Except clause
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37643>
_______________________________________

From report at bugs.python.org  Sun Jul 21 12:48:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 21 Jul 2019 16:48:55 +0000
Subject: [New-bugs-announce] [issue37644] Sphinx (Travis doc build) is
 blocking merging
Message-ID: <1563727735.93.0.97467728141.issue37644@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

One of the required CI tests is a Travis doc build, even if a PR does not touch any doc file.  The following failure appears to be deterministic on master and 3.8.  A 3.7 backport passed.  It has happened multiple times on multiple PRs today.  Example:
https://travis-ci.org/python/cpython/jobs/561700698
The failure is
'''
Warning, treated as error:
[distutils/examples:267] "`" found in "This is the description of the ``foobar`` package."
'''
I have no idea why this is seen as suspicious.

I have 4 PRs blocked by this.
https://github.com/python/cpython/pull/14872
https://github.com/python/cpython/pull/14879
https://github.com/python/cpython/pull/14883
https://github.com/python/cpython/pull/14881
The last one is the 3.8 backport of a PR that passed CI maybe 12 hours ago.  Its 3.7 backport passed and is merged.

If nothing else, can warnings not be treated as errors?

----------
components: Tests
keywords: 3.8regression
messages: 348253
nosy: mdk, terry.reedy, vstinner, zach.ware
priority: critical
severity: normal
stage: needs patch
status: open
title: Sphinx (Travis doc build) is blocking merging
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37644>
_______________________________________

From report at bugs.python.org  Sun Jul 21 13:46:15 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 21 Jul 2019 17:46:15 +0000
Subject: [New-bugs-announce] [issue37645] Replace
 PyEval_GetFuncName/PyEval_GetFuncDesc
Message-ID: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

PyEval_GetFuncName is bad API because

1. It hardcodes a limited number of function classes (which doesn't even include all function classes in the core interpreter) instead of supporting duck-typing.
2. In case of a "function" object, it relies on a borrowed reference to the function.
3. It is returning a C string instead of a Python string, so we cannot return a new reference even if we wanted to.

Since PyEval_GetFuncName and PyEval_GetFuncDesc are always used together, we might as well replace them by a single function with a proper API.

----------
components: Interpreter Core
messages: 348255
nosy: jdemeyer, vstinner
priority: normal
severity: normal
status: open
title: Replace PyEval_GetFuncName/PyEval_GetFuncDesc
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37645>
_______________________________________

From report at bugs.python.org  Sun Jul 21 19:24:25 2019
From: report at bugs.python.org (=?utf-8?q?Grzegorz_Kraso=C5=84?=)
Date: Sun, 21 Jul 2019 23:24:25 +0000
Subject: [New-bugs-announce] [issue37646] eval() in a list comprehension
Message-ID: <1563751465.46.0.439346831661.issue37646@roundup.psfhosted.org>


New submission from Grzegorz Kraso? <grzegorz.krason at gmail.com>:

eval() works in a global scope when invoked in a list comprehension.

----------
components: Interpreter Core
files: demo.py
messages: 348271
nosy: Grzegorz Kraso?
priority: normal
severity: normal
status: open
title: eval() in a list comprehension
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48495/demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37646>
_______________________________________

From report at bugs.python.org  Mon Jul 22 00:30:20 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Mon, 22 Jul 2019 04:30:20 +0000
Subject: [New-bugs-announce] [issue37647] Wrong lineno in traceback when
 formatting strings with % and multilines
Message-ID: <1563769820.35.0.117931851308.issue37647@roundup.psfhosted.org>


New submission from Bruno P. Kinoshita <brunodepaulak at yahoo.com.br>:

Hi,

Tested on Python 3.7 on Ubuntu LTS. But I believe this affects previous versions too, as found it from an issue posted in Jinja2 in 2013: https://github.com/pallets/jinja/issues/276

This code simulates the issue where the traceback has the wrong line number (without using any Jinja2 code):

```
class Z(object):
    def __str__(self):
        raise ValueError('Z error')


def raise_generator():
    yield 'three values are: %s %s %s' % (
        'primeiro',
        Z(),  # traceback must point to this lineno 9
        'terceiro'  # but points to this lineno 10 (__str__ only, __eq__ is OK)
    )


print(list(raise_generator()))
```

The output:

```
Traceback (most recent call last):
  File "/home/kinow/Development/python/workspace/cylc-flow/cylc/flow/tests/Z.py", line 14, in <module>
    print(list(raise_generator()))
  File "/home/kinow/Development/python/workspace/cylc-flow/cylc/flow/tests/Z.py", line 10, in raise_generator
    'terceiro'  # but points to this lineno 10 (__str__ only, __eq__ is OK)
  File "/home/kinow/Development/python/workspace/cylc-flow/cylc/flow/tests/Z.py", line 3, in __str__
    raise ValueError('Z error')
ValueError: Z error
```

Jinja uses something similar to the class Z to raise errors when the template has undefined variables. The curious part is that if instead of simply formatting the string with "%s" % (Z()) you use "%s" % (str(Z())) or if you callZ().__str__(), then the traceback reports the correct line number.

Not sure if intentional, but would be nice if the traceback reported the correct line number, and I think other applications could end up having the same issue.

This is my first issue, so I apologize if I did not include enough information, or if there is anything missing in this ticket. Let me know if I need to update it with more information or formatting the code.

Would be happy to work on this if this is considered an easy-to-fix issue.

Thanks all for your work on Python,

Bruno P. Kinoshita

----------
components: Interpreter Core
messages: 348277
nosy: kinow
priority: normal
severity: normal
status: open
title: Wrong lineno in traceback when formatting strings with % and multilines
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37647>
_______________________________________

From report at bugs.python.org  Mon Jul 22 03:58:57 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 22 Jul 2019 07:58:57 +0000
Subject: [New-bugs-announce] [issue37648] Fix minor inconsistency in the
 order of == operands
Message-ID: <1563782337.34.0.926786223428.issue37648@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There is two ways to write the comparison when we search an item equal to the needle:

    item == needle

and

    needle == item

In most cases they get the same result. But if __eq__ of the item or the needle is not correctly implemented (returns False instead of NotImplemented for unsupported types) the order can matter. We want the behavior be consistent in all cases.

The majority of the code uses needle on the right side of the == operator. But there are few outliners:

* tuple.__contains__ and list.__contains__. They code is different from the code used in methods count(), index(), remove() where needle is on the right.

* The general implementation of the "in" operator for iterators (see PySequence_Contains).

* dictitems.__contains__.

* The copy of list_contains in _ssl.c.

* The C implementation of _asyncio.Future.remove_done_callback. It differs from the Python implementation.

In all other code (many tens of occurrences) needle is on the right.

I think it is worth to fix the minor inconsistency in these few places.

See also the discussion on Python-Dev: https://mail.python.org/archives/list/python-dev at python.org/thread/VSV4K4AOKM4CBQMOELPFV5VMYALPH464/.

----------
components: Interpreter Core
messages: 348287
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix minor inconsistency in the order of == operands
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37648>
_______________________________________

From report at bugs.python.org  Mon Jul 22 06:21:54 2019
From: report at bugs.python.org (Orivej Desh)
Date: Mon, 22 Jul 2019 10:21:54 +0000
Subject: [New-bugs-announce] [issue37649] calculate_init fails to check that
 EXEC_PREFIX was decoded
Message-ID: <1563790914.65.0.328698742549.issue37649@roundup.psfhosted.org>


New submission from Orivej Desh <orivej at gmx.fr>:

See https://github.com/python/cpython/pull/14897

The bug was introduced in https://github.com/python/cpython/commit/0327bde9da203bb256b58218d012ca76ad0db4e4#diff-fa81ddea06129e7a2ef6b5a1c6a0af4dR925

----------
components: Interpreter Core
messages: 348292
nosy: orivej
priority: normal
pull_requests: 14683
severity: normal
status: open
title: calculate_init fails to check that EXEC_PREFIX was decoded
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37649>
_______________________________________

From report at bugs.python.org  Mon Jul 22 08:10:54 2019
From: report at bugs.python.org (Ryan Gonzalez)
Date: Mon, 22 Jul 2019 12:10:54 +0000
Subject: [New-bugs-announce] [issue37650] TemporaryDirectory objects should
 LOCK_SH to avoid being deleted by systemd-tmpfiles
Message-ID: <1563797454.09.0.560576153517.issue37650@roundup.psfhosted.org>


New submission from Ryan Gonzalez <rymg19 at gmail.com>:

If e.g. a tar archive is extracted that has dates from several months ago, if systemd-tmpfiles runs to clean up data, then it may delete that data while the directory is still being used. This can be avoided by holding a LOCK_SH on the directory while it's being used.

----------
components: Library (Lib)
messages: 348295
nosy: refi64
priority: normal
severity: normal
status: open
title: TemporaryDirectory objects should LOCK_SH to avoid being deleted by systemd-tmpfiles
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37650>
_______________________________________

From report at bugs.python.org  Mon Jul 22 09:36:22 2019
From: report at bugs.python.org (Gary van der Merwe)
Date: Mon, 22 Jul 2019 13:36:22 +0000
Subject: [New-bugs-announce] [issue37651] Change of inheritance of
 asyncio.CancelledError needs documentation
Message-ID: <1563802582.63.0.387759445278.issue37651@roundup.psfhosted.org>


New submission from Gary van der Merwe <garyvdm at gmail.com>:

asyncio.CancelledError inheritance was changed in 3.8. 

https://bugs.python.org/issue32528
https://github.com/python/cpython/commit/431b540bf79f0982559b1b0e420b1b085f667bb7

The documentation still instructs the user to perform a pattern needed before this change. The documentation should probably change to inform them of the change, and to let them know that pattern is only necessary prior to 3.8.

----------
assignee: docs at python
components: Documentation
messages: 348297
nosy: docs at python, garyvdm
priority: normal
severity: normal
status: open
title: Change of inheritance of asyncio.CancelledError needs documentation
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37651>
_______________________________________

From report at bugs.python.org  Mon Jul 22 11:13:18 2019
From: report at bugs.python.org (Ben)
Date: Mon, 22 Jul 2019 15:13:18 +0000
Subject: [New-bugs-announce] [issue37652] Multiprocessing shared_memory
 ValueError on race with ShareableList
Message-ID: <1563808398.25.0.353016896189.issue37652@roundup.psfhosted.org>


New submission from Ben <benjsimner at gmail.com>:

When running the attached on 3.8 and 3.9 (master) I get the following:

Process Process-3:
Traceback (most recent call last):                                                                                                                       
  File "/home/bjs/.pyenv/versions/3.9-dev/lib/python3.9/multiprocessing/process.py", line 313, in _bootstrap
    self.run()    
  File "/home/bjs/.pyenv/versions/3.9-dev/lib/python3.9/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/home/bjs/Downloads/e4671450a50df5a0648c6dda0c7b642a-3db67c29d8d9e6a6d629c2c016f5853ec22000ed/test.py", line 14, in g
    X[0]
  File "/home/bjs/.pyenv/versions/3.9-dev/lib/python3.9/multiprocessing/shared_memory.py", line 413, in __getitem__
    (v,) = struct.unpack_from(
ValueError: not enough values to unpack (expected 1, got 0)

(Tested on Windows and Linux)

Either this is a documentation error,  and the docs for shared_memory should state that the ShareableList does not have atomic operations and so this is unsafe,  or this is a suspicious behaviour.  I'm not sure which.

I could also just be using the library totally incorrectly.

----------
files: test.py
messages: 348299
nosy: bjs
priority: normal
severity: normal
status: open
title: Multiprocessing shared_memory ValueError on race with ShareableList
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48496/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37652>
_______________________________________

From report at bugs.python.org  Mon Jul 22 11:33:56 2019
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 22 Jul 2019 15:33:56 +0000
Subject: [New-bugs-announce] [issue37653] make install fails
Message-ID: <1563809636.35.0.686043283541.issue37653@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlenda at gmail.com>:

Make install is broken in subtarget libinstall. This was introduced with commit e8692818afd731c1b7e925c626ac8200b1f1c31e.

Fix in attached patch.

----------
components: Build
files: fix.patch
keywords: patch
messages: 348300
nosy: Erlend Egeberg Aasland
priority: normal
severity: normal
status: open
title: make install fails
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48497/fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37653>
_______________________________________

From report at bugs.python.org  Mon Jul 22 15:17:59 2019
From: report at bugs.python.org (Bill Collins)
Date: Mon, 22 Jul 2019 19:17:59 +0000
Subject: [New-bugs-announce] [issue37654] 2to3 no-ops on embeddable
 distribution
Message-ID: <1563823079.34.0.179597137003.issue37654@roundup.psfhosted.org>


New submission from Bill Collins <bilbocollins at gmail.com>:

Firstly, I'd acknowledge that expecting 2to3 to work on the embeddable distribution might be the problem, but the mode of failure is silent and delayed.

The problem is that 2to3 loads fix names by searching for files in a package that end in '.py' (https://github.com/python/cpython/blame/master/Lib/lib2to3/refactor.py#L30) which isn't much use on the embeddable distribution where everything is pre-comipled.

So, installing an sdist package that relies on 2to3 will succeed, but any attempt to then actually use the installed package will fail.

I'm not sure whether the correct behavior here might be to

1. Fix 2to3 to load from pyc files (explicitly enabling 2to3 based installation on embeddable)
2. Fix 2to3 to fail when no converters are found (or similar; explicitly *disabling* 2to3 based installation on embeddable).

Or something else entirely.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 348304
nosy: Bill Collins
priority: normal
severity: normal
status: open
title: 2to3 no-ops on embeddable distribution
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37654>
_______________________________________

From report at bugs.python.org  Mon Jul 22 17:33:30 2019
From: report at bugs.python.org (Frank B)
Date: Mon, 22 Jul 2019 21:33:30 +0000
Subject: [New-bugs-announce] [issue37655] Set subset operator docs
Message-ID: <1563831210.27.0.699744646514.issue37655@roundup.psfhosted.org>


New submission from Frank B <fbicknel at gmail.com>:

The docs say "Test whether the set is a proper subset of other" for both set < other and set > other built-in functions.

Is that a misprint? How could it be both?

For the <= and >= operators it properly reverses the order so one says:

Test whether every element in the set is in other.

and the other:

Test whether every element in other is in the set.

----------
assignee: docs at python
components: Documentation
files: 2019-07-22 1728 Screenshot.png
messages: 348307
nosy: Frank B2, docs at python
priority: normal
severity: normal
status: open
title: Set subset operator docs
versions: Python 2.7, Python 3.7
Added file: https://bugs.python.org/file48498/2019-07-22 1728 Screenshot.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37655>
_______________________________________

From report at bugs.python.org  Mon Jul 22 18:47:13 2019
From: report at bugs.python.org (Peter Farrell)
Date: Mon, 22 Jul 2019 22:47:13 +0000
Subject: [New-bugs-announce] [issue37656] Can't pip install because of
 bisect_left
Message-ID: <1563835633.66.0.295027730985.issue37656@roundup.psfhosted.org>


New submission from Peter Farrell <peterfarrell66 at gmail.com>:

Not able to start up Anaconda because of an error including "cannot import bisect_left" whatever that means. I uninstalled and tried to reinstall. No luck. Finally uninstalled and can't pip install anything because of this exact error. Here's my screenshot.

----------
files: pip_error.png
messages: 348308
nosy: Peter Farrell
priority: normal
severity: normal
status: open
title: Can't pip install because of bisect_left
Added file: https://bugs.python.org/file48499/pip_error.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37656>
_______________________________________

From report at bugs.python.org  Tue Jul 23 00:43:46 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 23 Jul 2019 04:43:46 +0000
Subject: [New-bugs-announce] [issue37657] ERROR: grip 4.5.2 requires
 docopt>=0.4.0, which is not installed.
Message-ID: <1563857026.02.0.43954136156.issue37657@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

I have Python-3.7.2 installed.
I've just installed Python3.8.0b2 on macOS,
and ran "Install Certificates.command".
The terminal output contained:

ERROR: grip 4.5.2 requires docopt>=0.4.0, which is not installed.

(certifi-2019.6.16 got installed correctly)
(Re-running the command again doesn't produce same output, because certifi is up to date)

----------
components: Installation
messages: 348316
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: ERROR: grip 4.5.2 requires docopt>=0.4.0, which is not installed.
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37657>
_______________________________________

From report at bugs.python.org  Tue Jul 23 08:16:17 2019
From: report at bugs.python.org (Nikita Ilyasov)
Date: Tue, 23 Jul 2019 12:16:17 +0000
Subject: [New-bugs-announce] [issue37658] In some cases asyncio.wait_for can
 lead to socket leak.
Message-ID: <1563884177.4.0.19779936427.issue37658@roundup.psfhosted.org>


New submission from Nikita Ilyasov <rainburst at gmail.com>:

In some cases `asyncio.wait_for` can lead to socket leak.

Condensed example:

```python
async def _create_connection(timeout=60, ssl_obj):
    loop = asyncio.get_event_loop()
    connector = loop.create_connection(MyEchoClientProtocol, '127.0.0.1', 5000, ssl=ssl_obj)
    connector = asyncio.ensure_future(connector)
    tr, pr = await asyncio.wait_for(connector, timeout=timeout, loop=loop)
    return tr, pr

async def main():
    ...
    res = await asyncio.wait_for(_acquire_impl(), timeout=timeout, loop=loop)

```

If my understanding is correct `wait_for` should work in exactly 2 ways

1. the inner task is completed and the outer task will receive the result ? transport and protocol in this case
2. The inner task is cancelled and no connection was established

I provided source code for client and server so the problem can be easily reproduced on your system.

certificate and key can be easily generated with `minica`


I found out that if I catch `CancelledError` and add a `done_callback` to the inner task, like so:

```python
    try:
        tr, pr = await asyncio.wait_for(connector, timeout=timeout, loop=loop)
        return tr, pr
    except asyncio.CancelledError as e:
        connector.add_done_callback(_done_callback)
        raise e
```
then inside of `_done_callback` I can access the transport and protocol object and close the transport manually to prevent leaking.


I run `netstat -a | grep 5000 | grep ESTAB | awk '{ print $5 }' | sort | uniq -c | grep 5000` after the script is done and there are many unclosed connections.

The output depends on your hardware so you might need to tweak the timeout parameter

----------
components: asyncio
files: example.py
messages: 348328
nosy: Nikita Ilyasov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: In some cases asyncio.wait_for can lead to socket leak.
type: resource usage
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48500/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37658>
_______________________________________

From report at bugs.python.org  Tue Jul 23 13:17:40 2019
From: report at bugs.python.org (James Xu)
Date: Tue, 23 Jul 2019 17:17:40 +0000
Subject: [New-bugs-announce] [issue37659] subprocess.list2cmdline() should
 not escape wrapping single/double quotes
Message-ID: <1563902260.7.0.339582644993.issue37659@roundup.psfhosted.org>


New submission from James Xu <kejxu at microsoft.com>:

While working on our project, we have noticed that for `subprocess.Popen(command, ...)`, when `command` is a string that contains escaped double quote, for example, `command = '"path to executable" --flag arg'`, this works fine. However, when command is changed to `shlex.split(command, posix=False)`, the Popen command fails. Looking a bit into the source code, it seems that for the command above,

```
>>> shlex.split('"path to executable" --flag arg', posix=False)
['"path to executable"', '--flag', 'arg']
```

and when this array of strings gets passed into `Popen`, the escaped double quote gets escaped again, since `subprocess.list2cmdline` does not check if a pair of double quote or single quote are wrapping the entire string `arg`. And this is the same behavior for both py2 and py3, https://github.com/python/cpython/blob/master/Lib/subprocess.py#L508. As a result, upon execution the command becomes, `'"\\"path to executable\\"" --flag arg'`

example:
```
>>> sp.list2cmdline(['"do things"'])
'"\\"do things\\""'
>>> sp.list2cmdline(['do things'])
'"do things"'
>
```

----------
components: Windows
messages: 348342
nosy: kejxu, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess.list2cmdline() should not escape wrapping single/double quotes
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37659>
_______________________________________

From report at bugs.python.org  Tue Jul 23 14:39:02 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Jul 2019 18:39:02 +0000
Subject: [New-bugs-announce] [issue37660] Drop support for Aspen magic
 directories in venv's activate script
Message-ID: <1563907142.04.0.0759083175795.issue37660@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

Or at least update the comment as the URL at https://github.com/python/cpython/blob/master/Lib/venv/scripts/common/activate#L62 is a 404 and the domain seems to be a news site in Asia now (http://www.zetadev.com/).

----------
components: Library (Lib)
messages: 348344
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Drop support for Aspen magic directories in venv's activate script
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37660>
_______________________________________

From report at bugs.python.org  Tue Jul 23 15:17:07 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Jul 2019 19:17:07 +0000
Subject: [New-bugs-announce] [issue37661] venv activation scripts
 erroneously check if __VENV_PROMPT__ is defined
Message-ID: <1563909427.85.0.687567591149.issue37661@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

If you look at https://github.com/python/cpython/blob/master/Lib/venv/__init__.py#L112-L113 you will see that the prompt context for a virtual environment is always set. Then if you look at the string substitutions for the activation scripts you will also see that the string substitution for __VENV_PROMPT__ is thus always done.

This is an issue as it means that for the fish and bash activation scripts they have erroneous checks for custom prompts. I.e. https://github.com/python/cpython/blob/master/Lib/venv/scripts/posix/activate.fish#L55 for fish and https://github.com/python/cpython/blob/master/Lib/venv/scripts/common/activate#L57 for bash will never fail, halting any other further checks unless one creates a custom EnvBuilder class which will make sure the prompt context stays empty all the way to string substitution. This impacts the colouring of the prompt in fish as that's only done if there is no default prompt (which is never true).

----------
components: Library (Lib)
messages: 348346
nosy: brett.cannon, vinay.sajip
priority: normal
severity: normal
status: open
title: venv activation scripts erroneously check if __VENV_PROMPT__ is defined
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37661>
_______________________________________

From report at bugs.python.org  Tue Jul 23 16:25:25 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Jul 2019 20:25:25 +0000
Subject: [New-bugs-announce] [issue37662] Document
 venv.EnvBuilder.upgrade_dependencies()
Message-ID: <1563913525.16.0.930618817758.issue37662@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

The upgrade_deps parameter to EnvBuilder exists and venv.EnvBuilder.create() calls self.upgrade_dependencies(), but that method isn't documented anywhere.

----------
messages: 348352
nosy: brett.cannon, vinay.sajip
priority: normal
severity: normal
status: open
title: Document venv.EnvBuilder.upgrade_dependencies()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37662>
_______________________________________

From report at bugs.python.org  Tue Jul 23 16:41:06 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Jul 2019 20:41:06 +0000
Subject: [New-bugs-announce] [issue37663] Making venv activation script
 prompts consistent
Message-ID: <1563914466.51.0.723098783517.issue37663@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

There are five activation scripts and they are all do things differently when it comes to prompt manipulation. Standardizing on one set of semantics would probably be good for consistency and so people know what to expect regardless of their shell.

Currently the various semantics are as follows (see subdirectories in https://github.com/python/cpython/tree/master/Lib/venv/scripts for the code):

- PowerShell: use __VENV_PROMPT__, make it green
- bash: use __VENV_PROMPT__ if defined (which is nearly true; bpo-37661), else if virtual env in a directory named "__" (for some defunked software named Aspen; bpo-37660) then use "[dir]", else "(dir)"
- Command Prompt: use __VENV_PROMPT__
- csh: use __VENV_NAME__ if defined, else calculate name and use "[dir]"
- fish: same as bash, except if not using __VENV_PROMPT__ then use white text on a blue background

So the variances/questions are:
1. Always use __VENV_PROMPT__ and don't bother testing? (bpo-37661 suggests we should, or else come up with a new way to tell whether a custom prompt was provided)
2. Always use colour regardless of whether the prompt is custom? (I vote "yes"; don't care about what the colours happen to be)
3. Parentheses or square brackets? (Due to bpo-37661 I vote for parentheses since that's what people are used to)

----------
components: Library (Lib)
messages: 348355
nosy: brett.cannon, vinay.sajip
priority: normal
severity: normal
status: open
title: Making venv activation script prompts consistent
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37663>
_______________________________________

From report at bugs.python.org  Tue Jul 23 17:51:27 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 23 Jul 2019 21:51:27 +0000
Subject: [New-bugs-announce] [issue37664] Update bundled pip and setuptools
Message-ID: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Can we have a newer bundled version of pip for 3.8/3.9?

In particular, I'd really like to be able to use the new location for a pip.ini inside of sys.prefix, as it will fix the problems with "python3 -m pip" on Windows when obtained from the Store (and we want to default to --user).

----------
messages: 348356
nosy: Marcus.Smith, dstufft, ncoghlan, paul.moore, steve.dower
priority: normal
severity: normal
status: open
title: Update bundled pip and setuptools
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37664>
_______________________________________

From report at bugs.python.org  Tue Jul 23 19:42:44 2019
From: report at bugs.python.org (Arun Sharma)
Date: Tue, 23 Jul 2019 23:42:44 +0000
Subject: [New-bugs-announce] [issue37665] threading.TIMEOUT_MAX integer
 overflow on 32-bit builds with threading.Thread.join
Message-ID: <1563925364.59.0.529540614468.issue37665@roundup.psfhosted.org>


New submission from Arun Sharma <arsharma at google.com>:

threading's TIMEOUT_MAX constant causes overflows when used as the timeout for threading.Thread.join on a 32-bit platform, like a Raspberry PI running Raspbian (2019-07-10-raspbian-buster).

The underlying code uses sem_timedwait.  The timespec on this platform resolves seconds to a 32-bit integer, adding the current time to the timeout to get a deadline.

====
>>> import threading
>>> threading.TIMEOUT_MAX
9223372036.0
====

The deadline is larger than the int32 UNIX Epoch and results in an overflow.

Just changing the threading.TIMEOUT_MAX to be based on the time left until the UNIX Epoch would require changing the timeout over the duration of the program and would not be very viable as the Epoch gets closer.

----------
files: timeout_max_32_bit.py
messages: 348358
nosy: Arun Sharma
priority: normal
severity: normal
status: open
title: threading.TIMEOUT_MAX integer overflow on 32-bit builds with threading.Thread.join
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48501/timeout_max_32_bit.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37665>
_______________________________________

From report at bugs.python.org  Tue Jul 23 19:54:18 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 23 Jul 2019 23:54:18 +0000
Subject: [New-bugs-announce] [issue37666] urllib.requests.urlopen doesn't
 support cadata=
Message-ID: <1563926058.03.0.180495297284.issue37666@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

The underlying https://docs.python.org/3/library/ssl.html#ssl.SSLContext.load_verify_locations API supports cafile, capath and cadata.

urlopen() only offers up cafile and capath.  It should also support cadata for completeness.

This matters for applications that embed their root certificate pem as data.  Requiring the user to write that to a file or ship that as a file just so the library can read it rather than passing it in as a string is gross.

Lets add cadata support to urlopen().

----------
assignee: christian.heimes
components: Library (Lib), SSL
messages: 348359
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.requests.urlopen doesn't support cadata=
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37666>
_______________________________________

From report at bugs.python.org  Wed Jul 24 00:10:58 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 24 Jul 2019 04:10:58 +0000
Subject: [New-bugs-announce] [issue37667] test.regrtest is now only running
 40 tests
Message-ID: <1563941458.91.0.702093018542.issue37667@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

After the PR for https://bugs.python.org/issue36044 when in, see the comment in the issue.

test.regrtest is now only running 40 tests.

that means all of our CI is failing to run most of the test suites.

----------
components: Tests
messages: 348365
nosy: gregory.p.smith, lukasz.langa
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test.regrtest is now only running 40 tests
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37667>
_______________________________________

From report at bugs.python.org  Wed Jul 24 06:30:41 2019
From: report at bugs.python.org (Hasan Diwan)
Date: Wed, 24 Jul 2019 10:30:41 +0000
Subject: [New-bugs-announce] [issue37668] Allow individual test to be
 specified by "#" or "."
Message-ID: <1563964241.47.0.656426706164.issue37668@roundup.psfhosted.org>


New submission from Hasan Diwan <hasan.diwan at gmail.com>:

The attached patch allows for individual tests to be specified using a #. 

Existing tests still pass:

 == Tests result: SUCCESS ==

All 40 tests OK.

Total duration: 4 min 15 sec
Tests result: SUCCESS

----------
components: Tests
files: python.pat
messages: 348377
nosy: Hasan Diwan
priority: normal
severity: normal
status: open
title: Allow individual test to be specified by "#" or "."
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48502/python.pat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37668>
_______________________________________

From report at bugs.python.org  Wed Jul 24 08:46:58 2019
From: report at bugs.python.org (=?utf-8?q?Damien_Nad=C3=A9?=)
Date: Wed, 24 Jul 2019 12:46:58 +0000
Subject: [New-bugs-announce] [issue37669] Make mock_open return per-file
 content
Message-ID: <1563972418.64.0.300779941937.issue37669@roundup.psfhosted.org>


New submission from Damien Nad? <bugzilla-python at livna.org>:

Let's say I have a function that opens 2 files and compare them. mock_open would not allow me to test this case, as it would return the same data for both files (through its read_data argument).

I want to be able to do this in a mocked-open context:
```
with open("file1") as file1:
    assert file1.read() == "data1"

with open("file2") as file2:
    assert file2.read() == "data2"
```

----------
components: Library (Lib)
messages: 348386
nosy: Anvil
priority: normal
severity: normal
status: open
title: Make mock_open return per-file content
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37669>
_______________________________________

From report at bugs.python.org  Wed Jul 24 14:03:21 2019
From: report at bugs.python.org (Caleb Donovick)
Date: Wed, 24 Jul 2019 18:03:21 +0000
Subject: [New-bugs-announce] [issue37670] Description of UserDict is
 misleading
Message-ID: <1563991401.59.0.133528027971.issue37670@roundup.psfhosted.org>


New submission from Caleb Donovick <donovick at cs.stanford.edu>:

The documentation for collections.UserDict states "In addition to supporting the methods and operations of mappings, UserDict instances provide the following attribute:  ..."

This however is misleading as it supports the operations of mutable mappings. Which is not stated anywhere.

----------
assignee: docs at python
components: Documentation
messages: 348393
nosy: docs at python, donovick
priority: normal
severity: normal
status: open
title: Description of UserDict is misleading

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37670>
_______________________________________

From report at bugs.python.org  Wed Jul 24 14:18:17 2019
From: report at bugs.python.org (Antal Nemes)
Date: Wed, 24 Jul 2019 18:18:17 +0000
Subject: [New-bugs-announce] [issue37671] itertools.combinations could be
 lazier
Message-ID: <1563992297.11.0.886326187816.issue37671@roundup.psfhosted.org>


New submission from Antal Nemes <thoneyvazul at gmail.com>:

Reproducible with current master (3.9, 151b91dfd21a100ecb1eba9e293c0a8695bf3bf5)

I would expect itertools.combinations to be lazy in the sense that it should not exhaust the input iterator in constructor time.

import itertools;
itertools.combinations(itertools.count(),2)

should return instantly. Instead it "hangs" until the process is killed.

Similarly, one can reproduce with the following simple crafted generator:

Python 3.9.0a0 (heads/master-dirty:151b91d, Jul 24 2019, 19:51:53) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def mygenerator_with_exception():
    yield 2
    yield 2
    yield 3
    raise Exception("Should not be raised")
... ... ... ... ... 
>>> g = mygenerator_with_exception()
>>> import itertools             
>>> itertools.combinations(g,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in mygenerator_with_exception
Exception: Should not be raised

Could you please consider making itertools.combinations truely lazy?

----------
components: Interpreter Core
messages: 348395
nosy: furiel
priority: normal
severity: normal
status: open
title: itertools.combinations could be lazier
type: behavior
versions: Python 3.5, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37671>
_______________________________________

From report at bugs.python.org  Wed Jul 24 17:30:32 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 24 Jul 2019 21:30:32 +0000
Subject: [New-bugs-announce] [issue37672] Switch Windows Store package to
 use pip.ini for user mode
Message-ID: <1564003832.35.0.0864190527749.issue37672@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Currently we set PIP_USER environment variable in the pip.exe redirector, which is not ideal. Now that we have the latest release of pip, we can use a pip.ini file to set the option by default.

----------
assignee: steve.dower
components: Windows
messages: 348408
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Switch Windows Store package to use pip.ini for user mode
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37672>
_______________________________________

From report at bugs.python.org  Wed Jul 24 17:39:36 2019
From: report at bugs.python.org (Lou Perazzoli)
Date: Wed, 24 Jul 2019 21:39:36 +0000
Subject: [New-bugs-announce] [issue37673] Tkinter won't create 5000 check
 boxes, stops at 1309.
Message-ID: <1564004376.63.0.730032701785.issue37673@roundup.psfhosted.org>


New submission from Lou Perazzoli <loupzz at gmail.com>:

Here's a short example.

----------
components: Tkinter
files: tk-bug.py
messages: 348409
nosy: Loupz
priority: normal
severity: normal
status: open
title: Tkinter won't create 5000 check boxes, stops at 1309.
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48503/tk-bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37673>
_______________________________________

From report at bugs.python.org  Wed Jul 24 18:15:42 2019
From: report at bugs.python.org (Mariatta)
Date: Wed, 24 Jul 2019 22:15:42 +0000
Subject: [New-bugs-announce] [issue37674] Is imp module deprecated or
 pending deprecation?
Message-ID: <1564006542.59.0.779053208257.issue37674@roundup.psfhosted.org>


New submission from Mariatta <mariatta at python.org>:

The doc https://docs.python.org/3.7/library/imp.html says "Deprecated since version 3.4: The imp package is pending deprecation in favor of importlib."

Is it in "deprecated" state, or "pendingdeprecation" state?
Should it just be removed in 3.9?

Maybe I just don't understand the difference of "deprecated" and "pending deprecation" :(

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 348411
nosy: Mariatta, docs at python
priority: normal
severity: normal
status: open
title: Is imp module deprecated or pending deprecation?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37674>
_______________________________________

From report at bugs.python.org  Wed Jul 24 19:15:13 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Jul 2019 23:15:13 +0000
Subject: [New-bugs-announce] [issue37675] 2to3 doesn't work when run from a
 zipfile
Message-ID: <1564010113.05.0.275841737457.issue37675@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:

get_all_fix_names does listdir() to find fixers. That breaks if the standard library is in a zipfile. It shouldn't be hard to replace this with pkgutil.iter_modules.

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.x conversion tool)
messages: 348413
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: 2to3 doesn't work when run from a zipfile
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37675>
_______________________________________

From report at bugs.python.org  Thu Jul 25 02:41:14 2019
From: report at bugs.python.org (Hendrik)
Date: Thu, 25 Jul 2019 06:41:14 +0000
Subject: [New-bugs-announce] [issue37676] cmath.phase array support
Message-ID: <1564036874.95.0.313936205307.issue37676@roundup.psfhosted.org>


New submission from Hendrik <jan-hendrik.mueller at gmx.net>:

It would be nice if cmath.phase supports arrays like this: 
```
import cmath
import numpy as np

z=255*np.ones((3,3)) * np.exp(1j * np.pi*np.ones((3,3)))

def get_k_amp_array(z):
    return abs(z)

def get_k_ph_array(z):
    return np.array([[cmath.phase(z_row) for z_row in z_col] for z_col in z ])

amp_array=  get_k_amp_array(z)
ph_array=   get_k_ph_array(z)

print(amp_array)
print(ph_array)
```

----------
components: Library (Lib)
messages: 348428
nosy: kolibril13
priority: normal
severity: normal
status: open
title: cmath.phase array support
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37676>
_______________________________________

From report at bugs.python.org  Thu Jul 25 04:07:01 2019
From: report at bugs.python.org (alvis)
Date: Thu, 25 Jul 2019 08:07:01 +0000
Subject: [New-bugs-announce] [issue37677] Seg Fault on OSX when
 multiprocessing
Message-ID: <1564042021.53.0.0155934240157.issue37677@roundup.psfhosted.org>


New submission from alvis <kgaihc at hotmail.com>:

Encountered a crash with the following logs.
I have already added no_proxy=*, and it fixed the issue which i can replicate consistent. However, this crash does not happen every time, maybe once in a few week.

Process:               Python [66435]
Path:                  /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.6.8 (3.6.8)
Code Type:             X86-64 (Native)
Parent Process:        Python [65077]
Responsible:           Python [66435]
User ID:               501

Date/Time:             2019-07-24 21:45:29.722 +0800
OS Version:            Mac OS X 10.14.2 (18C54)
Report Version:        12
Bridge OS Version:     3.5 (16P5125)
Anonymous UUID:        3F729BF3-2BB1-3830-B6FE-D22CA431DE5A


Time Awake Since Boot: 1600000 seconds

System Integrity Protection: enabled

Crashed Thread:        2

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000109b23aa2
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [66435]

VM Regions Near 0x109b23aa2:
    MALLOC_LARGE           0000000109aa3000-0000000109b23000 [  512K] rw-/rwx SM=COW  
--> 
    __TEXT                 0000000109b27000-0000000109b3d000 [   88K] r-x/rwx SM=COW  /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/numpy/.dylibs/libgcc_s.1.dylib

Application Specific Information:
*** multi-threaded process forked ***
crashed on child side of fork pre-exec 

Thread 2 Crashed:
0   libsystem_trace.dylib         	0x00007fff7d6fdab3 _os_log_cmp_key + 4
1   libsystem_c.dylib             	0x00007fff7d5aaa5e rb_tree_find_node + 53
2   libsystem_trace.dylib         	0x00007fff7d6fbc81 os_log_create + 370
3   libnetwork.dylib              	0x00007fff7c04058f nwlog_legacy_init_once + 47
4   libsystem_pthread.dylib       	0x00007fff7d6e1ce4 __pthread_once_handler + 66
5   libsystem_platform.dylib      	0x00007fff7d6d7acb _os_once_callout + 18
6   libsystem_pthread.dylib       	0x00007fff7d6e1c7f pthread_once + 56
7   libnetwork.dylib              	0x00007fff7c024ccd networkd_settings_init + 669
8   libnetwork.dylib              	0x00007fff7c024982 networkd_settings_get_bool + 18
9   libnetwork.dylib              	0x00007fff7c0244f0 -[NWConcrete_nw_parameters initWithStack:] + 160
10  libnetwork.dylib              	0x00007fff7c023d97 nw_path_create_evaluator_for_endpoint + 487
11  libnetwork.dylib              	0x00007fff7c2451bc nw_nat64_v4_address_requires_synthesis + 220
12  libsystem_info.dylib          	0x00007fff7d609e83 _gai_nat64_v4_address_requires_synthesis + 67
13  libsystem_info.dylib          	0x00007fff7d609210 _gai_nat64_second_pass + 512
14  libsystem_info.dylib          	0x00007fff7d5e7b4a si_addrinfo + 1978
15  libsystem_info.dylib          	0x00007fff7d5e7262 _getaddrinfo_internal + 242
16  libsystem_info.dylib          	0x00007fff7d5e715d getaddrinfo + 61
17  _socket.cpython-36m-darwin.so 	0x00000001092c24ed socket_getaddrinfo + 621
18  org.python.python             	0x0000000106d63697 _PyCFunction_FastCallDict + 183
19  org.python.python             	0x0000000106de5747 call_function + 439
20  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
21  org.python.python             	0x0000000106de61af _PyEval_EvalCodeWithName + 2447
22  org.python.python             	0x0000000106de6ae1 fast_function + 545
23  org.python.python             	0x0000000106de5721 call_function + 401
24  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
25  org.python.python             	0x0000000106de61af _PyEval_EvalCodeWithName + 2447
26  org.python.python             	0x0000000106de6ae1 fast_function + 545
27  org.python.python             	0x0000000106de5721 call_function + 401
28  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
29  org.python.python             	0x0000000106de6a3d fast_function + 381
30  org.python.python             	0x0000000106de5721 call_function + 401
31  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
32  org.python.python             	0x0000000106de61af _PyEval_EvalCodeWithName + 2447
33  org.python.python             	0x0000000106de6ae1 fast_function + 545
34  org.python.python             	0x0000000106de5721 call_function + 401
35  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
36  org.python.python             	0x0000000106de61af _PyEval_EvalCodeWithName + 2447
37  org.python.python             	0x0000000106de6dfb _PyFunction_FastCallDict + 763
38  org.python.python             	0x0000000106d1a6b7 _PyObject_FastCallDict + 247
39  org.python.python             	0x0000000106d1a7d5 _PyObject_Call_Prepend + 149
40  org.python.python             	0x0000000106d1a4f0 PyObject_Call + 96
41  org.python.python             	0x0000000106d7badd slot_tp_init + 125
42  org.python.python             	0x0000000106d77d09 type_call + 313
43  org.python.python             	0x0000000106d1a685 _PyObject_FastCallDict + 197
44  org.python.python             	0x0000000106de5648 call_function + 184
45  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
46  org.python.python             	0x0000000106de6a3d fast_function + 381
47  org.python.python             	0x0000000106de5721 call_function + 401
48  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
49  org.python.python             	0x0000000106de6a3d fast_function + 381
50  org.python.python             	0x0000000106de5721 call_function + 401
51  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
52  org.python.python             	0x0000000106de6a3d fast_function + 381
53  org.python.python             	0x0000000106de5721 call_function + 401
54  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
55  org.python.python             	0x0000000106de6a3d fast_function + 381
56  org.python.python             	0x0000000106de5721 call_function + 401
57  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
58  org.python.python             	0x0000000106de6a3d fast_function + 381
59  org.python.python             	0x0000000106de5721 call_function + 401
60  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
61  org.python.python             	0x0000000106de6a3d fast_function + 381
62  org.python.python             	0x0000000106de5721 call_function + 401
63  org.python.python             	0x0000000106de1eb7 _PyEval_EvalFrameDefault + 27559
64  org.python.python             	0x0000000106de6c5c _PyFunction_FastCallDict + 348
65  org.python.python             	0x0000000106d1a6b7 _PyObject_FastCallDict + 247
66  org.python.python             	0x0000000106d1a7d5 _PyObject_Call_Prepend + 149
67  org.python.python             	0x0000000106d1a4f0 PyObject_Call + 96
68  org.python.python             	0x0000000106e2d396 t_bootstrap + 70
69  org.python.python             	0x0000000106e26be9 pythread_wrapper + 25
70  libsystem_pthread.dylib       	0x00007fff7d6e3305 _pthread_body + 126
71  libsystem_pthread.dylib       	0x00007fff7d6e626f _pthread_start + 70
72  libsystem_pthread.dylib       	0x00007fff7d6e2415 thread_start + 13

----------
messages: 348429
nosy: alvis
priority: normal
severity: normal
status: open
title: Seg Fault on OSX when multiprocessing
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37677>
_______________________________________

From report at bugs.python.org  Thu Jul 25 05:49:26 2019
From: report at bugs.python.org (Sean Wang)
Date: Thu, 25 Jul 2019 09:49:26 +0000
Subject: [New-bugs-announce] [issue37678] Incorrect behaviour for
 user@password URI pattern in urlparse
Message-ID: <1564048166.67.0.214181978799.issue37678@roundup.psfhosted.org>


New submission from Sean Wang <wangxiao8611 at gmail.com>:

When an IPV4 URL with 'username:password' in it, and the password contains special characters like #[]?, urlparse would act as unexcepted.
example: 

urlparse('http://user:pass#?[word at example.com:80/path')

----------
components: Library (Lib)
messages: 348431
nosy: Sean.Wang
priority: normal
severity: normal
status: open
title: Incorrect behaviour for user at password URI pattern in urlparse
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37678>
_______________________________________

From report at bugs.python.org  Thu Jul 25 06:07:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 25 Jul 2019 10:07:19 +0000
Subject: [New-bugs-announce] [issue37679] test_with_pip fails on FreeBSD 10
 bot
Message-ID: <1564049239.7.0.14830055581.issue37679@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I guess the upgrade in issue37664 caused an issue with FreeBSD bot. The bot seems to fail after this change on master and 3.8.

https://buildbot.python.org/all/#/builders/167/builds/1380


test_with_pip (test.test_venv.EnsurePipTest) ... FAIL
======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_venv.py", line 495, in test_with_pip
    self.do_test_with_pip(False)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_venv.py", line 478, in do_test_with_pip
    self.assertEqual(err.rstrip(), "")
AssertionError: "WARNING: The directory '/.cache/pip/http[202 chars]lag." != ''
- WARNING: The directory '/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
+ 
----------------------------------------------------------------------

----------
components: Tests
messages: 348432
nosy: pablogsal, vstinner, xtreak
priority: normal
severity: normal
status: open
title: test_with_pip fails on FreeBSD 10 bot
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37679>
_______________________________________

From report at bugs.python.org  Thu Jul 25 09:22:47 2019
From: report at bugs.python.org (Omer Ozarslan)
Date: Thu, 25 Jul 2019 13:22:47 +0000
Subject: [New-bugs-announce] [issue37680] distutils appends LDFLAGS
 environment variable before object file names
Message-ID: <1564060967.95.0.321651965491.issue37680@roundup.psfhosted.org>


New submission from Omer Ozarslan <omerfaruko at gmail.com>:

distutils honors some environment variables during extension build, however, LDFLAGS is appended before declaring object files. This causes undefined symbols during importing an extension built with some static libraries using this environment variable. This is not apparent in the case of dynamic linking, but it can be observed by adding "-Wl,--as-needed" flag, since this will link libraries only if they are required. Therefore, it will be necessary to add them after object files in case of dynamic linking as well in that case.

I believe this part is the culprit as it appends LDFLAGS environment variable to executable name: https://github.com/python/cpython/blob/c994c8f/Lib/distutils/sysconfig.py#L211-L235

I attached a minimal example (it requires cython, which relies on distutils for compilation).

It would be nice if LDFLAGS is appended after object files, or a new environment variable (e.g. LDLIBS) is introduced to distutils to be appended after object files.

----------
components: Distutils
files: python-issue.tar.gz
messages: 348436
nosy: dstufft, eric.araujo, ozars
priority: normal
severity: normal
status: open
title: distutils appends LDFLAGS environment variable before object file names
Added file: https://bugs.python.org/file48505/python-issue.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37680>
_______________________________________

From report at bugs.python.org  Thu Jul 25 12:02:38 2019
From: report at bugs.python.org (hai shi)
Date: Thu, 25 Jul 2019 16:02:38 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue37681=5D_warning=3A_?=
 =?utf-8?b?4oCYbm9fc2FuaXRpemVfdGhyZWFk4oCZ?=
Message-ID: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

When I build cpython, I got this error:
Objects/obmalloc.c:1414:1: warning: ?no_sanitize_thread? attribute directive ignored [-Wattributes]
 {
 ^
I removed the _Py_NO_SANITIZE_THREAD and build again, this warning dismissed. not sure ASAN?TSAN and MSAN have some inner relation?

----------
components: Build
messages: 348441
nosy: shihai1991
priority: normal
severity: normal
status: open
title: warning: ?no_sanitize_thread?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37681>
_______________________________________

From report at bugs.python.org  Thu Jul 25 13:03:28 2019
From: report at bugs.python.org (Thomas Dybdahl Ahle)
Date: Thu, 25 Jul 2019 17:03:28 +0000
Subject: [New-bugs-announce] [issue37682] random.sample should support
 iterators
Message-ID: <1564074208.5.0.498175435162.issue37682@roundup.psfhosted.org>


New submission from Thomas Dybdahl Ahle <lobais at gmail.com>:

Given a generator `f()` we can use `random.sample(list(f()), 10)` to get a uniform sample of the values generated.
This is fine, and fast, as long as `list(f())` easily fits in memory.
However, if it doesn't, one has to implement the reservoir sampling algorithm as a pure python function, which is much slower, and not so easy.

It seems that having a fast reservoir sampling implementation in `random.sample` to use for iterators would be both useful and make the API more predictable.

Currently when passing an iterator `random.sample` throws `TypeError: Population must be a sequence or set.`.
This is inconsistent with most of the standard library which accepts lists and iterators transparently.

I apologize if this enhancement has already been discussed.
I wasn't able to find it.
If wanted, I can write up a pull request.
I believe questions like this: https://stackoverflow.com/questions/12581437/python-random-sample-with-a-generator-iterable-iterator makes it clear that such functionality is wanted and non-obvious.

----------
components: Library (Lib)
messages: 348445
nosy: thomasahle
priority: normal
severity: normal
status: open
title: random.sample should support iterators
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37682>
_______________________________________

From report at bugs.python.org  Thu Jul 25 13:50:21 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 25 Jul 2019 17:50:21 +0000
Subject: [New-bugs-announce] [issue37683] Use importlib.resources in venv
Message-ID: <1564077021.19.0.886613759672.issue37683@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

Right now the venv module directly reads the file system to find the activation scripts and then copies them over. Moving over to importlib.resources would be a more portable solution.

Unfortunately the venv API is specifically tied to the file system via EnvBuilder.install_scripts() (https://github.com/python/cpython/blob/master/Lib/venv/__init__.py#L341). I'm not sure how doable this idea would be due to this.

----------
components: Library (Lib)
messages: 348448
nosy: barry, brett.cannon, vinay.sajip
priority: low
severity: normal
status: open
title: Use importlib.resources in venv
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37683>
_______________________________________

From report at bugs.python.org  Thu Jul 25 15:47:06 2019
From: report at bugs.python.org (wim glenn)
Date: Thu, 25 Jul 2019 19:47:06 +0000
Subject: [New-bugs-announce] [issue37684] list.extend docs inaccurate
Message-ID: <1564084026.65.0.901156826849.issue37684@roundup.psfhosted.org>


New submission from wim glenn <wim.glenn at gmail.com>:

>From https://docs.python.org/3/tutorial/datastructures.html#more-on-lists :

    list.extend(iterable)
        Extend the list by appending all the items from the iterable.
        Equivalent to a[len(a):] = iterable.

The "equivalent" is not very good. Consider 

    def gen():
        yield 1
        yield 2
        raise Exception

Using `a.extend(gen())` would mutate `a`. Using slice assignment would still consume the generator, but `a` would not be modified.

I propose a different example to use to describe the behaviour of extend:

    for x in iterable:
        a.append(x)

----------
assignee: docs at python
components: Documentation
messages: 348450
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: list.extend docs inaccurate
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37684>
_______________________________________

From report at bugs.python.org  Thu Jul 25 17:07:46 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Jul 2019 21:07:46 +0000
Subject: [New-bugs-announce] [issue37685] Fix equality checks for some types
Message-ID: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The __eq__ implementation should return NotImplemented instead of False or raising an exception (like AttributeError or TypeError) when it does not support comparison with the other operand's type. It is so for most of implementations in the stdlib, but there are several exceptions. The proposed patch fixes these cases.

----------
components: Library (Lib)
messages: 348452
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix equality checks for some types
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37685>
_______________________________________

From report at bugs.python.org  Thu Jul 25 18:08:27 2019
From: report at bugs.python.org (Bin Hu)
Date: Thu, 25 Jul 2019 22:08:27 +0000
Subject: [New-bugs-announce] [issue37686] No error message in joining two
 root directories
Message-ID: <1564092507.62.0.964588671803.issue37686@roundup.psfhosted.org>


New submission from Bin Hu <hubin.lanl at gmail.com>:

Two root directories shall not be joined in the first place. But, when such a command is passed, os.path.join() module should give a warning message instead of just keeping the second argument being passed as the output. 

Python 3.7.3 (default, Mar 27 2019, 16:54:48)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.4.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from os import path

In [2]: a = '/tmp'

In [3]: b = '/data'

In [4]: print(path.join(a, b))
/data

In [5]: b = 'data'

In [6]: print(path.join(a, b))
/tmp/data

----------
components: Extension Modules
messages: 348457
nosy: Bin Hu
priority: normal
severity: normal
status: open
title: No error message in joining two root directories
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37686>
_______________________________________

From report at bugs.python.org  Thu Jul 25 18:34:42 2019
From: report at bugs.python.org (belegnar)
Date: Thu, 25 Jul 2019 22:34:42 +0000
Subject: [New-bugs-announce] [issue37687] Invalid regexp should rise
 exception
Message-ID: <1564094082.03.0.663017833645.issue37687@roundup.psfhosted.org>


New submission from belegnar <admin at zilantkon.ru>:

`re.error` should be rised on `re.compile("string{data}")` because manual says only numbers are valid within `{}`

----------
components: Regular Expressions
messages: 348458
nosy: belegnar, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Invalid regexp should rise exception
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37687>
_______________________________________

From report at bugs.python.org  Fri Jul 26 03:23:57 2019
From: report at bugs.python.org (Kirill Balunov)
Date: Fri, 26 Jul 2019 07:23:57 +0000
Subject: [New-bugs-announce] [issue37688] The results from
 os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path
 strings.
Message-ID: <1564125837.91.0.494799678642.issue37688@roundup.psfhosted.org>


New submission from Kirill Balunov <kirill.balunov at gmail.com>:

In the documentation it is said that os.path.isdir(...) an Path(...).is_dir()are equivalent substitutes.
https://docs.python.org/3/library/pathlib.html#correspondence-to-tools-in-the-os-module

But they give different result for empty path strings:
>>> import os
>>> from pathlib import Path
>>> dummy = "" 
>>> os.path.isdir(dummy)
 False

Obviously it's not an equivalence, so either this should be noted in the documentation or corrected in the code.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 348475
nosy: docs at python, godaygo
priority: normal
severity: normal
status: open
title: The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37688>
_______________________________________

From report at bugs.python.org  Fri Jul 26 11:56:04 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Jul 2019 15:56:04 +0000
Subject: [New-bugs-announce] [issue37689] Add Path.is_relative_to()
Message-ID: <1564156564.69.0.23140154802.issue37689@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

Right now, to know whether a Path is relative to another one, you have to call Path.relative_to(), catch ValueError, and act in consequence.

It would be nice to have a Path.is_relative_to() that does the equivalent for you and returns True/False.

This is probably a good easy issue for a beginner contributor.

----------
components: Library (Lib)
keywords: easy
messages: 348498
nosy: pitrou, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Add Path.is_relative_to()
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37689>
_______________________________________

From report at bugs.python.org  Fri Jul 26 13:32:29 2019
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Fri, 26 Jul 2019 17:32:29 +0000
Subject: [New-bugs-announce] [issue37690] Simplify linking of shared
 libraries on the AIX OS
Message-ID: <1564162349.26.0.0398435522922.issue37690@roundup.psfhosted.org>


New submission from Eric N. Vander Weele <ericvw at gmail.com>:

Have the approach of building shared libraries on the AIX operating
system be similar to that of a System V system.  The primary benefit of
this change is the elimination of custom AIX paths and reducing the
changes at `./configure` to affect just the `LDSHARED` environment
variable.

For background context, AIX sees shared libraries as fully linked and
resolved, where symbol references are resolved at link-time and cannot
be rebound at load-time.  System V resolves all global symbols by the
run-time linker.  Thus, conventional shared libraries in AIX cannot have
undefined symbols, while System V can.

However, AIX does allow for run-time linking in allowing symbols to be
undefined until load-time.

Therefore, this change affects how linking of shared libraries are
performed on AIX to behave similarly to that of System V.

Given that symbols are now going to be allowed to be undefined for AIX,
all the code paths for generating exported symbols and the related
wrapper scripts go away.

The real magic is in the `-G` flag for `LDSHARED`.  Effectively, `-G`
is equivalent to specifying the following:

* -berok: Suppress errors even if there are unresolved symbols
* -brtl: Enable run-time linking
* -bnortllib: Do not include a reference to the run-time linker
* -bnosymbolic: Assigns 'nosymbolic' attribute to most symbols (i.e.,
                can be rebound)
* -bnoautoexp: Prevent auto exportation of any symbols
* -bM:SRE: Set the module type to reusable (i.e., require a private copy
           of the data area for each process).

I have been using this patch for Python 3.7, 3.6, and 2.7 (with appropriate backporting adaptations) without issue for being able to build and use Python C/C++ extensions on AIX for about 6 months now.  Given that we haven't had any issues, I felt it was appropriate to see if this would be accepted upstream.

----------
components: Build, Extension Modules
files: aix-extension-simplify.patch
keywords: patch
messages: 348511
nosy: ericvw
priority: normal
severity: normal
status: open
title: Simplify linking of shared libraries on the AIX OS
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48508/aix-extension-simplify.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37690>
_______________________________________

From report at bugs.python.org  Sat Jul 27 01:28:58 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Jul 2019 05:28:58 +0000
Subject: [New-bugs-announce] [issue37691] Let math.dist() accept coordinates
 as sequences
Message-ID: <1564205338.06.0.366598705946.issue37691@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

I did some user testing with Python 3.8 and found that math.dist() was a little restrictive in only accepting coordinates as tuples.  Mostly it worked out fine except but was a little inconvenient with generalized unpacking:

   label, *coordinates = cursor.fetchone()  # coordinates is a list

Also, it would be nice to allow numpy arrays as arguments.

----------
assignee: rhettinger
components: Library (Lib)
messages: 348541
nosy: mark.dickinson, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Let math.dist() accept coordinates as sequences
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37691>
_______________________________________

From report at bugs.python.org  Sat Jul 27 12:49:33 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Jul 2019 16:49:33 +0000
Subject: [New-bugs-announce] [issue37692] IDLE: clarify shell part of
 highlight sample
Message-ID: <1564246173.2.0.322711834924.issue37692@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The 'console' highlight is described as Shell Normal Text.  It is the 'normal' text for non-error output *from the shell* (prompt and debug status), but not the 'normal' text, which is used for code.

Aside from this, the editor section uses examples rather than description, such as 'list' rather than 'builtin'.  I think the shell section should also:  "Traceback" instead of stderr (which beginners may or may not understand), 'program output' instead of 'stdout'.  Removing the two blank line will make room to put these on separate lines, like they actually are.

----------
assignee: terry.reedy
components: IDLE
messages: 348548
nosy: terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: clarify shell part of highlight sample
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37692>
_______________________________________

From report at bugs.python.org  Sat Jul 27 14:07:58 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 27 Jul 2019 18:07:58 +0000
Subject: [New-bugs-announce] [issue37693] IDLE: File names are hidden in
 "Open" menu (Linux)
Message-ID: <1564250878.35.0.446772632023.issue37693@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

In the most recent development version of Python 3.9, when opening the file selection menu through File > Open (or Ctrl-o) in the IDLE, the file names are hidden. Clicking once on each of the icons or the areas in front of them can make the names visible again, but this can be quite cumbersome to users. I'm not certain if this issue is specific to KWin (window manager, component of the Plasma DE), but I've never ran into this problem when using any other applications. 

If it would be helpful, I can attempt to see if this issue occurs when using other window managers.  I attached two screenshots below, the first one is the initial view of "Open" menu and the second one is what it looks like after clicking once on a few of the icons.

Tested on...
OS: Arch Linux 5.2.3
DE: Plasma
WM: KWin

----------
files: bpo-idle-open-menu-0.png
messages: 348554
nosy: aeros167
priority: normal
severity: normal
status: open
title: IDLE: File names are hidden in "Open" menu (Linux)
versions: Python 3.9
Added file: https://bugs.python.org/file48509/bpo-idle-open-menu-0.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37693>
_______________________________________

From report at bugs.python.org  Sat Jul 27 16:52:03 2019
From: report at bugs.python.org (Alexandre Hamelin)
Date: Sat, 27 Jul 2019 20:52:03 +0000
Subject: [New-bugs-announce] [issue37694] Crash when calling
 zipimport.zipimporter.__new__().<method>()
Message-ID: <1564260723.26.0.279102723907.issue37694@roundup.psfhosted.org>


New submission from Alexandre Hamelin <quad.on at gmail.com>:

Found a crash with zipimport.zipimporter. Might or might not be related to Issue31723 which I've found searching the issues afterwards.

    import zipimport
    zipimport.zipimporter.__new__(zipimport.zipimporter).find_module('')

Python 2.7 and 3.6. Seems to be 'fixed' in 3.7+ (Linux, x86-64); reports that __init__ hasn't been called yet.

Found during manual testing in a break-the-python-jail CTF-like challenge.

Backtrace for Python 2.7
Python 2.7.15 (default, Oct 10 2018, 09:10:43)
[GCC 6.4.0] on linux2

$ gdb -q python2
Reading symbols from python2...(no debugging symbols found)...done.
(gdb) run zipcrash.py
Starting program: /usr/bin/python2 zipcrash.py
process 11106 is executing new program: /usr/bin/python2.7
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a86695 in PyString_AsString () from /usr/lib64/libpython2.7.so.1.0
(gdb) bt
#0  0x00007ffff7a86695 in PyString_AsString () from /usr/lib64/libpython2.7.so.1.0
#1  0x00007ffff7b20269 in ?? () from /usr/lib64/libpython2.7.so.1.0
#2  0x00007ffff7b20400 in ?? () from /usr/lib64/libpython2.7.so.1.0
#3  0x00007ffff7adb3e7 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#4  0x00007ffff7adca6c in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#5  0x00007ffff7adcb59 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#6  0x00007ffff7af60df in ?? () from /usr/lib64/libpython2.7.so.1.0
#7  0x00007ffff7af7322 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0
#8  0x00007ffff7af8535 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#9  0x00007ffff7b0a537 in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#10 0x00007ffff74281db in __libc_start_main () from /lib64/libc.so.6
#11 0x00005555555547ca in _start ()
(gdb)


Backtrace for Python 3.6
Python 3.6.5 (default, Jul 16 2018, 11:40:44)
[GCC 6.4.0] on linux

$ gdb -q python3
Reading symbols from python3...(no debugging symbols found)...done.
(gdb) run zipcrash.py
Starting program: /usr/bin/python3 zipcrash.py
process 11149 is executing new program: /usr/bin/python3.6m
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7aa5eea in ?? () from /usr/lib64/libpython3.6m.so.1.0
(gdb) bt
#0  0x00007ffff7aa5eea in ?? () from /usr/lib64/libpython3.6m.so.1.0
#1  0x00007ffff7aa6a92 in ?? () from /usr/lib64/libpython3.6m.so.1.0
#2  0x00007ffff7aa6c9c in ?? () from /usr/lib64/libpython3.6m.so.1.0
#3  0x00007ffff7aa6f49 in ?? () from /usr/lib64/libpython3.6m.so.1.0
#4  0x00007ffff79a8d49 in _PyCFunction_FastCallDict () from /usr/lib64/libpython3.6m.so.1.0
#5  0x00007ffff7a1d0d5 in ?? () from /usr/lib64/libpython3.6m.so.1.0
#6  0x00007ffff7a20dea in _PyEval_EvalFrameDefault () from /usr/lib64/libpython3.6m.so.1.0
#7  0x00007ffff7a1cc3c in ?? () from /usr/lib64/libpython3.6m.so.1.0
#8  0x00007ffff7a1d1ce in PyEval_EvalCodeEx () from /usr/lib64/libpython3.6m.so.1.0
#9  0x00007ffff7a1d1fb in PyEval_EvalCode () from /usr/lib64/libpython3.6m.so.1.0
#10 0x00007ffff7a478b4 in ?? () from /usr/lib64/libpython3.6m.so.1.0
#11 0x00007ffff7a49f35 in PyRun_FileExFlags () from /usr/lib64/libpython3.6m.so.1.0
#12 0x00007ffff7a4a0a5 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython3.6m.so.1.0
#13 0x00007ffff7a610a3 in Py_Main () from /usr/lib64/libpython3.6m.so.1.0
#14 0x0000555555554b99 in main ()
(gdb)

----------
components: Extension Modules
messages: 348563
nosy: Alexandre Hamelin
priority: normal
severity: normal
status: open
title: Crash when calling zipimport.zipimporter.__new__().<method>()
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37694>
_______________________________________

From report at bugs.python.org  Sat Jul 27 23:14:58 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 28 Jul 2019 03:14:58 +0000
Subject: [New-bugs-announce] [issue37695] Incorrect error message for
 `unget_wch(bytes_object)`
Message-ID: <1564283698.6.0.693266446979.issue37695@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

For example:

    curses.unget_wch(b'x')
TypeError: expect bytes or str of length 1, or int, got bytes

----------
components: Extension Modules
messages: 348570
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: Incorrect error message for `unget_wch(bytes_object)`
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37695>
_______________________________________

From report at bugs.python.org  Sun Jul 28 10:51:10 2019
From: report at bugs.python.org (David Wilson)
Date: Sun, 28 Jul 2019 14:51:10 +0000
Subject: [New-bugs-announce] [issue37696] FileIO.read() on a closed TTY
 throws an exception prematurely
Message-ID: <1564325470.84.0.0876609070441.issue37696@roundup.psfhosted.org>


New submission from David Wilson <dw at botanicus.net>:

Given:

    $ cat tty-failure.py 

    import pty
    import os

    master, slave = pty.openpty()
    master = os.fdopen(master, 'r+b', 0)
    slave = os.fdopen(slave, 'r+b', 0)
    slave.write(b'foo')
    slave.close()
    print(master.read())

On Python 2, read() would return b'foo', with subsequent calls raising IOError, whereas on Python 3 an OSError is raised due to the underlying file descriptor returning EIO.

In the case of a PTY, EIO indicates the remote side has hung up and more or less can be treated as an EOF indicator.

On Python 3 the partial buffer should not be discarded when a subsequent read() syscall returns an error.

Secondarily, the change from IOError to OSError looks wrong. Does anyone know what's going on there? I would never expect to see OSError raised by a builtin

----------
components: IO
messages: 348578
nosy: dw
priority: normal
severity: normal
status: open
title: FileIO.read() on a closed TTY throws an exception prematurely
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37696>
_______________________________________

From report at bugs.python.org  Sun Jul 28 12:14:59 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 28 Jul 2019 16:14:59 +0000
Subject: [New-bugs-announce] [issue37697] Incorporate changes from
 importlib_metadata 0.19
Message-ID: <1564330499.13.0.825368111768.issue37697@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Importlib_metadata 0.19 is about to release. Let's sync the code with that milestone (https://gitlab.com/python-devs/importlib_metadata/-/milestones/20).

----------
components: Library (Lib)
messages: 348581
nosy: barry, jaraco
priority: normal
severity: normal
status: open
title: Incorporate changes from importlib_metadata 0.19
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37697>
_______________________________________

From report at bugs.python.org  Sun Jul 28 13:24:40 2019
From: report at bugs.python.org (hai shi)
Date: Sun, 28 Jul 2019 17:24:40 +0000
Subject: [New-bugs-announce] [issue37698] Update doc of PyBuffer_ToContiguous
Message-ID: <1564334680.0.0.401210106575.issue37698@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

Due to https://github.com/python/cpython/blob/master/Objects/memoryobject.c#L985,
order could be 'A' in PyBuffer_ToContiguous()

----------
assignee: docs at python
components: Documentation
messages: 348585
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: Update doc of PyBuffer_ToContiguous

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37698>
_______________________________________

From report at bugs.python.org  Sun Jul 28 23:34:58 2019
From: report at bugs.python.org (Brian Skinn)
Date: Mon, 29 Jul 2019 03:34:58 +0000
Subject: [New-bugs-announce] [issue37699] Explicit mention of raised
 ValueError's after .detach() of underlying IO buffer
Message-ID: <1564371298.05.0.400100937454.issue37699@roundup.psfhosted.org>


New submission from Brian Skinn <bskinn at alum.mit.edu>:

Once the underlying buffer/stream is .detach()ed from an instance of a subclass of TextIOBase or BufferedIOBase, accession of most attributes defined on TextIOBase/BufferedIOBase or the IOBase parent, as well as calling of most methods defined on TextIOBase/BufferedIOBase/IOBase, results in raising of a ValueError.

Currently, the documentation of both .detach() methods states simply:

> After the raw stream has been detached, the buffer is in an unusable state.

I propose augmenting the above to something like the following in the docs for both .detach() methods, to make this behavior more explicit:

> After the raw stream has been detached, the buffer
> is in an unusable state. As a result, accessing/calling most
> attributes/methods of either :class:`BufferedIOBase` or its
> :class:`IOBase` parent will raise :exc:`ValueError`.

I confirm that the error raised for both `BufferedReader` and `TextIOWrapper` after `.detach()` *is* ValueError in all of 3.5.7, 3.6.8, 3.7.3, and 3.8.0b1.

----------
assignee: docs at python
components: Documentation
messages: 348594
nosy: bskinn, docs at python
priority: normal
severity: normal
status: open
title: Explicit mention of raised ValueError's after .detach() of underlying IO buffer
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37699>
_______________________________________

From report at bugs.python.org  Mon Jul 29 00:22:16 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Mon, 29 Jul 2019 04:22:16 +0000
Subject: [New-bugs-announce] [issue37700] shutil.copyfile does not raise
 SpecialFileError for socket files
Message-ID: <1564374136.89.0.594392746042.issue37700@roundup.psfhosted.org>


New submission from Christopher Hunt <chrahunt at gmail.com>:

Currently shutil.copyfile only raises SpecialFileError for named pipes. When trying to use the function to copy a socket file, the exception raised depends on the platform, for example:

macOS: "[Errno 102] Operation not supported on socket: '/Users/guido/src/mypy/dmypy.sock'"
HP-UX: "[Errno 223] Operation not supported: 'example/foo'"
Solaris: "[Errno 122] Operation not supported on transport endpoint: 'example/foo'"
AIX: "[Errno 64] Operation not supported on socket: '../../example/foo'"
Linux: "[Errno 6] No such device or address: 'example/foo'"

This can be reproduced like:

    import os
    import shutil
    import socket
    import tempfile

    d = tempfile.mkdtemp()
    src = os.path.join(d, "src")
    dest = os.path.join(d, "dest")
    sock = socket.socket(socket.AF_UNIX)
    sock.bind(src)

    shutil.copyfile(src, dest)

Making shutil.copyfile raise SpecialFileError for socket files would improve the interface of this function since the same class of error could be ignored. This is mostly useful with shutil.copytree, which defaults to copyfile for its copy function.

----------
components: Library (Lib)
messages: 348595
nosy: chrahunt
priority: normal
severity: normal
status: open
title: shutil.copyfile does not raise SpecialFileError for socket files
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37700>
_______________________________________

From report at bugs.python.org  Mon Jul 29 00:36:51 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Mon, 29 Jul 2019 04:36:51 +0000
Subject: [New-bugs-announce] [issue37701] shutil.copyfile raises
 SpecialFileError for symlink to fifo
Message-ID: <1564375011.26.0.591034083368.issue37701@roundup.psfhosted.org>


New submission from Christopher Hunt <chrahunt at gmail.com>:

Currently shutil.copyfile raises SpecialFileError when src is a link to a fifo. To reproduce:

    import os
    import shutil
    import tempfile
    
    
    d = tempfile.mkdtemp()
    fifo = os.path.join(d, 'fifo')
    link_to_fifo = os.path.join(d, 'link-to-fifo')
    copy_of_link_to_fifo = os.path.join(d, 'copy-of-link-to-fifo')
    
    
    os.mkfifo(fifo)
    os.symlink(fifo, link_to_fifo)
    shutil.copyfile(link_to_fifo, copy_of_link_to_fifo)

Example output:

    Traceback (most recent call last):
      File "repro.py", line 14, in <module>
        shutil.copyfile(link_to_fifo, copy_of_link_to_fifo)
      File "/home/chris/.pyenv/versions/3.7.2/lib/python3.7/shutil.py", line 115, in copyfile
        raise SpecialFileError("`%s` is a named pipe" % fn)
    shutil.SpecialFileError: `/tmp/user/1000/tmpxhigll5g/link-to-fifo` is a named pipe

I would have expected this to copy the symlink without complaint. Raising a SpecialFileError would be OK if `follow_symlinks` was False.

----------
components: Library (Lib)
messages: 348597
nosy: chrahunt
priority: normal
severity: normal
status: open
title: shutil.copyfile raises SpecialFileError for symlink to fifo
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37701>
_______________________________________

From report at bugs.python.org  Mon Jul 29 03:45:29 2019
From: report at bugs.python.org (neonene)
Date: Mon, 29 Jul 2019 07:45:29 +0000
Subject: [New-bugs-announce] [issue37702] memory leak in ssl certification
Message-ID: <1564386329.8.0.956014299339.issue37702@roundup.psfhosted.org>


New submission from neonene <nicesalmon at gmail.com>:

Windows10/7(x86/x64)
After issue35941 (any PR merged)

In https-access, memory usage increases by about 200KB per urlopen()
and easily reach to giga bytes.

I found out leak of certificate-store-handles in _ssl.c and made patch,
which works fine for my pc.

I guess some users are in trouble with this leak.
I'm about to raise PR, so please review. Thanks!

----------
assignee: christian.heimes
components: SSL, Windows
messages: 348600
nosy: christian.heimes, neonene, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: memory leak in ssl certification
type: resource usage
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37702>
_______________________________________

From report at bugs.python.org  Mon Jul 29 04:50:09 2019
From: report at bugs.python.org (Dmitrii Ivaniushin)
Date: Mon, 29 Jul 2019 08:50:09 +0000
Subject: [New-bugs-announce] [issue37703] Inconsistent gather with child
 exception
Message-ID: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org>


New submission from Dmitrii Ivaniushin <defance at gmail.com>:

I found some issue that I suppose is a bug.

Let us have long running coroutines. We use them in gather, and one of them raises an error. Since then we cannot cancel the gather anymore, thus remaining children are not cancelable and executed until complete or raise an exception themselves.

===

import asyncio


async def coro_with_error():
    # Coro raises en error with 1 sec delay
    await asyncio.sleep(1)
    raise Exception('Error in coro')


async def cancellator(coro):
    # We use this to cancel gather with delay 1 sec
    await asyncio.sleep(1)
    coro.cancel()


async def success_long_coro():
    # Long running coro, 2 sec
    try:
        await asyncio.sleep(2)
        print("I'm ok!")
        return 42
    except asyncio.CancelledError:
        # Track that this coro is really cancelled
        print('I was cancelled')
        raise


async def collector_with_error():
    gather = asyncio.gather(coro_with_error(), success_long_coro())
    try:
        await gather
    except Exception:
        print(f"WHOAGH ERROR, gather done={gather.done()}")
        print(f'EXC={type(gather.exception()).__name__}')
        # We want to cancel still running success_long_coro()
        gather.cancel()


async def collector_with_cancel():
    # Gather result from success_long_coro()
    gather = asyncio.gather(success_long_coro())
    # schedule cancel in 1 sec
    asyncio.create_task(cancellator(gather))
    try:
        await gather
    except Exception:
        print(f"WHOAGH ERROR, gather done={gather.done()}")
        print(f'EXC={type(gather.exception()).__name__}')
        # We want to cancel still running success_long_coro()
        gather.cancel()
        return

# First case, cancel gather when children are running
print('First case')
loop = asyncio.get_event_loop()
loop.create_task(collector_with_cancel())
# Ensure test coros we fully run
loop.run_until_complete(asyncio.sleep(3))
print('Done')

# Second case, cancel gather when child raise error
print('Second case')
loop = asyncio.get_event_loop()
loop.create_task(collector_with_error())
# Ensure test coros we fully run
loop.run_until_complete(asyncio.sleep(3))
print('Done')

===

Actual output:

    First case
    I was cancelled
    WHOAGH ERROR, gather done=True
    EXC=CancelledError
    Done
    Second case
    WHOAGH ERROR, gather done=True
    EXC=Exception
    I'm ok!
    Done

Expected output:

    First case
    I was cancelled
    WHOAGH ERROR, gather done=True
    EXC=CancelledError
    Done
    Second case
    I was cancelled
    WHOAGH ERROR, gather done=True
    EXC=Exception
    Done

Documentations says:
> If gather() is cancelled, all submitted awaitables (that have not completed yet) are also cancelled.
But it mentions no cases on child coros' exceptions.

>From doc:
> If return_exceptions is False (default), the first raised exception is immediately propagated to the task that awaits on gather(). Other awaitables in the aws sequence won?t be cancelled and will continue to run.
Which is true, exception is propagated, the gather has an exception set, marked as done() so its children are not cancelled.

I believe asyncio should allow cancellation in that case.

----------
components: asyncio
messages: 348603
nosy: Dmitrii Ivaniushin, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Inconsistent gather with child exception
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37703>
_______________________________________

From report at bugs.python.org  Mon Jul 29 07:58:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jul 2019 11:58:12 +0000
Subject: [New-bugs-announce] [issue37704] Remove Tools/scripts/h2py.py
Message-ID: <1564401492.74.0.0281923171365.issue37704@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Python 2 standard library had platform specific modules like CDROM which were generated by Tools/scripts/h2py.py. These modules were removed, but h2py.py is still around.

There are now way better ways to expose C APIs in Python like cffi.

I propose to simply remove Tools/scripts/h2py.py.

Attached PR removes the file and update files which mention it. It would allow to simply close bpo-13032.

----------
components: Library (Lib)
messages: 348643
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove Tools/scripts/h2py.py
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37704>
_______________________________________

From report at bugs.python.org  Mon Jul 29 09:41:00 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 29 Jul 2019 13:41:00 +0000
Subject: [New-bugs-announce] [issue37705] winerror_to_errno implementation
Message-ID: <1564407660.89.0.454912973453.issue37705@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

OSError and _Py_fstat_noraise rely on winerror_to_errno() in PC/errmap.h in order to translate a Windows system error code into a POSIX errno value. PC/errmap.h is supposed to be generated by PC/generrmap.c, which is based on the old CRT's _dosmapperr() function. However, this function isn't implemented in the Universal CRT, and ucrt's corresponding function, __acrt_errno_from_os_error, isn't exported for public use.

If generrmap.c is effectively dead, then it's no longer possible to add custom mappings there, as was done for issue 12802 (ERROR_DIRECTORY -> ENOTDIR) and issue 13063 (ERROR_NO_DATA -> EPIPE). Also, errmap.h hasn't been regenerated in 8 years, and since then the CRT added a new mapped value: ERROR_NO_UNICODE_TRANSLATION (1113) -> EILSEQ. 

Unless someone can suggest a way to continue automatically generating errmap.h via generrmap.c, then I think winerror_to_errno should be manually implemented in a more readable and maintainable way, and updated from the ucrt source (ucrt\misc\errno.cpp) with each major Python release. The implementation could use a switch statement like it currently does, but with named error codes, grouped by result. For example:

    int
    winerror_to_errno(int winerror)
    {
        switch(winerror) {
        case ERROR_FILE_NOT_FOUND:            //    2
        case ERROR_PATH_NOT_FOUND:            //    3
        case ERROR_INVALID_DRIVE:             //   15
        case ERROR_NO_MORE_FILES:             //   18
        case ERROR_BAD_NETPATH:               //   53
        case ERROR_BAD_NET_NAME:              //   67
        case ERROR_BAD_PATHNAME:              //  161
        case ERROR_FILENAME_EXCED_RANGE:      //  206
            return ENOENT;

        case ERROR_BAD_ENVIRONMENT:           //   10
            return E2BIG;

        case ERROR_BAD_FORMAT:                //   11
        case ERROR_INVALID_STARTING_CODESEG:  //  188
        case ERROR_INVALID_STACKSEG:          //  189
        case ERROR_INVALID_MODULETYPE:        //  190
        case ERROR_INVALID_EXE_SIGNATURE:     //  191
        case ERROR_EXE_MARKED_INVALID:        //  192
        case ERROR_BAD_EXE_FORMAT:            //  193
        case ERROR_ITERATED_DATA_EXCEEDS_64k: //  194
        case ERROR_INVALID_MINALLOCSIZE:      //  195
        case ERROR_DYNLINK_FROM_INVALID_RING: //  196
        case ERROR_IOPL_NOT_ENABLED:          //  197
        case ERROR_INVALID_SEGDPL:            //  198
        case ERROR_AUTODATASEG_EXCEEDS_64k:   //  199
        case ERROR_RING2SEG_MUST_BE_MOVABLE:  //  200
        case ERROR_RELOC_CHAIN_XEEDS_SEGLIM:  //  201
        case ERROR_INFLOOP_IN_RELOC_CHAIN:    //  202
            return ENOEXEC;

        case ERROR_INVALID_HANDLE:            //    6
        case ERROR_INVALID_TARGET_HANDLE:     //  114
        case ERROR_DIRECT_ACCESS_HANDLE:      //  130
            return EBADF;

        case ERROR_WAIT_NO_CHILDREN:          //  128
        case ERROR_CHILD_NOT_COMPLETE:        //  129
            return ECHILD;

        case ERROR_NO_PROC_SLOTS:             //   89
        case ERROR_MAX_THRDS_REACHED:         //  164
        case ERROR_NESTING_NOT_ALLOWED:       //  215
            return EAGAIN;

        case ERROR_ARENA_TRASHED:             //    7
        case ERROR_NOT_ENOUGH_MEMORY:         //    8
        case ERROR_INVALID_BLOCK:             //    9
        case ERROR_NOT_ENOUGH_QUOTA:          // 1816
            return ENOMEM;

        case ERROR_ACCESS_DENIED:             //    5
        case ERROR_CURRENT_DIRECTORY:         //   16
        case ERROR_WRITE_PROTECT:             //   19
        case ERROR_BAD_UNIT:                  //   20
        case ERROR_NOT_READY:                 //   21
        case ERROR_BAD_COMMAND:               //   22
        case ERROR_CRC:                       //   23
        case ERROR_BAD_LENGTH:                //   24
        case ERROR_SEEK:                      //   25
        case ERROR_NOT_DOS_DISK:              //   26
        case ERROR_SECTOR_NOT_FOUND:          //   27
        case ERROR_OUT_OF_PAPER:              //   28
        case ERROR_WRITE_FAULT:               //   29
        case ERROR_READ_FAULT:                //   30
        case ERROR_GEN_FAILURE:               //   31
        case ERROR_SHARING_VIOLATION:         //   32
        case ERROR_LOCK_VIOLATION:            //   33
        case ERROR_WRONG_DISK:                //   34
        case ERROR_SHARING_BUFFER_EXCEEDED:   //   36
        case ERROR_NETWORK_ACCESS_DENIED:     //   65
        case ERROR_CANNOT_MAKE:               //   82
        case ERROR_FAIL_I24:                  //   83
        case ERROR_DRIVE_LOCKED:              //  108
        case ERROR_SEEK_ON_DEVICE:            //  132
        case ERROR_NOT_LOCKED:                //  158
        case ERROR_LOCK_FAILED:               //  167
        case 35:                              //   35 [undefined]
            return EACCES;

        case ERROR_FILE_EXISTS:               //   80
        case ERROR_ALREADY_EXISTS:            //  183
            return EEXIST;

        case ERROR_NOT_SAME_DEVICE:           //   17
            return EXDEV;

        case ERROR_DIRECTORY:                 //  267 [bpo-12802]
            return ENOTDIR;

        case ERROR_TOO_MANY_OPEN_FILES:       //    4
            return EMFILE;

        case ERROR_DISK_FULL:                 //  112
            return ENOSPC;

        case ERROR_BROKEN_PIPE:               //  109
        case ERROR_NO_DATA:                   //  232 [bpo-13063]
            return EPIPE;

        case ERROR_DIR_NOT_EMPTY:             //  145
            return ENOTEMPTY;

        case ERROR_NO_UNICODE_TRANSLATION:    // 1113
            return EILSEQ;

        case ERROR_INVALID_FUNCTION:          //    1
        case ERROR_INVALID_ACCESS:            //   12
        case ERROR_INVALID_DATA:              //   13
        case ERROR_INVALID_PARAMETER:         //   87
        case ERROR_NEGATIVE_SEEK:             //  131
        default:
            return EINVAL;
        }
    }

----------
components: Interpreter Core, Windows
messages: 348661
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: winerror_to_errno implementation
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37705>
_______________________________________

From report at bugs.python.org  Mon Jul 29 10:41:39 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 29 Jul 2019 14:41:39 +0000
Subject: [New-bugs-announce] [issue37706] IDLE test_sidebar testcases
 test_click_selection and test_drag_selection can fail on macOS
Message-ID: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org>


New submission from Ned Deily <nad at python.org>:

On macOS, there are two test failure seen with test_sidebar (tested on 10.14 with Tk 8.6.8 and 8.6.0 - the failures should be reproducible with the python.org 3.8.0b3 installer for macOS which will be available soon.)

======================================================================
FAIL: test_click_selection (idlelib.idle_test.test_sidebar.LineNumbersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/idle_test/test_sidebar.py", line 253, in test_click_selection
    self.assertEqual(self.get_selection(), ('2.0', '3.0'))
AssertionError: Tuples differ: ('1.0', '2.0') != ('2.0', '3.0')

First differing element 0:
'1.0'
'2.0'

- ('1.0', '2.0')
+ ('2.0', '3.0')

======================================================================
FAIL: test_drag_selection (idlelib.idle_test.test_sidebar.LineNumbersTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/idlelib/idle_test/test_sidebar.py", line 273, in test_drag_selection
    self.assertEqual(self.get_selection(), ('1.0', '4.0'))
AssertionError: Tuples differ: ('1.0', '3.0') != ('1.0', '4.0')

First differing element 1:
'3.0'
'4.0'

- ('1.0', '3.0')
?          ^

+ ('1.0', '4.0')
?          ^


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

----------
assignee: terry.reedy
components: IDLE
messages: 348666
nosy: ned.deily, taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE test_sidebar testcases test_click_selection and test_drag_selection can fail on macOS
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37706>
_______________________________________

From report at bugs.python.org  Mon Jul 29 14:34:07 2019
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 29 Jul 2019 18:34:07 +0000
Subject: [New-bugs-announce] [issue37707] Skip individual unit tests that
 are expensive for the PGO task
Message-ID: <1564425247.23.0.845576191882.issue37707@roundup.psfhosted.org>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

Add a new support decorator, @skip_if_pgo_task and then use it to mark test cases.  I suspect the PGO task works well if it can exercise common code paths.  Running long tests likely have rapidly diminishing benefits.  The instrumented PGO executable runs quite a bit slower than a normal build and so it is useful to spend a bit of time to exclude expensive tests.

----------
components: Build
messages: 348677
nosy: nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: Skip individual unit tests that are expensive for the PGO task
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37707>
_______________________________________

From report at bugs.python.org  Mon Jul 29 15:28:24 2019
From: report at bugs.python.org (Lex Flagel)
Date: Mon, 29 Jul 2019 19:28:24 +0000
Subject: [New-bugs-announce] [issue37708] Harmonize random.choice(s)
 behavior with random.sample on iterators
Message-ID: <1564428504.8.0.524832279971.issue37708@roundup.psfhosted.org>


New submission from Lex Flagel <flag0010 at gmail.com>:

It would be nice to make random.sample and random.choice both have the same behavior with iterators. Currently random.sample accepts them happily, and whereas random.choice does not.  E.g.

> import random
> d = {'a':1, 'b':2}
> random.sample(d.keys(),1)
Out: ['a']

> random.choice(d.keys())
Out: TypeError: 'dict_keys' object is not subscriptable

random.choice could be redefined as follows to harmonize behavior, but I think the solution for random.choices maybe be more involved:

def choice(x): 
    random.sample(x,1)[0]

----------
components: Library (Lib)
messages: 348680
nosy: Lex Flagel
priority: normal
severity: normal
status: open
title: Harmonize random.choice(s) behavior with random.sample on iterators
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37708>
_______________________________________

From report at bugs.python.org  Mon Jul 29 15:32:08 2019
From: report at bugs.python.org (Benjamin Schollnick)
Date: Mon, 29 Jul 2019 19:32:08 +0000
Subject: [New-bugs-announce] [issue37709] CSVReader ignores
 dialect.lineterminator
Message-ID: <1564428728.47.0.33259508348.issue37709@roundup.psfhosted.org>


New submission from Benjamin Schollnick <bschollnick at schollnick.net>:

I've run into a situation where the CSV input file is very unusual.  The Delimiter is "\x06" and the lineterminator is "\x07".

While I've written code to work around this, it would be significantly nicer if the CSV Reader code actually paid attention to the dialect's lineterminator value.

----------
components: Library (Lib)
messages: 348681
nosy: Benjamin Schollnick
priority: normal
severity: normal
status: open
title: CSVReader ignores dialect.lineterminator
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37709>
_______________________________________

From report at bugs.python.org  Mon Jul 29 17:17:25 2019
From: report at bugs.python.org (Andrew Collins)
Date: Mon, 29 Jul 2019 21:17:25 +0000
Subject: [New-bugs-announce] [issue37710] Python SSL module does not clear
 error queue before IO operations using SSL_get_error
Message-ID: <1564435045.14.0.99217067203.issue37710@roundup.psfhosted.org>


New submission from Andrew Collins <bsderandrew at gmail.com>:

Per the OpenSSL documentation:

"The current thread's error queue must be empty before the TLS/SSL I/O operation is attempted, or SSL_get_error() will not work reliably."

https://www.openssl.org/docs/man1.1.1/man3/SSL_get_error.html

Modules/_ssl.c does clear errors on socket creation, and upon handling an error itself, but does not clear before IO operations that are checked with SSL_get_error.

When using OpenSSL outside of Modules/_ssl.c in the same process context (for example, using libssh through python bindings), this can results in random ssl errors being picked up by Modules/_ssl.c.

----------
assignee: christian.heimes
components: SSL
messages: 348684
nosy: Andrew Collins, christian.heimes
priority: normal
severity: normal
status: open
title: Python SSL module does not clear error queue before IO operations using SSL_get_error
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37710>
_______________________________________

From report at bugs.python.org  Mon Jul 29 19:44:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jul 2019 23:44:36 +0000
Subject: [New-bugs-announce] [issue37711] regrtest: re-run tests in
 subprocesses
Message-ID: <1564443876.23.0.3433987967.issue37711@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

When using python3 -m test -w, failed tests are re-run in the regrtest main process, even if -jN option is used. If a test does crash, regrtest doesn't remove its temporary directory which can lead to random test failures like bpo-37359.

At least when using -jN, I suggest to run tests in a subprocess to ensure that regrtest is able to cleanup its temporary directory, even if a test does crash.

----------
components: Tests
messages: 348700
nosy: vstinner
priority: normal
severity: normal
status: open
title: regrtest: re-run tests in subprocesses
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37711>
_______________________________________

From report at bugs.python.org  Mon Jul 29 20:57:04 2019
From: report at bugs.python.org (Matthew Roeschke)
Date: Tue, 30 Jul 2019 00:57:04 +0000
Subject: [New-bugs-announce] [issue37712] Exception frames from
 unittest.TestCase.fail dependent on nesting
Message-ID: <1564448224.13.0.206274970387.issue37712@roundup.psfhosted.org>


New submission from Matthew Roeschke <mroeschke at housecanary.com>:

With this toy example:

import unittest

def this_fails():
    a = 1 + None

class TestExample(unittest.TestCase):

    def test_this(self):
        try:
            this_fails()
        except Exception:
            self.fail('Fail')

if __name__ == '__main__':
    unittest.run()

I get the last frame for each chained exception:

Traceback (most recent call last):
  File "/Users/me/test.py", line 10, in test_this
    this_fails()
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/me/test.py", line 12, in test_this
    self.fail('Fail')
AssertionError: Fail

But if the toy example contained a nested call, e.g.

    def helper(self):
        try:
            this_fails()
        except Exception:
            self.fail('Fail')

    def test_this(self):
        self.helper() 

I get the last 2 frames for each chained exception:

Traceback (most recent call last):
  File "/Users/me/test.py", line 10, in helper
    this_fails()
  File "/Users/me/test.py", line 4, in this_fails
    a = 1 + None
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/me/test.py", line 15, in test_this
    self.helper()
  File "/Users/me/test.py", line 12, in helper
    self.fail('Fail')
AssertionError: Fail

Ideally, it would be great if the traceback went back to the root of the exception regardless.

----------
components: Library (Lib)
messages: 348708
nosy: Matthew Roeschke
priority: normal
severity: normal
status: open
title: Exception frames from unittest.TestCase.fail dependent on nesting
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37712>
_______________________________________

From report at bugs.python.org  Mon Jul 29 23:39:50 2019
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 30 Jul 2019 03:39:50 +0000
Subject: [New-bugs-announce] [issue37713] 2to3 division problems leading to
 program crashes in Python3
Message-ID: <1564457990.59.0.231280845163.issue37713@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

The snake game will report a crash in Python3:
Traceback (most recent call last):
File "/home/xxm/Desktop/instrument/datasetpy3/Snake_game/runGame.py",line 20, in <module>
        w.addch(food[0], food[1], curses.ACS_PI)
TypeError: integer argument expected, got float

food is assigned at line 19 "food = [sh/2, sw/2]"
addch accepts "int" as the types of the first two parameter. In Python2, it will work well since the results of division will be "int".In Python3  ,the results will be "float"

----------
components: 2to3 (2.x to 3.x conversion tool)
files: runGame.py
messages: 348712
nosy: xxm
priority: normal
severity: normal
status: open
title: 2to3 division problems leading to  program crashes in Python3
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48512/runGame.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37713>
_______________________________________

From report at bugs.python.org  Tue Jul 30 00:26:13 2019
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 30 Jul 2019 04:26:13 +0000
Subject: [New-bugs-announce] [issue37714] 2to3  tab Problems
Message-ID: <1564460773.29.0.466388706007.issue37714@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Traceback (most recent call last):
  File "/home/xxm/Desktop/instrument/datasetpy3/FrisPy/example.py", line 4, in <module>
    import FrisPy
  File "/home/xxm/Desktop/instrument/datasetpy3/FrisPy/FrisPy/__init__.py", line 5, in <module>
    from .disc import *
  File "/home/xxm/Desktop/instrument/datasetpy3/FrisPy/FrisPy/disc.py", line 7, in <module>
    from . import coefficient_model
  File "/home/xxm/Desktop/instrument/datasetpy3/FrisPy/FrisPy/coefficient_model.py", line 34
    if isinstance(args[0],np.ndarray): args = args[0]
                                                    ^
TabError: inconsistent use of tabs and spaces in indentation

It seems that it will better to use 4 spaces to replace "tab" in 2to3.

----------
components: 2to3 (2.x to 3.x conversion tool)
files: example.py
messages: 348714
nosy: xxm
priority: normal
severity: normal
status: open
title: 2to3  tab Problems
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file48513/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37714>
_______________________________________

From report at bugs.python.org  Tue Jul 30 02:11:45 2019
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 30 Jul 2019 06:11:45 +0000
Subject: [New-bugs-announce] [issue37715] 2to3 set default encoding
Message-ID: <1564467105.65.0.60061017687.issue37715@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

There is a bug in lib2to3. When dealing with this project "struts-scan" by 2to3,the following bug will show up. 
Traceback (most recent call last):
  File "/home/xxm/Desktop/instrument/datasetpy3/struts-scan/struts-scan.py", line 18, in <module>
    sys.setdefaultencoding('utf-8')
AttributeError: module 'sys' has no attribute 'setdefaultencoding'

"sys.setdefaultencoding('utf-8')" is not dealt with by lib2to3. In Python3, there is no such API "setdefaultencoding" for "sys". 

A possible solution to improve 2to3 is to delete this line     "sys.setdefaultencoding('utf-8')" when converting Python2 projects

----------
components: 2to3 (2.x to 3.x conversion tool)
files: struts-scan.py
messages: 348716
nosy: xxm
priority: normal
severity: normal
status: open
title: 2to3 set default encoding
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file48514/struts-scan.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37715>
_______________________________________

From report at bugs.python.org  Tue Jul 30 02:37:14 2019
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 30 Jul 2019 06:37:14 +0000
Subject: [New-bugs-announce] [issue37716] 2to3 Accuracy of calculation
Message-ID: <1564468634.17.0.599980785257.issue37716@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

In Python 2,the output is 1366. After converting by 2to3, the output is 1197.1463275484991

There exists bug in the conversion of 2to3. The output should be consistent for original Python2 code and converted Python3 code. 

At line 10 of this python file. The code "integer /= 10" is not converted by 2to3. Then I find there is no fixer for division in 2to3,which may lead to inaccuracy of output or even worse results.

A possible fix solution is for the division problem of 2to3 I can think is that for division expression such as a/b in Python2, we can add the following type check to check type of a,b as a fix for conversion of 2to3:

def DivOp(a, b):
       if (isinstance(a, int) and isinstance(b, int)):
                      return (a // b)
       else:
                      return (a / b)  
and modify a/b as Div(a,b) in converted Python3 file

----------
components: 2to3 (2.x to 3.x conversion tool)
files: euler016.py
messages: 348717
nosy: xxm
priority: normal
severity: normal
status: open
title: 2to3 Accuracy of calculation
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48515/euler016.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37716>
_______________________________________

From report at bugs.python.org  Tue Jul 30 03:44:41 2019
From: report at bugs.python.org (retnikt)
Date: Tue, 30 Jul 2019 07:44:41 +0000
Subject: [New-bugs-announce] [issue37717] argparse subcommand docs has
 non-existent parameter "action"
Message-ID: <1564472681.57.0.734846453793.issue37717@roundup.psfhosted.org>


New submission from retnikt <retnikt at gmail.com>:

In the library documentation for argparse, the section for ArgumentParser.add_subparsers ( https://docs.python.org/3/library/argparse.html#sub-commands ) states that there is a parameter for 'action' with the description 'the basic type of action to be taken when this argument is encountered at the command line'. However, no such parameter actually exists, and passing it to the function causes very strange behaviour:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/argparse.py", line 1716, in add_subparsers
    action = parsers_class(option_strings=[], **kwargs)
TypeError: __init__() got an unexpected keyword argument 'parser_class'

This line should be removed from the documentation. It is present in versions 3.4+ and 2.7

----------
assignee: docs at python
components: Documentation
messages: 348718
nosy: docs at python, retnikt
priority: normal
severity: normal
status: open
title: argparse subcommand docs has non-existent parameter "action"
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37717>
_______________________________________

From report at bugs.python.org  Tue Jul 30 04:24:58 2019
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 30 Jul 2019 08:24:58 +0000
Subject: [New-bugs-announce] [issue37718] 2to3  exception handling
Message-ID: <1564475098.96.0.917553706699.issue37718@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

we run the converted Python3 code, the following error will happen:
Traceback (most recent call last):
  File "/home/xxm/Desktop/instrument/datasetpy3/Labeled-LDA-Python/example.py", line 50, in <module>
    llda_model.save_model_to_dir(save_model_dir)
  File "/home/xxm/Desktop/instrument/datasetpy3/Labeled-LDA-Python/model/labeled_lda.py", line 697, in save_model_to_dir
    LldaModel._write_object_to_file(save_model_path, save_model.__dict__)
  File "/home/xxm/Desktop/instrument/datasetpy3/Labeled-LDA-Python/model/labeled_lda.py", line 650, in _write_object_to_file
    print(("%s\n\t%s" % (message, e.message)))
AttributeError: 'TypeError' object has no attribute 'message'

it seems that attributes change between Python2 and Python3. However 2to3 lack for this fix when dealing with exception fix.

----------
components: 2to3 (2.x to 3.x conversion tool)
files: labeled_lda.py
messages: 348720
nosy: xxm
priority: normal
severity: normal
status: open
title: 2to3  exception handling
versions: Python 3.7
Added file: https://bugs.python.org/file48516/labeled_lda.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37718>
_______________________________________

From report at bugs.python.org  Tue Jul 30 05:46:06 2019
From: report at bugs.python.org (=?utf-8?q?Xavier_Doll=C3=A9?=)
Date: Tue, 30 Jul 2019 09:46:06 +0000
Subject: [New-bugs-announce] [issue37719] addSubtest not calling addFailure
 and addError
Message-ID: <1564479966.23.0.678975484256.issue37719@roundup.psfhosted.org>


New submission from Xavier Doll? <xdo at odoo.com>:

addSubTest from TestResult is appending elements to failures and errors without using addFailure or addError, making the extend of this class more difficult.

suggestion:

def addSubTest(self, test, subtest, err):
...
    if issubclass(err[0], test.failureException):
        self.addFailure(subtest, err)
    else:
        self.addError(subtest, err)

The suggested change would make it more concise and easier to extend.

----------
components: Tests
messages: 348728
nosy: Xavier Doll?
priority: normal
severity: normal
status: open
title: addSubtest not calling addFailure and addError
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37719>
_______________________________________

From report at bugs.python.org  Tue Jul 30 06:14:00 2019
From: report at bugs.python.org (Hans Peter)
Date: Tue, 30 Jul 2019 10:14:00 +0000
Subject: [New-bugs-announce] [issue37720] Crash of python3.7 with
 virt-manager
Message-ID: <1564481640.74.0.184955629667.issue37720@roundup.psfhosted.org>


New submission from Hans Peter <peace-full at web.de>:

Hi!

A few days ago, I upgraded to UbuntuMate 19.04.

I can't run 'virt-manager' because of this:

# virt-manager
Output: Segmentation fault


kernel: [ 2003.888116] virt-manager[16014]: segfault at 32d0 ip 00000000000032d0 sp 00007ffeb09ac658 error 14 in python3.7[400000+21000]

kernel: [ 2003.888124] Code: Bad RIP value.

Look at "crash_and_packages.log" I added to attachment.

Please help, to fix that. Thanks!

----------
components: Installation
files: crash_and_packages.log
messages: 348730
nosy: mother-earth40
priority: normal
severity: normal
status: open
title: Crash of python3.7 with virt-manager
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48517/crash_and_packages.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37720>
_______________________________________

From report at bugs.python.org  Tue Jul 30 11:41:30 2019
From: report at bugs.python.org (cherusk)
Date: Tue, 30 Jul 2019 15:41:30 +0000
Subject: [New-bugs-announce] [issue37721] smtpd: staling connect
Message-ID: <1564501290.13.0.408923844386.issue37721@roundup.psfhosted.org>


New submission from cherusk <matthias.tafelmeier at gmx.net>:

>From PR:

Following script stals/hangs. According to my tracing done, in the smtpd component. The concept of the script is baseline of my unit testing for [1], so not hypothetical:

import logging
import sys
logging.basicConfig(level=logging.DEBUG, stream=sys.stdout)

from smtpd import DebuggingServer as TestMailServer
import threading
from notifiers import get_notifier
import time
import itertools as it

mail_server = threading.Thread(target=TestMailServer, args=(("localhost", 2500), None))
mail_server.daemon = True
mail_server.start()

time.sleep(2)


for msg in it.repeat('copy', 100):
    print(msg)
    get_notifier('email').notify(from_='cherusk at localhost',
                                 to='root at localhost',
                                 message=msg,
                                 subject='TST',
                                 host='localhost',
                                 port=2500,
                                 tls=False,
                                 ssl=False,
                                 html=False,
                                 username="some",
                                 password='pw'
                                 )

I evaluated that on several platforms(FED29, UBUNTU-Latest), same symptoms. Also, on network stack I saw a clean TCP handshake happening, also cleanly ACKed by the smptd. So, presumption is that it's something in the dispatcher.

[1] https://github.com/cherusk/tw_timeliness/blob/master/test/time_engine_test.py

----------
components: email
messages: 348752
nosy: barry, cherusk, r.david.murray
priority: normal
pull_requests: 14785
severity: normal
status: open
title: smtpd: staling connect
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37721>
_______________________________________

From report at bugs.python.org  Tue Jul 30 15:33:35 2019
From: report at bugs.python.org (=?utf-8?b?0JjQstCw0L0g0JzQuNGF0LDQudC70L7Qsg==?=)
Date: Tue, 30 Jul 2019 19:33:35 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue37722=5D_imaplib_crashes_w?=
 =?utf-8?q?hen_trying_to_read_a_letter_from_an_imap_server_imaps=2E=D0=BF?=
 =?utf-8?b?0L7Rh9GC0LAu0YDRg9GB?=
Message-ID: <1564515215.95.0.35649081562.issue37722@roundup.psfhosted.org>


Change by ???? ???????? <artfulidalgo at gmail.com>:


----------
components: Library (Lib)
files: imaplib.png
nosy: ???? ????????
priority: normal
severity: normal
status: open
title: imaplib crashes when trying to read a letter from an imap server imaps.?????.???
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48520/imaplib.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37722>
_______________________________________

From report at bugs.python.org  Tue Jul 30 18:02:34 2019
From: report at bugs.python.org (yannvgn)
Date: Tue, 30 Jul 2019 22:02:34 +0000
Subject: [New-bugs-announce] [issue37723] important performance regression
 on regular expression parsing
Message-ID: <1564524154.39.0.245394903935.issue37723@roundup.psfhosted.org>


New submission from yannvgn <hi at yannvgn.io>:

On complex cases, parsing regular expressions takes much, much longer on Python >= 3.7

Example (ipython):

In [1]: import re
In [2]: char_list = ''.join([chr(i) for i in range(0xffff)])
In [3]: long_char_list = char_list * 10
In [4]: pattern = f'[{re.escape(long_char_list)}]'
In [5]: %time compiled = re.compile(pattern)

The test was run on Amazon Linux AMI 2017.03.

On Python 3.6.1, the regexp compiled in 2.6 seconds:
CPU times: user 2.59 s, sys: 30 ms, total: 2.62 s
Wall time: 2.64 s

On Python 3.7.3, the regexp compiled in 15 minutes (~350x increase in this case):
CPU times: user 15min 6s, sys: 240 ms, total: 15min 7s
Wall time: 15min 9s

Doing some profiling with cProfile shows that the issue is caused by sre_parse._uniq function, which does not exist in Python <= 3.6

The complexity of this function is on average O(N^2) but can be easily reduced to O(N).

The issue might not be noticeable with simple regexps, but programs like text tokenizers - which use complex regexps - might really be impacted by this regression.

----------
components: Regular Expressions
messages: 348771
nosy: ezio.melotti, mrabarnett, yannvgn
priority: normal
severity: normal
status: open
title: important performance regression on regular expression parsing
type: performance
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37723>
_______________________________________

From report at bugs.python.org  Tue Jul 30 18:20:23 2019
From: report at bugs.python.org (Tal Cohen)
Date: Tue, 30 Jul 2019 22:20:23 +0000
Subject: [New-bugs-announce] [issue37724] [[Errno 17] File exists: ] # Try
 create directories that are not part of the archive with
Message-ID: <1564525223.13.0.366878047407.issue37724@roundup.psfhosted.org>


Change by Tal Cohen <3talcohen at gmail.com>:


----------
components: Library (Lib)
nosy: Tal Cohen, lars.gustaebel
priority: normal
severity: normal
status: open
title: [[Errno 17] File exists: ] # Try create directories that are not part of the archive with
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37724>
_______________________________________

From report at bugs.python.org  Tue Jul 30 19:23:49 2019
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 30 Jul 2019 23:23:49 +0000
Subject: [New-bugs-announce] [issue37725] "make clean" should remove PGO
 task data
Message-ID: <1564529029.65.0.599090827857.issue37725@roundup.psfhosted.org>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

I find it annoying and surprising that "make clean" does not remove the PGO data.  If you change a source file, running "make clean" and "make" should result in a newly built executable, IMHO.  As it is now, you usually get a confusing build failure (PGO data is out of date).

The fix is fairly easy.  Make a new target that does what "clean" currently does.  Have the PGO build call that when it needs to preserve the PGO data.  Introduce a new "clean" target that does what the old clean did and also removes the PGO data.

Changing the build system is fraught with danger but I think this is a fairly safe change.  The current behavior is quite annoying, IMHO.

----------
components: Build
messages: 348773
nosy: nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: "make clean" should remove PGO task data
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37725>
_______________________________________

From report at bugs.python.org  Wed Jul 31 00:18:10 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 31 Jul 2019 04:18:10 +0000
Subject: [New-bugs-announce] [issue37726] Tutorial should not recommend
 getopt
Message-ID: <1564546690.91.0.192257836854.issue37726@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

I read on python-ideas that the tutorial recommends getopt as the simple argument parsing choice, and argparse as advanced. This is silly. We should only promote argparse (unless you want to use raw sys.argv[1:]).

----------
assignee: docs at python
components: Documentation
keywords: newcomer friendly
messages: 348774
nosy: docs at python, gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Tutorial should not recommend getopt
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37726>
_______________________________________

From report at bugs.python.org  Wed Jul 31 00:19:02 2019
From: report at bugs.python.org (Whitequill Riclo)
Date: Wed, 31 Jul 2019 04:19:02 +0000
Subject: [New-bugs-announce] [issue37727] error past 15 places
Message-ID: <1564546742.66.0.212195941437.issue37727@roundup.psfhosted.org>


New submission from Whitequill Riclo <theguild42 at gmail.com>:

I have found that when doing the calculation when running:

pow(1 + 1/100000000000000, 100000000000000) = 2.716110034087023

pow(1 + 1/1000000000000000, 1000000000000000) = 3.03503520654962

This is incorrect as the following is a well known way to calculate Euler's number.
I do not know what component is the cause so I just picked one.

----------
components: Library (Lib)
messages: 348775
nosy: Whitequill Riclo
priority: normal
severity: normal
status: open
title: error past 15 places
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37727>
_______________________________________

From report at bugs.python.org  Wed Jul 31 04:16:38 2019
From: report at bugs.python.org (rathinavelu thiruvenkatam)
Date: Wed, 31 Jul 2019 08:16:38 +0000
Subject: [New-bugs-announce] [issue37728] 'is' behaving differently in
 script and interactive shel
Message-ID: <1564560998.12.0.121909535779.issue37728@roundup.psfhosted.org>


New submission from rathinavelu thiruvenkatam <rathinavelu at gmail.com>:

af=1.1
bf=1.1
print(f'{af==bf},{af is bf}, {bf is af}' )

"""  Script outputs
 True,True, True. 

On Shell 
af=1.1
bf=1.1
print(f'{af==bf},{af is bf}, {bf is af}' )
True,False, False
"""

----------
messages: 348790
nosy: rathinavelu thiruvenkatam
priority: normal
severity: normal
status: open
title: 'is'  behaving differently in script and interactive shel
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37728>
_______________________________________

From report at bugs.python.org  Wed Jul 31 05:35:28 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 31 Jul 2019 09:35:28 +0000
Subject: [New-bugs-announce] [issue37729] gc: stats from multi process are
 mixed up
Message-ID: <1564565728.92.0.202188074199.issue37729@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

gc used several PySys_WriteStderr() calls to write stats.
This caused stats mixed up when stderr is shared by multiple
threads or processes.

Attached file (t.py) demonstrates it.
Sometimes stats from two processes are mixed up like this:

```
gc: collecting generation 0...
gc: objects in each generation: 782 0 7759
gc: objects in permanent generation: 0gc: collecting generation 0...

gc: objects in each generation: 782 0 7764
gc: objects in permanent generation: 0gc: done, 781 unreachable, 0 uncollectable, 0.0001s elapsed

gc: done, 781 unreachable, 0 uncollectable, 0.0000s elapsed
```

Writing one stat by one PySys_WriteStderr() reduces this.

----------
components: Interpreter Core
files: t.py
messages: 348795
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: gc: stats from multi process are mixed up
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48523/t.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37729>
_______________________________________

From report at bugs.python.org  Wed Jul 31 08:29:20 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jul 2019 12:29:20 +0000
Subject: [New-bugs-announce] [issue37730] NotImplemented is used instead of
 NotImplementedError in docs
Message-ID: <1564576160.73.0.181501805035.issue37730@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

In some places in the documentation NotImplemented is used instead of correct NotImplementedError.

All occurrences of NotImplemented should be manually checked and wrong spelling should be corrected.

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 348801
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: NotImplemented is used instead of NotImplementedError in docs
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37730>
_______________________________________

From report at bugs.python.org  Wed Jul 31 10:14:39 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 31 Jul 2019 14:14:39 +0000
Subject: [New-bugs-announce] [issue37731] Possible redifinition of
 _POSIX_C_SOURCE in ./pyconfig.h
Message-ID: <1564582479.63.0.743037360682.issue37731@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

While compiling Python, I got this warning.

./pyconfig.h:1590:0: warning: "_POSIX_C_SOURCE" redefined
 #define _POSIX_C_SOURCE 200809L

In file included from /usr/include/s390x-linux-gnu/bits/libc-header-start.h:33:0,
                 from /usr/include/string.h:26,
                 from /homes/jnanjeky/projects/cpython/Modules/expat/xmltok.c:34:
/usr/include/features.h:294:0: note: this is the location of the previous definition
 # define _POSIX_C_SOURCE 199506L

I think there is need to investigate this warning and potential remedy.

----------
messages: 348806
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Possible redifinition of _POSIX_C_SOURCE in ./pyconfig.h
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37731>
_______________________________________

From report at bugs.python.org  Wed Jul 31 10:17:16 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 31 Jul 2019 14:17:16 +0000
Subject: [New-bugs-announce] [issue37732] Possible uninitialized variable in
 Objects/obmalloc.c
Message-ID: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

Here is a compilation warning I got;

Objects/obmalloc.c: In function ?_PyObject_Malloc?:
Objects/obmalloc.c:1646:16: warning: ?ptr? may be used uninitialized in this function [-Wmaybe-uninitialized]
         return ptr;
                ^~~
We can investigate If its not a false alarm.

----------
messages: 348807
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Possible uninitialized variable in Objects/obmalloc.c
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37732>
_______________________________________

From report at bugs.python.org  Wed Jul 31 11:08:46 2019
From: report at bugs.python.org (LIU YONG)
Date: Wed, 31 Jul 2019 15:08:46 +0000
Subject: [New-bugs-announce] [issue37733] Fail to build Python 3.7.4 on AIX
 7.1 using gcc
Message-ID: <1564585726.95.0.247783534499.issue37733@roundup.psfhosted.org>


New submission from LIU YONG <ace.liuyong at gmail.com>:

Trying to build Python 3.7.4 on AIX 7.1 using gcc 6.3.0 but failed

Failed to build these modules:
_ctypes               _curses               _curses_panel    


building '_curses' extension
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include -I. -I/uxx/bxx/Python-3.7.4/Include -I/uxx/bxx/Python-3.7.4 -c /uxx/bxx/Python-3.7.4/Modules/_cursesmodule.c -o build/temp.aix-7.1-3.7/uxx/bxx/Python-3.7.4/Modules/_cursesmodule.o
Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-7.1-3.7/uxx/bxx/Python-3.7.4/Modules/_cursesmodule.o -lncurses -o build/lib.aix-7.1-3.7/_curses.so
ld: 0711-317 ERROR: Undefined symbol: .box32
ld: 0711-317 ERROR: Undefined symbol: ._setqiflush
ld: 0711-317 ERROR: Undefined symbol: .setsyx
ld: 0711-317 ERROR: Undefined symbol: ._getsyx
ld: 0711-317 ERROR: Undefined symbol: .w32attroff
ld: 0711-317 ERROR: Undefined symbol: .w32attron
ld: 0711-317 ERROR: Undefined symbol: .w32attrset
ld: 0711-317 ERROR: Undefined symbol: .w32addch
ld: 0711-317 ERROR: Undefined symbol: _unctrl
ld: 0711-317 ERROR: Undefined symbol: .w32insch
ld: 0711-317 ERROR: Undefined symbol: .w32echochar
ld: 0711-317 ERROR: Undefined symbol: .p32echochar
ld: 0711-317 ERROR: Undefined symbol: .initscr32
ld: 0711-317 ERROR: Undefined symbol: wacs_map
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
building '_curses_panel' extension
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include -I. -I/uxx/bxx/Python-3.7.4/Include -I/uxx/bxx/Python-3.7.4 -c /uxx/bxx/Python-3.7.4/Modules/_curses_panel.c -o build/temp.aix-7.1-3.7/uxx/bxx/Python-3.7.4/Modules/_curses_panel.o
In file included from /opt/freeware/include/ncurses/panel.h:42:0,
                 from /uxx/bxx/Python-3.7.4/Modules/_curses_panel.c:17:
/opt/freeware/include/ncurses/curses.h:388:16: error: conflicting types for 'attr_t'
 typedef chtype attr_t;  /* ...must be at least as wide as chtype */
                ^~~~~~
In file included from ./Include/py_curses.h:36:0,
                 from /uxx/bxx/Python-3.7.4/Modules/_curses_panel.c:15:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/6.3.0/include-fixed/curses.h:80:21: note: previous declaration of 'attr_t' was here
         typedef int attr_t;
                     ^~~~~~

----------
components: Build
messages: 348811
nosy: LIU YONG
priority: normal
severity: normal
status: open
title: Fail to build Python 3.7.4 on AIX 7.1 using gcc
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37733>
_______________________________________

From report at bugs.python.org  Wed Jul 31 12:20:02 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 31 Jul 2019 16:20:02 +0000
Subject: [New-bugs-announce] [issue37734] Registry keys for Windows Store
 package have wrong executable
Message-ID: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The next update to Windows will prevent launching executables from within the package install folder, and require you to launch from the user's local symlink to the executable (see issue37369).

Currently, the only value we can put into the registry when installing via the Store package points directly to the package install. There is no way to point at the local symlink.

I'm working with the Windows team to find either a fix or a workaround, but right now anyone who updates to preview Windows (or gets the update when it releases at the end of the year) will not be able to launch Python through tools that look in the registry.

----------
assignee: steve.dower
components: Windows
messages: 348812
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Registry keys for Windows Store package have wrong executable
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37734>
_______________________________________

From report at bugs.python.org  Wed Jul 31 12:49:40 2019
From: report at bugs.python.org (anand Mohan)
Date: Wed, 31 Jul 2019 16:49:40 +0000
Subject: [New-bugs-announce] [issue37735] Current Region as a Method either
 in openpyxl.worksheet.cell.Cell or .cell_range.CellRange
Message-ID: <1564591780.57.0.0395525070594.issue37735@roundup.psfhosted.org>


New submission from anand Mohan <anandupad at gmail.com>:

Excel has a CurrentRegion Method that is invoked as 
Range(range_string).CurrentRegion

The Idea behind this is to choose a region that have contiguous blank cells on all sides ( except the case of 1 column and 1 row ) that separate

I have Python code that I written to accomplish this Method. I have extended the CellRange class and added the methodand it is working as expected.

Please let me know if this will be a useful feature and I will submit code. It may not be the best code, but has performed well and correctly in all my testing so far 

Please see example snap shots attached fro Current Region is expected to work (for reference from the link
https://www.excel-easy.com/vba/examples/currentregion.html

Here is additional reference to the Method as implemented in Excel VBA
https://docs.microsoft.com/en-us/office/vba/api/excel.range.currentregion

----------
components: Demos and Tools
files: CurrentRegion.Example.png
messages: 348815
nosy: anand Mohan
priority: normal
severity: normal
status: open
title: Current Region as a Method either in openpyxl.worksheet.cell.Cell or .cell_range.CellRange
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file48524/CurrentRegion.Example.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37735>
_______________________________________