From report at bugs.python.org  Tue Oct  1 00:21:40 2019
From: report at bugs.python.org (paul rubin)
Date: Tue, 01 Oct 2019 04:21:40 +0000
Subject: [New-bugs-announce] [issue38333] add type signatures to library
 function docs
Message-ID: <1569903700.63.0.276076850828.issue38333@roundup.psfhosted.org>


New submission from paul rubin <phr-pythonbugs at nightsong.com>:

It would be nice if the library reference manual had type signatures for all the stdlib functions at some point.  It might be possible to extract a lot of them automatically from typeshed and semi-automatically paste them into the doc files.  It might also be ok to do this gradually.  I can help with this but wouldn't want to take on the entire task.

----------
assignee: docs at python
components: Documentation
messages: 353634
nosy: docs at python, phr
priority: normal
severity: normal
status: open
title: add type signatures to library function docs
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  1 04:17:22 2019
From: report at bugs.python.org (Daniel Hillier)
Date: Tue, 01 Oct 2019 08:17:22 +0000
Subject: [New-bugs-announce] [issue38334] zipfile: Seeking encrypted file
 breaks after seeking backwards
Message-ID: <1569917842.05.0.044912868688.issue38334@roundup.psfhosted.org>


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

Seeking back beyond the decrypted / unzipped buffer doesn't reset the decrypter's crc key values. All data read after seeking back beyond the buffer is garbled.

----------
components: Library (Lib)
messages: 353646
nosy: dhillier
priority: normal
severity: normal
status: open
title: zipfile: Seeking encrypted file breaks after seeking backwards
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  1 07:43:43 2019
From: report at bugs.python.org (Sanjay)
Date: Tue, 01 Oct 2019 11:43:43 +0000
Subject: [New-bugs-announce] [issue38335] simplify overlaps function in
 ipaddress.py
Message-ID: <1569930223.76.0.865877463422.issue38335@roundup.psfhosted.org>


New submission from Sanjay <sanjay537 at gmail.com>:

the current implementation of overlaps function tests either network or broadcast address is in other but
we can skip checking broadcast address is in other because we anyway check if other.network_address in self 

without loss of generality if we assume self has smaller prefixlen than other then when self.broadcast_address in other then other.network_address *SHOULD* be in self but the reverse is not true

so my first patch was to make the function logic simply do
`self.network_address in other or other.network_address in self`

but the current PR does a different change. We have introduced two new functions subnet_of and supernet_of

for two networks A, B there are only three possibilities 
1. they don't overlap
2. A is subnet of B
3. B is subnet of A

so we can reuse the existing function and just do
`return self.subnet_of(other) or self.supernet_of(other)`
the only thing is while overlaps() function returns false when we try to compare with a network or with diff version the other throws exception so I added a typecheck in the beginning.

P.S the docstring is slightly convoluted for newcomers, based on the three possibilities it should say "Tell if self is supernet or subnet of other" because "partly contained" can also mean two ranges intersect which can never happen to network prefixes. I have not made that change but can make it.

There are also some other issues I want to address but I want to do one at a time.

----------
components: Library (Lib)
files: skip_broadcast_in.patch
keywords: patch
messages: 353676
nosy: Sanjay
priority: normal
severity: normal
status: open
title: simplify overlaps function in ipaddress.py
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48634/skip_broadcast_in.patch

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

From report at bugs.python.org  Tue Oct  1 07:56:31 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Tue, 01 Oct 2019 11:56:31 +0000
Subject: [New-bugs-announce] [issue38336] Remove the __set__ method
 restriction on data descriptors for attribute lookup precedence
Message-ID: <1569930991.59.0.212656372364.issue38336@roundup.psfhosted.org>


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

The [language documentation](https://docs.python.org/3/reference/datamodel.html#invoking-descriptors) states:

> Data descriptors with __set__() and __get__() defined always override a redefinition in an instance dictionary. In contrast, non-data descriptors can be overridden by instances.

This override is not limited to data descriptors defining `__set__()` (and `__get__()`). It is also true for data descriptors defining `__delete__()` (and `__get__()`) and data descriptors defining both `__set__()` and `__delete__()` (and `__get__()`).

In other words, _any_ data descriptors (objects defining either `__set__()` or `__delete__()` or both) defining `__get__()` override an attribute redefinition in an instance dictionary.

----------
assignee: docs at python
components: Documentation
messages: 353685
nosy: docs at python, maggyero
priority: normal
severity: normal
status: open
title: Remove the __set__ method restriction on data descriptors for attribute lookup precedence
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct  1 08:01:59 2019
From: report at bugs.python.org (Jonas Drotleff)
Date: Tue, 01 Oct 2019 12:01:59 +0000
Subject: [New-bugs-announce] [issue38337] inspect: getmembers calls
 properties
Message-ID: <1569931319.11.0.161787180553.issue38337@roundup.psfhosted.org>


New submission from Jonas Drotleff <jonas.drotleff at gmail.com>:

When calling inspect.getmembers on a class that has a property (@property), the property will be called by the getattr call in getmembers.

Example:

import inspect

class Example:
    def __init__(self, var):
        self._var = var
        print('__init__')

    def foo(self, bar):
        print(bar)
        print('foo')

    @property
    def var(self):
        print('Access property')
        return self._var


if __name__ == '__main__':
    ex = Example('Hello')
    print('--- getmembers from instance ---')
    print(inspect.getmembers(ex))
    print('--- getmembers from class    ---')
    print(inspect.getmembers(Example))


Result:

__init__
--- getmembers from instance ---
Access property
[('__class__', <attribute '__class__' of 'object' objects>), ..., ('var', 'Hello')]
--- getmembers from class    ---
[('__class__', <attribute '__class__' of 'object' objects>), ..., ('var', <property object at 0x...>)]


Expected:

__init__
--- getmembers from instance ---
[('__class__', <attribute '__class__' of 'object' objects>), ..., ('var', <property object at 0x...>)]
--- getmembers from class    ---
[('__class__', <attribute '__class__' of 'object' objects>), ..., ('var', <property object at 0x...>)]

----------
components: Library (Lib)
messages: 353688
nosy: jnsdrtlf
priority: normal
severity: normal
status: open
title: inspect: getmembers calls properties
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/issue38337>
_______________________________________

From report at bugs.python.org  Tue Oct  1 08:55:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Oct 2019 12:55:54 +0000
Subject: [New-bugs-announce] [issue38338] [2.7] test_ssl fails
Message-ID: <1569934554.24.0.56143952582.issue38338@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

SSLv23 and TLS v1.0 are disabled by RHEL8 crypto policy.

AMD64 RHEL8 2.7:
https://buildbot.python.org/all/#/builders/245/builds/5

test_protocol_sslv23 (test.test_ssl.ThreadedTests)
Connecting to an SSLv23 server with various client options ... 
 Could not scan /etc/ssl/openssl.cnf for MinProtocol: [Errno 2] No such file or directory: '/etc/ssl/openssl.cnf'

 PROTOCOL_TLS->PROTOCOL_TLS CERT_NONE
 PROTOCOL_TLSv1->PROTOCOL_TLS CERT_NONE
ERROR

======================================================================
ERROR: test_protocol_sslv23 (test.test_ssl.ThreadedTests)
Connecting to an SSLv23 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/test/test_ssl.py", line 189, in f
    return func(*args, **kwargs)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/test/test_ssl.py", line 2402, in test_protocol_sslv23
    try_protocol_combo(ssl.PROTOCOL_SSLv23, ssl.PROTOCOL_TLSv1, 'TLSv1')
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/test/test_ssl.py", line 2134, in try_protocol_combo
    chatty=False, connectionchatty=False)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/test/test_ssl.py", line 2062, in server_params_test
    s.connect((HOST, server.port))
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/ssl.py", line 864, in connect
    self._real_connect(addr, False)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/ssl.py", line 855, in _real_connect
    self.do_handshake()
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/ssl.py", line 828, in do_handshake
    self._sslobj.do_handshake()
SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:727)

and

test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.1 server with various client options. ... 
 Could not scan /etc/ssl/openssl.cnf for MinProtocol: [Errno 2] No such file or directory: '/etc/ssl/openssl.cnf'

 PROTOCOL_TLSv1_1->PROTOCOL_TLSv1_1 CERT_NONE
 {PROTOCOL_TLS->PROTOCOL_TLSv1_1} CERT_NONE
 PROTOCOL_TLSv1_1->PROTOCOL_TLS CERT_NONE
ERROR

======================================================================
ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.1 server with various client options.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/test/test_ssl.py", line 189, in f
    return func(*args, **kwargs)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/test/test_ssl.py", line 2477, in test_protocol_tlsv1_1
    try_protocol_combo(ssl.PROTOCOL_SSLv23, ssl.PROTOCOL_TLSv1_1, 'TLSv1.1')
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/test/test_ssl.py", line 2134, in try_protocol_combo
    chatty=False, connectionchatty=False)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/test/test_ssl.py", line 2062, in server_params_test
    s.connect((HOST, server.port))
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/ssl.py", line 864, in connect
    self._real_connect(addr, False)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/ssl.py", line 855, in _real_connect
    self.do_handshake()
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64/build/Lib/ssl.py", line 828, in do_handshake
    self._sslobj.do_handshake()
SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:727)

----------
assignee: christian.heimes
components: SSL, Tests
messages: 353691
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: [2.7] test_ssl fails
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct  1 09:20:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Oct 2019 13:20:50 +0000
Subject: [New-bugs-announce] [issue38339] [3.5] The doc job of Travis CI
 fails on Python 3.5: needs at least Sphinx v1.8
Message-ID: <1569936050.09.0.437024380138.issue38339@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Example:
https://travis-ci.org/python/cpython/jobs/590339147

$ python --version

Python 3.6.3

$ pip --version

pip 9.0.1 from /home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages (python 3.6)

Could not locate requirements.txt. Override the install: key in your .travis.yml to install dependencies.
before_script.1

0.00s$ cd Doc
before_script.2

8.58s$ python -m pip install sphinx~=1.6.1 blurb

1.88s$ make check suspicious html SPHINXOPTS="-q -W -j4"

python3 tools/rstlint.py -i tools -i ./venv -i README.rst

No problems found.

make[1]: Entering directory `/home/travis/build/python/cpython/Doc'

mkdir -p build

Building NEWS from Misc/NEWS.d with blurb

PATH=./venv/bin:$PATH sphinx-build -b suspicious -d build/doctrees -D latex_elements.papersize= -q -W -j4 . build/suspicious 

Sphinx version error:

This project needs at least Sphinx v1.8 and therefore cannot be built with this version.

make[1]: *** [build] Error 1

make[1]: Leaving directory `/home/travis/build/python/cpython/Doc'

Suspicious check complete; look for any errors in the above output or in build/suspicious/suspicious.csv.  If all issues are false positives, append that file to tools/susp-ignored.csv.

make: *** [suspicious] Error 1

The command "make check suspicious html SPHINXOPTS="-q -W -j4"" exited with 2.
cache.2

store build cache

----------
assignee: docs at python
components: Documentation
messages: 353692
nosy: docs at python, mdk, vstinner
priority: normal
severity: normal
status: open
title: [3.5] The doc job of Travis CI fails on Python 3.5: needs at least Sphinx v1.8
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct  1 09:24:11 2019
From: report at bugs.python.org (ECAS India)
Date: Tue, 01 Oct 2019 13:24:11 +0000
Subject: [New-bugs-announce] [issue38340] ERROR WHILE BUILDING pyworld for
 x86_64-linux-gnu-gcc
Message-ID: <1569936251.44.0.0859719635079.issue38340@roundup.psfhosted.org>


New submission from ECAS India <erpuneetbawa at gmail.com>:

creating build/temp.linux-x86_64-3.7/lib/World
  creating build/temp.linux-x86_64-3.7/lib/World/src
  x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Ilib/World/src -I/usr/include/python3.7m -I/usr/local/lib/python3.7/dist-packages/numpy/core/include -c pyworld/pyworld.cpp -o build/temp.linux-x86_64-3.7/pyworld/pyworld.o
  x86_64-linux-gnu-gcc: error: pyworld/pyworld.cpp: No such file or directory
  x86_64-linux-gnu-gcc: fatal error: no input files
  compilation terminated.
  error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
  
  ----------------------------------------
  Failed building wheel for pyworld
  Running setup.py clean for pyworld
Failed to build pyworld

----------
files: Screenshot from 2019-10-01 18-53-25.png
messages: 353694
nosy: ECAS India
priority: normal
severity: normal
status: open
title: ERROR WHILE BUILDING pyworld for x86_64-linux-gnu-gcc
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file48635/Screenshot from 2019-10-01 18-53-25.png

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

From report at bugs.python.org  Tue Oct  1 16:50:46 2019
From: report at bugs.python.org (Norman Denayer)
Date: Tue, 01 Oct 2019 20:50:46 +0000
Subject: [New-bugs-announce] [issue38341] Add SMTPNotSupportedError in the
 exports of smtplib
Message-ID: <1569963046.98.0.477841717728.issue38341@roundup.psfhosted.org>


New submission from Norman Denayer <denayer.norman at gmail.com>:

Long story short:
smtplib.SMTPNotSupportedError seems the only exception not present in __all__ variable exposed by smtplib.py

Context:
I currently face an issue running mypy on one of my module:
...tools/email.py:46: error: Module has no attribute "SMTPNotSupportedError"
            except smtplib.SMTPNotSupportedError:

Digging into the context of this error, I note this exception is not exposed in the list __all__.

Regards,
Norman

----------
components: email
messages: 353712
nosy: Norman.Denayer, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Add SMTPNotSupportedError in the exports of smtplib
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct  1 18:22:11 2019
From: report at bugs.python.org (Anthony Tuininga)
Date: Tue, 01 Oct 2019 22:22:11 +0000
Subject: [New-bugs-announce] [issue38342] ImportError: cannot import name
 'MetadataPathFinder' from 'importlib.metadata'
Message-ID: <1569968531.94.0.379845933414.issue38342@roundup.psfhosted.org>


New submission from Anthony Tuininga <anthony.tuininga at gmail.com>:

Running the suggested code found at https://docs.python.org/3.8/whatsnew/3.8.html regarding the new importlib.metadata module

from importlib.metadata import version, requires, files
version('requests')

yields the error

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/importlib/metadata/__init__.py", line 365, in version
    return distribution(package).version
  File "/usr/local/lib/python3.8/importlib/metadata/__init__.py", line 338, in distribution
    return Distribution.from_name(package)
  File "/usr/local/lib/python3.8/importlib/metadata/__init__.py", line 159, in from_name
    dists = resolver(name)
  File "<frozen importlib._bootstrap_external>", line 1381, in find_distributions
ImportError: cannot import name 'MetadataPathFinder' from 'importlib.metadata' (/usr/local/lib/python3.8/importlib/metadata/__init__.py)

----------
components: Library (Lib)
messages: 353714
nosy: atuining
priority: normal
severity: normal
status: open
title: ImportError: cannot import name 'MetadataPathFinder' from 'importlib.metadata'
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct  1 19:01:39 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 01 Oct 2019 23:01:39 +0000
Subject: [New-bugs-announce] [issue38343] Version name in PC/layout read
 incorrectly for RC
Message-ID: <1569970899.08.0.367684181352.issue38343@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

I noticed that when the nuget.org packages published for 3.8.0rc1, they were given the version "3.8.0".

3.7.5rc1 was okay because it's still using the old approach to setting the version.

This needs to be fixed before any more RCs are released. I'll see if I can get the incorrectly versioned files removed from nuget and replace them with RCs.

----------
assignee: steve.dower
components: Windows
keywords: 3.8regression
messages: 353715
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Version name in PC/layout read incorrectly for RC
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct  2 02:30:23 2019
From: report at bugs.python.org (James Abel)
Date: Wed, 02 Oct 2019 06:30:23 +0000
Subject: [New-bugs-announce] [issue38344] activate.bat else needs to be on
 the same line as the if
Message-ID: <1569997823.02.0.0977203709428.issue38344@roundup.psfhosted.org>


New submission from James Abel <jamescabel at gmail.com>:

In activate.bat, the else needs to be on the same line as the if

----------
components: Windows
messages: 353722
nosy: James Abel, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: activate.bat else needs to be on the same line as the if
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct  2 02:30:42 2019
From: report at bugs.python.org (Robert Kearns)
Date: Wed, 02 Oct 2019 06:30:42 +0000
Subject: [New-bugs-announce] [issue38345] Add end lines to pyclbr objects
Message-ID: <1569997842.45.0.505629355226.issue38345@roundup.psfhosted.org>


Change by Robert Kearns <rxk0914 at hotmail.com>:


----------
components: Library (Lib)
nosy: RobertKearns
priority: normal
severity: normal
status: open
title: Add end lines to pyclbr objects
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  2 04:52:49 2019
From: report at bugs.python.org (Jim Jeon)
Date: Wed, 02 Oct 2019 08:52:49 +0000
Subject: [New-bugs-announce] [issue38346] Wrong behavior when using
 `assert_called_with` with mutable object
Message-ID: <1570006369.69.0.450054962888.issue38346@roundup.psfhosted.org>


New submission from Jim Jeon <jimjeon.me at gmail.com>:

When `assert_called_with` is used with mutable object, test fails if the object has changed. I think this is not what it meant to do.

https://docs.python.org/dev/library/unittest.mock-examples.html#coping-with-mutable-arguments

The same situation is explained in this document. But I don't understand why they did not fix and just are proposing some solutions to the users.

----------
components: Tests
files: Screen Shot 2019-10-02 at 5.22.05 PM.png
messages: 353727
nosy: Jim Jeon
priority: normal
severity: normal
status: open
title: Wrong behavior when using `assert_called_with` with mutable object
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file48638/Screen Shot 2019-10-02 at 5.22.05 PM.png

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

From report at bugs.python.org  Wed Oct  2 05:15:35 2019
From: report at bugs.python.org (=?utf-8?b?UsO8ZGlnZXIgUGzDvG0=?=)
Date: Wed, 02 Oct 2019 09:15:35 +0000
Subject: [New-bugs-announce] [issue38347] pathfix.py does not find Python
 scripts that have '-' in its filename
Message-ID: <1570007735.24.0.378926810144.issue38347@roundup.psfhosted.org>


New submission from R?diger Pl?m <r.pluem at gmx.de>:

Tools/scripts/pathfix.py does not find Python scripts that contain a '-' in their filename when working recursively.
This is caused by the regular expression used to detect whether a filename is a Python script:

r'^[a-zA-Z0-9_]+\.py$'

r'^[a-zA-Z0-9_-]+\.py$'

fixes this. I am not sure if you want to allow further characters in script names like spaces or other special characters. The pull request I will create will only fix the '-' issue.

----------
components: Demos and Tools
messages: 353728
nosy: rpluem
priority: normal
severity: normal
status: open
title: pathfix.py does not find Python scripts that have '-' in its filename
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  2 11:14:59 2019
From: report at bugs.python.org (Batuhan)
Date: Wed, 02 Oct 2019 15:14:59 +0000
Subject: [New-bugs-announce] [issue38348] Make python -m ast more
 configurable
Message-ID: <1570029299.56.0.0303865742584.issue38348@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

Allow user to set indent level and parsing status of type comments

----------
components: Library (Lib)
messages: 353741
nosy: BTaskaya, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Make python -m ast more configurable
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  2 12:10:03 2019
From: report at bugs.python.org (jackotonye)
Date: Wed, 02 Oct 2019 16:10:03 +0000
Subject: [New-bugs-announce] [issue38349] Email example using imaginary
 library installation error. The install shows that it only supports python
 2.x but is listed for python 3.6+
Message-ID: <1570032603.68.0.429442517445.issue38349@roundup.psfhosted.org>


New submission from jackotonye <tonyejck at gmail.com>:

https://docs.python.org/3.7/library/email.examples.html

----------
assignee: docs at python
components: Documentation
messages: 353743
nosy: docs at python, jackotonye
priority: normal
severity: normal
status: open
title: Email example using imaginary library installation error. The install shows that it only supports python 2.x but is listed for python 3.6+
type: resource usage
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct  2 12:35:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Oct 2019 16:35:07 +0000
Subject: [New-bugs-announce] [issue38350] ./configure --with-pydebug should
 use -O0 rather than -Og
Message-ID: <1570034107.68.0.232468214894.issue38350@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In Python 2.7, when using ./configure --with-pydebug, Python is built using -O0 compiler optimization level: disable all optimizations. The comment is quite explicit: "Optimization messes up debuggers, so turn it off for debug builds".

if test "$Py_DEBUG" = 'true' ; then
    # Optimization messes up debuggers, so turn it off for
    # debug builds.
    OPT="-g -O0 -Wall $STRICT_PROTO"
else
    OPT="-g $WRAP -O3 -Wall $STRICT_PROTO"
fi

In Python 3, -Og is preferred over -O0 for pydebug, if -Og is available:

if test "$Py_DEBUG" = 'true' ; then
    # Optimization messes up debuggers, so turn it off for
    # debug builds.
    if "$CC" -v --help 2>/dev/null |grep -- -Og > /dev/null; then
        OPT="-g -Og -Wall"
    else
        OPT="-g -O0 -Wall"
    fi
else
    OPT="-g $WRAP -O3 -Wall"
fi

Problem: in my experience, gdb traceback doesn't make sense sometimes, and gdb fails to inspect some function arguments and some variables which are displayed as <optimized out>.

See a very concrete example with a test_gdb failure on x86-64 when Python is compiled using gcc -Og:
https://bugzilla.redhat.com/show_bug.cgi?id=1734327#c22

My colleague who is working on gdb suggests to use -O0:
https://bugzilla.redhat.com/show_bug.cgi?id=1734327#c27

Since I started contributing to Python, I always forced gcc -O0 because any other optimization level caused me many issues in gdb. I'm using -O0 for 10 years with sucess.

The GCC documentation says "It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0." But my experience says the opposite.

Note: instead of -g, we could use -g3 to include debug information for macros and defines.

--

I'm proposing to change the *default* compiler flags from -Og to -O0. Obviously, Linux distributions and developers are free to override the compiler optimization level. For example: ./configure --with-pydebug CFLAGS="-Og" ensures that Python is always built using -Og.

I propose to modify 3.7, 3.8 and master branches.

----------
components: Build
messages: 353746
nosy: vstinner
priority: normal
severity: normal
status: open
title: ./configure --with-pydebug should use -O0 rather than -Og
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct  2 12:45:36 2019
From: report at bugs.python.org (Mariatta)
Date: Wed, 02 Oct 2019 16:45:36 +0000
Subject: [New-bugs-announce] [issue38351] Modernize email example from
 %-formatting to f-string
Message-ID: <1570034736.68.0.500723145519.issue38351@roundup.psfhosted.org>


New submission from Mariatta <mariatta at python.org>:

A string was formatted with %s in the code example 

https://github.com/python/cpython/blob/b3e7045f8314e7b62cd95861d207fe2f97e47198/Doc/includes/email-simple.py#L15 

```
msg['Subject'] = 'The contents of %s' % textfile
```

It would be great to modernize that into fstring.

Doc can be read at: https://docs.python.org/3.7/library/email.examples.html

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 353749
nosy: Mariatta, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Modernize email example from %-formatting to f-string
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct  2 14:31:17 2019
From: report at bugs.python.org (Karl Kornel)
Date: Wed, 02 Oct 2019 18:31:17 +0000
Subject: [New-bugs-announce] [issue38352] In typing docs,
 note explicit import needed for IO and Pattern/Match
Message-ID: <1570041077.58.0.399304866649.issue38352@roundup.psfhosted.org>


New submission from Karl Kornel <karl at kornel.us>:

Hello!

In https://github.com/python/cpython/blob/master/Lib/typing.py#L115-L117, there is a note about the io and re classes not being included in typing.__all__.  I am a relatively new user of typing, and I did `from typing import *` in my code.  I ran the code through mypy first, which reported no problems, but then running Python 3.6 failed with a NameError (name 'IO' is not defined).

Reading through the typing source, it's clear that this was an intentional decision.  So, instead of reporting a bug, I'd like to request a documentation enhancement!

The docs for typing make no mention of typing.io or typing.re.  So, my request is: In the sections for the IO/TextIO/BinaryIO and Pattern/Match classes, include text warning the user that these types are not imported when you do `from typing import *`.

----------
assignee: docs at python
components: Documentation
messages: 353763
nosy: Karl Kornel, docs at python
priority: normal
severity: normal
status: open
title: In typing docs, note explicit import needed for IO and Pattern/Match
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Oct  2 17:12:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Oct 2019 21:12:43 +0000
Subject: [New-bugs-announce] [issue38353] Cleanup the path configuration
 implementation code (getpath.c)
Message-ID: <1570050763.22.0.787922067096.issue38353@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Place holder issue for changes related to path configuration cleanup changes (Modules/getpath.c).

----------
components: Interpreter Core
messages: 353774
nosy: vstinner
priority: normal
severity: normal
status: open
title: Cleanup the path configuration implementation code (getpath.c)
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  2 17:32:12 2019
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 02 Oct 2019 21:32:12 +0000
Subject: [New-bugs-announce] [issue38354] Fix for bug 30378 regressed
 SysLogHandler
Message-ID: <1570051932.55.0.313239800858.issue38354@roundup.psfhosted.org>


New submission from Enji Cooper <yaneurabeya at gmail.com>:

The change made for bug 30378 caused a regression in our code by making
lookups for SysLogHandler addresses at init time, instead of making them more lazy. Example:

>>> import logging.handlers
>>> LOGGER = logging.getLogger("logger")
>>> LOGGER.addHandler(logging.handlers.SysLogHandler(address=('resolvessometimesbutnotthefirsttime.com', logging.handlers.SYSLOG_UDP_PORT)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/logging/handlers.py", line 767, in __init__
    ress = socket.getaddrinfo(host, port, 0, socktype)
socket.gaierror: [Errno -2] Name or service not known

This is exacerbated by the fact that a lot of code the organization I work for (and to be honest, I have written in the past) initializes global loggers once at import time. If the SysLogHandler is added to the global logger and the DNS resolution isn't possible (/etc/hosts is empty on Unix or does not contain the entry, and DNS out is to lunch), it will fall on its face at initialization time.

There needs to be a more graceful way of initializing loggers like this, or a way of delaying the host resolution, so it fails gracefully and doesn't crash the entire program (restoring the previous behavior).

Example: SMTPHandler doesn't do name resolution until it calls emit, which seems like a much more logical place to do the operation (especially since DNS records can change or become invalid).

----------
components: Library (Lib)
messages: 353775
nosy: calcheng, ngie
priority: normal
severity: normal
status: open
title: Fix for bug 30378 regressed SysLogHandler
type: crash
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/issue38354>
_______________________________________

From report at bugs.python.org  Wed Oct  2 18:37:37 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 02 Oct 2019 22:37:37 +0000
Subject: [New-bugs-announce] [issue38355] ntpath.realpath() fails on
 sys.executable
Message-ID: <1570055857.28.0.434394542652.issue38355@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The change to error handling did not include ERROR_CANT_ACCESS_FILE, but this error occurs in the Store package install.

After suppressing this error, it then occurs again when stripping the prefix - we should just check for the same error here to determine whether it's safe to remove the prefix of a file we can't access.

----------
assignee: steve.dower
components: Windows
keywords: 3.8regression
messages: 353782
nosy: lukasz.langa, paul.moore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: ntpath.realpath() fails on sys.executable
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct  2 18:53:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Oct 2019 22:53:01 +0000
Subject: [New-bugs-announce] [issue38356] test_asyncio:
 SubprocessThreadedWatcherTests leaks threads
Message-ID: <1570056781.39.0.894014377654.issue38356@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Warning seen o AMD64 Ubuntu Shared 3.x buildbot:
https://buildbot.python.org/all/#/builders/141/builds/2593

test_devnull_output (test.test_a=syncio.test_subprocess.SubprocessThreadedWatcherTests) ...
Warning -- threading_cleanup() failed to cleanup 1 threads (count: 1, dangling: 2)

The ThreadedChildWatcher class of asyncio.unix_events doesn't seem to have a method to join all threads. It should be done in tests to prevent "leaking" threads which can have side effects on following tests.

----------
components: Tests, asyncio
messages: 353784
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: SubprocessThreadedWatcherTests leaks threads
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  2 21:34:08 2019
From: report at bugs.python.org (Artificial)
Date: Thu, 03 Oct 2019 01:34:08 +0000
Subject: [New-bugs-announce] [issue38357] print adding extra bytes in hex
 above x7F
Message-ID: <1570066448.41.0.0345074372849.issue38357@roundup.psfhosted.org>


New submission from Artificial <me at artificialamateur.xyz>:

Any hex str of value above \x7F causes an extra byte to printed.

----------
files: Screenshot from 2019-10-02 20-31-50.png
messages: 353796
nosy: Artificial
priority: normal
severity: normal
status: open
title: print adding extra bytes in hex above x7F
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48641/Screenshot from 2019-10-02 20-31-50.png

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

From report at bugs.python.org  Thu Oct  3 04:50:12 2019
From: report at bugs.python.org (Puneet Bawa)
Date: Thu, 03 Oct 2019 08:50:12 +0000
Subject: [New-bugs-announce] [issue38358] ASSERTION ERROR WHILE USING
 TENSORFLOW
Message-ID: <1570092612.13.0.03397983919.issue38358@roundup.psfhosted.org>


New submission from Puneet Bawa <puneet.bawa at chitkara.edu.in>:

-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731a52f28>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07319edeb8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07319edeb8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07319cfe48>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07319cfe48>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073196d7f0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073196d7f0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731d361d0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731d361d0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731d361d0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731d361d0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731d361d0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731d361d0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731a743c8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731a743c8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073196bcf8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073196bcf8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731a4e748>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731a4e748>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731959668>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731959668>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073191ec50>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073191ec50>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07319023c8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07319023c8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07318b9400>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07318b9400>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731871a90>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731871a90>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073191d9e8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073191d9e8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073183da90>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073183da90>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731849f98>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731849f98>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07318a6e48>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07318a6e48>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731814470>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731814470>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07318227f0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07318227f0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073183d128>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073183d128>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07317db048>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07317db048>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07317cc048>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07317cc048>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731783e10>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731783e10>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073173ee10>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073173ee10>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073174b908>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073174b908>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07317f7208>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07317f7208>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731715e80>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731715e80>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731721c18>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731721c18>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07316ea588>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07316ea588>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073176fb00>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073176fb00>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731642be0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731642be0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07324fe5f8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07324fe5f8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07324fe5f8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07324fe5f8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07324fe5f8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07324fe5f8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07315f9fd0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07315f9fd0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073161c898>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073161c898>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731652080>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731652080>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07315d34a8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07315d34a8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731747a90>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731747a90>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731616080>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731616080>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073159bbe0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073159bbe0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07315ad898>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07315ad898>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073155d048>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073155d048>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731551358>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731551358>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073161c588>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073161c588>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731514240>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731514240>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314e3d68>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314e3d68>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314b8b70>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314b8b70>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314869b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314869b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314a12b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314a12b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314e9358>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314e9358>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314529b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314529b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731462518>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731462518>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313fd390>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313fd390>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313c2d30>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313c2d30>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313f8390>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313f8390>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313e87f0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313e87f0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731333b70>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731333b70>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731340630>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731340630>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073130ceb8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073130ceb8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731b4ee80>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731b4ee80>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731b4ee80>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731b4ee80>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731b4ee80>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731b4ee80>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312c42e8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312c42e8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314ce400>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07314ce400>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312e49e8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312e49e8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313b3ba8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07313b3ba8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312359e8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312359e8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312af4e0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312af4e0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312e4d30>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07312e4d30>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073197ec50>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073197ec50>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731bf9f28>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731bf9f28>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731227908>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731227908>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073127ccc0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073127ccc0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073116dcf8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073116dcf8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731178e10>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731178e10>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07311301d0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07311301d0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073124db38>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073124db38>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731168390>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731168390>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073115b7b8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073115b7b8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731121978>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731121978>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07310ce748>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07310ce748>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731130358>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731130358>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07310d87b8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07310d87b8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073106deb8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073106deb8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731084b38>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731084b38>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731092ba8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731092ba8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731026780>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731026780>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730fd09e8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730fd09e8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:From /home/puneet/kaldi-workspace/gan/Voice_Converter_CycleGAN/module.py:62: conv2d (from tensorflow.python.layers.convolutional) is deprecated and will be removed in a future version.
Instructions for updating:
Use `tf.keras.layers.Conv2D` instead.
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0731d6cef0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0731d6cef0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0731d6cef0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0731d6cef0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0731d6cef0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0731d6cef0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0731da9cf8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0731da9cf8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730fa3e80>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730fa3e80>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730f072b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730f072b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730ed8358>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730ed8358>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730f36978>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730f36978>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:From /home/puneet/kaldi-workspace/gan/Voice_Converter_CycleGAN/module.py:211: dense (from tensorflow.python.layers.core) is deprecated and will be removed in a future version.
Instructions for updating:
Use keras.layers.dense instead.
WARNING:tensorflow:Entity <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730dfe400>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730dfe400>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07313f8400>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07313f8400>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07313f8400>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07313f8400>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07313f8400>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07313f8400>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730efb860>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730efb860>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d97400>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d97400>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730e6e400>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730e6e400>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d4b908>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d4b908>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730df0668>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730df0668>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730e2d470>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730e2d470>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b647f0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b647f0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730cede80>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730cede80>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730df09e8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730df09e8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d4bbe0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d4bbe0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730cede80>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730cede80>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b510b8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b510b8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b16208>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b16208>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730c67588>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730c67588>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730c42978>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730c42978>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b64748>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b64748>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730adf5c0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730adf5c0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730adf5c0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730adf5c0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b646a0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b646a0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d82898>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d82898>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b110f0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b110f0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b45860>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730b45860>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a6f8d0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a6f8d0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730a8e550>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730a8e550>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730bb8710>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730bb8710>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730bb8710>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730bb8710>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730bb8710>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730bb8710>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07309fe128>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07309fe128>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07309faef0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07309faef0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a2fb00>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a2fb00>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07309c2fd0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07309c2fd0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a212b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a212b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730a76ba8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f0730a76ba8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a1d7f0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a1d7f0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a76ba8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a76ba8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a76ba8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a76ba8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a1d128>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730a1d128>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d82a58>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f0730d82a58>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f073096c080>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f073096c080>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07309362e8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f07309362e8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f073090e358>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv.call of <tensorflow.python.layers.convolutional.Conv2D object at 0x7f073090e358>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f07308f7518>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Dense.call of <tensorflow.python.layers.core.Dense object at 0x7f07308f7518>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:From /home/puneet/kaldi-workspace/gan/Voice_Converter_CycleGAN/model.py:93: The name tf.trainable_variables is deprecated. Please use tf.compat.v1.trainable_variables instead.

WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730893d68>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730893d68>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730893d68>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730893d68>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730893d68>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730893d68>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073093c710>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073093c710>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073083cb70>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073083cb70>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073087cb70>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073087cb70>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730936128>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730936128>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07308aaeb8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07308aaeb8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07308f7860>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07308f7860>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307ffbe0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307ffbe0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307d33c8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307d33c8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307b3898>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307b3898>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073078af28>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073078af28>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307aa3c8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307aa3c8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307a2630>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07307a2630>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306f09b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306f09b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306fd1d0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306fd1d0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306f0080>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306f0080>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306b3c18>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306b3c18>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073070f668>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073070f668>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306cd128>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306cd128>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073069c390>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073069c390>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306a5080>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306a5080>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730684978>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730684978>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073065ef28>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073065ef28>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07305f57b8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07305f57b8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07305c04a8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07305c04a8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07305cecf8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07305cecf8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07327527f0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07327527f0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07305386d8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07305386d8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07308932b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07308932b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07308932b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07308932b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731207128>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0731207128>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730f58eb8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730f58eb8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073056a160>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073056a160>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730627860>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730627860>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306a5320>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07306a5320>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07304f44e0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07304f44e0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730594588>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730594588>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730d65828>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730d65828>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07304a4320>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07304a4320>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073045d1d0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073045d1d0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07304f4e48>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07304f4e48>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073045dac8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073045dac8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730421b00>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730421b00>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303cd3c8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303cd3c8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303b6630>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303b6630>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303779b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303779b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303915f8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303915f8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303779b0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07303779b0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073034cc18>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073034cc18>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730331240>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730331240>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730363128>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f0730363128>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07302af390>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07302af390>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07302ba048>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07302ba048>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073028d0b8>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073028d0b8>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07302aafd0>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f07302aafd0>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:Entity <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073023ea90>> could not be transformed and will be executed as-is. Please report this to the AutgoGraph team. When filing the bug, set the verbosity to 10 (on Linux, `export AUTOGRAPH_VERBOSITY=10`) and attach the full output. Cause: converting <bound method Conv1D.call of <tensorflow.python.layers.convolutional.Conv1D object at 0x7f073023ea90>>: AssertionError: Bad argument number for Name: 3, expecting 4
WARNING:tensorflow:From /home/puneet/kaldi-workspace/gan/Voice_Converter_CycleGAN/model.py:107: The name tf.train.AdamOptimizer is deprecated. Please use tf.compat.v1.train.AdamOptimizer instead.

----------
components: Build
messages: 353831
nosy: Puneet Bawa
priority: normal
severity: normal
status: open
title: ASSERTION ERROR WHILE USING TENSORFLOW
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct  3 05:53:25 2019
From: report at bugs.python.org (Andrew Ushakov)
Date: Thu, 03 Oct 2019 09:53:25 +0000
Subject: [New-bugs-announce] [issue38359] pyw.exe opens console window in
 Windows 10
Message-ID: <1570096405.52.0.325874974028.issue38359@roundup.psfhosted.org>


New submission from Andrew Ushakov <andrew.ushakov at gmail.com>:

pyw.exe (Python Launcher for Windows Version 3.8.121.1013) opens a console window at startup. To reproduce, run command below from the console:

D:>pyw -c "import time; time.sleep(10)"

By the way command:

D:>pythomw -c "import time; time.sleep(10)"

works as expected, silently.

----------
components: Windows
messages: 353836
nosy: Andrew Ushakov, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pyw.exe opens console window in Windows 10
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct  3 07:20:54 2019
From: report at bugs.python.org (Joshua Root)
Date: Thu, 03 Oct 2019 11:20:54 +0000
Subject: [New-bugs-announce] [issue38360] single-argument form of -isysroot
 should be supported
Message-ID: <1570101654.53.0.395218631906.issue38360@roundup.psfhosted.org>


New submission from Joshua Root <josh+python at root.id.au>:

The path associated with the -isysroot compiler flag can be supplied either as a separate argument or in the same argument as -isysroot itself. The places in library code that do special handling of this flag should support both forms, but currently only support the two separate arguments form. This means that the flag may not be removed when pointing to a nonexistent SDK or when a different SDK is specified in the user's CFLAGS, and at worst a ValueError is raised in compiler_fixup.

----------
components: Distutils, macOS
messages: 353838
nosy: dstufft, eric.araujo, jmr, ned.deily, ronaldoussoren
priority: normal
pull_requests: 16146
severity: normal
status: open
title: single-argument form of -isysroot should be supported
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/issue38360>
_______________________________________

From report at bugs.python.org  Thu Oct  3 07:38:58 2019
From: report at bugs.python.org (Vaclav Bartos)
Date: Thu, 03 Oct 2019 11:38:58 +0000
Subject: [New-bugs-announce] [issue38361] syslog: Default "ident" in
 syslog.openlog() shouldn't contain slash
Message-ID: <1570102738.99.0.163183464343.issue38361@roundup.psfhosted.org>


New submission from Vaclav Bartos <bartos at cesnet.cz>:

When `syslog.openlog()` is called without parameters (or `syslog.syslog()` is called directly), the `ident` parameter should be set to "sys.argv[0] with leading path components stripped" (citation from docs).

I suppose this means that when sys.argv[0] is "/some/path/to/script", the ident should be set to "script" (this is the behavior in Python 2.7)

However, in Python 3.x, it gets set to "/script", i.e. the last slash is included in the string. I suppose this is not intended, it is just a "one-off" error in parsing the string.

The fix is trivial, see the linked GitHub PR.


To reproduce the bug:

$ python3
>>> import sys
>>> import syslog
>>> sys.argv[0] = "/some/path/to/script"
>>> syslog.syslog("TEST MESSAGE")
>>> 
$ tail -n 1 /var/log/messages
Oct  3 11:11:46 localhost /script: TEST MESSAGE

----------
components: Extension Modules
messages: 353839
nosy: vaclavbartos
priority: normal
pull_requests: 16147
severity: normal
status: open
title: syslog: Default "ident" in syslog.openlog() shouldn't contain slash
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/issue38361>
_______________________________________

From report at bugs.python.org  Thu Oct  3 07:44:52 2019
From: report at bugs.python.org (=?utf-8?b?0KHQstC10YLQu9C+0LzQuNGAINCR0LDQu9C10LLRgdC60Lg=?=)
Date: Thu, 03 Oct 2019 11:44:52 +0000
Subject: [New-bugs-announce] [issue38362] platform.system() comparison
 problem
Message-ID: <1570103092.18.0.780844249271.issue38362@roundup.psfhosted.org>


New submission from ????????? ???????? <s.balevski at gmail.com>:

Hi, I am using platform.system(). On linux I am using python3.6. 
>>> platform.system()
'Linux'
>>> platform.system() is 'Linux'
False 
>>> platform.system() == 'Linux'
True 

On Windows with python 3.7:
[?10/?3/?2019 2:42 PM]  
>>> platform.system()
'Windows'
>>> platform.system() is 'Windows'
True
>>> platform.system() == 'Windows'
True 

Is this a known problem?

----------
components: Library (Lib)
messages: 353840
nosy: ????????? ????????
priority: normal
severity: normal
status: open
title: platform.system() comparison problem
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Oct  3 08:10:17 2019
From: report at bugs.python.org (Stephen Tucker)
Date: Thu, 03 Oct 2019 12:10:17 +0000
Subject: [New-bugs-announce] [issue38363] No Module named ..." and UTF-8
 Byte Order Marks
Message-ID: <CAP=-cKWPrnrc7WpYcbLG99UVhTp0hC3bJbkJ3F8qiwqTuLR0aA@mail.gmail.com>


New submission from Stephen Tucker <stephen_tucker at sil.org>:

Hi,

I am running Python 2.7.10 on Windows 10.

I have discovered that if a .py source text file (that is, a Module text
file) starts with a UTF-8 Byte Order Mark, the module does not get "found"
by the  import  statement.

I have just spent an inordinate amount of time reaching this conclusion.

I realise that 2.7.10 is probably not being supported any more, however,
please let me ask the questions anyway:

Could ...
   Either:   ... the error message please be more helpful? (Like, for
example,  "Module begins with a Byte Order Mark")
   Or:    ... the BOM be allowed at the start of a Module?

Thanks.

Stephen Tucker.

----------
messages: 353841
nosy: Stephen_Tucker
priority: normal
severity: normal
status: open
title: No Module named ..." and UTF-8 Byte Order Marks

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

From report at bugs.python.org  Thu Oct  3 09:28:44 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Thu, 03 Oct 2019 13:28:44 +0000
Subject: [New-bugs-announce] [issue38364] inspect.iscoroutinefunction /
 isgeneratorfunction / isasyncgenfunction can't handle partialmethod objects
Message-ID: <1570109324.07.0.792957059658.issue38364@roundup.psfhosted.org>


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

This is a follow-up to #33261, which added general support for detecting generator / coroutine / async generator functions wrapped in partials. It appears that partialmethod objects were missed out.

While a partialmethod object will produce a functools.partial() object on binding to an instance, the .func attribute of that partial is a bound method, not a function, and the current _has_code_flag implementation unwraps methods *before* it unwraps partials.

Next, binding to a class produces a partialmethod._make_unbound_method.<locals>._method wrapper function. _unwrap_partial can't unwrap this, as it doesn't handle this case; it could look for the `_partialmethod` attribute and follow that to find the `.func` attribute.

Test case:

import inspect
import functools

class Foo:
    async def bar(self, a): return a
    ham = partialmethod(bar, "spam")

print(inspect.iscoroutinefunction(Foo.bar)  # True
print(inspect.iscoroutinefunction(Foo.ham)  # False
instance = Foo()
print(inspect.iscoroutinefunction(instance.bar)  # True
print(inspect.iscoroutinefunction(instance.ham)  # False

----------
components: Library (Lib)
messages: 353849
nosy: mjpieters
priority: normal
severity: normal
status: open
title: inspect.iscoroutinefunction / isgeneratorfunction / isasyncgenfunction can't handle  partialmethod objects
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct  3 11:27:22 2019
From: report at bugs.python.org (Stephen Tucker)
Date: Thu, 03 Oct 2019 15:27:22 +0000
Subject: [New-bugs-announce] [issue38365] Issue 38363 - False Alarm - Sorry!
Message-ID: <CAP=-cKXE9rZEAA_OG_KrVObV-2VkTC4cDBHDNp67y54ru5P29w@mail.gmail.com>


New submission from Stephen Tucker <stephen_tucker at sil.org>:

Hi,

Issue 38363 is a false alarm - I am sorry to have wasted your time.

My mistake was that the file that had the BOM in it also had a space at the
end of the filename. I removed the space and the module was found OK.

Sorry again.

Stephen Tucker.

----------
messages: 353854
nosy: Stephen_Tucker
priority: normal
severity: normal
status: open
title: Issue 38363 - False Alarm - Sorry!

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

From report at bugs.python.org  Thu Oct  3 19:04:49 2019
From: report at bugs.python.org (Io Mintz)
Date: Thu, 03 Oct 2019 23:04:49 +0000
Subject: [New-bugs-announce] [issue38366] dataclasses: generate the
 _hash_action table from the if-else tree
Message-ID: <1570143889.18.0.0994959118678.issue38366@roundup.psfhosted.org>


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

The dataclasses._hash_action table is currently a bit hard to read. It could be generated once from the if-else tree written in https://bugs.python.org/issue32929#msg312829 instead, which would both be easier to read and easier to maintain, while still maintaining the efficiency of the current dictionary.

----------
components: Library (Lib)
messages: 353887
nosy: iomintz
priority: normal
pull_requests: 16163
severity: normal
status: open
title: dataclasses: generate the _hash_action table from the if-else tree
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct  3 20:10:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Oct 2019 00:10:21 +0000
Subject: [New-bugs-announce] [issue38367] test_regrtest hanged on AMD64
 Windows10 3.x
Message-ID: <1570147821.98.0.530432590053.issue38367@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

https://buildbot.python.org/all/#/builders/3/builds/3617

...
0:25:50 load avg: 0.00 running: test_regrtest (13 min 48 sec)
0:26:20 load avg: 0.00 running: test_regrtest (14 min 18 sec)
0:26:50 load avg: 0.00 running: test_regrtest (14 min 48 sec)
0:27:02 load avg: 0.00 [419/419/1] test_regrtest crashed (Exit code 1)

(...)

0:27:02 load avg: 0.00 Re-running failed tests in verbose mode
0:27:02 load avg: 0.00 Re-running test_regrtest in verbose mode

Timeout (0:15:00)!
Thread 0x00002ee0 (most recent call first):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\subprocess.py", line 1457 in _readerthread
  File "D:\buildarea\3.x.bolen-windows10\build\lib\threading.py", line 882 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\threading.py", line 944 in _bootstrap_inner
  File "D:\buildarea\3.x.bolen-windows10\build\lib\threading.py", line 902 in _bootstrap

Thread 0x00002140 (most recent call first):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\threading.py", line 1039 in _wait_for_tstate_lock
  File "D:\buildarea\3.x.bolen-windows10\build\lib\threading.py", line 1023 in join
  File "D:\buildarea\3.x.bolen-windows10\build\lib\subprocess.py", line 1486 in _communicate
  File "D:\buildarea\3.x.bolen-windows10\build\lib\subprocess.py", line 1113 in communicate
  File "D:\buildarea\3.x.bolen-windows10\build\lib\subprocess.py", line 499 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_regrtest.py", line 504 in run_command
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_regrtest.py", line 529 in run_python
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_regrtest.py", line 584 in run_tests
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_regrtest.py", line 610 in test_module_autotest
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\case.py", line 616 in _callTestMethod
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\case.py", line 659 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\case.py", line 719 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\runner.py", line 176 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 2032 in _run_suite
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 2128 in run_unittest
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 209 in _test_module
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 234 in _runtest_inner2
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 270 in _runtest_inner
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 140 in _runtest
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 193 in runtest
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_worker
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 654 in _main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 634 in main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 712 in main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\regrtest.py", line 43 in _main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\regrtest.py", line 47 in <module>
  File "D:\buildarea\3.x.bolen-windows10\build\lib\runpy.py", line 85 in _run_code
  File "D:\buildarea\3.x.bolen-windows10\build\lib\runpy.py", line 192 in _run_module_as_main

(...)

1 re-run test:
    test_regrtest

Total duration: 27 min 35 sec
Tests result: FAILURE then SUCCESS


Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 1049, in temp_dir
    yield path
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 1101, in temp_cwd
    yield cwd_dir
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 634, in main
    self._main(tests, kwargs)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 707, in _main
    sys.exit(0)
SystemExit: 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 336, in _force_run
    return func(*args)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'D:\\buildarea\\3.x.bolen-windows10\\build\\build\\test_python_9260\\test_python_worker_11168'

----------
components: Tests
messages: 353889
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_regrtest hanged on AMD64 Windows10 3.x
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct  4 04:36:01 2019
From: report at bugs.python.org (Doug O'Riordan)
Date: Fri, 04 Oct 2019 08:36:01 +0000
Subject: [New-bugs-announce] [issue38368] Crash when subclassing ctypes.Union
Message-ID: <1570178161.94.0.1951756088.issue38368@roundup.psfhosted.org>


New submission from Doug O'Riordan <oriordan at biztosan.hu>:

Ran into Segfaults while trying to use pysnmp with 3.8.0rc1.
The code is running fine on 3.8.0b04.

$ python3.8
Python 3.8.0rc1 (default, Oct  2 2019, 14:15:18)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> class in6_addr_U(ctypes.Union):
...     _fields_ = [
...         ('__u6_addr8', ctypes.c_uint8 * 16),
...         ('__u6_addr16', ctypes.c_uint16 * 8),
...         ('__u6_addr32', ctypes.c_uint32 * 4),
...     ]
...
Segmentation fault

$ docker run -it python:3.8.0rc1-slim
Python 3.8.0rc1 (default, Oct  2 2019, 23:38:42)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> class in6_addr_U(ctypes.Union):
...     _fields_ = [
...         ('__u6_addr8', ctypes.c_uint8 * 16),
...         ('__u6_addr16', ctypes.c_uint16 * 8),
...         ('__u6_addr32', ctypes.c_uint32 * 4),
...     ]
...
$

The code is from here: https://github.com/etingof/pysnmp/blob/master/pysnmp/carrier/sockmsg.py#L47-L52

----------
components: ctypes
messages: 353906
nosy: oriordan
priority: normal
severity: normal
status: open
title: Crash when subclassing ctypes.Union
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct  4 05:18:54 2019
From: report at bugs.python.org (Paul Moore)
Date: Fri, 04 Oct 2019 09:18:54 +0000
Subject: [New-bugs-announce] [issue38369] Python 3.7.4 venv command does not
 install pip
Message-ID: <1570180734.57.0.0824297518984.issue38369@roundup.psfhosted.org>


New submission from Paul Moore <p.f.moore at gmail.com>:

The venv module with Python 3.4 on Windows doesn't install pip - even though the --without-pip flag is not specified. This appears to be a regression since pip is installed when using 3.7:

>C:\Utils\PythonVersions\Python-3.7.3\python.exe -m venv ve-373
>dir .\ve-373\Scripts\pip.exe


    Directory: C:\Work\Scratch\vv\ve-373\Scripts


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       04/10/2019     10:08         102765 pip.exe


>py -m venv ve-374
>dir .\ve-374\Scripts\pip.exe
dir : Cannot find path 'C:\Work\Scratch\vv\ve-374\Scripts\pip.exe' because it does not exist.
At line:1 char:1
+ dir .\ve-374\Scripts\pip.exe
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Work\Scratch...Scripts\pip.exe:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
>py -V
Python 3.7.4

----------
assignee: steve.dower
components: Library (Lib)
messages: 353911
nosy: paul.moore, steve.dower
priority: normal
severity: normal
status: open
title: Python 3.7.4 venv command does not install pip
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct  4 07:47:21 2019
From: report at bugs.python.org (plugin nieulq)
Date: Fri, 04 Oct 2019 11:47:21 +0000
Subject: [New-bugs-announce] [issue38370] An array as attribute of an object
 is shared between instances
Message-ID: <1570189641.68.0.415571181009.issue38370@roundup.psfhosted.org>


New submission from plugin nieulq <plu9in at gmail.com>:

I am using this version on Windows :
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)].
When an attribute of an object is an array, the array is shared between instances as shown in my example.
When executed, the output generated by the script is:
Value1
Value2
Value3
Value4
--------------------------------
Value1
Value2
Value3
Value4

It should be :

Value1
Value2
--------------------------------
Value3
Value4

----------
components: Windows
messages: 353928
nosy: paul.moore, plugin nieulq, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: An array as attribute of an object is shared between instances
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct  4 11:33:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Oct 2019 15:33:41 +0000
Subject: [New-bugs-announce] [issue38371] Tkinter: deprecate the split()
 method
Message-ID: <1570203221.73.0.664458057352.issue38371@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The tkapp.split() method has weird behavior. It splits a string recursively, so the type of items and the depth of nesting depends on spaces in string values. For example:

>>> import tkinter
>>> root = tkinter.Tcl()
>>> root.tk.split('Hi')
'Hi'
>>> root.tk.split('Hello "Good bye"')
('Hello', ('Good', 'bye'))

It may work as you meant in some cases (if items at the same level either all have spaces or all do not have spaces), but return unexpected  result for untested cases. It is more robust to use the tkapp.splitlist() method, which split exactly one level and always returns a tuple of strings. It can be used recursively if you need nested lists.

>>> root.tk.splitlist('Hi')
('Hi',)
>>> root.tk.splitlist('Hello "Good bye"')
('Hello', 'Good bye')
>>> [root.tk.splitlist(x) for x in root.tk.splitlist('Hello "Good bye"')]
[('Hello',), ('Good', 'bye')]

----------
components: Tkinter
messages: 353948
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Tkinter: deprecate the split() method
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct  4 12:54:45 2019
From: report at bugs.python.org (=?utf-8?b?0JHQtdCw0YLRgNC40YEg0JHQvtC90LXQstCw?=)
Date: Fri, 04 Oct 2019 16:54:45 +0000
Subject: [New-bugs-announce] [issue38372] Undefined behavior when changing
 dict while iterating it
Message-ID: <1570208085.28.0.0436589933875.issue38372@roundup.psfhosted.org>


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

When changing a dict while iterating through it by removing one key and inserting other which is calculated based on the old one, the dict is changed unexpectedly.

The following function:

```
def test(d: dict): 
     for i in d: 
         d[i+1] = d.pop(i)
```

when called with input dict `{1: 'test'}` transforms the dict to:
- `{6: 'test'}` in Python3.7.4;
- `{8: 'test'}` in Python3.5.3 and Python2.7.

If I change the function to add 2 to the key ( `d[i+2] = d.pop(i)` ) and use the same input `{1: 'test'}` the dict is changed to:
- `{11: 'test'}` in Python3.7;
- `{9: 'test'}` in Python3.5.

Similar thing happens with strings:

```
def test(d: dict): 
     for i in d: 
         d[i+'x'] = d.pop(i)
```

When called with input dict `{'a': 'test'}` it transforms it to:
- `{'axxxxx': 'test'}` in Python3.7.4;
- `{'axx': 'test'}` in Python3.5.3.

----------
components: Library (Lib)
messages: 353954
nosy: ??????? ??????
priority: normal
severity: normal
status: open
title: Undefined behavior when changing dict while iterating it
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/issue38372>
_______________________________________

From report at bugs.python.org  Fri Oct  4 18:43:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Oct 2019 22:43:43 +0000
Subject: [New-bugs-announce] [issue38373] List overallocation strategy
Message-ID: <1570229023.08.0.986734049649.issue38373@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently list uses the following formula for allocating an array for items (if size != 0):

    allocated = size + (size >> 3) + (3 if size < 9 else 6)

If add items by 1 the growth pattern is:  0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...

I think this strategy can be improved.

1. There is no much sense in allocating the space for 25 items. The standard Python allocator returns addresses aligned to 16 bytes on 64-bit platform. It will allocate a space for 26 items. It is more efficient if the starting address is a multiple of some power of two, and perhaps larger than the pointer size.

So it may be better to allocate a multiple of two or four items. Few first sizes are multiple of four, so this is good multiplier. I suggest to use the following expression:

    allocated = (size + (size >> 3) + 6) & ~3

It adds bits AND, but removes conditional value.

2. It is common enough case if the list is created from a sequence of a known size and do not adds items anymore. Or if it is created by concatenating of few sequences. In such cases the list can overallocate a space which will never be used. For example:

>>> import sys
>>> sys.getsizeof([1, 2, 3])
80
>>> sys.getsizeof([*(1, 2, 3)])
104

List display allocates a space for exactly 3 items. But a list created from a tuple allocates a space for 6 items.

Other example. Let extend a list by 10 items at a time.

size allocated
 10     17
 20     28
 30     39
 40     51
 50     51
 60     73
 70     73
 80     96
 90     96
100    118

We need to reallocate an array after first four steps. 17 is too small for 20, 28 is too small for 30, 39 is too small for 40. So overallocating does not help, it just spends a space.

My idea, that if we adds several items at a time and need to reallocate an array, we check if the overallocated size is enough for adding the same amount of items next time. If it is not enough, we do not overallocate.

The final algorithm is:

    allocated = (size + (size >> 3) + 6) & ~3
    if size - old_size > allocated - size:
        allocated = (size + 3) & ~3

It will save a space if extend a list by many items few times.

----------
components: Interpreter Core
messages: 353976
nosy: rhettinger, serhiy.storchaka, tim.peters
priority: normal
severity: normal
status: open
title: List overallocation strategy
type: resource usage
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct  4 18:55:21 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 04 Oct 2019 22:55:21 +0000
Subject: [New-bugs-announce] [issue38374] Remove weakref.ReferenceError
 entry from documentation
Message-ID: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>


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

The weakref documentation still mentions weakref.ReferenceError:

https://docs.python.org/3/library/weakref.html#weakref.ReferenceError

But this alias for the built-in ReferenceError exception was removed in the 3.0 development cycle (https://github.com/python/cpython/commit/2633c69fae7e413b2b64b01d8c0c901ae649a225#diff-b7975e9ef5a6be5f64e9bb391de03057), the last version where `weakref.ReferenceError` still exists is Python 2.7.

Please remove it, it's just confusing now.

----------
assignee: docs at python
components: Documentation
messages: 353977
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: Remove weakref.ReferenceError entry from documentation
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Oct  5 07:56:36 2019
From: report at bugs.python.org (Massimo)
Date: Sat, 05 Oct 2019 11:56:36 +0000
Subject: [New-bugs-announce] [issue38375] Enum lookup fails for callable
 values
Message-ID: <1570276596.73.0.237929240562.issue38375@roundup.psfhosted.org>


New submission from Massimo <massimo at typish.io>:

```
from enum import Enum

class T(Enum):
  TEST = 1

print(T["TEST"])

class S(Enum):
  TEST = lambda a: a

print(S["TEST"])
```
fails with `KeyError: 'TEST'` on the last line.

----------
components: Interpreter Core
messages: 354003
nosy: typish
priority: normal
severity: normal
status: open
title: Enum lookup fails for callable values
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat Oct  5 08:43:51 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 05 Oct 2019 12:43:51 +0000
Subject: [New-bugs-announce] [issue38376] ./configure --with-assertions
 generates a broken build
Message-ID: <1570279431.23.0.578903771856.issue38376@roundup.psfhosted.org>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

Following

./configure --prefix=$HOME/.local --with-assertions

and then running make leads to an error:

$ make
gcc -pthread -c -Wno-unused-result -Wsign-compare -g -fwrapv -O3 -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Objects/codeobject.o Objects/codeobject.c
gcc -pthread -c -Wno-unused-result -Wsign-compare -g -fwrapv -O3 -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c
gcc -pthread -c -Wno-unused-result -Wsign-compare -g -fwrapv -O3 -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Objects/descrobject.o Objects/descrobject.c
In file included from ./Include/object.h:746:0,
                 from ./Include/pytime.h:6,
                 from ./Include/Python.h:85,
                 from Objects/descrobject.c:3:
./Include/object.h:111:38: error: expected ?)? before ?*? token
 #define _PyObject_CAST(op) ((PyObject*)(op))
                                      ^
./Include/cpython/object.h:337:36: note: in definition of macro ?PyType_HasFeature?
 #define PyType_HasFeature(t,f)  (((t)->tp_flags & (f)) != 0)
                                    ^
./Include/unicodeobject.h:115:18: note: in expansion of macro ?PyType_FastSubclass?
                  PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS)
                  ^
./Include/object.h:122:34: note: in expansion of macro ?_PyObject_CAST?
 #define Py_TYPE(ob)             (_PyObject_CAST(ob)->ob_type)
                                  ^
./Include/unicodeobject.h:115:38: note: in expansion of macro ?Py_TYPE?
                  PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS)
                                      ^
./Include/unicodeobject.h:1042:56: note: in expansion of macro ?PyUnicode_Check?
 #define _PyUnicode_CheckConsistency(op, check_content) PyUnicode_Check(op)
                                                        ^
./Include/internal/pycore_object.h:14:17: note: in expansion of macro ?_PyUnicode_CheckConsistency?
 PyAPI_FUNC(int) _PyUnicode_CheckConsistency(PyObject *op, int check_content);
                 ^
./Include/object.h:111:40: error: expected ?)? before ?(? token
 #define _PyObject_CAST(op) ((PyObject*)(op))
                                        ^
./Include/cpython/object.h:337:36: note: in definition of macro ?PyType_HasFeature?
 #define PyType_HasFeature(t,f)  (((t)->tp_flags & (f)) != 0)
                                    ^
./Include/unicodeobject.h:115:18: note: in expansion of macro ?PyType_FastSubclass?
                  PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS)
                  ^
./Include/object.h:122:34: note: in expansion of macro ?_PyObject_CAST?
 #define Py_TYPE(ob)             (_PyObject_CAST(ob)->ob_type)
                                  ^
./Include/unicodeobject.h:115:38: note: in expansion of macro ?Py_TYPE?
                  PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS)
                                      ^
./Include/unicodeobject.h:1042:56: note: in expansion of macro ?PyUnicode_Check?
 #define _PyUnicode_CheckConsistency(op, check_content) PyUnicode_Check(op)
                                                        ^
./Include/internal/pycore_object.h:14:17: note: in expansion of macro ?_PyUnicode_CheckConsistency?
 PyAPI_FUNC(int) _PyUnicode_CheckConsistency(PyObject *op, int check_content);
                 ^
./Include/object.h:122:52: error: expected ?)? before ?->? token
 #define Py_TYPE(ob)             (_PyObject_CAST(ob)->ob_type)
                                                    ^
./Include/cpython/object.h:337:36: note: in definition of macro ?PyType_HasFeature?
 #define PyType_HasFeature(t,f)  (((t)->tp_flags & (f)) != 0)
                                    ^
./Include/unicodeobject.h:115:18: note: in expansion of macro ?PyType_FastSubclass?
                  PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS)
                  ^
./Include/unicodeobject.h:115:38: note: in expansion of macro ?Py_TYPE?
                  PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS)
                                      ^
./Include/unicodeobject.h:1042:56: note: in expansion of macro ?PyUnicode_Check?
 #define _PyUnicode_CheckConsistency(op, check_content) PyUnicode_Check(op)
                                                        ^
./Include/internal/pycore_object.h:14:17: note: in expansion of macro ?_PyUnicode_CheckConsistency?
 PyAPI_FUNC(int) _PyUnicode_CheckConsistency(PyObject *op, int check_content);
                 ^
./Include/cpython/object.h:337:38: error: expected ?)? before ?->? token
 #define PyType_HasFeature(t,f)  (((t)->tp_flags & (f)) != 0)
                                      ^
./Include/object.h:351:35: note: in expansion of macro ?PyType_HasFeature?
 #define PyType_FastSubclass(t,f)  PyType_HasFeature(t,f)
                                   ^
./Include/unicodeobject.h:115:18: note: in expansion of macro ?PyType_FastSubclass?
                  PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS)
                  ^
./Include/unicodeobject.h:1042:56: note: in expansion of macro ?PyUnicode_Check?
 #define _PyUnicode_CheckConsistency(op, check_content) PyUnicode_Check(op)
                                                        ^
./Include/internal/pycore_object.h:14:17: note: in expansion of macro ?_PyUnicode_CheckConsistency?
 PyAPI_FUNC(int) _PyUnicode_CheckConsistency(PyObject *op, int check_content);
                 ^
./Include/cpython/object.h:337:56: error: expected ?)? before ?!=? token
 #define PyType_HasFeature(t,f)  (((t)->tp_flags & (f)) != 0)
                                                        ^
./Include/object.h:351:35: note: in expansion of macro ?PyType_HasFeature?
 #define PyType_FastSubclass(t,f)  PyType_HasFeature(t,f)
                                   ^
./Include/unicodeobject.h:115:18: note: in expansion of macro ?PyType_FastSubclass?
                  PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_UNICODE_SUBCLASS)
                  ^
./Include/unicodeobject.h:1042:56: note: in expansion of macro ?PyUnicode_Check?
 #define _PyUnicode_CheckConsistency(op, check_content) PyUnicode_Check(op)
                                                        ^
./Include/internal/pycore_object.h:14:17: note: in expansion of macro ?_PyUnicode_CheckConsistency?
 PyAPI_FUNC(int) _PyUnicode_CheckConsistency(PyObject *op, int check_content);
                 ^
Makefile:1711: recipe for target 'Objects/descrobject.o' failed
make: *** [Objects/descrobject.o] Error 1

BTW, this happens even if Py_DEBUG=true is defined. System where the failure occurred: Ubuntu 16.04, 64-bit.

----------
components: Build
messages: 354006
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: ./configure --with-assertions generates a broken build
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct  5 09:47:18 2019
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 05 Oct 2019 13:47:18 +0000
Subject: [New-bugs-announce] [issue38377]
 test_asyncio.test_events.GetEventLoopTestsMixin.test_get_event_loop_new_process
 mixin breaks in the Unix environment without working /dev/shm
Message-ID: <1570283238.14.0.402660591178.issue38377@roundup.psfhosted.org>


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

======================================================================
ERROR: test_get_event_loop_new_process (test.test_asyncio.test_events.TestCGetEventLoop)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/test/test_asyncio/test_events.py", line 2647, in test_get_event_loop_new_process
    self.loop.run_until_complete(main()),
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/asyncio/base_events.py", line 608, in run_until_complete
    return future.result()
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/test/test_asyncio/test_events.py", line 2640, in main
    pool = concurrent.futures.ProcessPoolExecutor()
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/concurrent/futures/process.py", line 555, in __init__
    self._call_queue = _SafeQueue(
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/concurrent/futures/process.py", line 165, in __init__
    super().__init__(max_size, ctx=ctx)
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/multiprocessing/context.py", line 68, in Lock
    return Lock(ctx=self.get_context())
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/multiprocessing/synchronize.py", line 162, in __init__
    SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/multiprocessing/synchronize.py", line 57, in __init__
    sl = self._semlock = _multiprocessing.SemLock(
OSError: [Errno 38] Function not implemented

======================================================================
ERROR: test_get_event_loop_new_process (test.test_asyncio.test_events.TestPyGetEventLoop)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/test/test_asyncio/test_events.py", line 2647, in test_get_event_loop_new_process
    self.loop.run_until_complete(main()),
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/asyncio/base_events.py", line 608, in run_until_complete
    return future.result()
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/test/test_asyncio/test_events.py", line 2640, in main
    pool = concurrent.futures.ProcessPoolExecutor()
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/concurrent/futures/process.py", line 555, in __init__
    self._call_queue = _SafeQueue(
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/concurrent/futures/process.py", line 165, in __init__
    super().__init__(max_size, ctx=ctx)
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/multiprocessing/context.py", line 68, in Lock
    return Lock(ctx=self.get_context())
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/multiprocessing/synchronize.py", line 162, in __init__
    SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
  File "/home/abuild/rpmbuild/BUILD/Python-3.8.0rc1/Lib/multiprocessing/synchronize.py", line 57, in __init__
    sl = self._semlock = _multiprocessing.SemLock(
OSError: [Errno 38] Function not implemented

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

The problem is that in the OpenBuildService (the build system of SUSE distributions) /dev/shm is limited to:

abuild at milic:~/rpmbuild/BUILD/Python-3.8.0rc1> ls -ld /dev/shm
drwxr-xr-x 1 root root 0 Oct  5 13:23 /dev/shm
abuild at milic:~/rpmbuild/BUILD/Python-3.8.0rc1>

Provided PR will skip test if /dev/shm doesn?t exist or it doesn?t sufficient permissions.

----------
components: asyncio
messages: 354010
nosy: asvetlov, mcepl, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio.test_events.GetEventLoopTestsMixin.test_get_event_loop_new_process mixin breaks in the Unix environment without working /dev/shm
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct  5 11:04:03 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Oct 2019 15:04:03 +0000
Subject: [New-bugs-announce] [issue38378] os.sendfile() has improperly named
 parameter
Message-ID: <1570287843.24.0.0727618245068.issue38378@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

os.sendfile() has a keyword-or-positional parameter named "in". Since it is a keyword in Python, it is not possible to pass it as a keyword argument. You can only pass it as a positional argument or using a var-keyword argument (unlikely anybody uses the latter). The preceding parameter, "out", also can not be passed by keyword because of this.

It is weird, but usually does not cause a problem. You cannot use a keyword argument, period. But it prevents os.sendfile() from converting to Argument Clinic, because Argument Clinic does not allow using Python keywords as parameter names (I already created a patch for conversion, but in needs to solve this issue first).

There are two ways to solve this issue.

1. Rename parameter "in" (and maybe "out" for consistency). "out_fd" and "in_fd" look good names (they are use in Linux manpage).

2. Make "out" and "in" positional-only parameters.

----------
components: Extension Modules
messages: 354012
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: os.sendfile() has improperly named parameter
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct  5 13:31:26 2019
From: report at bugs.python.org (Tim Peters)
Date: Sat, 05 Oct 2019 17:31:26 +0000
Subject: [New-bugs-announce] [issue38379] finalizer resurrection in gc
Message-ID: <1570296686.13.0.00730737596554.issue38379@roundup.psfhosted.org>


New submission from Tim Peters <tim at python.org>:

While people are thinking about gc, zleak.py shows a small bug, and a possible opportunity for improvement, in the way gc treats finalizers that resurrect objects.

The bug:  the stats keep claiming gc is collecting an enormous number of objects, but in fact it's not collecting any.  Objects in the unreachable set shouldn't add to the "collected" count unless they _are_ collected.

Output:

resurrecting
collect 2000002
gen 2 stats {'collections': 2, 'collected': 2000002, 'uncollectable': 0}
resurrecting
collect 4000004
gen 2 stats {'collections': 3, 'collected': 6000006, 'uncollectable': 0}
resurrecting
collect 6000006
gen 2 stats {'collections': 4, 'collected': 12000012, 'uncollectable': 0}
resurrecting
collect 8000008
gen 2 stats {'collections': 5, 'collected': 20000020, 'uncollectable': 0}
resurrecting
collect 10000010
gen 2 stats {'collections': 6, 'collected': 30000030, 'uncollectable': 0}
...

Memory use grows without bound, and collections take ever longer.

The opportunity:  if any finalizer resurrects anything, gc gives up.  But the process of computing whether anything was resurrected also determines which initially-trash objects are reachable from the risen dead.  Offhand I don't see why we couldn't proceed collecting what remains trash.  Then zleak.py would reclaim everything instead of nothing.

Sketch:  rather than just set a flag, check_garbage() could move now-reachable objects to the old generation (and, for each one moved, decrement the count of collected objects).  Then delete_garbage() could proceed on what remains in the unreachable list.

----------
components: Interpreter Core
files: zleak.py
messages: 354020
nosy: nascheme, pitrou, tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: finalizer resurrection in gc
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48644/zleak.py

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

From report at bugs.python.org  Sat Oct  5 18:12:20 2019
From: report at bugs.python.org (Big Stone)
Date: Sat, 05 Oct 2019 22:12:20 +0000
Subject: [New-bugs-announce] [issue38380] Update SQLite to 3.30 in Windows
 and macOS installer builds
Message-ID: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>


New submission from Big Stone <stonebig34 at gmail.com>:

there is a security fix in sqlite-3.30

https://nvd.nist.gov/vuln/detail/CVE-2019-16168#VulnChangeHistorySection

https://www.sqlite.org/releaselog/3_30_0.html

----------
messages: 354023
nosy: Big Stone
priority: normal
severity: normal
status: open
title: Update SQLite to 3.30 in Windows and macOS installer builds

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

From report at bugs.python.org  Sat Oct  5 18:23:55 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Oct 2019 22:23:55 +0000
Subject: [New-bugs-announce] [issue38381] Possible wordcode optimization for
 STORE/LOAD pairs
Message-ID: <1570314235.55.0.575306260981.issue38381@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

In the show code below, the STORE_FAST x is FOLLOWED by LOAD_FAST x.   This is a common word code pairing.  Perhaps a new combined opcode would help:

        case TARGET(LOAD_AND_STORE_FAST): {
            PyObject *value = GETLOCAL(oparg);
            if (value == NULL) {
                format_exc_check_arg(tstate, PyExc_UnboundLocalError,
                                     UNBOUNDLOCAL_ERROR_MSG,
                                     PyTuple_GetItem(co->co_varnames, oparg));
                goto error;
            }
            Py_INCREF(value);
            SETLOCAL(oparg, value);
            FAST_DISPATCH();
        }

The combined opcode saves one one trip around the eval-loop and it saves
unnecessary stack manipulations (a PUSH() immediately followed by a POP()).

The code generation would likely need to be a compiler or AST step because it crosses basic block boundaries.  Care would need to be taken to not adversely affect tracing the code in a debugger.

Note in the following code, the "x" is never used after the STORE/LOAD pair.  In theory, the two opcodes could be dropped entirely; however, would affect a call to "locals()".

-------- Code disassembly ------

>>> def f(s):
	for x in g:
		yield x**2

		
>>> dis(f)
  2           0 LOAD_GLOBAL              0 (g)
              2 GET_ITER
        >>    4 FOR_ITER                14 (to 20)
              6 STORE_FAST               1 (x)

  3           8 LOAD_FAST                1 (x)
             10 LOAD_CONST               1 (2)
             12 BINARY_POWER
             14 YIELD_VALUE
             16 POP_TOP
             18 JUMP_ABSOLUTE            4
        >>   20 LOAD_CONST               0 (None)
             22 RETURN_VALUE

----------
components: Interpreter Core
messages: 354024
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Possible wordcode optimization for STORE/LOAD pairs
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct  5 21:46:18 2019
From: report at bugs.python.org (Warren Weckesser)
Date: Sun, 06 Oct 2019 01:46:18 +0000
Subject: [New-bugs-announce] [issue38382] statistics.harmonic_mean fails to
 raise error with negative input that follows a 0
Message-ID: <1570326378.93.0.0728676630318.issue38382@roundup.psfhosted.org>


New submission from Warren Weckesser <warren.weckesser at gmail.com>:

The function statistics.harmonic_mean is supposed to raise a StatisticsError if any element in the input is negative.  It fails to do so if the negative element is preceded by a zero.  When there is a zero before the negative element, the function returns 0:

>>> from statistics import harmonic_mean
>>> harmonic_mean([0, -1, 3])
0

If the zero occurs after the negative value, the StatisticsError exception is correctly raised:

>>> harmonic_mean([-1, 0, 3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/warren/repos/git/forks/cpython/Lib/statistics.py", line 406, in harmonic_mean
    T, total, count = _sum(1/x for x in _fail_neg(data, errmsg))
  File "/Users/warren/repos/git/forks/cpython/Lib/statistics.py", line 164, in _sum
    for typ, values in groupby(data, type):
  File "/Users/warren/repos/git/forks/cpython/Lib/statistics.py", line 406, in <genexpr>
    T, total, count = _sum(1/x for x in _fail_neg(data, errmsg))
  File "/Users/warren/repos/git/forks/cpython/Lib/statistics.py", line 289, in _fail_neg
    raise StatisticsError(errmsg)
statistics.StatisticsError: harmonic mean does not support negative values
>>> 

The problem is in this code in the function harmonic_mean:

    try:
        T, total, count = _sum(1/x for x in _fail_neg(data, errmsg))
    except ZeroDivisionError:
        return 0

When the zero occurs before the negative value, the ZeroDivisionError is raised before the negative value has been seen by the generator _fail_neg, and the function returns 0.

----------
components: Library (Lib)
messages: 354028
nosy: WarrenWeckesser
priority: normal
severity: normal
status: open
title: statistics.harmonic_mean fails to raise error with negative input that follows a 0
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct  6 06:51:34 2019
From: report at bugs.python.org (hai shi)
Date: Sun, 06 Oct 2019 10:51:34 +0000
Subject: [New-bugs-announce] [issue38383] undefined behavior in tailmatch()
 of bytes_methods.c
Message-ID: <1570359094.2.0.728788628974.issue38383@roundup.psfhosted.org>


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

`if (start + slen > len)` would cause undefined behavior?
such as: start=PY_SSIZE_T_MAX, slen=1

REFS:
[1] https://github.com/python/cpython/blob/master/Objects/bytes_methods.c#L746

----------
components: Interpreter Core
messages: 354032
nosy: shihai1991
priority: normal
severity: normal
status: open
title: undefined behavior in tailmatch() of bytes_methods.c
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct  6 09:39:09 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 06 Oct 2019 13:39:09 +0000
Subject: [New-bugs-announce] [issue38384] An assertion failure in test_pickle
Message-ID: <1570369149.47.0.841206648458.issue38384@roundup.psfhosted.org>


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

When running test_pickle, I sometimes see an assertion failure.

./python -m test test_pickle
0:00:00 load avg: 1.04 Run tests sequentially
0:00:00 load avg: 1.04 [1/1] test_pickle
python: Objects/typeobject.c:3151: _PyType_Lookup: Assertion `!PyErr_Occurred()' failed.
Fatal Python error: Aborted

Current thread 0x00007f8158632140 (most recent call first):
  File "/home/lubuntu2/cpython/Lib/test/pickletester.py", line 3400 in test_unpickling_buffering_readline
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 617 in _callTestMethod
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 663 in run
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 725 in __call__
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/lubuntu2/cpython/Lib/test/support/testresult.py", line 162 in run
  File "/home/lubuntu2/cpython/Lib/test/support/__init__.py", line 2032 in _run_suite
  File "/home/lubuntu2/cpython/Lib/test/support/__init__.py", line 2128 in run_unittest
  File "/home/lubuntu2/cpython/Lib/test/test_pickle.py", line 525 in test_main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 417 in run_tests_sequential
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 515 in run_tests
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 687 in _main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 634 in main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 712 in main
  File "/home/lubuntu2/cpython/Lib/test/__main__.py", line 2 in <module>
  File "/home/lubuntu2/cpython/Lib/runpy.py", line 85 in _run_code
  File "/home/lubuntu2/cpython/Lib/runpy.py", line 192 in _run_module_as_main
Aborted (core dumped)


In _Unpickler_SetInputStream(), _PyObject_LookupAttrId() is called three times in a row without any error handling.
If an exception occurs during the first or second call, _PyObject_LookupAttrId() will be called with a live exception.

----------
components: Extension Modules
messages: 354038
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: An assertion failure in test_pickle
type: crash
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Oct  6 15:10:16 2019
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Sun, 06 Oct 2019 19:10:16 +0000
Subject: [New-bugs-announce] [issue38385] statistics: incorrect documentation
Message-ID: <1570389016.13.0.165369947537.issue38385@roundup.psfhosted.org>


New submission from Eric O. LEBIGOT <eric.lebigot at normalesup.org>:

The documentation for the statistics package indicates that many of its functions (like median()) accept iterators. They seem to actually accept something more convenient, namely iterables.

Thus, iterator could probably be  usefully replaced by iterable on many of the functions (when applicable, which I would expect is everywhere).

----------
assignee: docs at python
components: Documentation
messages: 354043
nosy: docs at python, lebigot
priority: normal
severity: normal
status: open
title: statistics: incorrect documentation
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/issue38385>
_______________________________________

From report at bugs.python.org  Sun Oct  6 19:03:41 2019
From: report at bugs.python.org (yangzongwu)
Date: Sun, 06 Oct 2019 23:03:41 +0000
Subject: [New-bugs-announce] [issue38386] ModuleNotFoundError: No module
 named '_ctypes'
Message-ID: <1570403021.12.0.499983378492.issue38386@roundup.psfhosted.org>


New submission from yangzongwu <yangzong5 at gmail.com>:

I have try the following, but it is no useful
sudo apt install libffi-dev
 
but when i import _ctypes under python,it is OK
yzw at yzw-virtual-machine:~/Desktop/Test$ python3
Python 3.6.8 (default, Aug 20 2019, 17:12:48) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _ctypes
>>>


logs:
yzw at yzw-virtual-machine:~/Desktop/Test$ buildozer android clean

# Ensure build layout
No buildozer.spec found in the current directory. Abandon.
yzw at yzw-virtual-machine:~/Desktop/Test$ 
yzw at yzw-virtual-machine:~/Desktop/Test$ buildozer android clean
# Ensure build layout
No buildozer.spec found in the current directory. Abandon.
yzw at yzw-virtual-machine:~/Desktop/Test$ buildozer init
File buildozer.spec created, ready to customize!
yzw at yzw-virtual-machine:~/Desktop/Test$ buildozer -v android debug
# Check configuration tokens
# Ensure build layout
# Create directory /home/yzw/Desktop/Test/bin
# Check configuration tokens
# Preparing build
# Check requirements for android
# Run 'dpkg --version'
# Cwd None
Debian 'dpkg' package management program version 1.19.0.5 (amd64).
This is free software; see the GNU General Public License version 2 or
later for copying conditions. There is NO warranty.
# Search for Git (git)
#  -> found at /usr/bin/git
# Search for Cython (cython)
#  -> found at /home/yzw/.local/bin/cython
# Search for Java compiler (javac)
#  -> found at /usr/lib/jvm/java-8-openjdk-amd64/bin/javac
# Search for Java keytool (keytool)
#  -> found at /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/keytool
# Install platform
# Run '/usr/bin/python3 -m pip install -q --user \'appdirs\' \'colorama>=0.3.3\' \'jinja2\' \'six\' \'enum34; python_version<"3.4"\' \'sh>=1.10; sys_platform!="nt"\' \'pep517\' \'pytoml\' \'virtualenv\''
# Cwd None
# Apache ANT found at /home/yzw/.buildozer/android/platform/apache-ant-1.9.4
# Android SDK found at /home/yzw/.buildozer/android/platform/android-sdk
# Android NDK found at /home/yzw/.buildozer/android/platform/android-ndk-r17c
# Check application requirements
# Check garden requirements
# Compile platform
# Run '/usr/bin/python3 -m pythonforandroid.toolchain create --dist_name=myapp --bootstrap=sdl2 --requirements=python3,kivy --arch armeabi-v7a --copy-libs --color=always --storage-dir="/home/yzw/Desktop/Test/.buildozer/android/platform/build" --ndk-api=21'
# Cwd /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Will compile for the following archs: armeabi-v7a
[INFO]:    Found Android API target in $ANDROIDAPI: 27
[INFO]:    Available Android APIs are (27)
[INFO]:    Requested API target 27 is available, continuing.
[INFO]:    Found NDK dir in $ANDROIDNDK: /home/yzw/.buildozer/android/platform/android-ndk-r17c
[INFO]:    Found NDK version 17c
[INFO]:    Getting NDK API version (i.e. minimum supported API) from user argument
[INFO]:    Found virtualenv at /home/yzw/.local/bin/virtualenv
[INFO]:    ccache is missing, the build will not be optimized in the future.
[INFO]:    Found the following toolchain versions: ['4.9']
[INFO]:    Picking the latest gcc toolchain, here 4.9
[INFO]:    No existing dists meet the given requirements!
[INFO]:    No dist exists that meets your requirements, so one will be built.
[INFO]:    Found a single valid recipe set: ['hostpython3', 'libffi', 'openssl', 'sdl2_image', 'sdl2_mixer', 'sdl2_ttf', 'sqlite3', 'python3', 'sdl2', 'setuptools', 'six', 'pyjnius', 'android', 'kivy']
[INFO]:    The selected bootstrap is sdl2
[INFO]:    # Creating dist with sdl2 bootstrap
[INFO]:    Dist will have name myapp and requirements (python3, kivy)
[INFO]:    Dist contains the following requirements as recipes: ['hostpython3', 'libffi', 'openssl', 'sdl2_image', 'sdl2_mixer', 'sdl2_ttf', 'sqlite3', 'python3', 'sdl2', 'setuptools', 'six', 'pyjnius', 'android', 'kivy']
[INFO]:    Dist will also contain modules () installed from pip
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/bootstrap_builds/sdl2-python3
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Recipe build order is ['hostpython3', 'libffi', 'openssl', 'sdl2_image', 'sdl2_mixer', 'sdl2_ttf', 'sqlite3', 'python3', 'sdl2', 'setuptools', 'six', 'pyjnius', 'android', 'kivy']
[INFO]:    # Downloading recipes 
[INFO]:    Downloading hostpython3
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 57 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/hostpython3
[INFO]:    -> running basename https://www.python.or...(and 35 more)
[INFO]:    hostpython3 download already cached, skipping                      
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading libffi
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 52 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/libffi
[INFO]:    -> running basename https://github.com/li...(and 33 more)
[INFO]:    libffi download already cached, skipping                           
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading openssl
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 53 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/openssl
[INFO]:    -> running basename https://www.openssl.o...(and 30 more)
[INFO]:    openssl download already cached, skipping                          
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading sdl2_image
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 56 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/sdl2_image
[INFO]:    -> running basename https://www.libsdl.o...(and 53 more)
[INFO]:    sdl2_image download already cached, skipping                       
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading sdl2_mixer
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 56 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/sdl2_mixer
[INFO]:    -> running basename https://www.libsdl.o...(and 53 more)
[INFO]:    sdl2_mixer download already cached, skipping                       
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading sdl2_ttf
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 54 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/sdl2_ttf
[INFO]:    -> running basename https://www.libsdl.or...(and 49 more)
[INFO]:    sdl2_ttf download already cached, skipping                         
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading sqlite3
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 53 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/sqlite3
[INFO]:    -> running basename https://www.sqlite.or...(and 38 more)
[INFO]:    sqlite3 download already cached, skipping                          
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading python3
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 53 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/python3
[INFO]:    -> running basename https://www.python.or...(and 35 more)
[INFO]:    python3 download already cached, skipping                          
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading sdl2
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Tes...(and 49 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/sdl2
[INFO]:    -> running basename https://www.libsdl.or...(and 27 more)
[INFO]:    sdl2 download already cached, skipping                             
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading setuptools
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 56 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/setuptools
[INFO]:    -> running basename https://pypi.python....(and 54 more)
[INFO]:    setuptools download already cached, skipping                       
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading six
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Tes...(and 48 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/six
[INFO]:    -> running basename https://pypi.python.o...(and 42 more)
[INFO]:    six download already cached, skipping                              
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading pyjnius
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Te...(and 53 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/pyjnius
[INFO]:    -> running basename https://github.com/ki...(and 30 more)
[INFO]:    pyjnius download already cached, skipping                          
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Downloading android
[INFO]:    Skipping android download as no URL is set
[INFO]:    Downloading kivy
[INFO]:    -> running mkdir -p /home/yzw/Desktop/Tes...(and 49 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/packages/kivy
[INFO]:    -> running basename https://github.com/ki...(and 26 more)
[INFO]:    kivy download already cached, skipping                             
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    # Building all recipes for arch armeabi-v7a
[INFO]:    # Unpacking recipes
[INFO]:    Unpacking hostpython3 for armeabi-v7a
[INFO]:    -> running basename https://www.python.or...(and 35 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/hostpython3/desktop
[INFO]:    hostpython3 is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking libffi for armeabi-v7a
[INFO]:    -> running basename https://github.com/li...(and 33 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/libffi/armeabi-v7a__ndk_target_21
[INFO]:    libffi is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking openssl for armeabi-v7a
[INFO]:    -> running basename https://www.openssl.o...(and 30 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/openssl/armeabi-v7a__ndk_target_21
[INFO]:    openssl is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking sdl2_image for armeabi-v7a
[INFO]:    -> running basename https://www.libsdl.o...(and 53 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/bootstrap_builds/sdl2-python3/jni
[INFO]:    sdl2_image is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking sdl2_mixer for armeabi-v7a
[INFO]:    -> running basename https://www.libsdl.o...(and 53 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/bootstrap_builds/sdl2-python3/jni
[INFO]:    sdl2_mixer is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking sdl2_ttf for armeabi-v7a
[INFO]:    -> running basename https://www.libsdl.or...(and 49 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/bootstrap_builds/sdl2-python3/jni
[INFO]:    sdl2_ttf is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking sqlite3 for armeabi-v7a
[INFO]:    -> running basename https://www.sqlite.or...(and 38 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/sqlite3/armeabi-v7a__ndk_target_21
[INFO]:    sqlite3 is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking python3 for armeabi-v7a
[INFO]:    -> running basename https://www.python.or...(and 35 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/python3-libffi-openssl-sqlite3/armeabi-v7a__ndk_target_21
[INFO]:    python3 is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking sdl2 for armeabi-v7a
[INFO]:    -> running basename https://www.libsdl.or...(and 27 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/bootstrap_builds/sdl2-python3/jni
[INFO]:    sdl2 is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking setuptools for armeabi-v7a
[INFO]:    -> running basename https://pypi.python....(and 54 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21
[INFO]:    setuptools is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking six for armeabi-v7a
[INFO]:    -> running basename https://pypi.python.o...(and 42 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/six-python3/armeabi-v7a__ndk_target_21
[INFO]:    six is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Unpacking pyjnius for armeabi-v7a
[INFO]:    -> running basename https://github.com/ki...(and 30 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/pyjnius-python3-sdl2/armeabi-v7a__ndk_target_21
[INFO]:    pyjnius is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    -> running rm -rf /home/yzw/Desktop/Test...(and 109 more)
[INFO]:    -> running cp -a /home/yzw/Desktop/Test/...(and 215 more)
[INFO]:    Unpacking kivy for armeabi-v7a
[INFO]:    -> running basename https://github.com/ki...(and 26 more)
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/kivy-python3/armeabi-v7a__ndk_target_21
[INFO]:    kivy is already unpacked, skipping
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    # Prebuilding recipes
[INFO]:    Prebuilding hostpython3 for armeabi-v7a
[INFO]:    hostpython3 has no prebuild_armeabi_v7a, skipping
[INFO]:    Prebuilding libffi for armeabi-v7a
[INFO]:    libffi has no prebuild_armeabi_v7a, skipping
[INFO]:    Applying patches for libffi[armeabi-v7a]
[INFO]:    libffi already patched, skipping
[INFO]:    Prebuilding openssl for armeabi-v7a
[INFO]:    openssl has no prebuild_armeabi_v7a, skipping
[INFO]:    Prebuilding sdl2_image for armeabi-v7a
[INFO]:    sdl2_image has no prebuild_armeabi_v7a, skipping
[INFO]:    Applying patches for sdl2_image[armeabi-v7a]
[INFO]:    sdl2_image already patched, skipping
[INFO]:    Prebuilding sdl2_mixer for armeabi-v7a
[INFO]:    sdl2_mixer has no prebuild_armeabi_v7a, skipping
[INFO]:    Applying patches for sdl2_mixer[armeabi-v7a]
[INFO]:    sdl2_mixer already patched, skipping
[INFO]:    Prebuilding sdl2_ttf for armeabi-v7a
[INFO]:    sdl2_ttf has no prebuild_armeabi_v7a, skipping
[INFO]:    Prebuilding sqlite3 for armeabi-v7a
[INFO]:    sqlite3 has no prebuild_armeabi_v7a, skipping
[INFO]:    Prebuilding python3 for armeabi-v7a
[INFO]:    python3 has no prebuild_armeabi_v7a, skipping
[INFO]:    Applying patches for python3[armeabi-v7a]
[INFO]:    python3 already patched, skipping
[INFO]:    Prebuilding sdl2 for armeabi-v7a
[INFO]:    sdl2 has no prebuild_armeabi_v7a, skipping
[INFO]:    Prebuilding setuptools for armeabi-v7a
[INFO]:    setuptools has no prebuild_armeabi_v7a, skipping
[INFO]:    Prebuilding six for armeabi-v7a
[INFO]:    six has no prebuild_armeabi_v7a, skipping
[INFO]:    Prebuilding pyjnius for armeabi-v7a
[INFO]:    pyjnius has no prebuild_armeabi_v7a, skipping
[INFO]:    Applying patches for pyjnius[armeabi-v7a]
[INFO]:    pyjnius already patched, skipping
[INFO]:    Prebuilding android for armeabi-v7a
[INFO]:    android has no prebuild_armeabi_v7a, skipping
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/android-python3-sdl2/armeabi-v7a__ndk_target_21/android
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Prebuilding kivy for armeabi-v7a
[INFO]:    kivy has no prebuild_armeabi_v7a, skipping
[INFO]:    # Building recipes
[INFO]:    Building hostpython3 for armeabi-v7a
[INFO]:    Skipping hostpython3 (3.7.1) build, as it has already been completed
[INFO]:    Building libffi for armeabi-v7a
[INFO]:    libffi said it is already built, skipping
[INFO]:    Building openssl for armeabi-v7a
[INFO]:    openssl said it is already built, skipping
[INFO]:    Building sdl2_image for armeabi-v7a
[INFO]:    Building sdl2_mixer for armeabi-v7a
[INFO]:    Building sdl2_ttf for armeabi-v7a
[INFO]:    Building sqlite3 for armeabi-v7a
[INFO]:    sqlite3 said it is already built, skipping
[INFO]:    Building python3 for armeabi-v7a
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/python3-libffi-openssl-sqlite3/armeabi-v7a__ndk_target_21/python3/android-build
[WARNING]: Doing some hacky stuff to link properly
[INFO]:    -> running cp /home/yzw/.buildozer/andro...(and 83 more)
[INFO]:    -> running cp /home/yzw/.buildozer/andro...(and 81 more)
[WARNING]: lld not found, linking without it. Consider installing lld if linker errors occur.
[INFO]:    Activating flags for sqlite3
[INFO]:    Activating flags for libffi
[INFO]:    Activating flags for openssl
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Building sdl2 for armeabi-v7a
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/bootstrap_builds/sdl2-python3/jni
[INFO]:    -> running ndk-build V=1
[INFO]:    <- directory context /home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android
[INFO]:    Building setuptools for armeabi-v7a
[INFO]:    setuptools apparently isn't already in site-packages
[INFO]:    Installing setuptools into site-packages
[INFO]:    -> directory context /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools
[INFO]:    -> running python setup.py install -O2 -...(and 106 more)
Exception in thread background thread for pid 57350:                          
Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/home/yzw/.local/lib/python3.6/site-packages/sh.py", line 1540, in wrap
    fn(*args, **kwargs)
  File "/home/yzw/.local/lib/python3.6/site-packages/sh.py", line 2459, in background_thread
    handle_exit_code(exit_code)
  File "/home/yzw/.local/lib/python3.6/site-packages/sh.py", line 2157, in fn
    return self.command.handle_command_exit_code(exit_code)
  File "/home/yzw/.local/lib/python3.6/site-packages/sh.py", line 815, in handle_command_exit_code
    raise exc
sh.ErrorReturnCode_1: 

  RAN: /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/hostpython3/desktop/hostpython3/native-build/python setup.py install -O2 --root=/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/python-installs/myapp --install-lib=.

  STDOUT:
Traceback (most recent call last):
  File "setup.py", line 11, in <module>
    import setuptools
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/__init__.py", line 20, in <module>
    from setuptools.dist import Distribution, Feature
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/dist.py", line 36, in <module>
    from setuptools import windows_support
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/windows_support.py", line 2, in <module>
    import ctypes
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/hostpython3/desktop/hostpython3/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'


  STDERR:


Traceback (most recent call last):
  File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/toolchain.py", line 1192, in <module>
    main()
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/entrypoints.py", line 18, in main
    ToolchainCL()
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/toolchain.py", line 668, in __init__
    getattr(self, args.subparser_name.replace('-', '_'))(args)
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/toolchain.py", line 153, in wrapper_func
    build_dist_from_args(ctx, dist, args)
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/toolchain.py", line 206, in build_dist_from_args
    args, "ignore_setup_py", False
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/build.py", line 577, in build_recipes
    recipe.build_arch(arch)
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/recipe.py", line 844, in build_arch
    self.install_python_package(arch)
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/recipe.py", line 863, in install_python_package
    _env=hpenv, *self.setup_extra_args)
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/python-for-android/pythonforandroid/logger.py", line 180, in shprint
    for line in output:
  File "/home/yzw/.local/lib/python3.6/site-packages/sh.py", line 863, in next
    self.wait()
  File "/home/yzw/.local/lib/python3.6/site-packages/sh.py", line 792, in wait
    self.handle_command_exit_code(exit_code)
  File "/home/yzw/.local/lib/python3.6/site-packages/sh.py", line 815, in handle_command_exit_code
    raise exc
sh.ErrorReturnCode_1: 

  RAN: /home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/hostpython3/desktop/hostpython3/native-build/python setup.py install -O2 --root=/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/python-installs/myapp --install-lib=.

  STDOUT:
Traceback (most recent call last):
  File "setup.py", line 11, in <module>
    import setuptools
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/__init__.py", line 20, in <module>
    from setuptools.dist import Distribution, Feature
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/dist.py", line 36, in <module>
    from setuptools import windows_support
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/setuptools-python3/armeabi-v7a__ndk_target_21/setuptools/setuptools/windows_support.py", line 2, in <module>
    import ctypes
  File "/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/hostpython3/desktop/hostpython3/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'


  STDERR:

# Command failed: /usr/bin/python3 -m pythonforandroid.toolchain create --dist_name=myapp --bootstrap=sdl2 --requirements=python3,kivy --arch armeabi-v7a --copy-libs --color=always --storage-dir="/home/yzw/Desktop/Test/.buildozer/android/platform/build" --ndk-api=21
# 
# Buildozer failed to execute the last command
# The error might be hidden in the log above this error
# Please read the full log, and search for it before
# raising an issue with buildozer itself.
# In case of a bug report, please add a full log with log_level = 2

----------
components: Build
messages: 354052
nosy: yangzongwu
priority: normal
severity: normal
status: open
title: ModuleNotFoundError: No module named '_ctypes'
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Sun Oct  6 19:43:50 2019
From: report at bugs.python.org (Brad Solomon)
Date: Sun, 06 Oct 2019 23:43:50 +0000
Subject: [New-bugs-announce] [issue38387] Document PyDoc_STRVAR
Message-ID: <1570405430.86.0.169338229908.issue38387@roundup.psfhosted.org>


New submission from Brad Solomon <brad.solomon.1124 at gmail.com>:

The C-API reference would benefit from a short mention of PyDoc_STRVAR usage, since it is used so frequently within Modules/.

----------
assignee: docs at python
components: Documentation
messages: 354053
nosy: bsolomon1124, docs at python
priority: normal
pull_requests: 16195
severity: normal
status: open
title: Document PyDoc_STRVAR
type: enhancement

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

From report at bugs.python.org  Sun Oct  6 19:51:13 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Sun, 06 Oct 2019 23:51:13 +0000
Subject: [New-bugs-announce] [issue38388] Pickle protocol v 5 needs to be
 documented
Message-ID: <1570405873.92.0.178526679084.issue38388@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

Python 3.8 brings new pickle protocol, version 5.
It's not documented.

```
(venv) ? ~/m/proj> python
Python 3.7.4 (v3.7.4:e09359112e, Jul  8 2019, 14:54:52)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> pickle.HIGHEST_PROTOCOL
4
>>> ^D
(venv) ? ~/m/proj> python3.8
Python 3.8.0rc1 (v3.8.0rc1:34214de6ab, Oct  1 2019, 12:56:49)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> pickle.HIGHEST_PROTOCOL
5
>>> ^D
```

Yet there's no mention of "protocol version 5" at:

https://github.com/python/cpython/blob/master/Doc/library/pickle.rst
https://docs.python.org/3.9/library/pickle.html#data-stream-format
https://docs.python.org/3.8/library/pickle.html#data-stream-format

----------
assignee: docs at python
components: Documentation
messages: 354054
nosy: Dima.Tisnek, docs at python
priority: normal
severity: normal
status: open
title: Pickle protocol v 5 needs to be documented
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct  7 00:29:16 2019
From: report at bugs.python.org (Tamirys Pino)
Date: Mon, 07 Oct 2019 04:29:16 +0000
Subject: [New-bugs-announce] [issue38389] Bug on sorted with count key
Message-ID: <1570422556.48.0.0127805381731.issue38389@roundup.psfhosted.org>


New submission from Tamirys Pino <taamypino at gmail.com>:

>>> data=[2, 3, 2, 4, 5, 12, 2, 3, 3, 3, 12, 5]
>>> data
[2, 3, 2, 4, 5, 12, 2, 3, 3, 3, 12, 5]
>>> sorted(data)
[2, 2, 2, 3, 3, 3, 3, 4, 5, 5, 12, 12]
>>> sorted(data, key=data.count)
[4, 5, 12, 12, 5, 2, 2, 2, 3, 3, 3, 3]

[4, 5, 12, 12, 5, 2, 2, 2, 3, 3, 3, 3] should be [4, 5, 5, 12, 12, 2, 2, 2, 3, 3, 3, 3]

----------
messages: 354063
nosy: Tamirys Pino
priority: normal
severity: normal
status: open
title: Bug on sorted with count key
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct  7 05:14:51 2019
From: report at bugs.python.org (hai shi)
Date: Mon, 07 Oct 2019 09:14:51 +0000
Subject: [New-bugs-announce] [issue38390] Got an compile warning in
 dictobject.c
Message-ID: <1570439691.81.0.591764842739.issue38390@roundup.psfhosted.org>


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

The warning detail:

Objects/dictobject.c: In function ?_PyDictView_Intersect?:
Objects/dictobject.c:4189:15: warning: unused variable ?tmp? [-Wunused-variable]
     PyObject *tmp;
               ^

----------
components: Build
messages: 354068
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Got an compile warning in dictobject.c
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  7 05:36:21 2019
From: report at bugs.python.org (=?utf-8?q?Lo=C3=AFc_Etienne?=)
Date: Mon, 07 Oct 2019 09:36:21 +0000
Subject: [New-bugs-announce] [issue38391] Typo in tutorial code (does not
 compile)
Message-ID: <1570440981.11.0.0420917562712.issue38391@roundup.psfhosted.org>


New submission from Lo?c Etienne <loic.jonas.etienne at gmail.com>:

https://docs.python.org/3.7/extending/newtypes_tutorial.html

Is: PY_DECREF(m);
Should be: Py_DECREF(m);

----------
components: Demos and Tools
messages: 354069
nosy: Lo?c Etienne
priority: normal
severity: normal
status: open
title: Typo in tutorial code (does not compile)
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct  7 06:48:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Oct 2019 10:48:58 +0000
Subject: [New-bugs-announce] [issue38392] Ensure that objects entering the
 GC are valid
Message-ID: <1570445338.58.0.651902608854.issue38392@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

A bug in Python/hamt.c was only discovered 4 months after the code was added to Python:
* https://mail.python.org/pipermail/python-dev/2018-June/153857.html
* https://bugs.python.org/issue33803

The problem was that an object was tracked by the GC, whereas calling its traverse method crashed Python... depending when the traverse method is called exactly.

Pseudo-code:

  PyObject_GC_Track(<partially initialized object>);
  ...
  obj2 = PyObject_GC_NewVar(...);
  ...
  <finish to initialize the first object>

The problem is that PyObject_GC_NewVar() can trigger a GC collection which uses the partially initialized object, and then we get a cryptic crash in the GC (usually seen in visit_decref()).

I propose to make PyObject_GC_Track() stricter: validate that the object seems to be "valid" or "fully initialized". From the GC point of view, it means that calling tp_traverse must not crash.

Attached PR is a concrete implementation.

This issue is a follow-up of my previously failed attempt bpo-36389 "Add gc.enable_object_debugger(): detect corrupted Python objects in the GC". While bpo-36389 attempts to discoverd corrupted objects once a GC collection is triggered, this issue is restricted to objects entering the GC.

First problem: my PR breaks Modules/pyexpat.c whereas the code is not strictly a bug: in Python 3.8, it's ok to put a partially initialized object into the GC if no GC collection can be triggered before the object is fully initialized. In Modules/pyexpat.c case, the code looks safe from that point of view.

It means that such change is a backward incompatible change. IMHO it's a good step forward, since it is likely to discovered hidden bugs.

----------
components: Interpreter Core
messages: 354074
nosy: vstinner
priority: normal
severity: normal
status: open
title: Ensure that objects entering the GC are valid
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  7 09:27:24 2019
From: report at bugs.python.org (pmp-p)
Date: Mon, 07 Oct 2019 13:27:24 +0000
Subject: [New-bugs-announce] [issue38393] building modules from 3.8.0rc1
 fails in a venv when system 3.8 is present
Message-ID: <1570454844.33.0.763324170679.issue38393@roundup.psfhosted.org>


New submission from pmp-p <pmpp.pub at gmail.com>:

when trying to build rc1 from a b4 venv to prepare a python host for cross compilation on ubuntu xenial flavour x64

i got :


cd /tmp
python3.7 -m venv testenv
cd testenv/
. bin/activate
(testenv) /tmp/testenv $ tar xf /tmp/Python-3.8.0rc1.tar.xz && cd Python-3.8.0rc1

CC=clang ./configure --prefix=/tmp/python3.host --with-system-ffi --disable-ipv6 --without-ensurepip --with-c-locale-coercion --disable-shared && make

./python -E ./setup.py  build
step will fail for the reason i suspect is srcdir is taken from system python3.8 if installed ( /usr/local in that case )

$ ./python -E 
Python 3.8.0rc1 (default, Oct  7 2019, 15:16:07) 
[Clang 6.0.0 (tags/RELEASE_600/final)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_var('srcdir')
'/usr/local/lib/python3.8/config-3.8-x86_64-linux-gnu'
>>>

----------
messages: 354095
nosy: pmpp, vstinner
priority: normal
severity: normal
status: open
title: building modules from 3.8.0rc1 fails in a venv when system 3.8 is present
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct  7 10:01:54 2019
From: report at bugs.python.org (Florian Krause)
Date: Mon, 07 Oct 2019 14:01:54 +0000
Subject: [New-bugs-announce] [issue38394] time.get_clock_info reports
 "adjustable=False" for implementation="CLOCK_MONOTONIC"
Message-ID: <1570456914.26.0.677053488358.issue38394@roundup.psfhosted.org>


New submission from Florian Krause <siebenhundertzehn at gmail.com>:

clock_gettime(CLOCK_MONOTONIC) is adjustable via NTP, as described here: https://linux.die.net/man/2/clock_gettime

(and also mentioned in PEP 418).

Yet, time.get_clock_info reports it as "adjustable=False" (this even seems to be hardcoded for all clocks on Linux).

----------
components: Library (Lib)
messages: 354097
nosy: Florian Krause
priority: normal
severity: normal
status: open
title: time.get_clock_info reports "adjustable=False" for implementation="CLOCK_MONOTONIC"
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct  7 10:49:09 2019
From: report at bugs.python.org (Sam Gross)
Date: Mon, 07 Oct 2019 14:49:09 +0000
Subject: [New-bugs-announce] [issue38395] proxy_contains (weakref.proxy) can
 access an object with 0 refcount
Message-ID: <1570459749.44.0.879317891234.issue38395@roundup.psfhosted.org>


New submission from Sam Gross <colesbury at gmail.com>:

The implementation of weakref.proxy's methods call back into the Python API using a "borrowed reference" of the weakly referenced object (acquired via PyWeakref_GET_OBJECT). This API call may delete the last reference to the object (either directly or via GC), leaving a dangling pointer, which can be subsequently dereferenced.

Tested with Python 3.8.0b4 (debug build)

The following code crashes with a debug build of Python 3.8.0b4 on Linux.

import weakref

obj = None

class MyObj:
    def __iter__(self):
        global obj
        del obj
        return NotImplemented

obj = MyObj()
p = weakref.proxy(obj)
print(5 in p)


This particular test case does not crash with a release build (on Linux).

The implementation of `in` on a proxy object calls proxy_contains:

   return PySequence_Contains(PyWeakref_GET_OBJECT(proxy), value);

https://github.com/python/cpython/blob/v3.8.0b4/Objects/weakrefobject.c#L556


This eventually calls _PySequence_IterSearch. The call to PyObject_GetIter can call arbitrary code, which can lead to seq (the proxy's referent) being deleted. The subsequent call to type_error dereferences a dead object. 

    it = PyObject_GetIter(seq);
    if (it == NULL) {
        type_error("argument of type '%.200s' is not iterable", seq);
        return -1;
    }

https://github.com/python/cpython/blob/v3.8.0b4/Objects/abstract.c#L2003-L2007

I believe some functions, like proxy_length, may be immune to this problem because they do not access the borrowed referent after calling into user code. However, this is hard to verify from reading the code and may be fragile -- small changes to PyObject_Length/Size, for example, might .

See also https://bugs.python.org/issue16602

----------
components: Interpreter Core
messages: 354102
nosy: colesbury
priority: normal
severity: normal
status: open
title: proxy_contains (weakref.proxy) can access an object with 0 refcount
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct  7 11:55:56 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 07 Oct 2019 15:55:56 +0000
Subject: [New-bugs-announce] [issue38396] ast.literal_eval doesn't give
 information about node except the type of it
Message-ID: <1570463756.86.0.131436803473.issue38396@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

def _convert_num(node):
        if isinstance(node, Constant):
            if type(node.value) in (int, float, complex):
                return node.value
>       raise ValueError('malformed node or string: ' + repr(node))
E       ValueError: malformed node or string: <_ast.Name object at 0x7f0e7ebab320>

When a malformed node passes into literal_eval, it raises ValueError with repr of node (which is just a memory address and type). I think using dump(node) at there is a better option, like

node = <_ast.Name object at 0x7fa8279847d0>

    def _convert_num(node):
        if isinstance(node, Constant):
            if type(node.value) in (int, float, complex):
                return node.value
>       raise ValueError('malformed node or string: ' + dump(node))
E       ValueError: malformed node or string: Name(id='a', ctx=Load())

----------
components: Library (Lib)
messages: 354103
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: ast.literal_eval doesn't give information about node except the type of it
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  7 12:06:40 2019
From: report at bugs.python.org (retnikt)
Date: Mon, 07 Oct 2019 16:06:40 +0000
Subject: [New-bugs-announce] [issue38397] __init_subclass__ causes TypeError
 when used with more standard library metaclasses (such as EnumMeta)
Message-ID: <1570464400.89.0.0085195281122.issue38397@roundup.psfhosted.org>


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

Essentially the same as https://bugs.python.org/issue29581 (more detail is there), but for the additional meta-classes enum.EnumMeta and probably typing.NamedTupleMeta (discussion needed - is there a use-case for this?)

The __new__ method on these metaclasses should include **kwargs at the end of the method definition and pass them on to the super call in order to allow the special method __init_subclass__ to be defined with custom parameters on classes using the metaclass.

(also, perhaps the issue for typing should be reported separately on github python/typing instead)

----------
components: Library (Lib)
messages: 354104
nosy: retnikt
priority: normal
severity: normal
status: open
title: __init_subclass__ causes TypeError when used with more standard library metaclasses (such as EnumMeta)
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/issue38397>
_______________________________________

From report at bugs.python.org  Mon Oct  7 12:09:58 2019
From: report at bugs.python.org (PyScripter)
Date: Mon, 07 Oct 2019 16:09:58 +0000
Subject: [New-bugs-announce] [issue38398] PyUnicode functions are not
 exported by python 2 in Ubuntu
Message-ID: <1570464598.55.0.274340335252.issue38398@roundup.psfhosted.org>


New submission from PyScripter <pyscripter at gmail.com>:

As per title PyUnicode functions, such as PyUnicode_FromWideChar, are not exported on Ubuntu and possibly other Linux systems.  This is a show stopper for embedded Python.

To confirm:

>>> import ctypes
>>> hasattr(ctypes.pythonapi, "PyUnicode_FromWideChar")

It should return True, but it returns False. ?

I have tested with the default Ubuntu python 2.7.15 and with compiled python 2.7.16.

Note that the problem does not exist in python3 and also python 2.7 and 3.x in Windows.  So it is only python 2.7 in Ubuntu.

----------
components: Library (Lib)
messages: 354105
nosy: pyscripter
priority: normal
severity: normal
status: open
title: PyUnicode functions are not exported by python 2 in Ubuntu
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct  7 12:51:31 2019
From: report at bugs.python.org (AwesomeCronk)
Date: Mon, 07 Oct 2019 16:51:31 +0000
Subject: [New-bugs-announce] [issue38399] Error message persists when
 reimporting library
Message-ID: <1570467091.43.0.986668758934.issue38399@roundup.psfhosted.org>


New submission from AwesomeCronk <awesomecronk at gmail.com>:

I am working on a hexdump library in Python 3.7.4.
Whenever an issue is triggered, the error message shows up. I can usually edit and correct the file(library), but when I reimport the library and rerun the function, it throws the same error on the same line number, even if the line was removed or commented out.

----------
components: Interpreter Core
files: pythonerror.png
messages: 354120
nosy: AwesomeCronk
priority: normal
severity: normal
status: open
title: Error message persists when reimporting library
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48645/pythonerror.png

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

From report at bugs.python.org  Mon Oct  7 19:01:37 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Oct 2019 23:01:37 +0000
Subject: [New-bugs-announce] [issue38400] Python segfaults when configured
 with --with-pydebug --with-trace-refs
Message-ID: <1570489297.7.0.2347429078.issue38400@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

configure --with-pydebug --with-trace-refs && make

Modules/gcmodule.c:378: visit_decref: Assertion "!_PyObject_IsFreed(op)" failed
<object at 0x5557629ca260 is freed>
Fatal Python error: _PyObject_AssertFailed
Python runtime state: preinitialized

Current thread 0x00007f6e2863e740 (most recent call first):
<no Python frame>
/bin/sh: line 5: 28078 Aborted                 (core dumped) ./python -E -S -m sysconfig --generate-posix-vars
generate-posix-vars failed
make: * [Makefile:592: pybuilddir.txt] Error 1

----------
components: Interpreter Core
messages: 354151
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Python segfaults when configured with --with-pydebug --with-trace-refs
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct  7 20:24:53 2019
From: report at bugs.python.org (John Parejko)
Date: Tue, 08 Oct 2019 00:24:53 +0000
Subject: [New-bugs-announce] [issue38401] Make dataclass attribute
 docstrings accessible
Message-ID: <1570494293.05.0.934356434949.issue38401@roundup.psfhosted.org>


New submission from John Parejko <parejkoj at uw.edu>:

Dataclasses provide a very straightforward way to specify structured data. One can trivally document a dataclass's attributes via triple-quoted attribute docstrings per PEP 257. However, those docstrings are not accessible to pydoc, so they are lost to users of the dataclass.

For example, the attribute docstrings in the below dataclass should be available when looking at `help(SpectralData)`, but that help command does not show the docstrings.

```
@dataclasses.dataclass
class SpectralData:
    """Class to hold data and metadata from a fiber spectrograph."""
    wavelength: astropy.units.Quantity
    """The wavelength array produced by the instrument."""
    spectrum: np.ndarray
    """The flux array in instrumental units."""
    duration: float
    """The duration of the exposure in seconds."""
```

----------
assignee: docs at python
components: Documentation
messages: 354154
nosy: John Parejko2, docs at python
priority: normal
severity: normal
status: open
title: Make dataclass attribute docstrings accessible
type: enhancement

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

From report at bugs.python.org  Tue Oct  8 00:01:58 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Oct 2019 04:01:58 +0000
Subject: [New-bugs-announce] [issue38402] crypt: check error from library
 call
Message-ID: <1570507318.72.0.325157356882.issue38402@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:

(split off from #36161)

The crypt module currently doesn't check for errors from crypt or crypt_r. It should.

----------
messages: 354166
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: crypt: check error from library call
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  8 00:21:41 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Oct 2019 04:21:41 +0000
Subject: [New-bugs-announce] [issue38403] nuspec iconUrl field is deprecated
Message-ID: <1570508501.54.0.80221217734.issue38403@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The iconUrl field has to be replaced with an icon field, and we need to include the file in the package now.

Details at https://docs.microsoft.com/en-us/nuget/reference/nuspec#icon

----------
assignee: steve.dower
components: Windows
messages: 354167
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: nuspec iconUrl field is deprecated
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  8 00:44:33 2019
From: report at bugs.python.org (Poker Online Jakarta)
Date: Tue, 08 Oct 2019 04:44:33 +0000
Subject: [New-bugs-announce] [issue38404] Poker Online
Message-ID: <1570509873.23.0.248422964885.issue38404@roundup.psfhosted.org>


New submission from Poker Online Jakarta <jayadiliuss at gmail.com>:

<a href="https://www.jakartapoker.net/">poker online</a>

[url=https://www.jakartapoker.net/]poker online[/url]

----------
components: Argument Clinic
messages: 354169
nosy: larry, pokeronlinejakarta
priority: normal
severity: normal
status: open
title: Poker Online
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct  8 04:18:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2019 08:18:02 +0000
Subject: [New-bugs-announce] [issue38405] Nested subclasses of
 typing.NamedTuple are not pickleable
Message-ID: <1570522682.37.0.234893155024.issue38405@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Example:

>>> from typing import NamedTuple
>>> import pickle
>>> class A:
...     class B(NamedTuple):
...         x: int
... 
>>> pickle.dumps(A.B)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class '__main__.B'>: attribute lookup B on __main__ failed

----------
components: Library (Lib)
messages: 354176
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Nested subclasses of typing.NamedTuple are not pickleable
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  8 04:36:22 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2019 08:36:22 +0000
Subject: [New-bugs-announce] [issue38406] Missed some public names in
 help(typing)
Message-ID: <1570523782.74.0.0305216426842.issue38406@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Special forms NoReturn, Final, Literal and class ForwardRef are not shown in the help() output.

----------
components: Library (Lib)
messages: 354177
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Missed some public names in help(typing)
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  8 04:59:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Oct 2019 08:59:44 +0000
Subject: [New-bugs-announce] [issue38407] Add docstrings for
 typing.SupportsXXX classes
Message-ID: <1570525184.08.0.803412577085.issue38407@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

typing.SupportsXXX classes do not have docstrings and help() shows the docstring of the parent class instead, which is wrong ("Base class for protocol classes...").

----------
components: Library (Lib)
messages: 354179
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add docstrings for typing.SupportsXXX classes
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  8 05:51:03 2019
From: report at bugs.python.org (James Allsopp)
Date: Tue, 08 Oct 2019 09:51:03 +0000
Subject: [New-bugs-announce] [issue38408] urlparse gives no method to build
 a url with a port
Message-ID: <1570528263.82.0.631134670905.issue38408@roundup.psfhosted.org>


New submission from James Allsopp <jamesaallsopp at googlemail.com>:

Hi,
I like to build my Url's using url unparse, e.g.
site_to_test = urllib.parse.urlunparse((scheme, host, page, '', '', ''))
r = requests.get(site_to_test)

However, we reach a lot of sites through SSH tunnels, as our network is heavily locked down, and need to specify a port. Unfortunately, we can parse a url with a port, and get site_to_test.port = '9097' we can't run it the other way, e.g. this fails.
site_to_test = urllib.parse.urlunparse((scheme, host, page, '', '', '',port=9097))

This should be easy to fix and there's a use case for it.
Thanks

----------
components: Library (Lib)
messages: 354180
nosy: James Allsopp
priority: normal
severity: normal
status: open
title: urlparse gives no method to build a url with a port
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct  8 09:59:54 2019
From: report at bugs.python.org (Bob Dowling)
Date: Tue, 08 Oct 2019 13:59:54 +0000
Subject: [New-bugs-announce] [issue38409] Typo in doc string for str.strip
Message-ID: <1570543194.25.0.196797196101.issue38409@roundup.psfhosted.org>


New submission from Bob Dowling <bob.dowling.64 at gmail.com>:

The doc string for str.strip() has a typo: the "d" at the end of "removed" is missing.

help(str.strip)

Currently:
Return a copy of the string with leading and trailing whitespace remove.

Should be:
Return a copy of the string with leading and trailing whitespace removed.

I have attached an offered patch.

----------
components: Library (Lib)
files: str_strip.patch
keywords: patch
messages: 354209
nosy: Bob Dowling
priority: normal
severity: normal
status: open
title: Typo in doc string for str.strip
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48648/str_strip.patch

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

From report at bugs.python.org  Tue Oct  8 10:06:14 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 08 Oct 2019 14:06:14 +0000
Subject: [New-bugs-announce] [issue38410] Possible fatal errors due to
 _PyEval_SetAsyncGen{Finalizer, Firstiter}()
Message-ID: <1570543574.99.0.942798410146.issue38410@roundup.psfhosted.org>


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

_PyEval_SetAsyncGenFinalizer() and _PyEval_SetAsyncGenFirstiter() don't include proper error handling for their PySys_Audit() calls. This could lead to leaked exceptions and fatal errors.

----------
components: Interpreter Core
messages: 354210
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Possible fatal errors due to _PyEval_SetAsyncGen{Finalizer,Firstiter}()
type: crash
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  8 11:15:47 2019
From: report at bugs.python.org (Jack Robison)
Date: Tue, 08 Oct 2019 15:15:47 +0000
Subject: [New-bugs-announce] [issue38411] SQLITE_MISUSE race condition in
 sqlite3 is misleadingly raised as a binding error
Message-ID: <1570547747.91.0.842919846552.issue38411@roundup.psfhosted.org>


New submission from Jack Robison <jackrobison at lbry.com>:

There is a race condition in the sqlite3 module that is misleadingly raised as sqlite3.InterfaceError('Error binding parameter 0 - probably unsupported type.')

There are two issues here, one is the incorrectly raise error (https://bugs.python.org/issue16379), the other is the underlying SQLITE_MISUSE caused by the race condition. I believe this is a race between sqlite3 vs python garbage collection due to the releasing of the GIL. If the GIL releasing is removed from sqlite3, I cannot reproduce the race.

Here is a script to reproduce the error, as the number of runners or queries_per_executemany is increased the error happens more frequently. The minimal test case only needs two executemanys where each has two queries to run.





import asyncio
import sqlite3
from concurrent.futures.thread import ThreadPoolExecutor


async def misuse_sqlite(runners=2, queries_per_executemany=2):
    loop = asyncio.get_event_loop()

    expected_error = 'Error binding parameter 0 - probably unsupported type.'
    exceptions = []
    executor = ThreadPoolExecutor(1)
    db = executor.submit(sqlite3.connect, ':memory:', isolation_level=None).result()
    executor.submit(db.executescript, "create table test (id text primary key);")

    def query_in_executor():
        return asyncio.wrap_future(executor.submit(executemany))

    def executemany():
        try:
            return db.executemany("select * from test where id=?", ((str(i),) for i in range(queries_per_executemany)))
        except Exception as err:
            exceptions.append(err)

    for _ in range(runners):
        loop.call_soon(query_in_executor)
    await asyncio.sleep(0.01)

    assert all(str(err) == expected_error and isinstance(err, sqlite3.InterfaceError) for err in exceptions)

    executor.submit(db.close).result()
    executor.shutdown()

    return len(exceptions) > 0


attempts = 0

while True:
    attempts += 1
    if asyncio.run(misuse_sqlite()):
        print('error hit on attempt', attempts)
        break

----------
components: Library (Lib)
messages: 354218
nosy: Jack Robison
priority: normal
severity: normal
status: open
title: SQLITE_MISUSE race condition in sqlite3 is misleadingly raised as a binding error
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct  8 13:32:00 2019
From: report at bugs.python.org (belegnar)
Date: Tue, 08 Oct 2019 17:32:00 +0000
Subject: [New-bugs-announce] [issue38412] csv.reader failed to split string
 with spaces and quoted delimiter
Message-ID: <1570555920.82.0.491270320818.issue38412@roundup.psfhosted.org>


New submission from belegnar <admin at zilantkon.ru>:

```
>>> list(csv.reader(['param1,"param21,param22",param3']))
[['param1', 'param21,param22', 'param3']]
>>> list(csv.reader(['param1, "param21,param22", param3']))
[['param1', ' "param21', 'param22"', ' param3']]
```

version 3.7.4 on linux

----------
components: Library (Lib)
messages: 354224
nosy: belegnar
priority: normal
severity: normal
status: open
title: csv.reader failed to split string with spaces and quoted delimiter
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct  8 15:30:42 2019
From: report at bugs.python.org (Vladimir Ryabtsev)
Date: Tue, 08 Oct 2019 19:30:42 +0000
Subject: [New-bugs-announce] [issue38413] Remove or change "Multithreading"
 section
Message-ID: <1570563042.6.0.0902531064636.issue38413@roundup.psfhosted.org>


New submission from Vladimir Ryabtsev <greatvovan at gmail.com>:

This is regarding the page https://docs.python.org/3.7/library/sqlite3.html.

I believe this section on the very bottom of the page has been kept here for pretty long time, during that both SQLite and the sqlite3 module evolved and improved. Now the content contradicts to the description of function "connect()" in the part describing "check_same_thread" parameter. The function description says that using connections from multiple threads is allowed with serialization handled by the user (and it is true), while the bottom "Mutithreading" section says sharing connections is not allowed.

I think we can remove "Mutithreading" section entirely unless there is something important to add to what already mentioned.

----------
assignee: docs at python
components: Documentation
messages: 354227
nosy: Vladimir Ryabtsev, docs at python
priority: normal
severity: normal
status: open
title: Remove or change "Multithreading" section
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  8 15:57:40 2019
From: report at bugs.python.org (Umar Asghar)
Date: Tue, 08 Oct 2019 19:57:40 +0000
Subject: [New-bugs-announce] [issue38414] Ordering a nested dictionary in
 python with json format
Message-ID: <1570564660.13.0.727592441748.issue38414@roundup.psfhosted.org>


New submission from Umar Asghar <mrumarasghar at gmail.com>:

Python does not preserve ordering in JSON format. I have tested it out but it's not working. Here is my code.

# Python3 code to demonstrate 
# Sort nested dictionary by key 
# using OrderedDict() + sorted() 
from collections import OrderedDict 
from operator import getitem 
import json

# initializing dictionary 
test_dict = {'Nikhil' : { 'roll' : 24, 'marks' : 17}, 
            'Akshat' : {'roll' : 54, 'marks' : 12}, 
            'Akash' : { 'roll' : 12, 'marks' : 15}} 

# printing original dict 
print("The original dictionary : " + str(test_dict)) 

# using OrderedDict() + sorted() 
# Sort nested dictionary by key 
res = OrderedDict(sorted(test_dict.items(), 
    key = lambda x: getitem(x[1], 'marks'))) 

print("The sorted dictionary by marks is : " + str(res))
# Output
# The sorted dictionary by marks is : OrderedDict([('Akshat', {'marks': 12, 'roll': 54}), ('Akash', {'marks': 15, 'roll': 12}), ('Nikhil', {'marks': 17, 'roll': 24})])

res = json.dumps(res)

# print result 
print("The sorted dictionary by marks is : (json)")
print(json.loads(res)) 
# Output
# The sorted dictionary by marks is : 
# {'Akash': {'marks': 15, 'roll': 12}, 'Akshat': {'marks': 12, 'roll': 54}, 'Nikhil': {'marks': 17, 'roll': 24}}
Does anyone suggest any solution for it?

It's different than a simple dictionary. It only targets the nested dictionary ordering. Please don't mark it a duplication of simple dictionary ordering with JSON. thanks

----------
messages: 354228
nosy: Umar Asghar
priority: normal
severity: normal
status: open
title: Ordering a nested dictionary in python with json format

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

From report at bugs.python.org  Tue Oct  8 16:45:49 2019
From: report at bugs.python.org (Jason Fried)
Date: Tue, 08 Oct 2019 20:45:49 +0000
Subject: [New-bugs-announce] [issue38415] @asynccontextmanager decorated
 functions are not callable like @contextmanager
Message-ID: <1570567549.28.0.993731185011.issue38415@roundup.psfhosted.org>


New submission from Jason Fried <me at jasonfried.info>:

The standard contextmanager decorator produces a wrapper that itself can be used as a decorator

```
@contextmanager
def some_context():
    ...
    yield

@some_context()
def some_function():
    # we are inside a with some_context() now. 
    ...


```

When I created a version of asynccontextmanager internally before it was available in the  stdLib I copied this behavior and I have people internally to facebook using this behavior,  Was there a reason this behavior was not replicated to asynccontextmanager?  

I have a diff an tests to add

----------
components: Library (Lib)
messages: 354232
nosy: fried, yselivanov
priority: normal
severity: normal
status: open
title: @asynccontextmanager decorated functions are not callable like @contextmanager
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  8 17:14:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Oct 2019 21:14:26 +0000
Subject: [New-bugs-announce] [issue38416]
 test_largefile.TestSocketSendfile.test_it() failed with 15 min timeout on
 AMD64 FreeBSD 10-STABLE Non-Debug 3.x
Message-ID: <1570569266.33.0.0795173642593.issue38416@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

It seems like the 15 min timeout for the overall test_largefile is too short for the very slow AMD64 FreeBSD 10-STABLE Non-Debug 3.x buildbot.

The test creates two files of 2.5 GB on the disk.

One solution is to skip the test on this buildbot worker. For example, using a test resource like "largefile","cpu" resource, or another one. Maybe only skip TestSocketSendfile.test_it(), or even skip for the whole file. Currently, the whole file requires the "largefile" resource, but only on Windows and macOS.

Right now, the buildbot worker runs the test suite using:

   ./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --slowest --fail-env-changed --timeout=900 -j2 -j4 

So all resources are enabled.

--

https://buildbot.python.org/all/#/builders/167/builds/1695

test_it (test.test_largefile.TestCopyfile) ... ok
Timeout (0:15:00)!
Thread 0x0000000806c95400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_largefile.py", line 193 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/threading.py", line 882 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/threading.py", line 902 in _bootstrap

Thread 0x0000000801c06400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/socket.py", line 386 in _sendfile_use_sendfile
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/socket.py", line 483 in sendfile
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_largefile.py", line 207 in test_it
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/case.py", line 616 in _callTestMethod
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/case.py", line 659 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/case.py", line 719 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/support/__init__.py", line 2032 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/support/__init__.py", line 2128 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/runtest.py", line 209 in _test_module
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/main.py", line 318 in rerun_failed_tests
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/main.py", line 691 in _main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/main.py", line 634 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/libregrtest/main.py", line 712 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/__main__.py", line 2 in <module>
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/runpy.py", line 192 in _run_module_as_main
test_it (test.test_largefile.TestSocketSendfile) ... *** Error code 1

----------
components: Tests
messages: 354234
nosy: giampaolo.rodola, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_largefile.TestSocketSendfile.test_it() failed with 15 min timeout on AMD64 FreeBSD 10-STABLE Non-Debug 3.x
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  8 18:55:39 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 08 Oct 2019 22:55:39 +0000
Subject: [New-bugs-announce] [issue38417] Add support for settting umask in
 subprocess children
Message-ID: <1570575339.67.0.686572067981.issue38417@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

Another use of the deprecated unsafe preexec_fn was to call os.umask in the child prior to exec.

As seen in https://github.com/freeipa/freeipa/pull/3769 (see the code in there).

We should add an explicit feature for this to avoid people's desire for preexec_fn or for the heavyweight workaround of an intermediate shell calling umask before doing another exec.

Any common preexec_fn uses that we can encode into supported parameters will help our ability to remove the ill fated preexec_fn misfeature in the future.

----------
messages: 354238
nosy: gregory.p.smith
priority: high
severity: normal
stage: needs patch
status: open
title: Add support for settting umask in subprocess children
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct  8 22:28:04 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 09 Oct 2019 02:28:04 +0000
Subject: [New-bugs-announce] [issue38418] Audit event for os.system is
 incorrect
Message-ID: <1570588084.56.0.375267797277.issue38418@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

It's documented as "os.system" but implemented as just "system".

----------
assignee: steve.dower
messages: 354245
nosy: lukasz.langa, steve.dower
priority: normal
severity: normal
status: open
title: Audit event for os.system is incorrect
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct  8 23:48:05 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 09 Oct 2019 03:48:05 +0000
Subject: [New-bugs-announce] [issue38419] The path of check-c-globals.py on
 README is wrong
Message-ID: <1570592885.04.0.292567951687.issue38419@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

See https://github.com/python/cpython/blob/01171ebd966b0cd6352057799ad876dd1e07942e/Tools/c-analyzer/README#L37

----------
keywords: newcomer friendly
messages: 354246
nosy: corona10
priority: normal
severity: normal
status: open
title: The path of check-c-globals.py on README is wrong

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

From report at bugs.python.org  Wed Oct  9 04:22:42 2019
From: report at bugs.python.org (wang xuancong)
Date: Wed, 09 Oct 2019 08:22:42 +0000
Subject: [New-bugs-announce] [issue38420] defaultdict does not support
 parametric lambda
Message-ID: <1570609362.26.0.380213879875.issue38420@roundup.psfhosted.org>


New submission from wang xuancong <xuancong84 at gmail.com>:

A very common use of defaultdict is that if the key exist, use the corresponding mapped target, if the key does not exist, use the key itself. However, current Python 2/3 defaultdict does not support parametric lambda function:

>>> from collections import *
>>> aa=defaultdict(lambda t:t)
>>> aa
defaultdict(<function <lambda> at 0x10a55c950>, {})
>>> aa[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: <lambda>() missing 1 required positional argument: 't'
>>>

I would like to suggest that use the dict's query key as the first argument in the default lambda function. And use the dict itself as the 2nd argument in the default lambda function (e.g., if the key exist, use the mapped target, otherwise, use the size of the current defaultdict). I think that will make Python much more powerful than any other programming language. Anyone can think of any additional information for the default lambda function? Thanks!

----------
messages: 354255
nosy: xuancong84
priority: normal
severity: normal
status: open
title: defaultdict does not support parametric lambda
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/issue38420>
_______________________________________

From report at bugs.python.org  Wed Oct  9 08:45:03 2019
From: report at bugs.python.org (David Kernan)
Date: Wed, 09 Oct 2019 12:45:03 +0000
Subject: [New-bugs-announce] [issue38421] email.utils.parsetime_tz does not
 return "None"
Message-ID: <1570625103.37.0.0601159046628.issue38421@roundup.psfhosted.org>


New submission from David Kernan <davidsmurf at gmail.com>:

email.utils.parsetime_tz() is a function which attempts to parse a date, and returns a 10-item tuple.
The first 9 items represents a time, and the last item represents the timezone offset from UTC.

In Python 2, the original behavior was to return the date, and a "None" value when there was no timezone - this is documented here:
https://docs.python.org/3/library/email.utils.html#email.utils.parsedate_tz

In Python 3 however, the code specifically prevents "None" from being returned in place of a UTC offset:
https://github.com/python/cpython/blob/3.7/Lib/email/_parseaddr.py#L53-#L54

The Python 3 documentation for email.utils.parsetime_tz() - is still the same as the 2.7 documentation, and specifically mentions that should a timezone be missing from the string, the last item will be "None"

This isn't the case:

Python 3.6.8:
>>> import email.utils
>>> date_string = 'Wed, 09 Oct 2019 08:32:37'
>>> email.utils.parsedate_tz(date_string)
(2019, 10, 9, 8, 32, 37, 0, 1, -1, 0)
----

Python 2.7.16:
>>> import email.utils
>>> date_string = 'Wed, 09 Oct 2019 08:32:37'
>>> email.utils.parsedate_tz(date_string)
(2019, 10, 9, 8, 32, 37, 0, 1, -1, None)

---

Is this an error in code, or is it a mistake in the documentation?

----------
components: email
messages: 354265
nosy: David Kernan, barry, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.parsetime_tz does not return "None"
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/issue38421>
_______________________________________

From report at bugs.python.org  Wed Oct  9 11:15:39 2019
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 09 Oct 2019 15:15:39 +0000
Subject: [New-bugs-announce] [issue38422] Clarify docstrings of pathlib
 suffix(es)
Message-ID: <1570634139.23.0.159522926495.issue38422@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

I'm writing a PR for this right now.

----------
components: Library (Lib)
messages: 354279
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Clarify docstrings of pathlib suffix(es)
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct  9 13:14:39 2019
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Wed, 09 Oct 2019 17:14:39 +0000
Subject: [New-bugs-announce] [issue38423] Event loop implementation docs
 advertise set_event_loop
Message-ID: <1570641279.2.0.929881138502.issue38423@roundup.psfhosted.org>


New submission from Hrvoje Nik?i? <hniksic at gmail.com>:

The docs of SelectorEventLoop and ProactorEventLoop contain examples that call asyncio.set_event_loop:

      selector = selectors.SelectSelector()
      loop = asyncio.SelectorEventLoop(selector)
      asyncio.set_event_loop(loop)

But this won't have any effect on code that uses asyncio.run(), because asyncio.run() creates a fresh event loop. Since asyncio.run() is the recommended way to execute async code and is used consistently throughout the documentation, this might be confusing to someone who tries to e.g. use the proactor loop on Windows.

I propose the following:

* add a disclaimer that instantiating the event loop won't affect calls to asyncio.run(), and that loop.run_until_complete() must be used; and

* link to asyncio.set_event_loop_policy(), which does work with asyncio.run(), but doesn't allow fine-tuning the details, such as which selector to use for the SelectorEventLoop.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 354288
nosy: asvetlov, docs at python, hniksic, yselivanov
priority: normal
severity: normal
status: open
title: Event loop implementation docs advertise set_event_loop
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct  9 21:39:01 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 10 Oct 2019 01:39:01 +0000
Subject: [New-bugs-announce] [issue38424] typing.Generator shorthand
Message-ID: <1570671541.73.0.307162838122.issue38424@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

Currently to annotate a generator, something like `Generator[str, None, None]` is required. Which is a bit confusing and verbose.

Can we allow shorthand, like `Generator[str]` for simple cases?

I'm not entirely certain what the semantics ought to be...
Maybe Generator[t1, t2=Any, t3=None] ?

----------
components: Library (Lib)
messages: 354307
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: typing.Generator shorthand
type: enhancement

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

From report at bugs.python.org  Thu Oct 10 01:02:14 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 10 Oct 2019 05:02:14 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue38425=5D_Remove_warning=3A?=
 =?utf-8?q?_=E2=80=98res=E2=80=99_may_be_used_uninitialized_in_this_functi?=
 =?utf-8?q?on?=
Message-ID: <1570683734.97.0.750890713695.issue38425@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

Python/Python-ast.c: In function ?PyAST_obj2mod?:
Python/Python-ast.c:10253:12: warning: ?res? may be used uninitialized in this function [-Wmaybe-uninitialized]

CentOS Linux release 7.6.1810
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

----------
assignee: corona10
messages: 354312
nosy: corona10
priority: normal
severity: normal
status: open
title: Remove warning: ?res? may be used uninitialized in this function
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 10 01:31:15 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 10 Oct 2019 05:31:15 +0000
Subject: [New-bugs-announce] [issue38426] declare visit_validate in Py_DEBUG
 macro
Message-ID: <1570685475.13.0.949767572532.issue38426@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

I've got the warining like this.

Modules/gcmodule.c:1925:1: warning: ?visit_validate? defined but not used [-Wunused-function]
 visit_validate(PyObject *op, void *parent_raw)

This looks like only used in pydebug.
I'd like to propose declaring this function only in #ifdef Py_DEBUG.

My environment is 
CentOS Linux release 7.6.1810
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

----------
assignee: corona10
components: Interpreter Core
messages: 354313
nosy: corona10, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: declare visit_validate in Py_DEBUG macro
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 10 02:00:23 2019
From: report at bugs.python.org (Shengjing Zhu)
Date: Thu, 10 Oct 2019 06:00:23 +0000
Subject: [New-bugs-announce] [issue38427] Issue URL on translated Python
 docs site is always pointed to English version
Message-ID: <1570687223.02.0.730833049002.issue38427@roundup.psfhosted.org>


New submission from Shengjing Zhu <zsj950618 at gmail.com>:

On footer of https://docs.python.org/fr/3.8, "Found a bug?" links to https://docs.python.org/3/bugs.html

It should be https://docs.python.org/fr/3.8/bugs.html as 3.7 version.

----------
assignee: docs at python
components: Documentation
messages: 354314
nosy: docs at python, zhsj
priority: normal
severity: normal
status: open
title: Issue URL on translated Python docs site is always pointed to English version
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 10 04:35:51 2019
From: report at bugs.python.org (Rebecca Fair)
Date: Thu, 10 Oct 2019 08:35:51 +0000
Subject: [New-bugs-announce] [issue38428] Can't gracefully ctrl+C
 multiprocessing pool on Python3 & Windows
Message-ID: <1570696551.92.0.213022823921.issue38428@roundup.psfhosted.org>


New submission from Rebecca Fair <rebecca.fair at stfc.ac.uk>:

I want to be able to Ctrl+C to exit a multiprocessing Pool.map gracefully, and have made a solution based on this Stack Overflow answer: https://stackoverflow.com/questions/11312525/catch-ctrlc-sigint-and-exit-multiprocesses-gracefully-in-python

However, this solution works on Linux, and on Windows 10 with Python 2.7, but not on Windows 10 with Python 3.7. The Ctrl+C is just ignored and I have to kill the processes manually. I've attached the minimum code required to reproduce the problem.

Is this a bug, expected, or is there a workaround? I believe it might be caused by the behaviour of threading.Condition.wait() being changed in commit 7c3e577 but I don't know enough about signalling to say any more than that

----------
components: Windows
files: bug.py
messages: 354344
nosy: paul.moore, rebeccafair, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Can't gracefully ctrl+C multiprocessing pool on Python3 & Windows
versions: Python 3.7
Added file: https://bugs.python.org/file48653/bug.py

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

From report at bugs.python.org  Thu Oct 10 04:47:11 2019
From: report at bugs.python.org (Haruka Ma)
Date: Thu, 10 Oct 2019 08:47:11 +0000
Subject: [New-bugs-announce] [issue38429] Failed to compile with
 --enable-framework on macOS on master
Message-ID: <1570697231.32.0.587121640762.issue38429@roundup.psfhosted.org>


New submission from Haruka Ma <mrx at hcc.im>:

Since commit https://github.com/python/cpython/commit/c02b41b1fb115c87693530ea6a480b2e15460424 , some syntax errors are preventing cpython from compiling with --enable-framework on. 

Specifically, the errors are in Modules/getpath.c on line 1134 and 1165.

I've made some inline comments on github as well.

----------
components: macOS
messages: 354348
nosy: Haruka Ma, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Failed to compile with --enable-framework on macOS on master
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 10 05:41:34 2019
From: report at bugs.python.org (Evgeny Nizhibitsky)
Date: Thu, 10 Oct 2019 09:41:34 +0000
Subject: [New-bugs-announce] [issue38430] Memory leak in ThreadPoolExecutor
 + run_in_executor
Message-ID: <1570700494.14.0.073826419802.issue38430@roundup.psfhosted.org>


New submission from Evgeny Nizhibitsky <nizhibitsky at gmail.com>:

I have run into a memory leak caused by using run_in_executor + ThreadPoolExecutor while running some stability tests with custom web services.

It was 1 MB leaked for 1k requests made for my case and I've extracted the root cause and converted it into minimal script with both mentioned parts + just NOP function to "run".

The script can easily eat up to 1 GB of memory in less then 1 minute now. It uses external psutil library to report the memory allocated but it can be easily commented out and the leak will stay anyway.

One can found that script attached + Dockerfile/Makefile for reproducibility. I've also reproduced it in my own conda-based 3.7 environment as well as the master branch of cpython.

----------
components: asyncio
files: python-leak.zip
messages: 354351
nosy: Evgeny Nizhibitsky, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Memory leak in ThreadPoolExecutor + run_in_executor
type: resource usage
versions: Python 3.6, Python 3.7, Python 3.9
Added file: https://bugs.python.org/file48654/python-leak.zip

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

From report at bugs.python.org  Thu Oct 10 11:31:02 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Thu, 10 Oct 2019 15:31:02 +0000
Subject: [New-bugs-announce] [issue38431] dataclasses.InitVar breaks with
 typing.Optional
Message-ID: <1570721462.15.0.939525387822.issue38431@roundup.psfhosted.org>


New submission from Samuel Colvin <samcolvin at gmail.com>:

The following code works fine with python 3.7 but breaks with 3.8:

```
import dataclasses
from typing import Optional

@dataclasses.dataclass
class TestingDataclass:
    base_path: dataclasses.InitVar[Optional[str]] = None
```

Exception traceback:

```
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    class TestingDataclass:
  File "/usr/local/lib/python3.8/dataclasses.py", line 995, in dataclass
    return wrap(cls)
  File "/usr/local/lib/python3.8/dataclasses.py", line 987, in wrap
    return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
  File "/usr/local/lib/python3.8/dataclasses.py", line 967, in _process_class
    str(inspect.signature(cls)).replace(' -> None', ''))
  File "/usr/local/lib/python3.8/inspect.py", line 3050, in __str__
    formatted = str(param)
  File "/usr/local/lib/python3.8/inspect.py", line 2568, in __str__
    formatannotation(self._annotation))
  File "/usr/local/lib/python3.8/inspect.py", line 1202, in formatannotation
    return repr(annotation)
  File "/usr/local/lib/python3.8/dataclasses.py", line 213, in __repr__
    return f'dataclasses.InitVar[{self.type.__name__}]'
  File "/usr/local/lib/python3.8/typing.py", line 757, in __getattr__
    raise AttributeError(attr)
AttributeError: __name__
```

The code runs fine with `str` instead of `Optional[str]`.

Tested locally with `Python 3.8.0rc1 (tags/v3.8.0rc1:34214de6ab, Oct 10 2019, 16:15:14)`. The same error can be seen (in a more involved context) on travis [here](https://travis-ci.org/samuelcolvin/pydantic/jobs/596131963)

----------
components: Library (Lib)
messages: 354388
nosy: samuelcolvin
priority: normal
severity: normal
status: open
title: dataclasses.InitVar breaks with typing.Optional
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 10 12:01:41 2019
From: report at bugs.python.org (Behzad Seyfi)
Date: Thu, 10 Oct 2019 16:01:41 +0000
Subject: [New-bugs-announce] [issue38432] ZeroDivisionError when inf is
 expected
Message-ID: <1570723301.17.0.789552752187.issue38432@roundup.psfhosted.org>


New submission from Behzad Seyfi <seyfibeh at gmail.com>:

>>> 1/1e-323
inf

>>> 1/1e-324
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: float division by zero

in a 1/x fraction, up to x = 1e-324 it is inf but when x = 1e-325 or little it throws ZeroDivisionError. It is not acceptable and accountable behaviour for inf definition.

----------
components: Interpreter Core
messages: 354391
nosy: Behzad Seyfi
priority: normal
severity: normal
status: open
title: ZeroDivisionError when inf is expected
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct 10 12:17:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 10 Oct 2019 16:17:42 +0000
Subject: [New-bugs-announce] [issue38433] 2.7.17rc1 tcl/tk version
 regression on Windows
Message-ID: <1570724262.85.0.67744981479.issue38433@roundup.psfhosted.org>


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

In my current 2.7.16+ Windows 10-64 repository build, and on at least one 8.1-64 buildbot, the tcl/tk version is 8.5.19
>>> tk.Tk().tk.call('info', 'patchlevel')
'8.5.19'

In my installed 2.7.17rc1, it is the older 8.5.15.  It would seem to me that we should install the same latest 8.5 bugfix release that we test with.  (Or test with what we release ;-)  I presume the discrepancy is unintended due to an incomplete final 2.7 tcl/tk update.

----------
components: Build, Tkinter
messages: 354394
nosy: benjamin.peterson, serhiy.storchaka, terry.reedy, zach.ware
priority: release blocker
severity: normal
status: open
title: 2.7.17rc1 tcl/tk version regression on Windows
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 10 12:25:03 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Oct 2019 16:25:03 +0000
Subject: [New-bugs-announce] [issue38434] sys.addaudithook event is not
 documented
Message-ID: <1570724703.62.0.219483741722.issue38434@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The sys.addaudithook raises an audit event 'sys.addaudithook'.

The docs for the function refer to the event, as it has slightly different semantics than most, but it is not named explicitly and does not appear in the table of events.

----------
assignee: docs at python
components: Documentation
messages: 354396
nosy: docs at python, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: sys.addaudithook event is not documented
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct 10 14:18:17 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 10 Oct 2019 18:18:17 +0000
Subject: [New-bugs-announce] [issue38435] Start the deprecation cycle for
 subprocess preexec_fn
Message-ID: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

subprocess's preexec_fn feature needs to enter PendingDeprecationWarning state in 3.9, to become a DeprecationWarning in 3.10, with a goal of removing it in 3.11.

Rationale: We now live in a world full of threads, it is entirely unsafe to call back into the python interpreter within the forked child before exec per POSIX specification.

We've also already made preexec_fn no longer supported from CPython subinterpreters in 3.8.

If there are not already issues open for desired features of subprocess that do not yet have replacements or workarounds for *specific* actions that preexec_fn is being used for in your application, please open feature requests for those.  (ex: calling umask is https://bugs.python.org/issue38417, and group, uid, gid setting has already landed in 3.9)

----------
assignee: gregory.p.smith
messages: 354397
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Start the deprecation cycle for subprocess preexec_fn
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 10 15:16:04 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 10 Oct 2019 19:16:04 +0000
Subject: [New-bugs-announce] [issue38436] Improved performance for list
 addition.
Message-ID: <1570734964.11.0.75032337331.issue38436@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

The attached PR adds a fast path for BINARY_ADD instructions involving two lists, where the left list has a refcount of exactly 1.

In this case, we instead do a PySequence_InPlaceConcat operation. This has the affect of avoiding quadratic complexity for list summations, by keeping only one intermediate result and extending it in-place.

For (potentially large) lists:

    a + b + c + d ...

Currently executed as:

    tmp = a + b
    tmp = tmp + c
    tmp = tmp + d
    ...

With this change:

    tmp = a + b
    tmp += c
    tmp += d
    ...

Here are the pyperformance results (optimizations enabled):

Slower (6):
- pickle_list: 3.63 us +- 0.08 us -> 3.78 us +- 0.10 us: 1.04x slower (+4%)
- xml_etree_generate: 102 ms +- 2 ms -> 104 ms +- 3 ms: 1.02x slower (+2%)
- xml_etree_parse: 166 ms +- 4 ms -> 169 ms +- 9 ms: 1.02x slower (+2%)
- scimark_sparse_mat_mult: 5.42 ms +- 0.11 ms -> 5.47 ms +- 0.16 ms: 1.01x slower (+1%)
- pickle_dict: 23.6 us +- 0.8 us -> 23.8 us +- 0.4 us: 1.01x slower (+1%)
- scimark_fft: 413 ms +- 6 ms -> 416 ms +- 6 ms: 1.01x slower (+1%)

Faster (25):
- 2to3: 394 ms +- 18 ms -> 381 ms +- 8 ms: 1.03x faster (-3%)
- python_startup_no_site: 12.0 ms +- 0.2 ms -> 11.7 ms +- 0.2 ms: 1.03x faster (-3%)
- nqueens: 121 ms +- 2 ms -> 118 ms +- 3 ms: 1.03x faster (-2%)
- pathlib: 36.0 ms +- 1.3 ms -> 35.1 ms +- 0.9 ms: 1.02x faster (-2%)
- pickle_pure_python: 523 us +- 15 us -> 511 us +- 13 us: 1.02x faster (-2%)
- deltablue: 8.54 ms +- 0.25 ms -> 8.35 ms +- 0.27 ms: 1.02x faster (-2%)
- logging_silent: 220 ns +- 6 ns -> 215 ns +- 8 ns: 1.02x faster (-2%)
- raytrace: 566 ms +- 8 ms -> 554 ms +- 11 ms: 1.02x faster (-2%)
- hexiom: 11.2 ms +- 0.3 ms -> 11.0 ms +- 0.2 ms: 1.02x faster (-2%)
- go: 294 ms +- 6 ms -> 288 ms +- 5 ms: 1.02x faster (-2%)
- python_startup: 15.7 ms +- 0.4 ms -> 15.4 ms +- 0.5 ms: 1.02x faster (-2%)
- float: 136 ms +- 4 ms -> 134 ms +- 6 ms: 1.02x faster (-2%)
- scimark_sor: 232 ms +- 8 ms -> 228 ms +- 5 ms: 1.02x faster (-2%)
- fannkuch: 554 ms +- 8 ms -> 545 ms +- 9 ms: 1.02x faster (-2%)
- meteor_contest: 115 ms +- 2 ms -> 113 ms +- 3 ms: 1.02x faster (-2%)
- telco: 6.58 ms +- 0.22 ms -> 6.48 ms +- 0.15 ms: 1.02x faster (-2%)
- regex_effbot: 3.76 ms +- 0.08 ms -> 3.70 ms +- 0.09 ms: 1.02x faster (-2%)
- chaos: 129 ms +- 3 ms -> 127 ms +- 2 ms: 1.01x faster (-1%)
- regex_v8: 26.3 ms +- 0.4 ms -> 25.9 ms +- 0.6 ms: 1.01x faster (-1%)
- regex_compile: 200 ms +- 5 ms -> 197 ms +- 5 ms: 1.01x faster (-1%)
- logging_simple: 9.78 us +- 0.19 us -> 9.65 us +- 0.26 us: 1.01x faster (-1%)
- sqlite_synth: 3.24 us +- 0.10 us -> 3.20 us +- 0.06 us: 1.01x faster (-1%)
- unpickle: 16.4 us +- 0.5 us -> 16.2 us +- 0.5 us: 1.01x faster (-1%)
- logging_format: 10.8 us +- 0.2 us -> 10.7 us +- 0.3 us: 1.01x faster (-1%)
- json_loads: 30.2 us +- 0.8 us -> 29.9 us +- 0.6 us: 1.01x faster (-1%)

Benchmark hidden because not significant (14): json_dumps, nbody, pickle, pidigits, regex_dna, richards, scimark_lu, scimark_monte_carlo, spectral_norm, unpack_sequence, unpickle_list, unpickle_pure_python, xml_etree_iterparse, xml_etree_process

This is related to my earlier work in bpo-36229, however this is a much less invasive change that's limited to ceval.c, where our knowledge of context is much better.

----------
components: Interpreter Core
messages: 354399
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Improved performance for list addition.
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 10 15:39:02 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Oct 2019 19:39:02 +0000
Subject: [New-bugs-announce] [issue38437] Set GC_DEBUG for debug builds of
 the interpreter
Message-ID: <1570736342.37.0.0664122521403.issue38437@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

While working on bpo-38379 I had to manually set the GC_DEBUG macro to 1 to activate the extra checks that 'validate_list' does. These checks are super useful to make sure all the gc lists used are consistent and in the expected state with the expected masks.

For this reason, I propose to always activate GC_DEBUG for debug builds of the interpreter. It will have a performance impact, but the debugging benefits are substantial.

----------
messages: 354401
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Set GC_DEBUG for debug builds of the interpreter
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct 10 16:24:39 2019
From: report at bugs.python.org (Bob Alexander)
Date: Thu, 10 Oct 2019 20:24:39 +0000
Subject: [New-bugs-announce] [issue38438] argparse "usage" overly-complex
 with nargs="*"
Message-ID: <1570739079.02.0.395133592841.issue38438@roundup.psfhosted.org>


New submission from Bob Alexander <bobjalex at gmail.com>:

This program:

import argparse
ap = argparse.ArgumentParser()
ap.add_argument("arg", nargs="*")
ap.parse_args()

Gives usage message:
usage: help_complexity.py [-h] [arg [arg ...]]

It's correct, but unnecessarily complex and challenging to the user.
If I were manually writing the usage, arg... would do, or maybe [arg ...] to be consistent with other messages??

----------
components: Library (Lib)
messages: 354402
nosy: bobjalex
priority: normal
severity: normal
status: open
title: argparse "usage" overly-complex with nargs="*"
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Oct 10 19:14:55 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 10 Oct 2019 23:14:55 +0000
Subject: [New-bugs-announce] [issue38439] IDLE menu icon is blurry on GNOME
Message-ID: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

See the attached screenshot. All the GNOME apps have scalable icons, only the IDLE icon is scaled up from 48x48 pixels.

I've found similar issue32129, but apparently the accepted resolution was to change a bit of code somewhere, not to provide higher resolution icons.

----------
assignee: terry.reedy
components: IDLE
files: idle.png
messages: 354415
nosy: hroncok, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE menu icon is blurry on GNOME
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48655/idle.png

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

From report at bugs.python.org  Fri Oct 11 00:27:28 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Oct 2019 04:27:28 +0000
Subject: [New-bugs-announce] [issue38440] Possible news issues with IDLE
Message-ID: <1570768048.83.0.927013766779.issue38440@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

I've been exercising the 3.8.0rc1 version of IDLE and noticed two anomalies but have not had a chance to investigate further:

* Periodically in a long shell session, the cursor jumps to the beginning of the cumulative text output.  This necessitates a lot of scrolling to get back down to the active part of the session.

* The pop-up message box for interrupting currently running code will appear several times in succession.  Dismissing the box doesn't clear a queue of events, so the message may occur several times in a row.

----------
assignee: terry.reedy
components: IDLE
messages: 354418
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: Possible news issues with IDLE
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 11 03:26:31 2019
From: report at bugs.python.org (Aurora)
Date: Fri, 11 Oct 2019 07:26:31 +0000
Subject: [New-bugs-announce] [issue38441] failing to build the Documentation
Message-ID: <1570778791.42.0.554605100784.issue38441@roundup.psfhosted.org>


New submission from Aurora <auroraofearth at ya.ru>:

I'm failing to build the cpython/Doc dir.

The full build log is as follows:

mkdir -p build
Building NEWS from Misc/NEWS.d with blurb
PATH=./venv/bin:$PATH sphinx-build -b epub -d build/doctrees -D latex_elements.papersize=  -W . build/epub 
Running Sphinx v2.2.0
making output directory... done
building [mo]: targets for 0 po files that are out of date
building [epub]: targets for 476 source files that are out of date
updating environment: [new config] 476 added, 0 changed, 0 removed
reading sources... [100%] whatsnew/index                                                                                                                                 

Warning, treated as error:
/home/aurora/A.Code/Python/Reference/python/cpython/Doc/library/email.message.rst:4:duplicate object description of email.message, other instance in library/email.compat32-message, use :noindex: for one of them
make: *** [Makefile:46: build] Error 2


Running on Debian Experimental kernel v5.3

----------
assignee: docs at python
components: Documentation
messages: 354425
nosy: aurora, docs at python
priority: normal
severity: normal
status: open
title: failing to build the Documentation
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 11 03:38:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Oct 2019 07:38:37 +0000
Subject: [New-bugs-announce] [issue38442] Doc/whatsnew/3.8.rst has an
 execution bit
Message-ID: <1570779517.76.0.861587491217.issue38442@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

It likely happened when it was edited on Windows.

----------
assignee: docs at python
components: Documentation
messages: 354428
nosy: docs at python, lukasz.langa, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Doc/whatsnew/3.8.rst has an execution bit
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 11 03:53:54 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 11 Oct 2019 07:53:54 +0000
Subject: [New-bugs-announce] [issue38443] unavailable
 --with-universal-archs= macOS confgure options fail cryptically
Message-ID: <1570780434.84.0.507087684939.issue38443@roundup.psfhosted.org>


New submission from Ned Deily <nad at python.org>:

./configure's --with-universal-archs= supports a number of different CPU architecture combinations.  However most of them are no longer supported on current macOS systems.  If you choose an option with archs not available in the build tool chain in use, the configure script fails in various cryptic ways, usually with multiple configure test failures like:

checking dlfcn.h presence... yes
configure: WARNING: dlfcn.h: present but cannot be compiled
configure: WARNING: dlfcn.h:     check for missing prerequisite headers?
configure: WARNING: dlfcn.h: see the Autoconf documentation
configure: WARNING: dlfcn.h:     section "Present But Cannot Be Compiled"
configure: WARNING: dlfcn.h: proceeding with the compiler's result
configure: WARNING:     ## --------------------------------------- ##
configure: WARNING:     ## Report this to https://bugs.python.org/ ##
configure: WARNING:     ## --------------------------------------- ##

./configure should be more user-friendly here.  At a minimum, it should report near the beginning exactly which archs are going to be tested; it already reports the --with-universal-archs value.  Even better it should explicitly test for support of each arch in the build tool chain in use and stop if any of the requested archs are not available.

----------
components: Build, macOS
messages: 354429
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: unavailable --with-universal-archs= macOS confgure options fail cryptically
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 11 06:39:38 2019
From: report at bugs.python.org (Shmuel H.)
Date: Fri, 11 Oct 2019 10:39:38 +0000
Subject: [New-bugs-announce] [issue38444] dataclass: always generate default
 __init__ on __default_init__
Message-ID: <1570790378.12.0.986632197987.issue38444@roundup.psfhosted.org>


New submission from Shmuel H. <shmuelhazan0 at gmail.com>:

Currently, `dataclasses.dataclass` will generate `__init__` only where the user has not defined one. 

However, sometimes, with frozen classes or dataclasses with a lot of members, redefinition of this function is not trivial,
especially if the only purpose is to change the default behaviour for only one member:
```python
from dataclasses import dataclass

@dataclass(frozen=True)
class Dataclass:
    #...big list of members
    member20: int
    
    def __init__(self, member20: str, **kwargs):
        # self.member20 = int(member20)
        object.__setattr__(self, "member20", int(member20))
        # Now we have to trivially initialize 
        # 20 other members like that :[
```
My idea is to generate the default `__init__` into `__default_init__` even, if the user has defined their own version.
That will allow them to use it like that:
 ```python
from dataclasses import dataclass

@dataclass(frozen=True)
class Dataclass:
    #...big list of members
    member20: int
    
    def __init__(self, member20: str, **kwargs):
        # Oh, that's better :)
        self.__default_init__(member20=int(member20), **kwargs)
```

Implementing that is pretty trivial (I can do that if this change will be approved). 
Please let me know what you think about that.

----------
components: Library (Lib)
messages: 354437
nosy: Shmuel H.
priority: normal
severity: normal
status: open
title: dataclass: always generate default __init__ on __default_init__
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 11 07:16:42 2019
From: report at bugs.python.org (Nika)
Date: Fri, 11 Oct 2019 11:16:42 +0000
Subject: [New-bugs-announce] [issue38445] os.path.exists() takes bool as
 argument and returns True
Message-ID: <1570792602.16.0.709405121857.issue38445@roundup.psfhosted.org>


New submission from Nika <nika.boeblingen at mail.ru>:

os.path.exists() accepts either True or False as argument and returns True.
Reproducible on Windows, e. g.,  in jupyter notebook or in Eclipse, although not in IDLE, which returns False, as expected.

import os
print(os.path.exists(False))

----------
messages: 354440
nosy: Nika
priority: normal
severity: normal
status: open
title: os.path.exists() takes bool as argument and returns True
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct 11 07:29:11 2019
From: report at bugs.python.org (Dan Snider)
Date: Fri, 11 Oct 2019 11:29:11 +0000
Subject: [New-bugs-announce] [issue38446] Ambiguous signature for
 builtins.__build_class__
Message-ID: <1570793351.47.0.198943437011.issue38446@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

The function has the following signature documented:

    __build_class__(func, name, *bases, metaclass=None, **kwds) 

This implies that `func` and `name` are not positional only parameters when in fact, they are. Another problem with that signature is that None is not a valid value for the metaclass parameter.

----------
messages: 354442
nosy: bup
priority: normal
severity: normal
status: open
title: Ambiguous signature for builtins.__build_class__

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

From report at bugs.python.org  Fri Oct 11 09:01:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Oct 2019 13:01:44 +0000
Subject: [New-bugs-announce] [issue38447] test_multiprocessing_spawn:
 Dangling processes: {<SpawnProcess(QueueManager-1576,
 stopped)>} on AMD64 RHEL7 Refleaks 3.7
Message-ID: <1570798904.01.0.669672054648.issue38447@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 RHEL7 Refleaks 3.7:
https://buildbot.python.org/all/#/builders/311/builds/22

0:15:09 load avg: 12.21 [311/416/1] test_multiprocessing_spawn failed (env changed) (14 min 39 sec) -- running: test_shelve (5 min 11 sec), test_sqlite (1 min), test_cmd_line_script (1 min 26 sec), test_asyncio (3 min 13 sec), test_io (8 min 6 sec), test_pickle (53.8 sec), test_concurrent_futures (12 min 52 sec)
beginning 6 repetitions
123456
....Warning -- Dangling processes: {<SpawnProcess(QueueManager-1576, stopped)>}
Warning -- Dangling processes: {<SpawnProcess(QueueManager-1576, stopped)>}
.Warning -- Dangling processes: {<SpawnProcess(QueueManager-1788, started)>}
.

----------
components: Tests
messages: 354447
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn: Dangling processes: {<SpawnProcess(QueueManager-1576, stopped)>} on AMD64 RHEL7 Refleaks 3.7
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct 11 09:08:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Oct 2019 13:08:53 +0000
Subject: [New-bugs-announce] [issue38448] test_concurrent_futures:
 reap_children() reaped child process 26487 on AMD64 RHEL8 Refleaks 3.x
Message-ID: <1570799333.75.0.17786723855.issue38448@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 RHEL8 Refleaks 3.x:
https://buildbot.python.org/all/#/builders/272/builds/23

0:27:13 load avg: 4.88 [416/419/1] test_concurrent_futures failed (env changed) (17 min 11 sec) -- running: test_capi (7 min 28 sec), test_gdb (8 min 49 sec), test_asyncio (23 min 23 sec)
beginning 6 repetitions
123456
.Warning -- reap_children() reaped child process 26487
.....
Warning -- multiprocessing.process._dangling was modified by test_concurrent_futures
  Before: set()
  After:  {<weakref at 0x7fdc08f44e30; to 'SpawnProcess' at 0x7fdc0a467c30>}

----------
components: Tests
messages: 354448
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_concurrent_futures: reap_children() reaped child process 26487 on AMD64 RHEL8 Refleaks 3.x
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 11 10:06:40 2019
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Fri, 11 Oct 2019 14:06:40 +0000
Subject: [New-bugs-announce] [issue38449] regression - mimetypes guess_type
 is confused by ; in the filename
Message-ID: <1570802800.7.0.378651276775.issue38449@roundup.psfhosted.org>


New submission from Yaroslav Halchenko <yarikoptic at gmail.com>:

Our tests in DataLad started to fail while building on Debian with Python 3.7.5rc1 whenever they passed just fine previously with 3.7.3rc1. Analysis boiled down to mimetypes

    $> ./python3.9 -c 'import mimetypes; mimedb = mimetypes.MimeTypes(strict=False); print(mimedb.guess_type(";1.tar.gz"))'                           
    (None, None)
    
    $> ./python3.9 -c 'import mimetypes; mimedb = mimetypes.MimeTypes(strict=False); print(mimedb.guess_type("1.tar.gz"))' 
    ('application/x-tar', 'gzip')
    
    $> git describe
    v3.8.0b1-1174-g2b7dc40b2af


Ref: 

- original issue in DataLad: https://github.com/datalad/datalad/issues/3769

----------
components: Library (Lib)
messages: 354455
nosy: Yaroslav.Halchenko
priority: normal
severity: normal
status: open
title: regression - mimetypes guess_type is confused by ; in the filename
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 11 12:02:58 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Fri, 11 Oct 2019 16:02:58 +0000
Subject: [New-bugs-announce] [issue38450] 3.8 Release Notes: IDLE section
 dupe
Message-ID: <1570809778.37.0.687630988781.issue38450@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

In the 3.8 release notes (https://docs.python.org/3.8/whatsnew/3.8.html), the section "IDLE and idlelib" is duplicated as "idlelib and IDLE". Also, the section "gc" and "gzip" between them are not sorted alphabetically like the rest of the list.

----------
assignee: docs at python
components: Documentation
messages: 354464
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: 3.8 Release Notes: IDLE section dupe
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct 11 13:50:10 2019
From: report at bugs.python.org (Pouria)
Date: Fri, 11 Oct 2019 17:50:10 +0000
Subject: [New-bugs-announce] [issue38451] Datetime definition does not work
 in function definition as list definition
Message-ID: <1570816210.41.0.305155920593.issue38451@roundup.psfhosted.org>


Change by Pouria <Pouriaff7171 at gmail.com>:


----------
components: Library (Lib)
nosy: Pouria_ff
priority: normal
severity: normal
status: open
title: Datetime definition does not work in function definition as list definition
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/issue38451>
_______________________________________

From report at bugs.python.org  Fri Oct 11 13:50:10 2019
From: report at bugs.python.org (Pouria)
Date: Fri, 11 Oct 2019 17:50:10 +0000
Subject: [New-bugs-announce] [issue38451] Datetime definition does not work
 in function definition as list definition
Message-ID: <1570816210.41.0.305155920593.issue38451@roundup.psfhosted.org>


Change by Pouria <Pouriaff7171 at gmail.com>:


----------
components: Library (Lib)
nosy: Pouria_ff
priority: normal
severity: normal
status: open
title: Datetime definition does not work in function definition as list definition
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/issue38451>
_______________________________________

From report at bugs.python.org  Fri Oct 11 17:28:59 2019
From: report at bugs.python.org (Danylo)
Date: Fri, 11 Oct 2019 21:28:59 +0000
Subject: [New-bugs-announce] [issue38452] unittest setUpClass missing 1
 required positional argument: 'cls'
Message-ID: <1570829339.09.0.69466145285.issue38452@roundup.psfhosted.org>


New submission from Danylo <dizcza at gmail.com>:

Currently, unittest setUpClass and tearDownClass methods are incorrectly called from within its core.

```
class TestUltrasonicEnv(unittest.TestCase):

    def setUpClass(cls):
        pass
    

    def tearDownClass(cls):
        pass
```

Traceback (the same for teadDownClass)
```
  File "/home/dizcza/anaconda3/envs/robotsim/lib/python3.7/unittest/suite.py", line 163, in _handleClassSetUp
    setUpClass()
TypeError: setUpClass() missing 1 required positional argument: 'cls'
```

The traceback is self-descriptive.

----------
components: Tests
messages: 354501
nosy: dizcza
priority: normal
severity: normal
status: open
title: unittest setUpClass missing 1 required positional argument: 'cls'
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct 11 18:27:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 11 Oct 2019 22:27:20 +0000
Subject: [New-bugs-announce] [issue38453] ntpath.realpath() should make
 absolute path earlier
Message-ID: <1570832840.2.0.910161330311.issue38453@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Because the abspath() call is deferred until the end of the resolution process, if the current working directory is not already a real path, it will not be fully resolved.

By passing it through abspath() at the start of the function, we ensure that the correct path is resolved.

This will help resolve some inconsistencies in the test suite when tests are launched with a short filename (FILENA~1) in the working directory (though some other fixes are probably needed to help here).

----------
components: Windows
messages: 354509
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: ntpath.realpath() should make absolute path earlier
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 12 01:06:32 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 12 Oct 2019 05:06:32 +0000
Subject: [New-bugs-announce] [issue38454] test_listdir is failing on ubuntu
 with WSL
Message-ID: <1570856792.9.0.835565691535.issue38454@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

Run tests sequentially
0:00:00 load avg: 0.52 [1/1] test_os
test test_os failed -- Traceback (most recent call last):
  File "/home/isidentical/cpython/Lib/test/test_os.py", line 2059, in test_listdir
    self.assertEqual(found, expected)
AssertionError: Items in the first set but not the second:
'@test_12966_tmp-?'
Items in the second set but not the first:
'@test_12966_tmp-\udcff'

test_os failed

== Tests result: FAILURE ==

1 test failed:
    test_os

Total duration: 2 sec 587 ms
Tests result: FAILURE


System:
 - Ubuntu 18.04 bionic
 - x86_64 Linux 4.4.0-18362-Microsoft

----------
components: Tests
messages: 354518
nosy: BTaskaya, steve.dower
priority: normal
severity: normal
status: open
title: test_listdir is failing on ubuntu with WSL
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 12 15:11:40 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 12 Oct 2019 19:11:40 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue38455=5D_=E2=80=98memset?=
 =?utf-8?b?4oCZIG9mZnNldCBbMTcsIDg4XSBmcm9tIHRoZSBvYmplY3QgYXQg4oCYYWRk?=
 =?utf-8?q?rbuf=E2=80=99_is_out_of_the_bounds_of_referenced_subobject?=
Message-ID: <1570907500.34.0.810333858419.issue38455@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Compiling 3.8 in release mode emits this warning:

In function ?getsockaddrarg?,
    inlined from ?sock_bind? at /home/pablogsal/github/python/3.8/Modules/socketmodule.c:3066:10:
/home/pablogsal/github/python/3.8/Modules/socketmodule.c:2288:9: warning: ?memset? offset [17, 88] from the object at ?addrbuf? is out of the bounds of referenced subobject ?sa? with type ?struct sockaddr? at offset 0 [-Warray-bounds]
 2288 |         memset(sa, 0, sizeof(*sa));
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~

----------
messages: 354547
nosy: lukasz.langa, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: ?memset? offset [17, 88] from the object at ?addrbuf? is out of the bounds of referenced subobject
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct 12 17:27:44 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Oct 2019 21:27:44 +0000
Subject: [New-bugs-announce] [issue38456] Reduce the time test_subprocess
 takes to complete.
Message-ID: <1570915664.41.0.600749429007.issue38456@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

test_subprocess is one of our long running tests, this slows down CI and buildbots.  There is room for improvement in its total execution time.

Use this issue as a rollup issue for any such work.  we need to keep it reliable, just focus on reducing either user/sys cpu time or wall time.

----------
assignee: gregory.p.smith
components: Tests
messages: 354554
nosy: gregory.p.smith
priority: low
severity: normal
status: open
title: Reduce the time test_subprocess takes to complete.
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 12 17:48:12 2019
From: report at bugs.python.org (Yuval S)
Date: Sat, 12 Oct 2019 21:48:12 +0000
Subject: [New-bugs-announce] [issue38457] __package__ is None in __init__.py
 until an import is used
Message-ID: <1570916892.54.0.164577302417.issue38457@roundup.psfhosted.org>


New submission from Yuval S <sadan.yuval at gmail.com>:

In Python 2.7, the __package__ variable isn't set when __init__.py is run, until an import is done. In Python 3.5, it is set correctly.

e.g.

# mkdir x && echo "print(__package__)" | tee x/__init__.py x/test.py
# python2 x.test
None
x
# python3 x.test
x
x
# echo -e "import os\n$(cat x/__init__.py)" > x/__init__.py
# python2 x.test
x
x

This is very old, as it's there at least since 2010: https://stackoverflow.com/questions/4437394/package-is-none-when-importing-a-python-module 

I would expect Python 2 and 3 to behave the same.

----------
components: Library (Lib)
messages: 354555
nosy: Yuval S
priority: normal
severity: normal
status: open
title: __package__ is None in __init__.py until an import is used
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 12 19:54:11 2019
From: report at bugs.python.org (DEVOR BLAKE DANIELS)
Date: Sat, 12 Oct 2019 23:54:11 +0000
Subject: [New-bugs-announce] [issue38458] lists
Message-ID: <1570924451.06.0.602805161238.issue38458@roundup.psfhosted.org>


New submission from DEVOR BLAKE DANIELS <dev40573 at gmail.com>:

l=[2,3,4]
p=l
p[0]=5
when I change p[0] to 5,l[0] is also changed to 5. I use slicing to get around this ,but when dealing with lists like s[][],slicing does not work

----------
files: three.py
messages: 354558
nosy: dev40573
priority: normal
severity: normal
status: open
title: lists
type: behavior
Added file: https://bugs.python.org/file48657/three.py

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

From report at bugs.python.org  Sun Oct 13 04:31:23 2019
From: report at bugs.python.org (John Lennon)
Date: Sun, 13 Oct 2019 08:31:23 +0000
Subject: [New-bugs-announce] [issue38459] typing: Classes that inherit
 `Generic[...]` indirectly aren't considered generic.
Message-ID: <1570955483.97.0.910944150391.issue38459@roundup.psfhosted.org>


New submission from John Lennon <enjigglypuffcx at gmail.com>:

Given the file `example.py` with the following contents:


```python

from typing import Generic, TypeVar

KT = TypeVar("KT")
VT = TypeVar("VT")


class GenericMapping(Generic[KT, VT]):
    pass


class SomeImplMapping(GenericMapping):
    pass


a: GenericMapping[int, float]
b: SomeImplMapping[int, float]
```


I would expect `SomeImplMapping` to be generic as well as `GenericMapping`. However, currently this code fails with the following error:

```sh
Traceback (most recent call last):
  File "adt.py", line 18, in <module>
    b: SomeImplMapping[int, float]
  File "/usr/local/lib/python3.7/typing.py", line 254, in inner
    return func(*args, **kwds)
  File "/usr/local/lib/python3.7/typing.py", line 841, in __class_getitem__
    _check_generic(cls, params)
  File "/usr/local/lib/python3.7/typing.py", line 204, in _check_generic
    raise TypeError(f"{cls} is not a generic class")
TypeError: <class '__main__.SomeImplMapping'> is not a generic class
```


If I understand everything correctly, that's because `typing` doesn't check bases of the class to have `__parameters__` attribute:

https://github.com/python/cpython/blob/master/Lib/typing.py#L210

I did not found the restriction that only direct childs of `Generic[..]` class can be generic in the docs, so I think this is a bug.

----------
components: Library (Lib)
messages: 354568
nosy: John Lennon
priority: normal
severity: normal
status: open
title: typing: Classes that inherit `Generic[...]` indirectly aren't considered generic.
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Oct 13 08:20:54 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Sun, 13 Oct 2019 12:20:54 +0000
Subject: [New-bugs-announce] [issue38460] 3.8 Release Notes: document
 asyncio exception changes
Message-ID: <1570969254.43.0.827620904639.issue38460@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

In Python 3.8 asyncio exceptions were consolidated into the new module "asyncio.exceptions". Previously they were spread out over several modules. While the documentation always mandated to import the exceptions from top-level "asyncio", code that incorrectly imported directly from the submodules will break.

----------
assignee: docs at python
components: Documentation
messages: 354577
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: 3.8 Release Notes: document asyncio exception changes
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct 13 09:06:44 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Sun, 13 Oct 2019 13:06:44 +0000
Subject: [New-bugs-announce] [issue38461] 3.8 Release Notes: "curses"
 misspelled as "ncurses"
Message-ID: <1570972004.47.0.506267753893.issue38461@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

The "curses" module is misspelled and sorted as "ncurses" in the release notes.

----------
messages: 354579
nosy: srittau
priority: normal
severity: normal
status: open
title: 3.8 Release Notes: "curses" misspelled as "ncurses"

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

From report at bugs.python.org  Sun Oct 13 09:31:35 2019
From: report at bugs.python.org (Roy Smith)
Date: Sun, 13 Oct 2019 13:31:35 +0000
Subject: [New-bugs-announce] [issue38462] Typo (nam ing) in import system
 docs
Message-ID: <1570973495.13.0.272264963981.issue38462@roundup.psfhosted.org>


New submission from Roy Smith <roy at panix.com>:

In https://docs.python.org/3.5/reference/import.html#importsystem, section "5.2 Packages", second sentence, the word "naming" is broken across two lines.

In 3.7.5rc1 as well.  Didn't check any others.

----------
assignee: docs at python
components: Documentation
messages: 354581
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: Typo (nam ing) in import system docs
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct 13 09:47:22 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Sun, 13 Oct 2019 13:47:22 +0000
Subject: [New-bugs-announce] [issue38463] 3.8 Release Notes: Link to
 SSLContext.post_handshake_auth missing
Message-ID: <1570974442.94.0.731112598518.issue38463@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

The link to SSLContext.post_handshake_auth in the "ssl" section in the release notes is missing.

----------
assignee: docs at python
components: Documentation
messages: 354582
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: 3.8 Release Notes: Link to SSLContext.post_handshake_auth missing
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct 13 10:20:27 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Sun, 13 Oct 2019 14:20:27 +0000
Subject: [New-bugs-announce] [issue38464] documentation for
 NormalDist.quantiles(): missing argument
Message-ID: <1570976427.94.0.852447580797.issue38464@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

The documentation for NormalDist.quantiles() (https://docs.python.org/3.8/library/statistics.html#statistics.NormalDist) is missing the "n" argument from the definition.

----------
assignee: docs at python
components: Documentation
messages: 354584
nosy: docs at python, rhettinger, srittau
priority: normal
severity: normal
status: open
title: documentation for NormalDist.quantiles(): missing argument
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct 13 10:57:15 2019
From: report at bugs.python.org (hai shi)
Date: Sun, 13 Oct 2019 14:57:15 +0000
Subject: [New-bugs-announce] [issue38465] The type of ob_exports in
 PyByteArrayObject become Py_ssize_t.
Message-ID: <1570978635.87.0.596564542888.issue38465@roundup.psfhosted.org>


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

for a code example:
```
v = []
b = bytearray(0xffff)
for i in range(2**31+1)
    # the ob_exports would be overflow in 32 bit machine when i = 2**31.
    v.append(memoryview(b))
```
IMHO, i thought converting the type of ob_exports to Py_ssize_t is fine.

PS: I have no actual user scenario.

----------
components: Interpreter Core
messages: 354586
nosy: shihai1991
priority: normal
severity: normal
status: open
title: The type of ob_exports in PyByteArrayObject become Py_ssize_t.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 13 11:40:26 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Sun, 13 Oct 2019 15:40:26 +0000
Subject: [New-bugs-announce] [issue38466] threading.excepthook doc talks
 about "object"
Message-ID: <1570981226.47.0.762418362865.issue38466@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

The documentation of threading.excepthook (https://docs.python.org/3.8/library/threading.html#threading.excepthook) talks about "object", when it only has a "thread" attribute:

"Storing object using a custom hook can resurrect it if it is set to an object which is being finalized. Avoid storing object after the custom hook completes to avoid resurrecting objects."

I believe this is a copy and paste error from sys.unraisablehook.

----------
assignee: docs at python
components: Documentation
messages: 354588
nosy: docs at python, srittau, vstinner
priority: normal
severity: normal
status: open
title: threading.excepthook doc talks about "object"
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct 13 12:04:33 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Sun, 13 Oct 2019 16:04:33 +0000
Subject: [New-bugs-announce] [issue38467] Misspelled argument names for
 typing.get_origin and get_args
Message-ID: <1570982673.75.0.804199303932.issue38467@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

The arguments for typing.get_origin() and typing.get_args() are named "typ" in the documentation (https://docs.python.org/3.8/library/typing.html#typing.get_origin), while they are named "tp" in the implementation. Important if used as keyword argument.

----------
assignee: docs at python
components: Documentation
messages: 354590
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: Misspelled argument names for typing.get_origin and get_args
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct 13 12:13:45 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sun, 13 Oct 2019 16:13:45 +0000
Subject: [New-bugs-announce] [issue38468] Refactor python-config.in - use
 getvar()
Message-ID: <1570983225.71.0.166757825145.issue38468@roundup.psfhosted.org>


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

Use getvar for all still existing sysconfig.get_config_var() calls.

----------
messages: 354591
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Refactor python-config.in - use getvar()
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 13 16:54:11 2019
From: report at bugs.python.org (Pierre Quentel)
Date: Sun, 13 Oct 2019 20:54:11 +0000
Subject: [New-bugs-announce] [issue38469] PEP 572 : assignment expression to
 a global variable in a comprehension
Message-ID: <1571000051.15.0.611092311064.issue38469@roundup.psfhosted.org>


New submission from Pierre Quentel <pierre.quentel at gmail.com>:

PEP 572 says that "an assignment expression occurring in a (...) comprehension (...) binds the target in the containing scope, honoring a nonlocal or global declaration for the target in that scope, if one exists."

In Appendix B, the PEP shows this example :

def f():
    global TARGET
    a = [TARGET := EXPR for VAR in ITERABLE]

So I don't understand why this fails:

Python 3.8.0rc1 (tags/v3.8.0rc1:34214de, Oct  1 2019, 18:42:37) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 0
>>> def f():
...     global x
...     [x := i for i in range(5)]
...
  File "<stdin>", line 3
SyntaxError: no binding for nonlocal 'x' found
>>>

Is this a bug or am I missing something ?

----------
components: Interpreter Core
messages: 354601
nosy: quentel
priority: normal
severity: normal
status: open
title: PEP 572 : assignment expression to a global variable in a comprehension
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct 13 20:45:36 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 14 Oct 2019 00:45:36 +0000
Subject: [New-bugs-announce] [issue38470] test_compileall fails in AMD64
 Windows7 SP1 3.x
Message-ID: <1571013936.71.0.668005842061.issue38470@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

This buildbot has been failing for a long time (example failure https://buildbot.python.org/all/#/builders/40/builds/3291) since https://github.com/python/cpython/commit/4267c989e7fc6cd528e8a1d04a07fac5cca85ec7:

======================================================================
FAIL: test_compile_dir_maxlevels (test.test_compileall.CompileallTestsWithSourceEpoch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_py_compile.py", line 30, in wrapper
    return fxn(*args, **kwargs)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_compileall.py", line 257, in test_compile_dir_maxlevels
    self.assertTrue(os.path.isfile(self.bc_path_long))
AssertionError: False is not true
======================================================================
FAIL: test_compile_dir_maxlevels (test.test_compileall.CompileallTestsWithoutSourceEpoch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_py_compile.py", line 20, in wrapper
    return fxn(*args, **kwargs)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_compileall.py", line 257, in test_compile_dir_maxlevels
    self.assertTrue(os.path.isfile(self.bc_path_long))
AssertionError: False is not true
----------------------------------------------------------------------


Can someone try to fix the error, otherwise we would  need to revert commit 4267c989e7fc6cd528e8a1d04a07fac5cca85ec7.

----------
components: Tests, Windows
messages: 354609
nosy: hroncok, pablogsal, paul.moore, petr.viktorin, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: test_compileall fails in AMD64 Windows7 SP1 3.x
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 14 06:42:35 2019
From: report at bugs.python.org (Paul Martin)
Date: Mon, 14 Oct 2019 10:42:35 +0000
Subject: [New-bugs-announce] [issue38471] _ProactorDatagramTransport: If
 close() is called when write buffer is not empty,
 the remaining data is not sent and connection_lost is not called
Message-ID: <1571049755.46.0.456741846567.issue38471@roundup.psfhosted.org>


New submission from Paul Martin <greatestloginnameever at gmail.com>:

Expected behaviour for DatagramTransport (from_SelectorDatagramTransport):

transport.close() called.
If there is data in the write buffer, don't call connection_lost.
When all data is written and the buffer is empty, check if connection has been lost and if so, call connection_lost

However for _ProactorDatagramTransport, if close is called with data in the buffer, _loop_writing returns immediately, so it never gets to the point of sending the remaining data or calling connection_lost. The code for calling connection_lost inside _loop_writing is completely unreachable, because the method immediately returns if the connection has been lost.

----------
components: Windows, asyncio
messages: 354626
nosy: asvetlov, paul.moore, primal, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: _ProactorDatagramTransport: If close() is called when write buffer is not empty, the remaining data is not sent and connection_lost is not called
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 14 08:28:35 2019
From: report at bugs.python.org (Alex Grund)
Date: Mon, 14 Oct 2019 12:28:35 +0000
Subject: [New-bugs-announce] [issue38472] GCC detection in setup.py is broken
Message-ID: <1571056115.0.0.505317698716.issue38472@roundup.psfhosted.org>


New submission from Alex Grund <flamefire89 at gmail.com>:

`setup.py` runs `<CC> -E -v - </dev/null 1>/dev/null` to figure out include and library paths from the compiler in the function `add_gcc_paths`.

However sample output from the compiler is:

Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=g++
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: ../configure --enable-languages=c,c++,fortran --enable-lto --enable-checking=release --disable-multilib --enable-shared=yes --enable-static=yes --enable-threads=posix --enable-plugins --enable-gold=default --enable-ld --with-plugin-ld=ld.gold --prefix=/sw/installed/GCCcore/9.1.0 --with-local-prefix=/sw/installed/GCCcore/9.1.0 --enable-bootstrap --with-isl=/dev/shm/easybuild-build/GCCcore/9.1.0/dummy-/gcc-9.1.0/stage2_stuff
Thread-Modell: posix
gcc-Version 9.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-E' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /software/haswell/GCCcore/9.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.1.0/cc1 -E -quiet -v -iprefix /software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/ - -mtune=generic -march=x86-64
nicht vorhandenes Verzeichnis ?/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/include? wird ignoriert
doppeltes Verzeichnis ?/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/9.1.0/include? wird ignoriert
doppeltes Verzeichnis ?/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/9.1.0/include-fixed? wird ignoriert
nicht vorhandenes Verzeichnis ?/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/include? wird ignoriert
doppeltes Verzeichnis ?/sw/installed/GCCcore/9.1.0/include? wird ignoriert
  da es ein Nicht-Systemverzeichnis ist, das ein Systemverzeichnis dupliziert
Suche f?r ?#include "..."? beginnt hier:
Suche f?r ?#include <...>? beginnt hier:
 /sw/installed/binutils/2.32-GCCcore-9.1.0/include
 /sw/installed/zlib/1.2.11-GCCcore-9.1.0/include
 /software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/include
 /software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/include-fixed
 /sw/installed/GCCcore/9.1.0/include
 /usr/include
Ende der Suchliste.
COMPILER_PATH=/software/haswell/GCCcore/9.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.1.0/:/software/haswell/GCCcore/9.1.0/bin/../libexec/gcc/
LIBRARY_PATH=/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/:/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/:/sw/installed/GCCcore/9.1.0/lib64/../lib64/:/sw/installed/GCCcore/9.1.0/lib/../lib64/:/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/sw/installed/binutils/2.32-GCCcore-9.1.0/lib/:/sw/installed/zlib/1.2.11-GCCcore-9.1.0/lib/:/sw/installed/GCCcore/9.1.0/lib64/:/sw/installed/GCCcore/9.1.0/lib/:/software/haswell/GCCcore/9.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-E' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'


So the correct matcher would be "gcc-Version", maybe in addition to "gcc version"

Due to this the setup fails to build e.g. bzip2 modules as the include and lib paths are passed in via CPATH and LIBRARY_PATH only (module system on HPC system)

----------
components: Build
messages: 354629
nosy: Alex Grund
priority: normal
severity: normal
status: open
title: GCC detection in setup.py is broken
type: compile error
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/issue38472>
_______________________________________

From report at bugs.python.org  Mon Oct 14 10:25:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Oct 2019 14:25:09 +0000
Subject: [New-bugs-announce] [issue38473] AttributeError on asserting
 autospecced mock object added using attach_mock
Message-ID: <1571063109.86.0.136370910863.issue38473@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

The following program causes AttributeError while retrieving the spec signature of a call. It seems that not all mocks specced should have _spec_signature where if autospec is used and the mock is attached with attach_mock then the "mock" attribute has the correct object from which _spec_signature has to be derived. On the attribute being not present we can fallback to the sig being None. This can be workaround by disabling autospec but since this is present in 3.7.5RC1 and 3.8.0RC1 I am tagging it as regression. 

I am also attaching a patch with script to reproduce this that should pass with the patch. I will try to make a PR tonight. Sorry for the last minute report I just stumbled upon this while debugging https://bugs.python.org/issue21478#msg354489. This change was introduced as part of https://bugs.python.org/issue36871 by me. I am tagging the nosy list from issue for review of the patch.


import unittest
from unittest.mock import patch, Mock, call, ANY


class Foo:
    def set_foo(self, val): pass


class FooTest(unittest.TestCase):
    @patch(f"{__name__}.Foo.set_foo", autospec=True)
    def test_autospec_attach_mock_assert(self, mock_set_foo):
        manager = Mock()
        manager.attach_mock(mock_set_foo, "set_foo_func")
        obj = Foo()
        obj.set_foo(3)
        manager.assert_has_calls([call.set_foo_func(ANY, 3)])

if __name__ == "__main__":
    unittest.main()


?  Python-3.7.5rc1 ./python autospec_regression.py
E
======================================================================
ERROR: test_autospec_attach_mock_assert (__main__.FooTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/xtreak/Python-3.7.5rc1/Lib/unittest/mock.py", line 1255, in patched
    return func(*args, **keywargs)
  File "autospec_regression.py", line 16, in test_autospec_attach_mock_assert
    manager.assert_has_calls([call.set_foo_func(ANY, 3)])
  File "/home/xtreak/Python-3.7.5rc1/Lib/unittest/mock.py", line 897, in assert_has_calls
    expected = [self._call_matcher(c) for c in calls]
  File "/home/xtreak/Python-3.7.5rc1/Lib/unittest/mock.py", line 897, in <listcomp>
    expected = [self._call_matcher(c) for c in calls]
  File "/home/xtreak/Python-3.7.5rc1/Lib/unittest/mock.py", line 812, in _call_matcher
    sig = self._get_call_signature_from_name(_call[0])
  File "/home/xtreak/Python-3.7.5rc1/Lib/unittest/mock.py", line 798, in _get_call_signature_from_name
    sig = child._spec_signature
AttributeError: 'function' object has no attribute '_spec_signature'

----------------------------------------------------------------------
Ran 1 test in 0.003s

FAILED (errors=1)

Patch : 


?  Python-3.7.5rc1 diff -u Lib/unittest/mock.py Lib/unittest/mock_patched.py
--- Lib/unittest/mock.py	2019-10-01 22:53:17.000000000 +0530
+++ Lib/unittest/mock_patched.py	2019-10-14 19:18:00.038416294 +0530
@@ -795,7 +795,16 @@
                 break
             else:
                 children = child._mock_children
-                sig = child._spec_signature
+                # If an autospecced object is attached using attach_mock the
+                # child would be a function with mock object as attribute from
+                # which signature has to be derived. If there is no signature
+                # attribute then fallback to None to ensure old signature is 
+                # not used.
+                child = _extract_mock(child)
+                try:
+                    sig = child._spec_signature
+                except AttributeError:
+                    sig = None
 
         return sig

----------
components: Library (Lib)
keywords: 3.7regression, 3.8regression
messages: 354635
nosy: cjw296, gregory.p.smith, lisroach, lukasz.langa, mariocj89, michael.foord, ned.deily, xtreak
priority: normal
severity: normal
status: open
title: AttributeError on asserting autospecced mock object added using attach_mock
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 14 14:30:34 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 14 Oct 2019 18:30:34 +0000
Subject: [New-bugs-announce] [issue38474] digit check logic can be replaced
 by Py_ISDIGIT on prepare_s
Message-ID: <1571077834.59.0.937971525821.issue38474@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

digit check logic can be replaced by Py_ISDIGIT on prepare_s.

----------
assignee: corona10
messages: 354643
nosy: corona10
priority: normal
severity: normal
status: open
title: digit check logic can be replaced by Py_ISDIGIT on prepare_s

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

From report at bugs.python.org  Mon Oct 14 15:31:02 2019
From: report at bugs.python.org (DEVOR BLAKE DANIELS)
Date: Mon, 14 Oct 2019 19:31:02 +0000
Subject: [New-bugs-announce] [issue38475] Break Statement
Message-ID: <1571081462.55.0.733459298847.issue38475@roundup.psfhosted.org>


New submission from DEVOR BLAKE DANIELS <dev40573 at gmail.com>:

The break statement in my AiO() function seems to cause my Uinput() function to malfunction.

----------
components: Windows
files: three.py
messages: 354645
nosy: dev40573, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Break Statement
versions: Python 3.8
Added file: https://bugs.python.org/file48659/three.py

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

From report at bugs.python.org  Mon Oct 14 17:52:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Oct 2019 21:52:47 +0000
Subject: [New-bugs-announce] [issue38476]
 test_multiprocessing_fork.test_terminate() failed on AMD64 Debian PGO 3.x
Message-ID: <1571089967.06.0.895638026997.issue38476@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

test_multiprocessing_fork.test_terminate() failed twice on AMD64 Debian PGO 3.x:

https://buildbot.python.org/all/#/builders/47/builds/3699

0:23:37 load avg: 0.01 [419/419/1] test_multiprocessing_fork crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x00007f0272748700 (most recent call first):
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/connection.py", line 414 in _recv_bytes
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/pool.py", line 599 in _handle_results
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/threading.py", line 882 in run
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/threading.py", line 902 in _bootstrap

Thread 0x00007f027a8a6500 (most recent call first):
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/pool.py", line 674 in _help_stuff_finish
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/pool.py", line 689 in _terminate_pool
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/util.py", line 201 in __call__
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/pool.py", line 656 in terminate
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/test/_test_multiprocessing.py", line 2521 in test_terminate
...
0:23:37 load avg: 0.01 Re-running test_multiprocessing_fork in verbose mode
...
test_starmap (test.test_multiprocessing_fork.WithProcessesTestPool) ... ok
test_starmap_async (test.test_multiprocessing_fork.WithProcessesTestPool) ... ok
Timeout (0:15:00)!
Thread 0x00007f251d553700 (most recent call first):
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/connection.py", line 414 in _recv_bytes
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/pool.py", line 599 in _handle_results
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/threading.py", line 882 in run
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/threading.py", line 902 in _bootstrap

Thread 0x00007f2523e76500 (most recent call first):
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/pool.py", line 674 in _help_stuff_finish
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/pool.py", line 689 in _terminate_pool
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/util.py", line 201 in __call__
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/multiprocessing/pool.py", line 656 in terminate
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.pgo/build/Lib/test/_test_multiprocessing.py", line 2521 in test_terminate

----------
components: Tests
messages: 354669
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_fork.test_terminate() failed on AMD64 Debian PGO 3.x
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 14 21:42:50 2019
From: report at bugs.python.org (Louis Huemiller)
Date: Tue, 15 Oct 2019 01:42:50 +0000
Subject: [New-bugs-announce] [issue38477] magiccube2x2 permutations 28%
 slower with Python 3.8.0rc1 vs 3.7
Message-ID: <1571103770.08.0.648523147203.issue38477@roundup.psfhosted.org>


New submission from Louis Huemiller <lhuemill at gmail.com>:

Have created a program that by brute force determines all reachable states of a 2-by-2 MagicCube, sometimes referred to as a 2x2 Rubick's cube. On one of my servers, which is described in the attached file 20191011b_configuration, this program takes 19520.03 seconds to execute under Python2.7.15+, while under 3.8.0rc1 it takes 21887.53 seconds. This program is taking 12.13% longer to execute with 3.8.0rc1 versus 2.7.15+. The exact versions of Python as reported by sys.version are:

  2.7.15+ (default, Oct  7 2019, 17:39:04)
  [GCC 7.4.0]

  3.8.0rc1 (default, Oct  1 2019, 21:48:24)
  [GCC 7.4.0]

Used the following script to execute this program under Python 2.7, 3.6, 3.7, and 3.8:

  mkdir -p ./results
  echo "======== git log ========" > ./results/20191011b_configuration
  git log -n4 >> ./results/20191011b_configuration

  echo ""  >> ./results/20191011b_configuration
  echo "======== uname ========" >> ./results/20191011b_configuration
  uname -a >> ./results/20191011b_configuration

  echo ""  >> ./results/20191011b_configuration
  echo "======== lsb_release ========" >> 
  ./results/20191011b_configuration
  lsb_release -a >> ./results/20191011b_configuration

  echo ""  >> ./results/20191011b_configuration
  echo "======== lshw ========" >> ./results/20191011b_configuration
  sudo lshw >> ./results/20191011b_configuration

  make clean
  make
  ./target/permutations2x2 > \
    ./results/20191011b_magiccube2x2_permutations_cxx_unordered_map 2>&1
  python3.8 ./permutations2x2  > \
    ./results/20191011b_magiccube2x2_permutations_python3.8.0rc1 2>&1
  python3.7 ./permutations2x2  > \
    ./results/20191011b_magiccube2x2_permutations_python3.7 2>&1
  python3.6 ./permutations2x2  > \
    ./results/20191011b_magiccube2x2_permutations_python3.6 2>&1
  python2.7 ./permutations2x2  > 
  ./results/20191011b_magiccube2x2_permutations_python2.7 2>&1

Doing egrep "^# Total_Time:" on each of the output files, shows that the various executions took the following amount of time:

  cxx_unordered_map:# Total_Time: 1098.25
  python2.7:# Total_Time: 19520.03
  python3.6:# Total_Time: 19562.28
  python3.7:# Total_Time: 17012.67
  python3.8.0rc1:# Total_Time: 21887.53

Under Python2.7 and Python3.6 the program ran in approximately the same amount of time, while under Python3.7 it ran 12.8% faster than execution with Python2.7. Finally, the python3.8.0rc1 execution is noticeably slower than all the other executions, at 12.1% lower than Python2.7 and 28.6% slower than Python3.7.

The source for the magic_cube2x2 program is available under gist.github.com at:

  https://gist.github.com/lhuemill/f1273291e5f5e85e4b42e5c7614e60ef

This program creates a fairly large dictionary of 88.179840M entries. Each entry has a key of a string of length 29 and a value string of with a maximum length of 22 characters. A quick back-of-the-envelope calculation shows that this dictionary would use approximately 9GB of memory, but for some reason, all of the Python executions use approximately 22.6GB of memory. Even the C++ version is using 20.2GB when the permutations are stored in an unordered_map<string, string> and 20.55GB when stored in a map<string, string>. Quite surprising that the C++ is using over twice the expected amount of memory.

  CAUTION: When executing this program with less than the needed
           amount of physical memory, be careful that swap is not
           backed by a flash device. Doing so will likely cause
           a significant amount of I/O to the flash device and
           likely quickly wear it out.

----------
files: 20191005b_configuration
messages: 354682
nosy: Louis Huemiller
priority: normal
severity: normal
status: open
title: magiccube2x2 permutations 28% slower with Python 3.8.0rc1 vs 3.7
type: performance
versions: Python 3.8
Added file: https://bugs.python.org/file48660/20191005b_configuration

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

From report at bugs.python.org  Mon Oct 14 22:26:32 2019
From: report at bugs.python.org (Brian Shaginaw)
Date: Tue, 15 Oct 2019 02:26:32 +0000
Subject: [New-bugs-announce] [issue38478] inspect.signature.bind does not
 correctly handle keyword argument with same name as positional-only
 parameter
Message-ID: <1571106392.69.0.85003046785.issue38478@roundup.psfhosted.org>


New submission from Brian Shaginaw <bshaginaw120 at gmail.com>:

>>> import inspect
>>> def foo(bar, /, **kwargs):
...   print(bar, kwargs)
...
>>> foo(1, bar=2)
1 {'bar': 2}
>>> inspect.signature(foo).bind(1, bar=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/inspect.py", line 3025, in bind
    return self._bind(args, kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/inspect.py", line 2964, in _bind
    raise TypeError(
TypeError: multiple values for argument 'bar'


Python 3.8 introduced positional-only parameters, which allow parameter names to remain available for use in **kwargs. It looks like `inspect.signature.bind` does not recognize this, and thinks the parameter is being passed twice, which causes the above TypeError.

Expected result: <BoundArguments (bar=1, kwargs={'bar': 2})>

----------
components: Library (Lib)
messages: 354683
nosy: brian.shaginaw
priority: normal
severity: normal
status: open
title: inspect.signature.bind does not correctly handle keyword argument with same name as positional-only parameter
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 15 01:31:30 2019
From: report at bugs.python.org (Young Y)
Date: Tue, 15 Oct 2019 05:31:30 +0000
Subject: [New-bugs-announce] [issue38479] Segmentation fault: 11 Python3.6
 on Macbook
Message-ID: <1571117490.83.0.0706569063391.issue38479@roundup.psfhosted.org>


New submission from Young Y <honglou2001 at gmail.com>:

Segmentation fault: 11Process:               Python [5343]
Path:                  /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.6.5 (3.6.5)
Code Type:             X86-64 (Native)
Parent Process:        bash [3524]
Responsible:           Python [5343]
User ID:               501

Date/Time:             2019-10-15 13:26:45.395 +0800
OS Version:            Mac OS X 10.14.1 (18B75)
Report Version:        12
Anonymous UUID:        4552DCD6-6528-6E1A-0C86-24A09F7835F8


Time Awake Since Boot: 9600 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000201c49b57
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [5343]

VM Regions Near 0x201c49b57:
    VM_ALLOCATE            0000000181c4a000-0000000181c4b000 [    4K] r-x/rwx SM=PRV  
--> 
    __UNIXSTACK            00007fff5b000000-00007fff5c000000 [ 16.0M] rw-/rwx SM=ALI  /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python

Application Specific Information:
dyld: launch, running initializers
/Library/Application Support/Cylance/Desktop/CyMemDef.dylib

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                           	0x0000000201c49b57 0 + 8619596631
1   CyMemDef.dylib                	0x0000000100a77737 _vm_protect(unsigned int, unsigned long, unsigned long, unsigned int, int) + 149
2   CyMemDef.dylib                	0x0000000100a73e3e mach_override_setup + 219
3   CyMemDef.dylib                	0x0000000100a79297 injector(inject_s*, unsigned long) + 355
4   CyMemDef.dylib                	0x0000000100a790a5 MemDefMemory_initialize() + 35
5   CyMemDef.dylib                	0x0000000100a77050 memdefosx_initialize + 28
6   dyld                          	0x00007fff5f67dcc8 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 518
7   dyld                          	0x00007fff5f67dec6 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
8   dyld                          	0x00007fff5f6790da ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 358
9   dyld                          	0x00007fff5f67906d ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 249
10  dyld                          	0x00007fff5f678254 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 134
11  dyld                          	0x00007fff5f6782e8 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 74
12  dyld                          	0x00007fff5f667774 dyld::initializeMainExecutable() + 199
13  dyld                          	0x00007fff5f66c78f dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 6237
14  dyld                          	0x00007fff5f6664f6 dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 1154
15  dyld                          	0x00007fff5f666036 _dyld_start + 54

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000100a94178  rbx: 0x0000000101c4ab3a  rcx: 0x0000000000000000  rdx: 0x0000000000000008
  rdi: 0x0000000000000103  rsi: 0x0000000101c4ab3a  rbp: 0x00007fff5bffdef0  rsp: 0x00007fff5bffdaa8
   r8: 0x0000000000000005   r9: 0x0000000000000000  r10: 0x0000000000000000  r11: 0x0000000000000246
  r12: 0x0000000000000005  r13: 0x0000000000000103  r14: 0x0000000000000000  r15: 0x0000000000000008
  rip: 0x0000000201c49b57  rfl: 0x0000000000010246  cr2: 0x0000000201c49b57
  
Logical CPU:     1
Error Code:      0x00000014
Trap Number:     14


Binary Images:
       0x100000000 -        0x100000ff7 +org.python.python (3.6.5 - 3.6.5) <C539EB14-B454-D151-7B93-6A12255582B2> /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x100450fe7  com.apple.CoreFoundation (6.9 - 1560.12) <B5BDC307-6C89-3DE0-B4B9-4C2C650E4528> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
       0x1006fb000 -        0x100922fef +org.python.python (3.6.5, [c] 2001-2018 Python Software Foundation. - 3.6.5) <EBF198CD-A37E-A0F1-1E7C-19B9F912D34A> /Library/Frameworks/Python.framework/Versions/3.6/Python
       0x100a6b000 -        0x100a6cffb  libSystem.B.dylib (1252.200.5) <D5AFCC78-2AC2-37EB-B0EF-BB00FD38ED00> /usr/lib/libSystem.B.dylib
       0x100a72000 -        0x100a83ff7 +CyMemDef.dylib (0) <7F2E0690-20B4-335A-AE40-D51A0FD1582F> /Library/Application Support/Cylance/*/CyMemDef.dylib
       0x100ab5000 -        0x10123bfe7  libobjc.A.dylib (750.1) <9CE27EC3-3A12-35D1-8F2F-3550B9668259> /usr/lib/libobjc.A.dylib
       0x1013f3000 -        0x1013f4ff7  libDiagnosticMessagesClient.dylib (107) <C542CB3C-AA44-3D7F-B88C-79CC31B481AB> /usr/lib/libDiagnosticMessagesClient.dylib
       0x1013fa000 -        0x10165dffb  libicucore.A.dylib (62108.0.1) <969815D4-A345-31BB-82B7-0C3B58CA7E90> /usr/lib/libicucore.A.dylib
       0x10174b000 -        0x10175dffb  libz.1.dylib (70.200.4) <99A3D725-8388-38B4-B66C-5E9006E6F072> /usr/lib/libz.1.dylib
       0x101763000 -        0x101778fff  libc++abi.dylib (400.17) <BA948A32-9024-3E55-98D4-18E31F6AED25> /usr/lib/libc++abi.dylib
       0x10178f000 -        0x1017e6ff7  libc++.1.dylib (400.9.4) <D4AB366F-48A9-3C7D-91BD-41198F69DD57> /usr/lib/libc++.1.dylib
       0x101847000 -        0x10184bff3  libcache.dylib (81) <FE21A7E9-DBEB-33AC-836B-785AD036ACF4> /usr/lib/system/libcache.dylib
       0x101851000 -        0x10185bff3  libcommonCrypto.dylib (60118.220.1) <1099E427-6E81-3059-87AF-6F5FD81CA998> /usr/lib/system/libcommonCrypto.dylib
       0x101869000 -        0x101870fff  libcompiler_rt.dylib (63.4) <A4D9CF37-D076-3CE9-95F1-DA89DA1601B6> /usr/lib/system/libcompiler_rt.dylib
       0x10187e000 -        0x101887ff3  libcopyfile.dylib (146.200.3) <4BCDADBF-79F5-3829-B47D-64DA0D44BCBF> /usr/lib/system/libcopyfile.dylib
       0x10188e000 -        0x101912fdf  libcorecrypto.dylib (602.220.6) <E1046E01-A2FD-35B4-B018-ACC372F3880E> /usr/lib/system/libcorecrypto.dylib
       0x10192f000 -        0x101969ff7  libdispatch.dylib (1008.220.2) <D8B56783-152A-34A8-94E9-8E6BAE049384> /usr/lib/system/libdispatch.dylib
       0x10199a000 -        0x1019c9fff  libdyld.dylib (635.2) <1B79A5CE-125F-301F-A441-C1869573AED0> /usr/lib/system/libdyld.dylib
       0x1019ec000 -        0x1019ecffb  libkeymgr.dylib (30) <A73AA788-C35C-3284-BFCA-95B1BBDF0CF3> /usr/lib/system/libkeymgr.dylib
       0x1019f1000 -        0x1019f1ff7  liblaunch.dylib (1336.220.5) <95EB6EAF-2DC5-344F-BADB-CA4E35E4E503> /usr/lib/system/liblaunch.dylib
       0x1019f8000 -        0x1019fdfff  libmacho.dylib (921) <ECC4E97C-575E-3A08-8191-BF02D7D4E637> /usr/lib/system/libmacho.dylib
       0x101a04000 -        0x101a06ffb  libquarantine.dylib (86.220.1) <6AE5AEEC-A9FD-3CF8-92DD-12B5AFBE12DE> /usr/lib/system/libquarantine.dylib
       0x101a0d000 -        0x101a0eff3  libremovefile.dylib (45.200.2) <D74A307B-3DC7-3992-B16C-DACB8207BE13> /usr/lib/system/libremovefile.dylib
       0x101a14000 -        0x101a2bff3  libsystem_asl.dylib (356.200.4) <EC9D8AD4-E5CB-3765-804A-9E1E9DC045D2> /usr/lib/system/libsystem_asl.dylib
       0x101a39000 -        0x101a39fff  libsystem_blocks.dylib (73) <26419398-C30C-30F1-B656-A92AFA9560F6> /usr/lib/system/libsystem_blocks.dylib
       0x101a3e000 -        0x101ac6fff  libsystem_c.dylib (1272.200.26) <3DEEE96E-6DF6-35AD-8654-D69AC26B907B> /usr/lib/system/libsystem_c.dylib
       0x101aef000 -        0x101af2ff7  libsystem_configuration.dylib (963.200.27) <02CC3996-B34E-333C-8806-AE2699D34424> /usr/lib/system/libsystem_configuration.dylib
       0x101af9000 -        0x101afcff7  libsystem_coreservices.dylib (66) <254B6849-2C8F-302C-8616-B8324A11AB30> /usr/lib/system/libsystem_coreservices.dylib
       0x101b02000 -        0x101b08ffb  libsystem_darwin.dylib (1272.200.26) <974E9EF7-DE72-34B7-B056-0A81C10DF8EB> /usr/lib/system/libsystem_darwin.dylib
       0x101b13000 -        0x101b19ff7  libsystem_dnssd.dylib (878.200.35) <FFC665AA-B257-35AD-BD8B-32FD42C2EEC1> /usr/lib/system/libsystem_dnssd.dylib
       0x101b1f000 -        0x101b6bff3  libsystem_info.dylib (517.200.9) <0707C387-D7DE-372E-8FF1-3DE5C91932D6> /usr/lib/system/libsystem_info.dylib
       0x101b82000 -        0x101bcdff7  libsystem_m.dylib (3158.200.7) <43D1796B-954F-37D6-B1AC-9D80DF0655A2> /usr/lib/system/libsystem_m.dylib
       0x101bdc000 -        0x101c00ff7  libsystem_malloc.dylib (166.220.1) <3B196122-4E0D-3E3F-AA3E-5115B976DE26> /usr/lib/system/libsystem_malloc.dylib
       0x101c0f000 -        0x101c1aff3  libsystem_networkextension.dylib (767.220.1) <C54EB8F6-F305-3452-8DB1-F7DA6859AF8C> /usr/lib/system/libsystem_networkextension.dylib
       0x101c27000 -        0x101c2efff  libsystem_notify.dylib (172.200.21) <BCCB222F-DC64-3954-A836-DCCE6659CA5A> /usr/lib/system/libsystem_notify.dylib
       0x101c35000 -        0x101c38ff7  libsystem_sandbox.dylib (851.220.9) <4D6433A8-C703-3ED9-82EB-B9E481A0FD2F> /usr/lib/system/libsystem_sandbox.dylib
       0x101c3f000 -        0x101c41ff3  libsystem_secinit.dylib (30.220.1) <6C681113-8C48-3256-BEF6-0C3723DEB926> /usr/lib/system/libsystem_secinit.dylib
       0x101c47000 -        0x101c6eff7  libsystem_kernel.dylib (4903.221.2) <0E882078-7330-3B49-AA5D-3CDB5645A4E5> /usr/lib/system/libsystem_kernel.dylib
       0x101c89000 -        0x101c92fef  libsystem_platform.dylib (177.200.16) <B75B04AD-69FE-3ADE-84D2-C17972FC8F49> /usr/lib/system/libsystem_platform.dylib
       0x101c9b000 -        0x101ca5fff  libsystem_pthread.dylib (330.220.2) <4958273C-4273-3501-8137-E44249E10D9C> /usr/lib/system/libsystem_pthread.dylib
       0x101cb0000 -        0x101cb7ff7  libsystem_symptoms.dylib (820.227.2) <3147D594-F41F-35FD-BF0B-6B8B66A407DE> /usr/lib/system/libsystem_symptoms.dylib
       0x101cbe000 -        0x101cd3ff7  libsystem_trace.dylib (906.220.1) <D5045DC5-A165-3238-A470-1796F12BF84F> /usr/lib/system/libsystem_trace.dylib
       0x101ce3000 -        0x101ce8ffb  libunwind.dylib (35.4) <41222EF6-2233-3CF4-947A-15D48CB8C030> /usr/lib/system/libunwind.dylib
       0x101cf0000 -        0x101d20fff  libxpc.dylib (1336.220.5) <B2137772-E202-3656-A089-F6DD517007D5> /usr/lib/system/libxpc.dylib
    0x7fff5f665000 -     0x7fff5f6e36a7  dyld (635.2) <1780094A-8FE2-3EAA-B4A3-C4CF14BC5196> /usr/lib/dyld

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 26541
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=25.4M resident=0K(0%) swapped_out_or_unallocated=25.4M(100%)
Writable regions: Total=25.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=25.5M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Kernel Alloc Once                    8K        2 
MALLOC                            9260K        8 
MALLOC guard page                   16K        5 
VM_ALLOCATE                          4K        2 
__DATA                            4316K       59 
__LINKEDIT                        4768K       46 
__TEXT                            20.7M       48 
__UNICODE                          564K        2 
__UNIXSTACK                       16.0M        2 
shared memory                        8K        3 
===========                     =======  ======= 
TOTAL                             55.2M      167 

Model: MacBookPro14,1, BootROM 184.0.0.0.0, 2 processors, Intel Core i5, 2.3 GHz, 16 GB, SMC 2.43f6
Graphics: Intel Iris Plus Graphics 640, Intel Iris Plus Graphics 640, Built-In
Memory Module: BANK 0/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
Memory Module: BANK 1/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x170), Broadcom BCM43xx 1.0 (7.77.61.1 AirPortDriverBrcmNIC-1305.2)
Bluetooth: Version 6.0.9f2, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.0 Bus
USB Device: USB 2.0 BILLBOARD
Thunderbolt Bus: MacBook Pro, Apple Inc., 39.2

----------
messages: 354686
nosy: Young Y
priority: normal
severity: normal
status: open
title: Segmentation fault: 11 Python3.6 on Macbook
versions: Python 3.6

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

From report at bugs.python.org  Tue Oct 15 03:34:20 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 15 Oct 2019 07:34:20 +0000
Subject: [New-bugs-announce] [issue38480] resource.setrlimit() should raise
 PermissionError
Message-ID: <1571124860.16.0.598909630124.issue38480@roundup.psfhosted.org>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

>>> import resource
    >>> high = 300 * 1024 * 1024
    >>> resource.setrlimit(resource.RLIMIT_MEMLOCK, (high, high))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: not allowed to raise maximum limit
    >>> 

Internally EPERM is translated into ValueError (should have been PermissionError). resource.prlimit(), on the other hand, is not affected (correctly raises PermissionError):

    >>> resource.prlimit(os.getpid(), resource.RLIMIT_MEMLOCK, (high, high))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    PermissionError: [Errno 1] Operation not permitted


It seems 'ValueError' was used in order to provide a more informative error message, but IMO it was a bad call.
Proposal is to change this in 3.9 only, and document it under whatsnew/porting.

----------
components: Library (Lib)
messages: 354701
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: resource.setrlimit() should raise PermissionError
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 15 03:36:40 2019
From: report at bugs.python.org (=?utf-8?b?5qWa6Im6?=)
Date: Tue, 15 Oct 2019 07:36:40 +0000
Subject: [New-bugs-announce] [issue38481] Class static property not static
Message-ID: <1571125000.71.0.339898408736.issue38481@roundup.psfhosted.org>


New submission from ?? <1090217062 at qq.com>:

code:
------------------------------------------------------------------
    class D:
        num = 0
        
        def __init__(self):
            self.num += 1
            print('D num', self.num)

    for i in range(5):
        D()
---------------------------------------------------------------
console print:
---------------------------------------------------------------
Connected to pydev debugger (build 183.5429.31)
D num 1
D num 1
D num 1
D num 1
D num 1

Process finished with exit code 0

----------
components: Windows
messages: 354702
nosy: chuyi, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Class static property not static
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct 15 04:21:30 2019
From: report at bugs.python.org (Jim Carroll)
Date: Tue, 15 Oct 2019 08:21:30 +0000
Subject: [New-bugs-announce] [issue38482] BUG in
 codecs.BufferedIncrementalDecoder
Message-ID: <1571127690.05.0.477916235895.issue38482@roundup.psfhosted.org>


New submission from Jim Carroll <jim at carroll.com>:

While working with codecs.iterdecode(), encountered "can't concat int to bytes". The source of the problem is BufferedIncrementalDecoder stores it's internal buffer as a bytes (ie: b""), but decode() can be passed either a byte string or in the case of iterdecode() an int.  The solution is to test for this in the decode and if passed an int to coerce to bytes (see attach patch)

Platform: Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32

Code to demonstrate the issue:

>>> import codecs
>>> source = ''.join([chr(x) for x in range(256)])
>>> enc = b''.join(codecs.iterencode(source, 'utf-8'))
>>> list(''.join(codecs.iterdecode(enc, 'utf-8')))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python37\lib\codecs.py", line 1048, in iterdecode
    output = decoder.decode(input)
  File "C:\Python37\lib\codecs.py", line 321, in decode
    data = self.buffer + input
TypeError: can't concat int to bytes

----------
components: Library (Lib)
files: codecs.patch
keywords: patch
messages: 354707
nosy: jamercee
priority: normal
severity: normal
status: open
title: BUG in codecs.BufferedIncrementalDecoder
versions: Python 3.7
Added file: https://bugs.python.org/file48661/codecs.patch

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

From report at bugs.python.org  Tue Oct 15 06:51:40 2019
From: report at bugs.python.org (Cooper Lees)
Date: Tue, 15 Oct 2019 10:51:40 +0000
Subject: [New-bugs-announce] [issue38483] [venv] Add ~/.venvrc to change
 module defaults
Message-ID: <1571136700.53.0.3102397559.issue38483@roundup.psfhosted.org>


New submission from Cooper Lees <me at cooperlees.com>:

I'd like to propose adding a run commands (.venvrc) file support to the venv library.

File Location: `~/.venvrc`

This file will support all current CLI arguments and override the defaults for each CLI if present in the file. I will also endeavour to add test for POSIX + Windows systems.

I propose using `configparser` and an `.ini` style config for the `.venvrc`.

My main use for this is to allow myself to default to always using `--upgrade-deps` when I create new venvs.

Thoughts? Concerns?

----------
components: Library (Lib)
messages: 354712
nosy: cooperlees
priority: normal
severity: normal
status: open
title: [venv] Add ~/.venvrc to change module defaults
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 15 08:37:14 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Tue, 15 Oct 2019 12:37:14 +0000
Subject: [New-bugs-announce] [issue38484] HTMLParser.handle_starttag should
 mention that value can be None
Message-ID: <1571143034.46.0.408177469405.issue38484@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

The documentation for HTMLParser.handle_starttag (https://docs.python.org/3/library/html.parser.html#html.parser.HTMLParser.handle_starttag) should mention that the value of an attribute can be `None` for argument-less attributes. I can submit a PR if wanted.

----------
assignee: docs at python
components: Documentation
messages: 354719
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: HTMLParser.handle_starttag should mention that value can be None
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 15 10:22:34 2019
From: report at bugs.python.org (Jim Carroll)
Date: Tue, 15 Oct 2019 14:22:34 +0000
Subject: [New-bugs-announce] [issue38485] BUG Modules/_io/texio.c
Message-ID: <1571149354.19.0.486917734419.issue38485@roundup.psfhosted.org>


New submission from Jim Carroll <jim at carroll.com>:

The io.TextIOWrapper class initializes a codec.IncrementalEncoder and uses it to encode str, but it never calls the encoder's encode('', final=True). According to the docs https://docs.python.org/3.5/library/codecs.html#codecs.IncrementalEncoder.encode:  

``If this is the last call to encode() final must be true (the default is false).``

Without a call to encode('', final=True), codecs cannot be created that use codecs.BufferedIncrementalEncoder which depend on being called with final=True to flush any internal buffers.

Platform: Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32

----------
messages: 354733
nosy: jamercee
priority: normal
severity: normal
status: open
title: BUG Modules/_io/texio.c
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct 15 12:02:16 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 15 Oct 2019 16:02:16 +0000
Subject: [New-bugs-announce] [issue38486] Dead links in mailbox doc
Message-ID: <1571155336.35.0.351516835001.issue38486@roundup.psfhosted.org>


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

Reported on mailing list: https://mail.python.org/archives/list/docs at python.org/thread/NIXFQMWFNSNO6RXPINY56CQQ5L7QIRUV/

qmail.org is dead.  The mailbox doc [1] contains two links to man pages in qmail.org.
Can we just remove them?

[1] https://docs.python.org/3/library/mailbox.html

----------
assignee: docs at python
components: Documentation
messages: 354738
nosy: docs at python, inada.naoki
priority: normal
severity: normal
status: open
title: Dead links in mailbox doc
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 15 13:12:40 2019
From: report at bugs.python.org (Marcos Dione)
Date: Tue, 15 Oct 2019 17:12:40 +0000
Subject: [New-bugs-announce] [issue38487] expat infinite loop
Message-ID: <1571159560.58.0.207422547054.issue38487@roundup.psfhosted.org>


New submission from Marcos Dione <mdione at grulic.org.ar>:

I'm trying to add external entities support to xmltodict[1]. For that I extended the handler to have a ExternalEntityRefHandler handler. After reading a couple of files, the script lock in a tight loop.

I ran the script with gdb (!!) and found that expat think that two of the parsers are parent of each other. I setup a breakpoint in XML_ExternalEntityParserCreate() (yes, this is expat, I know) right after the new parser uses the old parser as parent (xmlparse.c:1279 in my system).

Here are the backtraces and values I found:

--- >8 ---
landuse-lowzoom None styles-otm/landuse-lowzoom.xml None

#0  XML_ExternalEntityParserCreate (oldParser=0xadc4d0, context=context at entry=0x7ffff6c871e0 "landuse-lowzoom", encodingName=encodingName at entry=0x0) at ../../src/lib/xmlparse.c:1281
#1  0x000000000044ec90 in pyexpat_xmlparser_ExternalEntityParserCreate_impl (encoding=0x0, context=0x7ffff6c871e0 "landuse-lowzoom", self=0x7ffff6d556e0) at ../Modules/pyexpat.c:943
#2  pyexpat_xmlparser_ExternalEntityParserCreate (self=0x7ffff6d556e0, args=<optimized out>, nargs=<optimized out>) at ../Modules/clinic/pyexpat.c.h:137
[...]
#15 0x000000000044d80d in my_ExternalEntityRefHandler (parser=<optimized out>, context=0xae1d2c "landuse-lowzoom", base=<optimized out>, systemId=<optimized out>, publicId=<optimized out>)
    at ../Modules/pyexpat.c:659
#16 0x00007ffff7d990c8 in doContent (parser=parser at entry=0xadc4d0, startTagLevel=startTagLevel at entry=0, enc=<optimized out>,
    s=s at entry=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., nextPtr=nextPtr at entry=0xadc500, haveMore=1 '\001') at ../../src/lib/xmlparse.c:2685
#17 0x00007ffff7d9957c in contentProcessor (parser=parser at entry=0xadc4d0,
    start=start at entry=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., endPtr=endPtr at entry=0xadc500) at ../../src/lib/xmlparse.c:2444
#18 0x00007ffff7d96a73 in doProlog (parser=parser at entry=0xadc4d0, enc=0x7ffff7db89e0 <utf8_encoding>,
    s=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "...,
    s at entry=0xae04e4 "text-water-lowzoom SYSTEM \"styles-otm/text-water-lowzoom.xml\">\n\t<!ENTITY text-glacier-lowzoom SYSTEM \"styles-otm/text-glacier-lowzoom.xml\">\n\t<!ENTITY text-natural-poly SYSTEM \"styles-otm/text-natural-"..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., tok=29, next=<optimized out>, nextPtr=0xadc500, haveMore=1 '\001', allowClosingDoctype=1 '\001') at ../../src/lib/xmlparse.c:4371
#19 0x00007ffff7d97f3a in prologProcessor (parser=0xadc4d0,
    s=0xae04e4 "text-water-lowzoom SYSTEM \"styles-otm/text-water-lowzoom.xml\">\n\t<!ENTITY text-glacier-lowzoom SYSTEM \"styles-otm/text-glacier-lowzoom.xml\">\n\t<!ENTITY text-natural-poly SYSTEM \"styles-otm/text-natural-"..., end=0xae0ce6 '\001' <repeats 200 times>..., nextPtr=0xadc500) at ../../src/lib/xmlparse.c:4094
#20 0x00007ffff7d9bb1c in XML_ParseBuffer (isFinal=0, len=<optimized out>, parser=0xadc4d0) at ../../src/lib/xmlparse.c:1893
#21 XML_ParseBuffer (parser=0xadc4d0, len=len at entry=2048, isFinal=isFinal at entry=0) at ../../src/lib/xmlparse.c:1863
#22 0x000000000060886d in pyexpat_xmlparser_ParseFile (self=0x7ffff6d556e0, file=<optimized out>) at ../Modules/pyexpat.c:841

(gdb) print oldParser
$33 = (XML_Parser) 0xadc4d0
(gdb) print parser
$32 = (XML_Parser) 0xadecb0

7ffff6d556e0, 7ffff6d55750
<_io.BufferedReader name='styles-otm/landuse-lowzoom.xml'>
<_io.BufferedReader name='styles-otm/landuse-lowzoom.xml'>
landuse None styles-otm/landuse.xml None

#0  XML_ExternalEntityParserCreate (oldParser=0xadecb0, context=context at entry=0x7ffff6c88660 "landuse", encodingName=encodingName at entry=0x0) at ../../src/lib/xmlparse.c:1281
#1  0x000000000044ec90 in pyexpat_xmlparser_ExternalEntityParserCreate_impl (encoding=0x0, context=0x7ffff6c88660 "landuse", self=0x7ffff6d55750) at ../Modules/pyexpat.c:943
#2  pyexpat_xmlparser_ExternalEntityParserCreate (self=0x7ffff6d55750, args=<optimized out>, nargs=<optimized out>) at ../Modules/clinic/pyexpat.c.h:137
[...]
#15 0x000000000044d80d in my_ExternalEntityRefHandler (parser=<optimized out>, context=0xae1d2c "landuse", base=<optimized out>, systemId=<optimized out>, publicId=<optimized out>) at ../Modules/pyexpat.c:659
#16 0x00007ffff7d990c8 in doContent (parser=parser at entry=0xadc4d0, startTagLevel=startTagLevel at entry=0, enc=<optimized out>,
    s=s at entry=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., nextPtr=nextPtr at entry=0xadc500, haveMore=1 '\001') at ../../src/lib/xmlparse.c:2685
#17 0x00007ffff7d9957c in contentProcessor (parser=parser at entry=0xadc4d0,
    start=start at entry=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., endPtr=endPtr at entry=0xadc500) at ../../src/lib/xmlparse.c:2444
#18 0x00007ffff7d96a73 in doProlog (parser=parser at entry=0xadc4d0, enc=0x7ffff7db89e0 <utf8_encoding>,
    s=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "...,
    s at entry=0xae04e4 "text-water-lowzoom SYSTEM \"styles-otm/text-water-lowzoom.xml\">\n\t<!ENTITY text-glacier-lowzoom SYSTEM \"styles-otm/text-glacier-lowzoom.xml\">\n\t<!ENTITY text-natural-poly SYSTEM \"styles-otm/text-natural-"..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., tok=29, next=<optimized out>, nextPtr=0xadc500, haveMore=1 '\001', allowClosingDoctype=1 '\001') at ../../src/lib/xmlparse.c:4371
#19 0x00007ffff7d97f3a in prologProcessor (parser=0xadc4d0,
    s=0xae04e4 "text-water-lowzoom SYSTEM \"styles-otm/text-water-lowzoom.xml\">\n\t<!ENTITY text-glacier-lowzoom SYSTEM \"styles-otm/text-glacier-lowzoom.xml\">\n\t<!ENTITY text-natural-poly SYSTEM \"styles-otm/text-natural-"..., end=0xae0ce6 '\001' <repeats 200 times>..., nextPtr=0xadc500) at ../../src/lib/xmlparse.c:4094
#20 0x00007ffff7d9bb1c in XML_ParseBuffer (isFinal=0, len=<optimized out>, parser=0xadc4d0) at ../../src/lib/xmlparse.c:1893
#21 XML_ParseBuffer (parser=0xadc4d0, len=len at entry=2048, isFinal=isFinal at entry=0) at ../../src/lib/xmlparse.c:1863
#22 0x000000000060886d in pyexpat_xmlparser_ParseFile (self=0x7ffff6d556e0, file=<optimized out>) at ../Modules/pyexpat.c:841

(gdb) print oldParser
$35 = (XML_Parser) 0xadecb0
(gdb) print parser
$34 = (XML_Parser) 0xae5e00

7ffff6d55750, 7ffff6d557c0
<_io.BufferedReader name='styles-otm/landuse.xml'>
<_io.BufferedReader name='styles-otm/landuse.xml'>
landuse-over-hillshade None styles-otm/landuse-over-hillshade.xml None

#0  XML_ExternalEntityParserCreate (oldParser=0xae5e00, context=context at entry=0x7ffff6c81a60 "landuse-over-hillshade", encodingName=encodingName at entry=0x0) at ../../src/lib/xmlparse.c:1281
#1  0x000000000044ec90 in pyexpat_xmlparser_ExternalEntityParserCreate_impl (encoding=0x0, context=0x7ffff6c81a60 "landuse-over-hillshade", self=0x7ffff6d557c0) at ../Modules/pyexpat.c:943
#2  pyexpat_xmlparser_ExternalEntityParserCreate (self=0x7ffff6d557c0, args=<optimized out>, nargs=<optimized out>) at ../Modules/clinic/pyexpat.c.h:137
[...]
#15 0x000000000044d80d in my_ExternalEntityRefHandler (parser=<optimized out>, context=0xae1d2c "landuse-over-hillshade", base=<optimized out>, systemId=<optimized out>, publicId=<optimized out>)
    at ../Modules/pyexpat.c:659
#16 0x00007ffff7d990c8 in doContent (parser=parser at entry=0xadc4d0, startTagLevel=startTagLevel at entry=0, enc=<optimized out>,
    s=s at entry=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., nextPtr=nextPtr at entry=0xadc500, haveMore=1 '\001') at ../../src/lib/xmlparse.c:2685
#17 0x00007ffff7d9957c in contentProcessor (parser=parser at entry=0xadc4d0,
    start=start at entry=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., endPtr=endPtr at entry=0xadc500) at ../../src/lib/xmlparse.c:2444
#18 0x00007ffff7d96a73 in doProlog (parser=parser at entry=0xadc4d0, enc=0x7ffff7db89e0 <utf8_encoding>,
    s=0xae08dd "<Map background-color=\"#e0e0e0\" srs=\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +over\" buffer-size=\"256\">\n\t<!-- style definitions "...,
    s at entry=0xae04e4 "text-water-lowzoom SYSTEM \"styles-otm/text-water-lowzoom.xml\">\n\t<!ENTITY text-glacier-lowzoom SYSTEM \"styles-otm/text-glacier-lowzoom.xml\">\n\t<!ENTITY text-natural-poly SYSTEM \"styles-otm/text-natural-"..., end=end at entry=0xae0ce6 '\001' <repeats 200 times>..., tok=29, next=<optimized out>, nextPtr=0xadc500, haveMore=1 '\001', allowClosingDoctype=1 '\001') at ../../src/lib/xmlparse.c:4371
#19 0x00007ffff7d97f3a in prologProcessor (parser=0xadc4d0,
    s=0xae04e4 "text-water-lowzoom SYSTEM \"styles-otm/text-water-lowzoom.xml\">\n\t<!ENTITY text-glacier-lowzoom SYSTEM \"styles-otm/text-glacier-lowzoom.xml\">\n\t<!ENTITY text-natural-poly SYSTEM \"styles-otm/text-natural-"..., end=0xae0ce6 '\001' <repeats 200 times>..., nextPtr=0xadc500) at ../../src/lib/xmlparse.c:4094
#20 0x00007ffff7d9bb1c in XML_ParseBuffer (isFinal=0, len=<optimized out>, parser=0xadc4d0) at ../../src/lib/xmlparse.c:1893
#21 XML_ParseBuffer (parser=0xadc4d0, len=len at entry=2048, isFinal=isFinal at entry=0) at ../../src/lib/xmlparse.c:1863
#22 0x000000000060886d in pyexpat_xmlparser_ParseFile (self=0x7ffff6d556e0, file=<optimized out>) at ../Modules/pyexpat.c:841

(gdb) print oldParser
$36 = (XML_Parser) 0xae5e00
(gdb) print parser
$37 = (XML_Parser) 0xadecb0
--- 8< ---

As I hope you can see, the last two values (parent 0xae5e00, new 0xadecb0) are the exact opposite of the previous one (parent 0xadecb0, new 0xae5e00). Later, when get_hash_secret_salt() is called, it enters in a infinite loop climbing up the parent ladder.

Now, this looks like an expat issue ands not pyexpat, but given that pyexpat provides its own allocator, and that the parser addresses are returned by that, I will start opening this issue here. If it can be proven that it's an expat issue, I'll take it to their issue tracker.

-----
[1] https://github.com/martinblech/xmltodict/issues/226

----------
components: XML
files: expat.tar.gz
messages: 354747
nosy: StyXman
priority: normal
severity: normal
status: open
title: expat infinite loop
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48663/expat.tar.gz

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

From report at bugs.python.org  Tue Oct 15 17:19:42 2019
From: report at bugs.python.org (Xavier Fernandez)
Date: Tue, 15 Oct 2019 21:19:42 +0000
Subject: [New-bugs-announce] [issue38488] Update bundled pip to 19.3
Message-ID: <1571174382.81.0.982982924079.issue38488@roundup.psfhosted.org>


Change by Xavier Fernandez <xav.fernandez at gmail.com>:


----------
components: Library (Lib)
nosy: Xavier Fernandez
priority: normal
pull_requests: 16363
severity: normal
status: open
title: Update bundled pip to 19.3
type: enhancement

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

From report at bugs.python.org  Tue Oct 15 17:28:44 2019
From: report at bugs.python.org (Daniel Schlomer)
Date: Tue, 15 Oct 2019 21:28:44 +0000
Subject: [New-bugs-announce] [issue38489] Python 3.7 documentation is
 unavailable for download
Message-ID: <1571174924.15.0.531140690105.issue38489@roundup.psfhosted.org>


New submission from Daniel Schlomer <djschlomer at gmail.com>:

All the download links at https://docs.python.org/3.7/download.html return a 404 error.

----------
messages: 354751
nosy: schlomer
priority: normal
severity: normal
status: open
title: Python 3.7 documentation is unavailable for download
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct 15 17:40:09 2019
From: report at bugs.python.org (=?utf-8?q?Tymek_Wo=C5=82od=C5=BAko?=)
Date: Tue, 15 Oct 2019 21:40:09 +0000
Subject: [New-bugs-announce] [issue38490] statistics: add covariance and
 Pearson's correlation
Message-ID: <1571175609.51.0.475949905245.issue38490@roundup.psfhosted.org>


New submission from Tymek Wo?od?ko <twolodzko at gmail.com>:

Covariance and Pearson's correlation are one of the most basic bivariate statistics.

https://en.wikipedia.org/wiki/Covariance
https://en.wikipedia.org/wiki/Pearson_correlation_coefficient

----------
messages: 354754
nosy: Tymek Wo?od?ko
priority: normal
severity: normal
status: open
title: statistics: add covariance and Pearson's correlation
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 15 19:30:24 2019
From: report at bugs.python.org (devlocalca)
Date: Tue, 15 Oct 2019 23:30:24 +0000
Subject: [New-bugs-announce] [issue38491] Can not build Python 3.8.0 on
 Linux - missing dependencies
Message-ID: <1571182224.79.0.802019819326.issue38491@roundup.psfhosted.org>


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

I can not build the 3.8.0 source code on Linux due to missing dependencies that I cannot find.

More information here:

https://www.reddit.com/r/Python/comments/digewe/python_38_not_possible_to_install_on_linux_why/

Can someone please show me how to build/install Python 3.8.0 on Linux from source, as Python 3.8.0 is not available to install from any RHEL 8 / CentOS 8 repo.

Email:  devlocalca at gmail.com

----------
components: Build
messages: 354757
nosy: devlocalca
priority: normal
severity: normal
status: open
title: Can not build Python 3.8.0 on Linux - missing dependencies
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 15 22:03:12 2019
From: report at bugs.python.org (evaldas)
Date: Wed, 16 Oct 2019 02:03:12 +0000
Subject: [New-bugs-announce] [issue38492] Microsoft Store app IDLE (Python
 3.8) has dependency on msvcp140.dll
Message-ID: <1571191392.22.0.935623826778.issue38492@roundup.psfhosted.org>


New submission from evaldas <evaldaz at gmail.com>:

OS: x64 Windows 10 Professional 1903 fresh installation (with latest updates)

Python 3.8 app (final version 3.8.0, not RC) installation from Microsoft Store adds two shortcuts to the Start menu:
- Python 3.8
- IDLE (Python 3.8)

Clicking the "Python 3.8" (python3.8.exe) starts Python interpreter - all fine and good.

Clicking the "IDLE (Python 3.8)" (idle3.8.exe) displays only the error message "MSVCP140.DLL was not found" (I do not remember exact sentence, because eventually I manually installed Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019).

----------
assignee: terry.reedy
components: IDLE, Windows
messages: 354765
nosy: evaldas, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Microsoft Store app IDLE (Python 3.8) has dependency on msvcp140.dll
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 16 00:36:12 2019
From: report at bugs.python.org (clintolsen)
Date: Wed, 16 Oct 2019 04:36:12 +0000
Subject: [New-bugs-announce] [issue38493] os.CLD_KILLED should be implemented
Message-ID: <1571200572.77.0.0960305175101.issue38493@roundup.psfhosted.org>


New submission from clintolsen <clint.olsen at gmail.com>:

I was running some experiments with os.waitid() and noticed that os.CLD_KILLED is not listed in the documentation.

However, if a process is killed by the system this (missing) value is returned from this function. It seems like possible constant values should be covered or at least documented as such? How should we code around unsupported constant values?

----------
messages: 354769
nosy: clintolsen
priority: normal
severity: normal
status: open
title: os.CLD_KILLED should be implemented
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Wed Oct 16 02:22:50 2019
From: report at bugs.python.org (valkheim)
Date: Wed, 16 Oct 2019 06:22:50 +0000
Subject: [New-bugs-announce] [issue38494] Add assert_not_called_with
Message-ID: <1571206970.26.0.707248566898.issue38494@roundup.psfhosted.org>


New submission from valkheim <valkheim at protonmail.com>:

This would be nice to integrate an assert_not_called_with feature.

I had to implement it to test a publish/subscribe patterns where multiple subscibers got called but not with the same arguments.

Here is my implementation:

```
def assert_not_called_with(self, *args, **kwargs):
    """assert that the mock was never called with the specified arguments.
    """
    try:
        self.assert_called_with(*args, **kwargs)
    except AssertionError:
        return
    raise AssertionError(
        "Expected %s to not have been called."
        % self._format_mock_call_signature(args, kwargs)
    )
```

An alternative would had been to iterate the call_args_list but it wouldn't result in a clean one-line assert

coming from: https://github.com/testing-cabal/mock/issues/473

----------
messages: 354770
nosy: valkheim
priority: normal
severity: normal
status: open
title: Add assert_not_called_with
type: enhancement

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

From report at bugs.python.org  Wed Oct 16 03:36:41 2019
From: report at bugs.python.org (Alex Mashianov)
Date: Wed, 16 Oct 2019 07:36:41 +0000
Subject: [New-bugs-announce] [issue38495] print built-in function docs bug
Message-ID: <1571211401.15.0.283514863374.issue38495@roundup.psfhosted.org>


New submission from Alex Mashianov <mashianov at gmail.com>:

Python docs says print() function default sep='': http://joxi.ru/EA44JnfonNwLAb.png

While in reality sep=' ':
http://joxi.ru/n2YXyRsbw6oYm6.png

Probably it's a bug with space not being escaped in html to prevent trimming.

----------
assignee: docs at python
components: Documentation
messages: 354778
nosy: Alex Mashianov, docs at python
priority: normal
severity: normal
status: open
title: print built-in function docs bug
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/issue38495>
_______________________________________

From report at bugs.python.org  Wed Oct 16 04:00:10 2019
From: report at bugs.python.org (Mikko Rantalainen)
Date: Wed, 16 Oct 2019 08:00:10 +0000
Subject: [New-bugs-announce] [issue38496] Python3 allows mixture of tabs and
 spaces for indentation
Message-ID: <1571212810.12.0.63942359908.issue38496@roundup.psfhosted.org>


New submission from Mikko Rantalainen <mikko.rantalainen at peda.net>:

Contrary to PEP-8 (https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces) claiming "Python 3 disallows mixing the use of tabs and spaces for indentation", in reality Python 3 allows mixing tabs and spaces without warnings or errors. For example (with all spaces replaced with middle dot and all spaces replaced with a short arrow):

#!/usr/bin/python3
for?i?in?range(2):
??for?j?in?range(3):
???for?k?in?range(4):
?????print(i,j,k,sep=",")

Either the PEP-8 should be fixed or the parser/compiler should be fixed. 

The current behavior seems a bit unstable because the exact order of spaces and tabs causes "TabError: inconsistent use of tabs and spaces in indentation" to appear more or less random.

I'd prefer python3 to require that *all whitespace* at the start of the all the lines is tabs for the whole file or spaces for the whole file. And first indented line sets the preference for the whole file.

(Personally I'd prefer tabs contrary to PEP-8 language but this bug is not about the preference. This is PEP-8 claiming things that are not true.)

$ python3 --version
Python 3.5.2

----------
components: Interpreter Core
messages: 354779
nosy: Mikko Rantalainen
priority: normal
severity: normal
status: open
title: Python3 allows mixture of tabs and spaces for indentation
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 16 04:13:45 2019
From: report at bugs.python.org (=?utf-8?b?SWxhw68=?=)
Date: Wed, 16 Oct 2019 08:13:45 +0000
Subject: [New-bugs-announce] [issue38497] Wrong argument name in
 documentation for pipes.Template.open
Message-ID: <1571213625.11.0.339305647326.issue38497@roundup.psfhosted.org>


New submission from Ila? <ilaideutel at gmail.com>:

Documentation for the pipes module indicates that the second argument of open()
is "mode", but it is actually "rw".

Python 3.7.4 (default, Oct  4 2019, 06:57:26)
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pipes import Template; Template().open('/tmp/f', mode='r')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: open() got an unexpected keyword argument 'mode'

Python 2.7.16 (default, Mar 11 2019, 18:59:25)
[GCC 8.2.1 20181127] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pipes import Template; Template().open('/tmp/f', mode='r')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: open() got an unexpected keyword argument 'mode'

https://docs.python.org/3/library/pipes.html#pipes.Template.open

----------
assignee: docs at python
components: Documentation
messages: 354781
nosy: docs at python, ilai
priority: normal
severity: normal
status: open
title: Wrong argument name in documentation for pipes.Template.open
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/issue38497>
_______________________________________

From report at bugs.python.org  Wed Oct 16 04:39:12 2019
From: report at bugs.python.org (Weiliang Li)
Date: Wed, 16 Oct 2019 08:39:12 +0000
Subject: [New-bugs-announce] [issue38498] The expression '' in '' == '' is
 evaluated as True
Message-ID: <1571215152.37.0.955381336834.issue38498@roundup.psfhosted.org>


Change by Weiliang Li <to.be.impressive at gmail.com>:


----------
nosy: kigawas
priority: normal
severity: normal
status: open
title: The expression '' in '' == '' is evaluated as True
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Oct 16 09:55:57 2019
From: report at bugs.python.org (Alori)
Date: Wed, 16 Oct 2019 13:55:57 +0000
Subject: [New-bugs-announce] [issue38499] Add rmtree() to pathlib.Path
Message-ID: <1571234157.02.0.903860423187.issue38499@roundup.psfhosted.org>


New submission from Alori <valorien at gmail.com>:

pathlib.Path supports deletion of both files (Path.unlink()) and directories (Path.rmdir()).

Unfortunately, Path.rmdir() does not allow deletion of non-empty directories which means users must use shutil.rmtree() when deleting such paths.

Since pathlib.Path already supports file and (empty) directory deletion, adding Path.rmtree(missing_ok=False) would support both the utility and the completeness of pathlib.

----------
components: Library (Lib)
messages: 354799
nosy: valorien
priority: normal
severity: normal
status: open
title: Add rmtree() to pathlib.Path
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 16 12:17:06 2019
From: report at bugs.python.org (Fabio Zadrozny)
Date: Wed, 16 Oct 2019 16:17:06 +0000
Subject: [New-bugs-announce] [issue38500] Provide a way to get/set
 PyInterpreterState.frame_eval without needing to access interpreter
 internals
Message-ID: <1571242626.68.0.14615334114.issue38500@roundup.psfhosted.org>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

In CPython 3.7 it was possible to do:

#include "pystate.h"
...
PyThreadState *ts = PyThreadState_Get();
PyInterpreterState *interp = ts->interp;
interp->eval_frame = my_frame_eval_func;

This is no longer possible because in 3.8 the PyInterpreterState is opaque, so, Py_BUILD_CORE_MODULE needs to be defined defined and "internal/pycore_pystate.h" must be included to set PyInterpreterState.eval_frame.

This works but isn't ideal -- maybe there could be a function to set PyInterpreterState.eval_frame?

----------
components: Interpreter Core
messages: 354803
nosy: fabioz, vstinner
priority: normal
severity: normal
status: open
title: Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 16 14:31:14 2019
From: report at bugs.python.org (Eric Larson)
Date: Wed, 16 Oct 2019 18:31:14 +0000
Subject: [New-bugs-announce] [issue38501] multiprocessing.Pool hangs atexit
 (and garbage collection sometimes)
Message-ID: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>


New submission from Eric Larson <larson.eric.d at gmail.com>:

The following code hangs on Python 3.8.0.rc0 on Ubuntu 19.10 when exiting the interpreter:


from multiprocessing import Pool

class A(object):
    def __init__(self):
        self.pool = Pool(processes=2)

solver = A()


When you eventually do ctrl-C, the traceback is:


^CProcess ForkPoolWorker-2:
Error in atexit._run_exitfuncs:
Process ForkPoolWorker-1:
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/util.py", line 277, in _run_finalizers
    finalizer()
  File "/usr/lib/python3.8/multiprocessing/util.py", line 201, in __call__
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 689, in _terminate_pool
    cls._help_stuff_finish(inqueue, task_handler, len(pool))
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 674, in _help_stuff_finish
    inqueue._rlock.acquire()
KeyboardInterrupt
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
  File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/usr/lib/python3.8/multiprocessing/queues.py", line 355, in get
    with self._rlock:
  File "/usr/lib/python3.8/multiprocessing/synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
KeyboardInterrupt
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
  File "/usr/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/usr/lib/python3.8/multiprocessing/queues.py", line 356, in get
    res = self._reader.recv_bytes()
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 216, in recv_bytes
    buf = self._recv_bytes(maxlength)
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 414, in _recv_bytes
    buf = self._recv(4)
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 379, in _recv
    chunk = read(handle, remaining)
KeyboardInterrupt


A similar problem seems to occur when garbage collecting when it's part of a class, and that class has not yet called `self.pool.terminate()` and `self.pool.close()`. Hopefully fixing the `atexit` behavior will similarly fix the `gc.collect()` behavior.

Cross-ref is in SciPy, https://github.com/scipy/scipy/issues/10927. It appears to also cause hangs on Travis 3.8-dev builds: https://travis-ci.org/scipy/scipy/jobs/598786785

----------
components: Library (Lib)
messages: 354813
nosy: Eric Larson
priority: normal
severity: normal
status: open
title: multiprocessing.Pool hangs atexit (and garbage collection sometimes)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 16 18:46:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Oct 2019 22:46:46 +0000
Subject: [New-bugs-announce] [issue38502] regrtest: use process groups
Message-ID: <1571266006.89.0.625453271604.issue38502@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Problem.

When regrtest is interrupted by CTRL+c and regrtest multiprocessing code (-jN command line option) is used, regrtest randomly fails to stop come TestWorkerProcess threads.

The problem is that only the direct child process is kill by SIGKILL. If the test spawns a grandchild process, this one will not be killed.

Moreover, the grandchild process inherits the child process stdout and stderr. But regrtest mltiprocessing uses pipes for the child process stdout and stderr.

At the end, Popen.communicate() hangs randomly in the main regrtest process (in a TestWorkerProcess thread) until the child process *and* the grandchild process completes. Except that the main regrtest does not directly kill the grandchild process.

=> see bpo-38207


Solution.

I propose to:

(1) use Popen() with start_new_session=True: a worker process calls setsid() to create a new process group.
(2) Don't kill worker processes, but kill the process groups of worker processes.

Attached PR implements this solution.

----------
components: Tests
messages: 354818
nosy: vstinner
priority: normal
severity: normal
status: open
title: regrtest: use process groups
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 17 04:22:02 2019
From: report at bugs.python.org (wang xuancong)
Date: Thu, 17 Oct 2019 08:22:02 +0000
Subject: [New-bugs-announce] [issue38503] bug: string search can find \n,
 but can NEVER find \r
Message-ID: <1571300522.6.0.320185035424.issue38503@roundup.psfhosted.org>


New submission from wang xuancong <xuancong84 at gmail.com>:

If I load a file which contains "\r" and "\n", I can find "\n", but not "\r". This behaviour is inconsistent in Python 3, but consistent in Python 2.

>>> open('./3cjkxdnw/accessibilityLog/1570181896323.csv', 'rb').read().count(b'\r')
88
>>> open('./3cjkxdnw/accessibilityLog/1570181896323.csv').read().count('\r')
0
>>> type(open('./3cjkxdnw/accessibilityLog/1570181896323.csv').read())
<class 'str'>
>>> type('\r')
<class 'str'>

Thanks!

----------
messages: 354834
nosy: xuancong84
priority: normal
severity: normal
status: open
title: bug: string search can find \n, but can NEVER find \r
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 17 05:34:18 2019
From: report at bugs.python.org (=?utf-8?b?5YiY5a625Lic?=)
Date: Thu, 17 Oct 2019 09:34:18 +0000
Subject: [New-bugs-announce] [issue38504] Reduce the size of deb package
Message-ID: <1571304858.59.0.51110588392.issue38504@roundup.psfhosted.org>


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

I am not very good at python, but now I have a need, which is how to compile the source code into a deb package, so that the deb is minimal. The obtained deb package only need to meet the function of installing modules through pip and no extra features are needed.

----------
messages: 354837
nosy: ???
priority: normal
severity: normal
status: open
title: Reduce the size of deb package
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct 17 08:23:54 2019
From: report at bugs.python.org (Caris Moses)
Date: Thu, 17 Oct 2019 12:23:54 +0000
Subject: [New-bugs-announce] [issue38505] Mock.call_args and
 Mock.call_args_list
Message-ID: <1571315034.98.0.296986686038.issue38505@roundup.psfhosted.org>


New submission from Caris Moses <caris.moses at gmail.com>:

When I use some_mock.attach_mock(...) and make calls, the resulting some_mock.call_args is None while the some_mock.mock_calls list is not empty.

The code below shows this in Python 3.7.5:

from unittest import TestCase
from unittest.mock import patch, Mock

def foo(value):
    return value

class MyObjectTest(TestCase):

    @patch(f'{__name__}.foo')
    def test_do_something(self, mock_foo):
        manager = Mock()
        manager.attach_mock(mock_foo, 'foo_func')
        foo(3)
        print(manager.mock_calls)
        print(manager.call_args)
        print(manager.call_args_list)

if __name__ == "__main__":
    unittest.main()

The print statements return:
[call.foo_func(3)]
None
[]

While the code below (without attach_mock) works fine:

from unittest import TestCase
from unittest.mock import patch, Mock

def foo(value):
    return value

class MyObjectTest(TestCase):

    @patch(f'{__name__}.foo')
    def test_do_something(self, mock_foo):
        foo(3)
        print(mock_foo.mock_calls)
        print(mock_foo.call_args)
        print(mock_foo.call_args_list)

if __name__ == "__main__":
    unittest.main()

Print statements correctly return:
[call(3)]
call(3)
[call(3)]

I also tested in Python 3.8.0 and got the same result.

----------
messages: 354841
nosy: Caris Moses
priority: normal
severity: normal
status: open
title: Mock.call_args and Mock.call_args_list

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

From report at bugs.python.org  Thu Oct 17 10:31:04 2019
From: report at bugs.python.org (ynyyn)
Date: Thu, 17 Oct 2019 14:31:04 +0000
Subject: [New-bugs-announce] [issue38506] Launcher for Windows (py.exe) may
 rank Python 3.xx (in the future) after 3.x
Message-ID: <1571322664.68.0.257867788049.issue38506@roundup.psfhosted.org>


New submission from ynyyn <ynyyn at vip.qq.com>:

I, for interest, read some of source code of Python launcher, and found it used string comparison function (`wcscmp()`, in function `compare_pythons()`) to sort Python version in descending order.

It works well currently. But if Python 3.10 or Python 3.xx comes up in the future, Python 3.xx will be ranked after 3.x.

I modified the Registry and made a fake version Python 3.10, to check the launcher's behaviour.

```
PS > py -0p
Installed Pythons found by C:\Windows\py.exe Launcher for Windows
 -3.8-64        D:\Program Files\Python38\python.exe *
 -3.7-64        D:\Program Files\Python37\python.exe
 -3.7-32        D:\Program Files (x86)\Python37-32\python.exe
 -3.6-32        C:\Program Files (x86)\Python36-32\python.exe
 -3.10-64       D:\Program Files\Python37\python.exe
 -2.7-64        C:\python27-x64\python.exe
```

The result turned out that Python 3.10 was really ranked after 3.x.

And it seems that Python 3.xx should be a valid (or supported) version according to the comment from function `validate_version()`.


```
static BOOL
validate_version(wchar_t * p)
{
    /*
    Version information should start with the major version,
    Optionally followed by a period and a minor version,
    Optionally followed by a minus and one of 32 or 64.
    Valid examples:
      ...
      2.7-32
      The intent is to add to the valid patterns:
      3.10
      3-32
      ...
    */

I am not sure whether this is a potential defect that had been confirmed before... But I do not see some relevant comments in the source code.

----------
components: Windows
messages: 354843
nosy: paul.moore, steve.dower, tim.golden, ynyyn, zach.ware
priority: normal
severity: normal
status: open
title: Launcher for Windows (py.exe) may rank Python 3.xx (in the future) after 3.x
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct 17 10:45:11 2019
From: report at bugs.python.org (JUN-WEI SONG)
Date: Thu, 17 Oct 2019 14:45:11 +0000
Subject: [New-bugs-announce] [issue38507] Improve the documentation of the
 nested list initialization
Message-ID: <1571323511.47.0.548747991495.issue38507@roundup.psfhosted.org>


New submission from JUN-WEI SONG <sungboss2004 at gmail.com>:

When I used the nested list, I need to initialize the nested list, so I used this expression:

>>> nested_list = [[]] * 5

see also: https://stackoverflow.com/questions/12791501/python-initializing-a-list-of-lists

So I later learned that such an expression would make the list inside the list have the same reference, which would cause the problem that you modified one element would lead to all elements changed in the nested list.

For example:

>>> nested_list[0].append(1)
>>> nested_list
[[1], [1], [1], [1], [1]]

Therefore, maybe we could tell users how to initialize the list on the documentation like below:

If you need to initialize the nested list, you could follow the below example, also, be aware of the expression like ``[[]] * 5``, this will cause the five lists in the nested list to have the same reference.

   >>> nested_list = [[] for _ in range(5)]

----------
assignee: docs at python
components: Documentation
messages: 354844
nosy: docs at python, krnick
priority: normal
severity: normal
status: open
title: Improve the documentation of the nested list initialization
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 17 10:53:28 2019
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 17 Oct 2019 14:53:28 +0000
Subject: [New-bugs-announce] [issue38508] Tracing events anomaly when
 creating a multi-line list
Message-ID: <1571324008.26.0.275213051562.issue38508@roundup.psfhosted.org>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

When creating a multi-line list it seems that there's an additional line event that goes back to the start of the list.

i.e.: considering the code as:

[
1,
2
]

when stepping through the list, a debugger would get a line event at the `1` then at `2` and then at `['.

I'm attaching a sample code which prints the traced lines, where it's possible to see that there's a line event that goes backward to the list creation there (note that on Python 3.7 there's no line event for the list creation).

----------
components: Interpreter Core
files: snippet33.py
messages: 354845
nosy: fabioz
priority: normal
severity: normal
status: open
title: Tracing events anomaly when creating a multi-line list
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48665/snippet33.py

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

From report at bugs.python.org  Thu Oct 17 12:38:32 2019
From: report at bugs.python.org (Aniruddha Bhattacharjee)
Date: Thu, 17 Oct 2019 16:38:32 +0000
Subject: [New-bugs-announce] [issue38509] Insufficient description of
 relative imports in docs.python.org
Message-ID: <1571330312.31.0.925076175941.issue38509@roundup.psfhosted.org>


New submission from Aniruddha Bhattacharjee <aniruddha97bhatt at gmail.com>:

In the section "relative imports" of the documentation for "import system", the use of relative imports is explained with the use of an example, however if you try the exact same thing it gives an error. This is nicely explained in https://stackoverflow.com/questions/14132789/relative-imports-for-the-billionth-time and https://www.python.org/dev/peps/pep-0395/. This has also been added as an open issue in the documentation . Is this still under consideration, then I would be happy to update the docs. Thanks

----------
assignee: docs at python
components: Documentation
messages: 354851
nosy: Aniruddha Bhattacharjee, docs at python
priority: normal
severity: normal
status: open
title: Insufficient description of relative imports in docs.python.org
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Oct 17 16:55:39 2019
From: report at bugs.python.org (Chiu Speq)
Date: Thu, 17 Oct 2019 20:55:39 +0000
Subject: [New-bugs-announce] [issue38510] build python with --enable-shared
 with static linked python against libpython*.a
Message-ID: <1571345739.37.0.277931445502.issue38510@roundup.psfhosted.org>


New submission from Chiu Speq <speq.chiu at gmail.com>:

Build python with --enable-shared will create python binary linked against the shared library. You have LD_LIBRARY_PATH before using python binary if it is installed non-system wide. (ex. using gnu modules load).
Changing BLDLIBRARY in configuration could make program work as usual (without setting LD_LIBRARY_PATH) and generating shared-object as well.

----------
components: Build
files: configure.patch
keywords: patch
messages: 354854
nosy: Chiu Speq
priority: normal
severity: normal
status: open
title: build python with --enable-shared with static linked python against libpython*.a
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48666/configure.patch

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

From report at bugs.python.org  Fri Oct 18 02:54:41 2019
From: report at bugs.python.org (minjeong kim)
Date: Fri, 18 Oct 2019 06:54:41 +0000
Subject: [New-bugs-announce] [issue38511] Multiprocessing does not work
 properly when using the trace module.
Message-ID: <1571381681.91.0.0356393028102.issue38511@roundup.psfhosted.org>


New submission from minjeong kim <98nba at naver.com>:

normal result :
$ python test.py
{'p1': 1, 'p2': 1, 'p3': 1, 'p4': 1}

run with tracing :
$ python -mtrace --trackcalls test.py
{}

It seems that the foo and save functions that multiprocess should call are not called.

----------
components: Library (Lib)
files: test.py
messages: 354864
nosy: rls1004
priority: normal
severity: normal
status: open
title: Multiprocessing does not work properly when using the trace module.
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file48667/test.py

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

From report at bugs.python.org  Fri Oct 18 05:33:13 2019
From: report at bugs.python.org (zr22122)
Date: Fri, 18 Oct 2019 09:33:13 +0000
Subject: [New-bugs-announce] [issue38512] bug of the v3.8 api demo case
Message-ID: <1571391193.91.0.262010952347.issue38512@roundup.psfhosted.org>


New submission from zr22122 <2212239597 at qq.com>:

There exists a bug in the python 3.7 API document, as the picture shows below.
When run this code in my python3.7.3 windows7 os, error occurs.

----------
components: Regular Expressions
files: 2.png
messages: 354871
nosy: ezio.melotti, mrabarnett, zr22122
priority: normal
severity: normal
status: open
title: bug of the v3.8 api demo case
versions: Python 3.8
Added file: https://bugs.python.org/file48668/2.png

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

From report at bugs.python.org  Fri Oct 18 05:39:54 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Oct 2019 09:39:54 +0000
Subject: [New-bugs-announce] [issue38513] Should we maintain Jython related
 code?
Message-ID: <1571391594.51.0.774238079811.issue38513@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

I can read some of Jython related code on the master branch.
ASFIK, this codes are the legacy of Jython2.
Currently, Jython3 stops development since 2017.
https://github.com/jython/jython3

Can we get rid of the Jython related code?
Or is there any reason to maintain those codes?

----------
messages: 354872
nosy: corona10, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Should we maintain Jython related code?

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

From report at bugs.python.org  Fri Oct 18 06:00:47 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=)
Date: Fri, 18 Oct 2019 10:00:47 +0000
Subject: [New-bugs-announce] [issue38514] pathlib's mkdir documentation
 improvement
Message-ID: <1571392847.0.0.675625809065.issue38514@roundup.psfhosted.org>


New submission from J?r?me Laurens <jerome.laurens at u-bourgogne.fr>:

There are some inconsistencies in the actual documentation of path lib's mkdir doc.

Here is the 3.7 version, annotated and followed by a change proposal

Path.mkdir(mode=0o777, parents=False, exist_ok=False)
Create a new directory at this given path. If mode is given, it is combined with the process? umask value to determine the file mode and access flags. If the path already exists, FileExistsError is raised. <<<<<<<<<<<<<<<<<< NOT ALWAYS due to exist_ok.

If parents is true, any missing parents of this path are created as needed; they are created with the default permissions without taking mode into account (mimicking the POSIX mkdir -p command).

If parents is false (the default), a missing parent raises FileNotFoundError.

If exist_ok is false (the default), FileExistsError is raised if the target directory already exists.

If exist_ok is true, FileExistsError exceptions will be ignored (same behavior as the POSIX mkdir -p command), but only if the last path component is not an existing non-directory file. <<<<<<<<<<<<<<<<<< UNCLEAR: 1) what is an ignored exception ? 2) The reference to POSIX should appear at the end, like above, 3) the last path component is a string 4) usage of a double negation ignore/is not

----- CHANGE ----

Path.mkdir(mode=0o777, parents=False, exist_ok=False)
Create a new directory in the file system at this given path.

If mode is given, it is combined with the process? umask value to determine the file mode and access flags.

If parents is false (the default), a missing parent raises FileNotFoundError.

If parents is true, any missing parents of this path are created as needed; they are created with the default permissions without taking mode into account (mimicking the POSIX mkdir -p command).

If exist_ok is false (the default), FileExistsError is raised if the given path already exists in the file system, whether a directory or not.

If exist_ok is true, FileExistsError is raised only if the given path already exists in the file system and is not a directory (same behavior as the POSIX mkdir -p command).

Thanks for reading

JL

----------
assignee: docs at python
components: Documentation
messages: 354874
nosy: docs at python, jlaurens
priority: normal
severity: normal
status: open
title: pathlib's mkdir documentation improvement
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct 18 07:04:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Oct 2019 11:04:24 +0000
Subject: [New-bugs-announce] [issue38515] regrtest main process timed out
 after 5 min on AMD64 FreeBSD CURRENT Shared 3.8
Message-ID: <1571396664.18.0.656974468417.issue38515@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

https://buildbot.python.org/all/#/builders/212/builds/322

=> see the traceback below.

I'm not sure that it's an issue with Python. It seems like the system was way too loaded: system load around 13.29 for 2 CPUs. I know that this buildbot worker is super slow.

The main regrtest process is supposed to write an update every 30 seconds. Timeout after 5 minutes means that the main process was either *very very slow*, or that the _get_result() method was blocked because of a real bug. I'm surprised since the code works well on all other workers. If it's a bug, one explanation would be that it's a race condition which trigger only under very precise timings.

In the main thread of the main process, the code is stuck on:

   self.output.get(timeout=30)

where self.output is a queue.Queue() instance. This line should not take longer than 30 seconds, except if the system is *really* slow.

Maybe that day, the poor AMD64 FreeBSD CURRENT Shared 3.8 was just too slow?

--

It's not the first time that I see this issue. In bpo-37531, it already failed on the same buildbot worker (koobs-freebsd-current):
https://bugs.python.org/issue37531#msg354078

When it failed, the main regrtest process used a timeout of 60 seconds. I changed this timeout to 5 minutes in commit 0ec618af98ac250a91ee9c91f8569e6df6772758.

5 minutes is already quite big. It means that the system failed to give back the CPU to regrtest main process in 5 minutes, whereas it should get the CPU after 30 seconds.

--


https://buildbot.python.org/all/#/builders/212/builds/322

...
== FreeBSD-13.0-CURRENT-amd64-64bit-ELF little-endian
== cwd: /usr/home/buildbot/python/3.8.koobs-freebsd-current/build/build/test_python_4823
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
Using random seed 6868206
0:00:00 load avg: 9.98 Run tests in parallel using 4 child processes
0:00:05 load avg: 10.14 [  1/423] test_opcodes passed
...
0:02:12 load avg: 11.82 running: test_capi (2 min 2 sec), test_pickle (1 min 40 sec), test_multiprocessing_spawn (1 min), test_support (2 min 11 sec)
...
0:13:15 load avg: 12.41 [ 80/423] test_rlcompleter passed -- running: test_lib2to3 (1 min 7 sec), test_multiprocessing_spawn (12 min 2 sec)
...
0:13:17 load avg: 12.30 [ 81/423] test_idle skipped -- running: test_lib2to3 (1 min 9 sec), test_multiprocessing_spawn (12 min 4 sec)
...
0:39:19 load avg: 13.70 running: test_concurrent_futures (4 min 23 sec), test_codecmaps_kr (30.0 sec), test_io (5 min 14 sec), test_tokenize (7 min 20 sec)
...
0:40:53 load avg: 13.80 [208/423] test_socketserver passed -- running: test_concurrent_futures (5 min 57 sec), test_tokenize (8 min 53 sec)
0:41:16 load avg: 13.94 [209/423] test_faulthandler passed (38.2 sec) -- running: test_concurrent_futures (6 min 20 sec), test_tokenize (9 min 16 sec)
0:41:29 load avg: 13.29 [210/423] test_glob passed -- running: test_concurrent_futures (6 min 33 sec), test_zipfile (36.3 sec), test_tokenize (9 min 30 sec)
Timeout (0:05:00)!
Thread 0x000000080257c800 (most recent call first):
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/selectors.py", line 415 in select
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", line 1866 in _communicate
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", line 1024 in communicate
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 191 in _run_process
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 229 in _runtest
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 264 in run
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 932 in _bootstrap_inner
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 890 in _bootstrap

Thread 0x000000080257b900 (most recent call first):
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/selectors.py", line 415 in select
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", line 1866 in _communicate
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", line 1024 in communicate
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 191 in _run_process
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 229 in _runtest
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 264 in run
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 932 in _bootstrap_inner
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 890 in _bootstrap

Thread 0x000000080257b400 (most recent call first):
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/selectors.py", line 415 in select
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", line 1866 in _communicate
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", line 1024 in communicate
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 191 in _run_process
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 229 in _runtest
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 264 in run
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 932 in _bootstrap_inner
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 890 in _bootstrap

Thread 0x000000080257be00 (most recent call first):
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/selectors.py", line 415 in select
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", line 1866 in _communicate
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/subprocess.py", line 1024 in communicate
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 191 in _run_process
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 229 in _runtest
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 264 in run
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 932 in _bootstrap_inner
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 890 in _bootstrap

Thread 0x0000000800ac3000 (most recent call first):
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/threading.py", line 306 in wait
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/queue.py", line 179 in get
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 372 in _get_result
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 423 in run_tests
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/runtest_mp.py", line 444 in run_tests_multiprocess
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/main.py", line 513 in run_tests
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/main.py", line 687 in _main
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/main.py", line 634 in main
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/libregrtest/main.py", line 712 in main
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/test/__main__.py", line 2 in <module>
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-current/build/Lib/runpy.py", line 192 in _run_module_as_main
*** Error code 1

Stop.
make: stopped in /usr/home/buildbot/python/3.8.koobs-freebsd-current/build

----------
components: Tests
messages: 354875
nosy: vstinner
priority: normal
severity: normal
status: open
title: regrtest main process timed out after 5 min on AMD64 FreeBSD CURRENT Shared 3.8
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 18 08:11:14 2019
From: report at bugs.python.org (Michael Jaquier)
Date: Fri, 18 Oct 2019 12:11:14 +0000
Subject: [New-bugs-announce] [issue38516] PEP 3132 -- Extended Iterable
 Unpacking inconsistent assignment of * variable
Message-ID: <1571400674.51.0.246530871643.issue38516@roundup.psfhosted.org>


New submission from Michael Jaquier <mjaquier at me.com>:

x = [1,2,3]

Case (1)
*b, = x 
*b == [1, 2, 3]

Case(2)
*b, _ = x 
b = [1,2]



Is it not more logical for this to give consistent values regardless. 

i.e.,

*b, = [1,2,3] ; b == [1,2]

*b, _ = [1,3,2] ;  b == [1,2] ;  _ == [3]

----------
components: Library (Lib)
messages: 354881
nosy: mjaquier
priority: normal
severity: normal
status: open
title: PEP 3132 -- Extended Iterable Unpacking inconsistent assignment of * variable
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct 18 09:18:33 2019
From: report at bugs.python.org (Ricardo Branco)
Date: Fri, 18 Oct 2019 13:18:33 +0000
Subject: [New-bugs-announce] [issue38517] functools.cached_property should
 support partial functions and partialmethod's
Message-ID: <1571404713.25.0.542654366975.issue38517@roundup.psfhosted.org>


New submission from Ricardo Branco <ricardo.smartmatic at gmail.com>:

functools.cached_property should support partial functions and partialmethod's

This way one can create cached_property's dynamically.

----------
components: Library (Lib)
messages: 354893
nosy: Ricardo Branco
priority: normal
severity: normal
status: open
title: functools.cached_property should support partial functions and partialmethod's
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct 18 09:46:33 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 18 Oct 2019 13:46:33 +0000
Subject: [New-bugs-announce] [issue38518] Pickle protocol 5 is not
 documented in the data-stream-format section for the pickle docs
Message-ID: <1571406393.97.0.877250924995.issue38518@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

The Data Stream format section of the pickle docs (https://docs.python.org/3/library/pickle.html#data-stream-format) fails to document protocol 5 in the list of protocols.

----------
assignee: docs at python
components: Documentation
messages: 354898
nosy: docs at python, pablogsal, pitrou
priority: normal
severity: normal
status: open
title: Pickle protocol 5 is not documented in the data-stream-format section for the pickle docs
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 18 14:30:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 18 Oct 2019 18:30:38 +0000
Subject: [New-bugs-announce] [issue38519] Internal include files missing on
 Windows
Message-ID: <1571423438.26.0.118785392888.issue38519@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The include/internal directory is not being included in the packages published to nuget.org or the Microsoft Store.

This prevents some advanced users from being able to compile against these packages.

----------
assignee: steve.dower
components: Windows
messages: 354914
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Internal include files missing on Windows
type: compile error
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 18 16:48:15 2019
From: report at bugs.python.org (Adrien)
Date: Fri, 18 Oct 2019 20:48:15 +0000
Subject: [New-bugs-announce] [issue38520] There is no proper way to know if
 a process is the main one
Message-ID: <1571431695.05.0.294533702536.issue38520@roundup.psfhosted.org>


New submission from Adrien <delgan.py at gmail.com>:

Hi.

I noticed that there exists the function "threading.main_thread()", but there is no equivalent for the "multiprocessing" module.

Is there a reason for this absence?

These StackOverflow questions are related to this problem:
- https://stackoverflow.com/questions/42283265/how-to-determine-if-running-current-process-is-parent
- https://stackoverflow.com/questions/30790660/python-multiprocessing-name-of-the-main-process
- https://stackoverflow.com/questions/18216050/is-there-a-way-to-check-if-a-module-is-being-loaded-by-multiprocessing-standard

Current proposed solutions have flaws.
It's suggested to check if "current_process().name == 'MainProcess'" but anyone can re-write the name of a process with "current_process().name = 'foobar'" so this does not seem to be a reliable solution.
Another alternative is to check for the type of the process, which is different for main and child, respectively "mulitprocessing.process._MainProcess" and "multiprocessing.process.Process". This is obviously hacky as it relies on implementation detail.

What are you thoughts on adding a new "multiprocessing.main_process()" function?

----------
components: Library (Lib)
messages: 354918
nosy: Delgan
priority: normal
severity: normal
status: open
title: There is no proper way to know if a process is the main one
type: enhancement

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

From report at bugs.python.org  Fri Oct 18 16:57:18 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Oct 2019 20:57:18 +0000
Subject: [New-bugs-announce] [issue38521] Error in NormalDist.__eq__
Message-ID: <1571432238.37.0.27679322592.issue38521@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The equality comparison has a typo that wasn't caught by the tests.

----------
assignee: rhettinger
components: Library (Lib)
messages: 354919
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Error in NormalDist.__eq__
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 18 18:01:11 2019
From: report at bugs.python.org (=?utf-8?q?S=C3=BCmer_Cip?=)
Date: Fri, 18 Oct 2019 22:01:11 +0000
Subject: [New-bugs-announce] [issue38522] Py_USING_MEMORY_DEBUGGER is
 referenced in docs but not present in code
Message-ID: <1571436071.95.0.156296507321.issue38522@roundup.psfhosted.org>


New submission from S?mer Cip <sumerc at gmail.com>:

Hi all,

While trying to debug Python C extension via valgrind, I was reading the document Misc/README.valgrind and it seems there are some parts not being uptodate. There is comments comments like following:

Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c, then rebuild Python. This define seems to be removed from the obmalloc.c file and also I am not sure if anything is using it at all. When I searched the code, only Python/dtoa.c have a reference to this define. Anyway, I have not specifically investigated the reason behind of the removal of the define but it seems it is removed somewhere between 3.3 and 3.4. I am assuming it might be related with tracemalloc maybe? 

Cheers,

----------
components: Build
messages: 354922
nosy: S?mer.Cip
priority: normal
severity: normal
status: open
title: Py_USING_MEMORY_DEBUGGER is referenced in docs but not present in code
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Oct 18 18:29:15 2019
From: report at bugs.python.org (Rob nelson)
Date: Fri, 18 Oct 2019 22:29:15 +0000
Subject: [New-bugs-announce] [issue38523] ignore_dangling_symlinks in
 shutil.copytree does not apply recursively
Message-ID: <1571437755.03.0.462874003253.issue38523@roundup.psfhosted.org>


New submission from Rob nelson <veaviticus at gmail.com>:

The ignore_dangling_symlinks attribute in shutil.copytree is not passed down recursively, resulting in dangling symlinks located anywhere other than the root of the source tree to raise an error.

The line causing the error for 3.9: https://github.com/python/cpython/blob/v3.8.0/Lib/shutil.py#L486

Trivial patches and an improved test case for:
3.7: https://github.com/veaviticus/cpython/commit/a662ae8a3f85380ec76ed3dfbc778aad8c5ac37a

3.8: https://github.com/veaviticus/cpython/commit/64f72c7196243bd3e2cf4136ebbb9f9ffe206750

3.9: https://github.com/veaviticus/cpython/commit/e55dd12e558443c350d241d87bf17dfc322dbfcf

----------
components: Library (Lib)
messages: 354924
nosy: veaviticus
priority: normal
severity: normal
status: open
title: ignore_dangling_symlinks in shutil.copytree does not apply recursively
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Oct 19 03:30:51 2019
From: report at bugs.python.org (hongweipeng)
Date: Sat, 19 Oct 2019 07:30:51 +0000
Subject: [New-bugs-announce] [issue38524] functools.cached_property is not
 supported for setattr
Message-ID: <1571470251.68.0.879446650629.issue38524@roundup.psfhosted.org>


New submission from hongweipeng <hongweichen8888 at sina.com>:

```
from functools import cached_property
def age(self):
    return 10
class A:
    def __init__(self):
        setattr(self.__class__, 'age', property(age))
        setattr(self.__class__, 'age3', cached_property(age))

    age2 = cached_property(age)

a = A()
print(a.age)    # 10
print(a.age2)   # 10
print(a.age3)   # TypeError: Cannot use cached_property instance without calling __set_name__
```
Is it expected?

----------
messages: 354929
nosy: hongweipeng
priority: normal
severity: normal
status: open
title: functools.cached_property is not supported for setattr
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct 19 04:00:52 2019
From: report at bugs.python.org (Ivan Bykov)
Date: Sat, 19 Oct 2019 08:00:52 +0000
Subject: [New-bugs-announce] [issue38525] Strange reversed dict behavior
Message-ID: <1571472052.75.0.136395293008.issue38525@roundup.psfhosted.org>


New submission from Ivan Bykov <ivan.bykov at gmail.com>:

Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
>>> list(reversed({1: 1}))
[1]
>>> list(reversed({}))

================================ RESTART: Shell ================================
>>>

----------
components: Interpreter Core
messages: 354931
nosy: ivb
priority: normal
severity: normal
status: open
title: Strange reversed dict behavior
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct 19 07:47:18 2019
From: report at bugs.python.org (Alex Walters)
Date: Sat, 19 Oct 2019 11:47:18 +0000
Subject: [New-bugs-announce] [issue38526] zipfile.Path has the wrong method
 name
Message-ID: <1571485638.73.0.512747413003.issue38526@roundup.psfhosted.org>


New submission from Alex Walters <tritium-list at sdamon.com>:

https://docs.python.org/3.8/library/zipfile.html#zipfile.Path.listdir

The docs for zipfile.Path list a method named 'listdir', the closest approximation to the functionality described in the actual code is a method named 'iterdir'

----------
assignee: docs at python
components: Documentation
messages: 354936
nosy: docs at python, tritium
priority: normal
severity: normal
status: open
title: zipfile.Path has the wrong method name
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct 19 10:47:05 2019
From: report at bugs.python.org (Arnon Yaari)
Date: Sat, 19 Oct 2019 14:47:05 +0000
Subject: [New-bugs-announce] [issue38527] configure script fails to detect
 "float word ordering" on Solaris
Message-ID: <1571496425.89.0.0695984738868.issue38527@roundup.psfhosted.org>


New submission from Arnon Yaari <wiggin15 at gmail.com>:

When running the configure script on Solaris SPARC (versions 10 and 11), the script fails with the following error:

    checking whether float word ordering is bigendian... unknown
    configure: error:

    Unknown float word ordering. You need to manually preset
    ax_cv_c_float_words_bigendian=no (or yes) according to your system.


The configure script uses "grep" on a compiled binary to see how a float variable is compiled. On Solaris, the regular "grep" command may be an old version that fails to search in a binary file. The correct command should be "ggrep" (the GNU grep).
Luckily, Python's configure script already finds this command in an earlier check:

    checking for grep that handles long lines and -e... /usr/bin/ggrep

All we have to do, then, is use the command that configure finds. i.e. replace "grep" -> "$GREP".

----------
components: Build
messages: 354941
nosy: wiggin15
priority: normal
severity: normal
status: open
title: configure script fails to detect "float word ordering" on Solaris
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 19 13:44:21 2019
From: report at bugs.python.org (Julin)
Date: Sat, 19 Oct 2019 17:44:21 +0000
Subject: [New-bugs-announce] [issue38528] Docs for 2.7 version switcher
 still shows 3.8 as pre
Message-ID: <1571507061.36.0.813335494011.issue38528@roundup.psfhosted.org>


New submission from Julin <julinshaji02 at gmail.com>:

The version switcher in the docs for Python2.7 still shows version 3.8 as `pre (3.8)`. Can we change it to `3.8.0` to mirror that in docs of 3.8?

Also, 2.7 docs version switcher at the moment show `dev (3.9)` for 3.9 whereas the 3.8 docs say `3.9.0a0` can it be changed as well?

----------
assignee: docs at python
components: Documentation
messages: 354950
nosy: docs at python, ju-sh
priority: normal
severity: normal
status: open
title: Docs for 2.7 version switcher still shows 3.8 as pre
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 19 14:40:28 2019
From: report at bugs.python.org (Ron Frederick)
Date: Sat, 19 Oct 2019 18:40:28 +0000
Subject: [New-bugs-announce] [issue38529] Python 3.8 improperly warns about
 closing properly closed streams
Message-ID: <1571510429.0.0.996597968813.issue38529@roundup.psfhosted.org>


New submission from Ron Frederick <ronf at timeheart.net>:

In testing AsyncSSH against Python 3.8, I noticed a large number of the following errors, even though I was properly closing streams before the objects holding them were garbage-collected.

    An open stream object is being garbage collected; call "stream.close()" explicitly.

After some investigation, the problem appears to be that closing a stream is not good enough to prevent the error. The check in asyncio doesn't properly handle the case where the stream is closing, but has not fully closed. Here's a simple test program that demonstrates this:

import asyncio

async def tcp_client():
    reader, writer = await asyncio.open_connection('127.0.0.1', 22)

    writer.close()

asyncio.run(tcp_client())

It's possible to avoid this message by awaiting on writer.wait_closed(), but wait_closed() doesn't exist until Python 3.7, making it very difficult to write portable code and still avoid this message.

----------
components: asyncio
messages: 354953
nosy: Ron Frederick, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Python 3.8 improperly warns about closing properly closed streams
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct 19 14:57:31 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 19 Oct 2019 18:57:31 +0000
Subject: [New-bugs-announce] [issue38530] Offer suggestions on AttributeError
Message-ID: <1571511451.65.0.74942926189.issue38530@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

To improve the debugging experience in both interactive and non-interactive code, I propose to offer suggestions when attribute access fails. For example:

>>> class A: foo = None
... 
>>> A.fou
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'A' has no attribute 'fou'

Did you mean: foo?

This also applies to imports from modules and other situations:

>>> import collections
>>> collections.NamedTuple
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'collections' has no attribute 'NamedTuple'

Did you mean: namedtuple?

----------
components: Interpreter Core
messages: 354954
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Offer suggestions on AttributeError
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Oct 19 16:59:52 2019
From: report at bugs.python.org (Christoph Zwerschke)
Date: Sat, 19 Oct 2019 20:59:52 +0000
Subject: [New-bugs-announce] [issue38531] argparse action "extend" not
 documented as new
Message-ID: <1571518792.2.0.7359491758.issue38531@roundup.psfhosted.org>


New submission from Christoph Zwerschke <cito at online.de>:

A new action "extend" has been added to argparse in https://github.com/python/cpython/commit/aa32a7e1116f7aaaef9fec453db910e90ab7b101

The documentation should specify that this is new in Python 3.8 addition. I wondered why it didn't work in Python 3.7.

----------
assignee: docs at python
components: Documentation
messages: 354966
nosy: cito, docs at python
priority: normal
severity: normal
status: open
title: argparse action "extend" not documented as new
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Oct 19 22:51:28 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 20 Oct 2019 02:51:28 +0000
Subject: [New-bugs-announce] [issue38532] Missing decrefs in the _ctypes
 module
Message-ID: <1571539888.18.0.273531379045.issue38532@roundup.psfhosted.org>


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

In PyCFuncPtr_FromDll(), there are two missing calls to Py_DECREF() if PySys_Audit() fails!

----------
components: Extension Modules
messages: 354980
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Missing decrefs in the _ctypes module
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Oct 20 00:31:43 2019
From: report at bugs.python.org (Jon)
Date: Sun, 20 Oct 2019 04:31:43 +0000
Subject: [New-bugs-announce] [issue38533] py script runs with python.exe but
 not pythonw.exe (python console)
Message-ID: <1571545903.38.0.511013655415.issue38533@roundup.psfhosted.org>


New submission from Jon <yourbestfriendjax at gmail.com>:

3.7.5.  Any py script that I run with python.exe or py.exe executes just fine.  But if I try to run any py script with pythonW.exe or pyW.exe it will not run.  

I don't know where the logging for the python executable is located.

On the same machine, java.exe and javaW.exe work properly. (jar file runs exactly the same with either executable.  Only the cmd/console window is suppressed with "w" exe.



I am trying to isolate whether or not python 3.7.5 is to blame or this new windows 10 x64 1809 LTSC machine is to blame.

I have tested in both python 3.7.5 x86 and x64 versions.  the "W" console version does not run any py scripts.

On my previous laptop (win 8.1 x64) and (win2012 r2 x64 server, no problems) with 3.7.4 32 bit.

---

How do I have multiple MINOR versions of python together?  e.g. 3.7.3, 3.7.4, 3.7.5?  Can they be placed in separate folders?

----------
components: Windows
messages: 354982
nosy: 4evermaat, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: py script runs with python.exe but not pythonw.exe (python console)
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Oct 20 03:59:24 2019
From: report at bugs.python.org (Wator Sead)
Date: Sun, 20 Oct 2019 07:59:24 +0000
Subject: [New-bugs-announce] [issue38534] Version 3.8.0 has released with a
 wrong MS KB number reference
Message-ID: <1571558364.86.0.253246786334.issue38534@roundup.psfhosted.org>


New submission from Wator Sead <seahoh at gmail.com>:

https://bugs.python.org/msg347421

Maybe you forgot it, please fix it in next versions.

----------
assignee: docs at python
components: Documentation, Installation, Windows
messages: 354986
nosy: docs at python, paul.moore, seahoh, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Version 3.8.0 has released with a wrong MS KB number reference
type: resource usage
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct 20 04:21:37 2019
From: report at bugs.python.org (Alex Hall)
Date: Sun, 20 Oct 2019 08:21:37 +0000
Subject: [New-bugs-announce] [issue38535] Incorrect col_offset for
 decorators with zero arguments (empty parentheses)
Message-ID: <1571559697.79.0.983996718555.issue38535@roundup.psfhosted.org>


New submission from Alex Hall <alex.mojaki at gmail.com>:

In a decorator such as `@a()`, the ast.Call node has a col_offset starting from the @ symbol. This doesn't happen for decorators without arguments (e.g. `@a`) or with some arguments (e.g. `@a(x)`).

----------
components: Interpreter Core
files: decorator_python_bug.py
messages: 354987
nosy: alexmojaki
priority: normal
severity: normal
status: open
title: Incorrect col_offset for decorators with zero arguments (empty parentheses)
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48669/decorator_python_bug.py

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

From report at bugs.python.org  Sun Oct 20 04:58:32 2019
From: report at bugs.python.org (Jonas Aschenbrenner)
Date: Sun, 20 Oct 2019 08:58:32 +0000
Subject: [New-bugs-announce] [issue38536] Trailing space in formatted
 currency with international=True and locale de_DE
Message-ID: <1571561912.94.0.419750510226.issue38536@roundup.psfhosted.org>


New submission from Jonas Aschenbrenner <jonas.aschenbrenner at gmail.com>:

>>> import locale
>>> locale.setlocale(locale.LC_ALL, ('de_DE', 'UTF-8'))
'de_DE.UTF-8'
>>> locale.currency(1345345345352.22, international=True)
'1345345345352,22 EUR '

Expected: '1345345345352,22 EUR'

----------
components: Library (Lib)
messages: 354989
nosy: Jonas Aschenbrenner
priority: normal
severity: normal
status: open
title: Trailing space in formatted currency with international=True and locale de_DE
versions: Python 3.7

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

From report at bugs.python.org  Sun Oct 20 08:51:18 2019
From: report at bugs.python.org (PEW's Corner)
Date: Sun, 20 Oct 2019 12:51:18 +0000
Subject: [New-bugs-announce] [issue38537] Python 2.7.17 reports itself as
 2.7.16
Message-ID: <1571575878.44.0.238301674763.issue38537@roundup.psfhosted.org>


New submission from PEW's Corner <pewscorner at gmail.com>:

After upgrading Python 2.7.16 to 2.7.17 using the Windows x86 MSI installer, the new Python still reports itself as version 2.7.16:

D:\Python27>.\python.exe
Python 2.7.16 (v2.7.16:413a49145e, Mar  4 2019, 01:30:55) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.version_info
sys.version_info(major=2, minor=7, micro=16, releaselevel='final', serial=0)
>>>

The python.exe file is dated Oct. 19, but the python27.dll is dated Mar. 4, so doesn't seem to have been updated. Repairing or removing and reinstalling doesn't make any difference, so the old dll seems to be part of the new installation.

----------
components: Installation
messages: 354997
nosy: pewscorner
priority: normal
severity: normal
status: open
title: Python 2.7.17 reports itself as 2.7.16
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 20 11:32:28 2019
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Oct 2019 15:32:28 +0000
Subject: [New-bugs-announce] [issue38538] dictobject dictviews don't return
 NotImplemented for unrecognized types.
Message-ID: <1571585548.13.0.376831813762.issue38538@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

In the following snippet:

    >>> class Ror:
    ...     def __ror__(self, other):
    ...         return set()
    ...
    >>> {}.keys() | Ror()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'Ror' object is not iterable

I expect the __or__ implementation of dict_keys to return NotImplemented when given a non-interesting thing, so my __ror__ can run and get an empty set instead of a TypeError.

Strangely enough, it worked in Python 2.7, I'm not fluent enough en 2.7 object nor C implementation to know why, the dictviews_or looks the same for me.

It looks easy to fix without breaking the tests in dictobject.c like:

    --- a/Objects/dictobject.c
    +++ b/Objects/dictobject.c
    @@ -4284,7 +4284,8 @@ dictviews_or(PyObject* self, PyObject *other)
         tmp = _PyObject_CallMethodIdOneArg(result, &PyId_update, other);
         if (tmp == NULL) {
             Py_DECREF(result);
    -        return NULL;
    +        PyErr_Clear();
    +        Py_RETURN_NOTIMPLEMENTED;
         }

the question is more: should we? I think so but am I missing something?

----------
messages: 355007
nosy: mdk
priority: normal
severity: normal
status: open
title: dictobject dictviews don't return NotImplemented for unrecognized types.
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/issue38538>
_______________________________________

From report at bugs.python.org  Sun Oct 20 15:17:35 2019
From: report at bugs.python.org (Julin)
Date: Sun, 20 Oct 2019 19:17:35 +0000
Subject: [New-bugs-announce] [issue38539] Update demo files
Message-ID: <1571599055.13.0.42950539659.issue38539@roundup.psfhosted.org>


New submission from Julin <julinshaji02 at gmail.com>:

The demo programs inside Tools/demo, which is to guide people new to the language (that's the purpose, right?), makes use of several bad coding practices.

Like
 - `while 1:` being used instead of `while True:`
 - star import
 - function call and an `if` statement being on the same line, etc.

It can easily mislead someone new to the language especially since it is part of the codebase and part of distribution as well.

Can we update these files? Most of these seem have not been updated in some time.

A discussion touching this problem on #python-dev suggested that the demos were written when the docs were yet to be polished and now that we have a fully fledged documentation, maybe the demo files can be dropped.

But since the bpo has an option 'Demos and tools' under 'components', I guess maybe the demos are still considered essential.

What do you all think?

----------
components: Demos and Tools
messages: 355013
nosy: ju-sh
priority: normal
severity: normal
status: open
title: Update demo files
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 21 02:20:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Oct 2019 06:20:30 +0000
Subject: [New-bugs-announce] [issue38540] Possible leaks in PyArg_Parse for
 "es#" and "et#"
Message-ID: <1571638830.02.0.0342300206761.issue38540@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There are possible leaks in PyArg_Parse and similar functions for format units "es#" and "et#". Macros STORE_SIZE and (since 3.8) FETCH_SIZE can leave the function despite there is an own reference to an encoded string (s). The leak is only possible when PY_SSIZE_T_CLEAN is not defined.

----------
components: Interpreter Core
messages: 355022
nosy: inada.naoki, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Possible leaks in PyArg_Parse for "es#" and "et#"
type: resource usage
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Oct 21 04:15:44 2019
From: report at bugs.python.org (ttrd)
Date: Mon, 21 Oct 2019 08:15:44 +0000
Subject: [New-bugs-announce] [issue38541] Performance degradation of
 attribute accesses in Python 3.7.4
Message-ID: <1571645744.43.0.285485842632.issue38541@roundup.psfhosted.org>


New submission from ttrd <randy.doering at tracetronic.de>:

After upgrading from Python 3.7.3 to Python 3.7.4, we noticed an increased runtime of about 50% in some tests of our application.

After some testing we constructed the following hypothesis: Accessing instance attributes of classes that define a custom metaclass take more time in Python 3.7.4. The access takes the more time the more classes are in the MRO of the concerning class (in other words the more base classes the concerning class has got).

We verified the hypothesis by creating a minimal example (file attached) that produced the output at the bottom. (The index defines the number of base classes. The four variants are with/without a metaclass and with simple/multiple inheritance. The kind of inheritance has no influence on the runtime.)

In Python 3.7.4 (in contrast to 3.7.3 and 3.8), you can see that the usage of a metaclass results in a linear increase of the runtime of attribute accesses depending on the number of base classes.

We could also identify the issue/commit that introduced the performance issue:
https://bugs.python.org/issue28866
https://github.com/python/cpython/commit/bfd0b7720196b9ff647cc33dafbd31a04496402c

In the Python 3.8 branch, the performance issue seems to be resolved by:
https://bugs.python.org/issue36922
https://github.com/python/cpython/commit/988fff5d0e7fccecbf776c08ec56695820b3b4a8

Will this performance issue be addressed in a future 3.7 version (e.g. 3.7.6) or is it in your optinion sufficient that the issue seems to be resolved in 3.8?


Python 3.7.3 (constant runtime)

3.668036e-08 noMetaBaseX[1].attr
3.630355e-08 noMetaBaseX[2].attr
3.687350e-08 noMetaBaseX[5].attr
3.827102e-08 noMetaBaseX[10].attr
3.724956e-08 noMetaBaseX[20].attr
3.912778e-08 noMetaBaseX[50].attr
4.072552e-08 noMetaBaseX[100].attr
3.620875e-08 metaBaseX[1].attr
3.640054e-08 metaBaseX[2].attr
3.599339e-08 metaBaseX[5].attr
3.606570e-08 metaBaseX[10].attr
3.946514e-08 metaBaseX[20].attr
3.715085e-08 metaBaseX[50].attr
3.762364e-08 metaBaseX[100].attr
3.667802e-08 noMetaRecBaseX[1].attr
3.579415e-08 noMetaRecBaseX[2].attr
3.647997e-08 noMetaRecBaseX[5].attr
3.577428e-08 noMetaRecBaseX[10].attr
3.686319e-08 noMetaRecBaseX[20].attr
3.832261e-08 noMetaRecBaseX[50].attr
4.087625e-08 noMetaRecBaseX[100].attr
3.654509e-08 noMetaRecBaseX[1].attr
3.617825e-08 noMetaRecBaseX[2].attr
3.573970e-08 noMetaRecBaseX[5].attr
3.664559e-08 noMetaRecBaseX[10].attr
3.702526e-08 noMetaRecBaseX[20].attr
3.774067e-08 noMetaRecBaseX[50].attr
3.836915e-08 noMetaRecBaseX[100].attr

Python 3.7.4 (see lines marked with ->)

4.042378e-08 noMetaBaseX[1].attr
3.704071e-08 noMetaBaseX[2].attr
3.868766e-08 noMetaBaseX[5].attr
3.716869e-08 noMetaBaseX[10].attr
3.693100e-08 noMetaBaseX[20].attr
3.947849e-08 noMetaBaseX[50].attr
3.790146e-08 noMetaBaseX[100].attr
-> 5.010019e-08 metaBaseX[1].attr
-> 5.215336e-08 metaBaseX[2].attr
-> 6.103393e-08 metaBaseX[5].attr
-> 7.947347e-08 metaBaseX[10].attr
-> 1.082155e-07 metaBaseX[20].attr
-> 2.264330e-07 metaBaseX[50].attr
-> 4.951039e-07 metaBaseX[100].attr
3.727378e-08 noMetaRecBaseX[1].attr
3.815971e-08 noMetaRecBaseX[2].attr
3.661390e-08 noMetaRecBaseX[5].attr
3.709824e-08 noMetaRecBaseX[10].attr
3.785757e-08 noMetaRecBaseX[20].attr
3.813983e-08 noMetaRecBaseX[50].attr
3.856352e-08 noMetaRecBaseX[100].attr
-> 5.260115e-08 metaRecBaseX[1].attr
-> 5.661043e-08 metaRecBaseX[2].attr
-> 6.760995e-08 metaRecBaseX[5].attr
-> 8.038124e-08 metaRecBaseX[10].attr
-> 1.100538e-07 metaRecBaseX[20].attr
-> 2.246786e-07 metaRecBaseX[50].attr
-> 4.877147e-07 metaRecBaseX[100].attr
	
?Python 3.8.0rc1 (constant runtime)

?4.045787e-08 noMetaBaseX[1].attr
4.206206e-08 noMetaBaseX[2].attr
4.209608e-08 noMetaBaseX[5].attr
4.049552e-08 noMetaBaseX[10].attr
4.133343e-08 noMetaBaseX[20].attr
4.229599e-08 noMetaBaseX[50].attr
4.259420e-08 noMetaBaseX[100].attr
4.146996e-08 metaBaseX[1].attr
4.140459e-08 metaBaseX[2].attr
4.143048e-08 metaBaseX[5].attr
4.054639e-08 metaBaseX[10].attr
4.219960e-08 metaBaseX[20].attr
4.222810e-08 metaBaseX[50].attr
4.420123e-08 metaBaseX[100].attr
4.044410e-08 noMetaRecBaseX[1].attr
4.043790e-08 noMetaRecBaseX[2].attr
4.209061e-08 noMetaRecBaseX[5].attr
4.042041e-08 noMetaRecBaseX[10].attr
4.048202e-08 noMetaRecBaseX[20].attr
4.260607e-08 noMetaRecBaseX[50].attr
4.267928e-08 noMetaRecBaseX[100].attr
4.037958e-08 metaRecBaseX[1].attr
3.968827e-08 metaRecBaseX[2].attr
4.011758e-08 metaRecBaseX[5].attr
3.954960e-08 metaRecBaseX[10].attr
4.057979e-08 metaRecBaseX[20].attr
4.145640e-08 metaRecBaseX[50].attr
4.148783e-08 metaRecBaseX[100].attr

----------
components: Interpreter Core
files: timeAttrAccess.py
messages: 355029
nosy: ttrd
priority: normal
severity: normal
status: open
title: Performance degradation of attribute accesses in Python 3.7.4
type: performance
versions: Python 3.7
Added file: https://bugs.python.org/file48670/timeAttrAccess.py

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

From report at bugs.python.org  Mon Oct 21 05:43:52 2019
From: report at bugs.python.org (egaudry)
Date: Mon, 21 Oct 2019 09:43:52 +0000
Subject: [New-bugs-announce] [issue38542] Expose _PyGC_generation0 for
 allowing internal use directly from a CPython extension
Message-ID: <1571651032.85.0.698320385475.issue38542@roundup.psfhosted.org>


New submission from egaudry <eg at fft.be>:

Hi

I would like to be able to get an handle on PyGC_Head*_PyGC_generation0 from a CPython extension.
This is possible when building Python on a Posix host, but not on Windows because of a missing PyAPI_DATA wrapping of the said object in the objimpl.h header.

Having the possibility to inspect the PyGC_Head here can be very useful when customizing the way a garbage-collectable object created from CPython extension would be cleaned/inspected, etc.

Any chance this patch could be added to get the same capabilities on Windows and Posix platforms ?

Thanks for your feedback,
Eloi

----------
components: Interpreter Core
files: gc.diff
keywords: patch
messages: 355034
nosy: egaudry
priority: normal
severity: normal
status: open
title: Expose _PyGC_generation0 for allowing internal use directly from a CPython extension
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48671/gc.diff

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

From report at bugs.python.org  Mon Oct 21 05:46:20 2019
From: report at bugs.python.org (egaudry)
Date: Mon, 21 Oct 2019 09:46:20 +0000
Subject: [New-bugs-announce] [issue38543] Expose Py_TabcheckFlag as other
 PyAPI_DATA flag
Message-ID: <1571651180.6.0.332450448454.issue38543@roundup.psfhosted.org>


New submission from egaudry <eg at fft.be>:

When looking at the pydebug.h header file, I see that some symbols are not declared as exported.

For instance, I would like to be able to change the value of the Py_TabcheckFlag when running specific codelines.
Any chance this patch could be added ?

----------
components: Interpreter Core
files: tab.diff
keywords: patch
messages: 355035
nosy: egaudry
priority: normal
severity: normal
status: open
title: Expose Py_TabcheckFlag as other PyAPI_DATA flag
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48672/tab.diff

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

From report at bugs.python.org  Mon Oct 21 06:19:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Oct 2019 10:19:04 +0000
Subject: [New-bugs-announce] [issue38544] test_venv: test_isolation() failed
 on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\
Message-ID: <1571653144.99.0.203555280128.issue38544@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

https://buildbot.python.org/all/#/builders/40/builds/3317

test_executable (test.test_venv.BasicTest) ... ok
test_executable_symlinks (test.test_venv.BasicTest) ... skipped 'Needs symlinks'
test_isolation (test.test_venv.BasicTest) ... ERROR
ERROR
test_multiprocessing (test.test_venv.BasicTest) ... ok
test_overwrite_existing (test.test_venv.BasicTest) ... ok

======================================================================
ERROR: test_isolation (test.test_venv.BasicTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 272, in test_isolation
    builder.create(self.env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 65, in create
    context = self.ensure_directories(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 108, in ensure_directories
    self.clear_directory(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 91, in clear_directory
    shutil.rmtree(fn)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 730, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 612, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 610, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp2y7z3288\\Scripts'

----------
components: Tests
messages: 355040
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 21 06:31:01 2019
From: report at bugs.python.org (Laurie Opperman)
Date: Mon, 21 Oct 2019 10:31:01 +0000
Subject: [New-bugs-announce] [issue38545] Implement setter and deleter on
 functools.cached_property
Message-ID: <1571653861.42.0.831485996557.issue38545@roundup.psfhosted.org>


New submission from Laurie Opperman <laurie_opperman at hotmail.com>:

Support setting/updating and clearing the cached value of a cached-property (getter implemented by bpo-21145). Pretty straight-forward to implement

The question is whether cached-property updating should be:
a) always allowed
b) enabled with a cached-property instance attribute
c) enabled with the decorated method's class attribute
d) enabled with the decorated method's instance attribute
e) enabled in a separate decorator (eg functools.updatable_cached_property)

Note: options a, b, c, and d will make functools.cached_property a data descriptor.

I prefer option b or c, as the decision to make the property updatable becomes the property's definer's.

Also, should a warning be raised if a cached value is being overwritten? Should a warning be raised if no cached value is to be deleted?

----------
components: Library (Lib)
messages: 355045
nosy: Epic_Wink
priority: normal
severity: normal
status: open
title: Implement setter and deleter on functools.cached_property
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 21 07:20:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Oct 2019 11:20:00 +0000
Subject: [New-bugs-announce] [issue38546] test_concurrent_futures:
 test_interpreter_shutdown() warning "reap_children() reaped child process"
 on AMD64 RHEL7 3.x
Message-ID: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

https://buildbot.python.org/all/#/builders/254/builds/162

test_no_stale_references (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.56s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.90s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.54s ok
test_submit (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.52s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.57s ok
test_traceback (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.48s ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.03s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.02s ok
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 1.45s ok
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 1.62s Warning -- reap_children() reaped child process 28936
ok

----------
components: Tests
messages: 355051
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_concurrent_futures: test_interpreter_shutdown() warning "reap_children() reaped child process" on AMD64 RHEL7 3.x
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 21 07:38:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Oct 2019 11:38:39 +0000
Subject: [New-bugs-announce] [issue38547] test_pty fails when using setsid()
Message-ID: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

regrtest has been modified in bpo-38502 to use setsid() when using multiprocessing mode (-jN command line option).

Problem: David Bolen identified that test_pty started to fail on his bolen-ubuntu worker (Ubuntu 18.04.3) since my commit ecb035cd14c11521276343397151929a94018a22.

https://buildbot.python.org/all/#/builders/141/builds/2679

0:19:05 load avg: 1.81 [234/419/1] test_pty crashed (Exit code -1) -- running: test_unicodedata (55.5 sec)

I can reproduce the issue locally:

---
$ ./python -m test -j2 test_pty -v
== CPython 3.9.0a0 (heads/urlparse_ipv6:cc733a8cb6, Oct 21 2019, 11:34:36) [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)]
== Linux-5.2.18-200.fc30.x86_64-x86_64-with-glibc2.29 little-endian
== cwd: /home/vstinner/python/master/build/test_python_20242
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 0.70 Run tests in parallel using 2 child processes
0:00:00 load avg: 0.70 [1/1/1] test_pty crashed (Exit code -1)
test_basic (test.test_pty.PtyTest) ...

== Tests result: FAILURE ==

1 test failed:
    test_pty

Total duration: 383 ms
Tests result: FAILURE
---

It's surprising that there is no output!

I would prefer to keep process groups in regrtest, it's really helpful to be able to kill all processes spawned by a test worker process.

I'm not sure how/why PTY depends is incompatible with setsid().

----------
components: Tests
messages: 355059
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_pty fails when using setsid()
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 21 08:12:20 2019
From: report at bugs.python.org (kryptomatrix)
Date: Mon, 21 Oct 2019 12:12:20 +0000
Subject: [New-bugs-announce] [issue38548] open() and file.write() without
 file.close()
Message-ID: <1571659940.93.0.484534204799.issue38548@roundup.psfhosted.org>


New submission from kryptomatrix <volker.weissmann at gmx.de>:

Consider the following program:

f = open("out.txt", "w")
f.write("abc\n")
exit(0)

Please note the absence of f.close().
The documentation 
https://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files
says that you should use f.close() or with f = open(), but is not clear whether the program above without f.close() is guaranteed to write. The tutorial says:
"If you don?t explicitly close a file, Python?s garbage collector will eventually destroy the object and close the open file for you, but the file may stay open for a while. Another risk is that different Python implementations will do this clean-up at different times."
For me this sounds like even without f.close() the file is guaranteed to be written. If it is not guaranteed to be written, you should fix the documentation, if it is guaranteed to be written, then I will open another issue because the following program does not write into out.txt on my machine:

from sympy.core import AtomicExpr
class MyWeirdClass(AtomicExpr):
	def __init__(self):
		pass
f = open("out.txt", "w")
f.write("abc\n")
exit(0)

Note: sys.version is: "3.7.3 (default, Oct  7 2019, 12:56:13) \n[GCC 8.3.0]"

----------
assignee: docs at python
components: Documentation
messages: 355062
nosy: docs at python, kryptomatrix
priority: normal
severity: normal
status: open
title: open() and file.write() without file.close()
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct 21 10:21:13 2019
From: report at bugs.python.org (Alex Grund)
Date: Mon, 21 Oct 2019 14:21:13 +0000
Subject: [New-bugs-announce] [issue38549] Compiler build paths and related
 environment variables are ignored for native builds
Message-ID: <1571667673.82.0.434242539711.issue38549@roundup.psfhosted.org>


New submission from Alex Grund <flamefire89 at gmail.com>:

In e.g. Linux users can set CPATH and LIBRARY_PATH to a list of paths considered by e.g. GCC, Clang, ... as if they were passed to `-I`, `-L`

These paths show up in the verbose compiler output too.

However in native builds (not cross-compiling) these variables/directories are ignored which leads to failure of e.g. building the BZip2 extension (among others).

Use case: On HPC modules are used, which means e.g. BZip2 is not installed into a system directory but into some other folder and CPATH, LIBRARY_PATH, LD_LIBRARY_PATH, ... are modified so it can be found by compiler and runtime. However the Python build script does not find it as it ignores those "compiler paths".

This did work ages ago, but was broken when it was decided that compiler paths (output of `gcc -E -v`) is no longer used for native builds and that function was later even renamed: https://github.com/python/cpython/commit/32f5fdd7f4213743fe2f6eedd0fe2108f3157021#diff-2eeaed663bd0d25b7e608891384b7298R514

I propose to rename the function back to its original name and use it always.

----------
components: Build
messages: 355073
nosy: Alex Grund
priority: normal
severity: normal
status: open
title: Compiler build paths and related environment variables are ignored for native builds
type: compile error
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/issue38549>
_______________________________________

From report at bugs.python.org  Mon Oct 21 12:00:04 2019
From: report at bugs.python.org (Mike Gilbert)
Date: Mon, 21 Oct 2019 16:00:04 +0000
Subject: [New-bugs-announce] [issue38550] hashlib missing algorithms
Message-ID: <1571673604.24.0.668685601916.issue38550@roundup.psfhosted.org>


New submission from Mike Gilbert <floppymaster at gmail.com>:

After upgrading to Python 3.7.5, several algorithms are unavailable in the hashlib module.

This seems to have been caused by the "fix" for https://bugs.python.org/issue33936. I will submit a PR with a more appropriate change shortly.

Python 3.7.4:
>>> hashlib.algorithms_available
{'ripemd160', 'blake2s256', 'sha512', 'sha3-224', 'sha3_224', 'blake2s', 'shake_128', 'sha3-384', 'sha3_384', 'whirlpool', 'md4', 'md5', 'sha512-224', 'sha3-512', 'sha1', 'blake2b', 'sha384', 'md5-sha1', 'sha3-256', 'shake_256', 'mdc2', 'sha224', 'blake2b512', 'shake128', 'sm3', 'sha256', 'shake256', 'sha3_512', 'sha512-256', 'sha3_256'}

Python 3.7.5:
>>> hashlib.algorithms_available
{'sha224', 'sha256', 'sha3_224', 'blake2s', 'md5', 'sha3_256', 'sha384', 'sha3_512', 'sha3_384', 'shake_256', 'blake2b', 'sha512', 'shake_128', 'sha1'}

----------
components: Extension Modules
messages: 355080
nosy: floppymaster
priority: normal
severity: normal
status: open
title: hashlib missing algorithms
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Oct 21 14:10:43 2019
From: report at bugs.python.org (Peter Ludemann)
Date: Mon, 21 Oct 2019 18:10:43 +0000
Subject: [New-bugs-announce] [issue38551] lib2to3 Grammar.txt doesn't have
 Python 3.8 grammar changes
Message-ID: <1571681443.98.0.927590549429.issue38551@roundup.psfhosted.org>


New submission from Peter Ludemann <peter.ludemann at gmail.com>:

As far as I can tell, the lib2to3/Grammar.txt file in the Python 3.8 release is the same as that of the Python 3.7 release, which means it doesn't have the "walrus" operator and the "/" parameter syntax.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 355092
nosy: Peter Ludemann
priority: normal
severity: normal
status: open
title: lib2to3 Grammar.txt doesn't have Python 3.8 grammar changes
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 21 14:22:57 2019
From: report at bugs.python.org (William Minchin)
Date: Mon, 21 Oct 2019 18:22:57 +0000
Subject: [New-bugs-announce] [issue38552] Colored Prompt broken in REPL in
 Windows in 3.8
Message-ID: <1571682177.17.0.615459893721.issue38552@roundup.psfhosted.org>


New submission from William Minchin <w_minchin at hotmail.com>:

I have a Python startup file that colorizes my prompt. This worked on Python 3.7, but breaks on Python 3.8. I'm on Windows using Powershell 6.2.3, but `cmd` does the same.

Maybe related, but the colorization also failed on Python 3.7 if a virtual environment was active.

I am using `colorama` to provide the ANSI color codes.

The startup files:

```
import sys
import colorama

colorama.init()

_GREEN = colorama.Fore.GREEN
_YELLOW = colorama.Fore.YELLOW
_RESET = colorama.Style.RESET_ALL

print("setting prompt, {}, {}, {}.".format(_GREEN, _YELLOW, _RESET))
sys.ps1 = "{}>>> {}".format(_GREEN, _RESET)
sys.ps2 = "{}... {}".format(_YELLOW, _RESET)
print()
```

----------
components: Windows
files: python_colored_prompt.png
messages: 355097
nosy: MinchinWeb, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Colored Prompt broken in REPL in Windows in 3.8
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48673/python_colored_prompt.png

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

From report at bugs.python.org  Mon Oct 21 19:53:20 2019
From: report at bugs.python.org (Laurie Opperman)
Date: Mon, 21 Oct 2019 23:53:20 +0000
Subject: [New-bugs-announce] [issue38553] Document functools.cached_property
 supports value updating and clearing
Message-ID: <1571702000.84.0.0143851282892.issue38553@roundup.psfhosted.org>


New submission from Laurie Opperman <laurie_opperman at hotmail.com>:

As I discovered during working on bpo-38545, `functools.cached_property` natively supports cached value setting/updating and clearing (via attribute assignment and deletion, respectively) through mechanisms defined in the language for non-data descriptors:

    class A:
        j = 0
    
        @functools.cached_property
        def b(self):
            self.j += 1
            return self.j

    a = A()
    print(a.b)  # 1
    print(a.b)  # 1
    del a.b
    print(a.b)  # 2
    print(a.b)  # 2
    a.b = 42
    print(a.b)  # 42
    print(a.b)  # 42
    del a.b
    print(a.b)  # 3
    print(a.b)  # 3

I propose that this functionality be documented, for two reasons:
1. To notify developers that this functionality is available, and how to access it
2. To notify developers that this functionality needs to be explicitly disabled. This is important as the built-in `property` is the reverse: property setting and deletion needs to be explicitly implemented

Disabling the value can be achieved by subclassing `functools.cached_property` and overriding/implementing `__set__` and `__delete__` to raise:

    class immutable_cached_property(functools.cached_property):
        def __set__(self, instance, value):
            raise AttributeError("can't set attribute")

        def __delete__(self, instance):
            raise AttributeError("can't delete attribute")

Further reading:
- Defining descriptors: https://docs.python.org/3/reference/datamodel.html#implementing-descriptors
- Descriptor how-to: https://docs.python.org/3/howto/descriptor.html
- Class construction: https://docs.python.org/3/reference/datamodel.html#creating-the-class-object

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 355110
nosy: Epic_Wink, docs at python
priority: normal
severity: normal
status: open
title: Document functools.cached_property supports value updating and clearing
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 21 23:16:04 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 22 Oct 2019 03:16:04 +0000
Subject: [New-bugs-announce] [issue38554] A fatal error in test_descr
Message-ID: <1571714164.19.0.164454938501.issue38554@roundup.psfhosted.org>


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

When running test_descr, I encountered a fatal error!


./python -m test test_descr
0:00:00 load avg: 0.46 Run tests sequentially
0:00:00 load avg: 0.46 [1/1] test_descr
python: Objects/typeobject.c:7318: update_one_slot: Assertion `!PyErr_Occurred()' failed.
Fatal Python error: Aborted

Current thread 0x00007ff22eb72140 (most recent call first):
  File "/home/lubuntu2/cpython/Lib/test/test_descr.py", line 3923 in test_mutable_bases
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 617 in _callTestMethod
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 663 in run
  File "/home/lubuntu2/cpython/Lib/unittest/case.py", line 725 in __call__
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/lubuntu2/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/lubuntu2/cpython/Lib/test/support/testresult.py", line 162 in run
  File "/home/lubuntu2/cpython/Lib/test/support/__init__.py", line 2032 in _run_suite
  File "/home/lubuntu2/cpython/Lib/test/support/__init__.py", line 2128 in run_unittest
  File "/home/lubuntu2/cpython/Lib/test/test_descr.py", line 5643 in test_main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 417 in run_tests_sequential
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 515 in run_tests
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 687 in _main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 634 in main
  File "/home/lubuntu2/cpython/Lib/test/libregrtest/main.py", line 712 in main
  File "/home/lubuntu2/cpython/Lib/test/__main__.py", line 2 in <module>
  File "/home/lubuntu2/cpython/Lib/runpy.py", line 85 in _run_code
  File "/home/lubuntu2/cpython/Lib/runpy.py", line 192 in _run_module_as_main
Aborted (core dumped)

This is because update_all_slots() is called immediately after add_all_subclasses() in type_set_bases(). If an exception occurs in add_all_subclasses() (for example, MemoryError), update_all_slots() will be called with a live exception.

----------
components: Interpreter Core
messages: 355113
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A fatal error in test_descr
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 22 05:31:18 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Oct 2019 09:31:18 +0000
Subject: [New-bugs-announce] [issue38555] Undefined behavior in
 dictreviter_iternext
Message-ID: <1571736678.22.0.114806248729.issue38555@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

&DK_ENTRIES(k)[i] can be evaluated when i is -1. Getting the address before the beginning of the array is an undefined behavior in C.

----------
components: Interpreter Core
messages: 355122
nosy: inada.naoki, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Undefined behavior in dictreviter_iternext
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 22 08:39:25 2019
From: report at bugs.python.org (EGN)
Date: Tue, 22 Oct 2019 12:39:25 +0000
Subject: [New-bugs-announce] [issue38556] Walrus operator in Python 3.8.0 in
 list comprehensions
Message-ID: <1571747965.17.0.120540707485.issue38556@roundup.psfhosted.org>


New submission from EGN <pilatinum at gmail.com>:

Just tried to use Walrus operator in list comprehensions (for loop) and it is not possible.

Is it a bug?

----------
messages: 355124
nosy: EGN
priority: normal
severity: normal
status: open
title: Walrus operator in Python 3.8.0 in list comprehensions
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 22 11:51:00 2019
From: report at bugs.python.org (wim glenn)
Date: Tue, 22 Oct 2019 15:51:00 +0000
Subject: [New-bugs-announce] [issue38557] PyTuple_GetSlice docs minor
 inaccuracy
Message-ID: <1571759460.27.0.105772262724.issue38557@roundup.psfhosted.org>


New submission from wim glenn <wim.glenn at gmail.com>:

https://docs.python.org/3/c-api/tuple.html#c.PyTuple_GetSlice

In the c-api it says (emphasis mine):

    PyObject* PyTuple_GetSlice(PyObject *p, Py_ssize_t low, Py_ssize_t high)?
    Return value: New reference.

    Take a slice of the tuple pointed to by p from low to high and return it **as a new tuple**.

But when slicing the entire tuple, CPython will return already existing instance, not a new tuple.

https://github.com/python/cpython/blob/3.8/Objects/tupleobject.c#L448-L451

I propose the language in the docs be loosened so as not to tie the hands of implementation

----------
assignee: docs at python
components: Documentation
messages: 355141
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: PyTuple_GetSlice docs minor inaccuracy
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/issue38557>
_______________________________________

From report at bugs.python.org  Tue Oct 22 16:27:12 2019
From: report at bugs.python.org (Matt Ward)
Date: Tue, 22 Oct 2019 20:27:12 +0000
Subject: [New-bugs-announce] [issue38558] Data Structures documentation out
 of sync with new Walrus operator
Message-ID: <1571776032.37.0.709698360286.issue38558@roundup.psfhosted.org>


New submission from Matt Ward <matt at matthewward.net>:

The 3.8 documentation still includes the text.

```Note that in Python, unlike C, assignment cannot occur inside expressions. C programmers may grumble about this, but it avoids a common class of problems encountered in C programs: typing = in an expression when == was intended.```

https://docs.python.org/3.8/tutorial/datastructures.html#more-on-conditions

This would seem to no longer be the case with with the inclusion of https://www.python.org/dev/peps/pep-0572/ in 3.8 unless I am misunderstanding the above statement.

----------
assignee: docs at python
components: Documentation
messages: 355151
nosy: Matt Ward, docs at python
priority: normal
severity: normal
status: open
title: Data Structures documentation out of sync with new Walrus operator
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 22 17:48:33 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 22 Oct 2019 21:48:33 +0000
Subject: [New-bugs-announce] [issue38559] async generators aclose() behavior
 in 3.8
Message-ID: <1571780913.57.0.640148082181.issue38559@roundup.psfhosted.org>


New submission from Yury Selivanov <yselivanov at gmail.com>:

I believe I might have discovered a problem with asynchronous generators in 3.8.


# Prelude

In Python prior to 3.8 it was possible to overlap running of "asend()" and "athrow()" methods for the same asynchronous generator.

In plain English, it was possible to await on "agen.asend()" while some other coroutine is already awaiting on "agen.asend()".  That created all kinds of problems with asynchronous generators when people used them to implement channels by trying to push values into the same asynchronous generator from different coroutines.  Regular code that used asynchronous generators in plain and non-sophisticated way did not care.

For classic synchronous generators we have a check for preventing overlapping use of "send()" and "throw()" -- the "gi_running" flag.  If the flag is set, both methods raise a RuntimeError saying that "generator already executing".


# Python 3.8

As was discussed in issues #30773 and #32526 we decided to replicate the same behavior for asynchronous generators, mainly:

* add an "ag_running" flag;

* set "ag_running" when "anext()" or "athrow()" begin to rung, and set it off when they are finished executing;

* if the flag is set when we are about to run "anext()" or "athrow()" it means that another coroutine is reusing the same generator object in parallel and so we raise a RuntimeError.


# Problem

Closing a generator involves throwing a GeneratorExit exception into it.  Throwing the exception is done via calling "throw()" for sync generators, and "athrow()" for async generators.

As shown in https://gist.github.com/1st1/d9860cbf6fe2e5d243e695809aea674c, it's an error to close a synchronous generator while it is being iterated.  This is how async generators *started to behave* in 3.8.

The problem is that asyncio's "loop.shutdown_asyncgens()" method tries to shutdown orphan asynchronous generators by calling "aclose()" on them.  The method is public API and is called by "asyncio.run()" automatically.

Prior to 3.8, calling "aclose()" worked (maybe not in the most clean way). A GeneratorExit was thrown into an asynchronous generator regardless of whether it was running or not, aborting the execution.

In 3.8, calling "aclose()" can crash with a RuntimeError.  It's no longer possible to *reliably cancel* a running asynchrounous generator.


# Dilemma

Replicating the behavior of synchronous generators in asynchronous generators seems like the right thing.  But it seems that the requirements for asynchronous generators are different, and 3.8 breaks backwards compat.


# Proposed Solution

We keep "asend()" and "athrow()" as is in 3.8.  They will continue to raise RuntimeError if used in parallel on the same async generator.

We modify "aclose()" to allow it being called in parallel with "asend()" or "athrow()".  This will restore the <3.8 behavior and fix the "loop.shutdown_asyncgens()" method.


Thoughts?

----------
components: Interpreter Core
messages: 355158
nosy: asvetlov, gvanrossum, lukasz.langa, ncoghlan, njs, yselivanov
priority: normal
severity: normal
status: open
title: async generators aclose() behavior in 3.8
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Oct 22 20:20:42 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 23 Oct 2019 00:20:42 +0000
Subject: [New-bugs-announce] [issue38560] Allow iterable argument unpacking
 after a keyword argument?
Message-ID: <1571790042.34.0.496395652559.issue38560@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

Calls of the form f(name=value, *args) are currently legal syntax. The resulting argument binding is awkward, and almost never does what you want/expect it to:

>>> def f(x, y, z):
...     print(x, y, z)
... 

>>> f(x=0, *(1, 2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() got multiple values for argument 'x'

>>> f(y=0, *(1, 2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() got multiple values for argument 'y'

>>> f(z=0, *(1, 2))
1 2 0

I'm not sure if this is intentional, or an oversight. Every other way of passing positional arguments after keyword arguments results in an error:

f(kwarg=kwarg, arg)  # SyntaxError: positional argument follows keyword argument
f(**kwargs, arg)     # SyntaxError: positional argument follows keyword argument unpacking
f(**kwargs, *args)   # SyntaxError: iterable argument unpacking follows keyword argument unpacking

I think this case should raise a "SyntaxError: iterable argument unpacking follows keyword argument".

I'd like to work on this if we believe it should be changed.

----------
components: Interpreter Core
messages: 355195
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Allow iterable argument unpacking after a keyword argument?
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 22 21:40:48 2019
From: report at bugs.python.org (Samuel Grayson)
Date: Wed, 23 Oct 2019 01:40:48 +0000
Subject: [New-bugs-announce] [issue38561] multiprocessing.Queue fails
 intermittently with "Broken pipe"
Message-ID: <1571794848.94.0.432646449728.issue38561@roundup.psfhosted.org>


New submission from Samuel Grayson <sam.grayson.ubuntu at gmail.com>:

See [this SO post for more details](https://stackoverflow.com/q/51680479/1078199)

----------
components: Library (Lib)
files: test.py
messages: 355204
nosy: Samuel Grayson
priority: normal
severity: normal
status: open
title: multiprocessing.Queue fails intermittently with "Broken pipe"
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48674/test.py

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

From report at bugs.python.org  Wed Oct 23 01:01:21 2019
From: report at bugs.python.org (Ayse)
Date: Wed, 23 Oct 2019 05:01:21 +0000
Subject: [New-bugs-announce] [issue38562] pip install --upgrade git
 submodule update --recursive does not exist
Message-ID: <1571806881.21.0.49403497643.issue38562@roundup.psfhosted.org>


New submission from Ayse <adogan at okstate.edu>:

Hi, 

I was trying to apply a github code, for that I need to get this first:git clone --recursive https://github.com/rbgirshick/py-faster-rcnn.git  but it when I run this it is saying this:
PS C:\Users\Ayse Dogan> python -m pip install --user --upgrade git clone --recursive https://github.com/rbgirshick/py-faste
r-rcnn.git

Usage:
  C:\ProgramData\Anaconda3\python.exe -m pip install [options] <requirement specifier> [package-index-options] ...
  C:\ProgramData\Anaconda3\python.exe -m pip install [options] -r <requirements file> [package-index-options] ...
  C:\ProgramData\Anaconda3\python.exe -m pip install [options] [-e] <vcs project url> ...
  C:\ProgramData\Anaconda3\python.exe -m pip install [options] [-e] <local project path> ...
  C:\ProgramData\Anaconda3\python.exe -m pip install [options] <archive url/path> ...

no such option: --recursive

As I see from Issue35135 this was happening for some other packages. 
Could you please help me about it?

Sincerely, 
Ayse

----------
components: Installation
messages: 355208
nosy: aysedogan, docs at python, pgacv2, xtreak
priority: normal
severity: normal
status: open
title: pip install --upgrade git submodule update --recursive does not exist
versions: Python 3.7

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

From report at bugs.python.org  Wed Oct 23 08:13:28 2019
From: report at bugs.python.org (Carlton Gibson)
Date: Wed, 23 Oct 2019 12:13:28 +0000
Subject: [New-bugs-announce] [issue38563] Asyncio regression on Windows with
 Python 3.8
Message-ID: <1571832808.37.0.827662310876.issue38563@roundup.psfhosted.org>


New submission from Carlton Gibson <carlton.gibson at noumenal.es>:

6ea29c5e90dde6c240bd8e0815614b52ac307ea1 for 
https://bugs.python.org/issue34687

"Make asynico use ProactorEventLoop by default"

This introducesd a regression in asgiref, and hence Django 3.0.x. 


https://github.com/django/asgiref/issues/132
https://code.djangoproject.com/ticket/30900


The error from the asgiref issue is clearest: 

```
asgiref\sync.py:97: in __call__
    loop_future.result()
..\..\..\AppData\Local\Programs\Python\Python38\lib\concurrent\futures\_base.py:432: in result
    return self.__get_result()
..\..\..\AppData\Local\Programs\Python\Python38\lib\concurrent\futures\_base.py:388: in __get_result
    raise self._exception
..\..\..\AppData\Local\Programs\Python\Python38\lib\concurrent\futures\thread.py:57: in run
    result = self.fn(*self.args, **self.kwargs)
asgiref\sync.py:130: in _run_event_loop
    loop.close()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  

self = <ProactorEventLoop running=False closed=False debug=False>

    def close(self):
        if self.is_running():
            raise RuntimeError("Cannot close a running event loop")
        if self.is_closed():
            return
    
>       signal.set_wakeup_fd(-1)
E       ValueError: set_wakeup_fd only works in main thread
```

Off the main thread, we use a ThreadPoolExecutor and wait for the future to finish. 

It looks as if `ProactorEventLoop` needs to check the current thread before triggering the signal in close().

----------
components: asyncio
messages: 355214
nosy: asvetlov, carltongibson, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio regression on Windows with Python 3.8
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 23 10:44:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Oct 2019 14:44:20 +0000
Subject: [New-bugs-announce] [issue38564] test_asyncio:
 test_run_coroutine_threadsafe_with_timeout()
Message-ID: <1571841860.24.0.514293762677.issue38564@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 FreeBSD Shared 3.x:
https://buildbot.python.org/all/#/builders/371/builds/7

This buildbot worker is known to be very slow.

test_run_coroutine_threadsafe_with_timeout (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
Test coroutine submission from a thread to an event loop ... FAIL

FAIL: test_run_coroutine_threadsafe_with_timeout (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
Test coroutine submission from a thread to an event loop
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_asyncio/test_tasks.py", line 3210, in test_run_coroutine_threadsafe_with_timeout
    self.loop.run_until_complete(future)
AssertionError: TimeoutError not raised

----------
components: Tests
messages: 355223
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_run_coroutine_threadsafe_with_timeout()
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 23 10:50:54 2019
From: report at bugs.python.org (Scott Sanderson)
Date: Wed, 23 Oct 2019 14:50:54 +0000
Subject: [New-bugs-announce] [issue38565] Expose the value passed of typed
 passed to functools.lru_cache
Message-ID: <1571842254.4.0.33528560442.issue38565@roundup.psfhosted.org>


New submission from Scott Sanderson <scoutoss at gmail.com>:

In some circumstances, it's useful to be able in inspect the parameters with which an instance of functools.lru_cache was instantiated. It's currently possible to recover the cache's maxsize via the .cache_info() method, but there's no way to recover the value passed for `typed`, which controls whether the lru_cache's cache is partitioned by input type.

This came up in the context of cloudpickle, a library that tries to extend pickle to support more types (in particular, interactively-defined functions and classes) for use-cases like cluster computing. 

It's currently not possible to pickle an lru-cache decorated function that's defined in __main__ (which includes, e.g. a Jupyter Notebook). We can **almost** fix this with a pure library solution (see https://github.com/cloudpipe/cloudpickle/pull/309), but we're currently blocked by the fact that there's no way to recover the value that was passed for `typed`. Exposing a .typed attribute on the extension type for lru_cached functions fixes this

For more discussion, see the above linked PR, along with https://github.com/cloudpipe/cloudpickle/issues/178.

----------
components: Library (Lib)
messages: 355226
nosy: Scott Sanderson2
priority: normal
severity: normal
status: open
title: Expose the value passed of typed passed to functools.lru_cache
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 23 12:28:38 2019
From: report at bugs.python.org (James Gerity)
Date: Wed, 23 Oct 2019 16:28:38 +0000
Subject: [New-bugs-announce] [issue38566] Description of '\w' behavior is
 vague in `re` documentation
Message-ID: <1571848118.32.0.881781017255.issue38566@roundup.psfhosted.org>


New submission from James Gerity <snoopjedi at gmail.com>:

The documentation for the `re` library? describes the behavior of the specifier '\w' as matching "Unicode word characters," which is very vague. The closest thing I can find that corresponds to this language is the guidance offered in Unicode Technical Standard #18?, which defines the class `<word_character>` to include all alphabetic and decimal codepoints, as well as U+200C ZERO WIDTH NON-JOINER and U+200D ZERO WIDTH JOINER. This does not appear to be a correct description of `re`, however, as these zero-width characters are not counted when matching '\w', e.g.:

```
>>> re.match('\w*', 'Auf\u200Clage')
<re.Match object; span=(0, 3), match='Auf'>
```

It seems from examining the CPython source? that SRE treats '\w' as meaning any alphanumeric character OR U+005F SPACING UNDERSCORE, which does not match any Unicode class definition I've been able to find.

Can anyone provide clarification on what part of Unicode this documentation is referring to? If there is some other definition, the documentation should be more specific about referring to it (and including a link would be preferred). If instead the documentation is incorrect, this language should be changed to describe the true meaning of \w.

? https://docs.python.org/3/library/re.html#index-32
? http://unicode.org/reports/tr18/
? https://github.com/python/cpython/blob/master/Modules/_sre.c#L125

----------
assignee: docs at python
components: Documentation
messages: 355239
nosy: docs at python, snoopjedi
priority: normal
severity: normal
status: open
title: Description of '\w' behavior is vague in `re` documentation

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

From report at bugs.python.org  Wed Oct 23 13:45:50 2019
From: report at bugs.python.org (stein-k)
Date: Wed, 23 Oct 2019 17:45:50 +0000
Subject: [New-bugs-announce] [issue38567] urllib.parse.unquote_plus raises
 incorrect errormessage when string parameter is bytes
Message-ID: <1571852750.66.0.0310766347617.issue38567@roundup.psfhosted.org>


New submission from stein-k <karlsen.stein at gmail.com>:

urllib.parse.unquote_plus(b'abc%20def')
...
TypeError: a bytes-like object is required, not 'str'

----------
components: Library (Lib)
messages: 355242
nosy: stein-k
priority: normal
severity: normal
status: open
title: urllib.parse.unquote_plus raises incorrect errormessage when string parameter is bytes
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 23 15:09:14 2019
From: report at bugs.python.org (Ying Wang)
Date: Wed, 23 Oct 2019 19:09:14 +0000
Subject: [New-bugs-announce] [issue38568] [3.7.5 x86_64 Linux] f-string
 parsing results in EOL
Message-ID: <1571857754.85.0.698050163763.issue38568@roundup.psfhosted.org>


New submission from Ying Wang <yingw787.personal at gmail.com>:

Hey,

I encountered an interesting bug when trying to do string parsing using f-strings. I am currently under the impression that within the curly braces is any expression that can be successfully evaluated in a REPL. Here's the error:

```bash
yingw787 at yingw787-Oryx-Pro:~/src/gpudb-dev-v6.2.0/kio/kio/tests/regression/_data/csv$ python
Python 3.7.5 (default, Oct 15 2019, 21:38:37) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> blah = '"hi"'
>>> blah
'"hi"'
>>> f'{blah.strip('"')}'
  File "<stdin>", line 1
    f'{blah.strip('"')}'
                       ^
SyntaxError: EOL while scanning string literal
>>> '{0}'.format(blah.strip('"'))
'hi'
>>> 
```

I can use '.format()' for now, but it might be nice to align f-string expr behavior w/ .format(). Please let me know if you need more reproduction steps, or if you need a helping hand :)

Thanks
Ying

----------
components: Interpreter Core
messages: 355254
nosy: yingw787
priority: normal
severity: normal
status: open
title: [3.7.5 x86_64 Linux] f-string parsing results in EOL
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Oct 23 15:57:45 2019
From: report at bugs.python.org (Marco Sulla)
Date: Wed, 23 Oct 2019 19:57:45 +0000
Subject: [New-bugs-announce] [issue38569] Unknown distribution option:
 'license_files'
Message-ID: <1571860665.03.0.77407877223.issue38569@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

I tried to add to `setuptools.setup()` the argument license_files. It works, but I get this warning:

/usr/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution option: 'license_files'

I suppose the warning can be removed.

----------
components: Distutils
messages: 355262
nosy: Marco Sulla, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Unknown distribution option: 'license_files'
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 23 17:00:28 2019
From: report at bugs.python.org (timonegk)
Date: Wed, 23 Oct 2019 21:00:28 +0000
Subject: [New-bugs-announce] [issue38570] Shlex does not parse commands
 containing single quotes correctly
Message-ID: <1571864428.26.0.327920266668.issue38570@roundup.psfhosted.org>


New submission from timonegk <python at timonengelke.de>:

Steps to reproduce:
>>> from shlex import split
>>> line = "export F=$'\\''"
>>> split(line)
ValueError: No closing quotation

However, when printing the line

>>> print(line)
export F=$'\''

and pasting the output in bash, no further quotation marks are required.
The behavior of bash is described in its man page (line 497 for me, Chapter Quoting) and occurs also when bash is called with --posix. Therefore I guess that shlex does not reproduce the posix behavior here.

----------
components: Library (Lib)
messages: 355265
nosy: timonegk
priority: normal
severity: normal
status: open
title: Shlex does not parse commands containing single quotes correctly
type: behavior
versions: Python 2.7, Python 3.7

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

From report at bugs.python.org  Wed Oct 23 21:50:19 2019
From: report at bugs.python.org (Kevin Chen)
Date: Thu, 24 Oct 2019 01:50:19 +0000
Subject: [New-bugs-announce] [issue38571] Segfault with StopIteration
Message-ID: <1571881819.52.0.556347570713.issue38571@roundup.psfhosted.org>


New submission from Kevin Chen <kchen at mit.edu>:

Unfortunately, I don't currently have a simple test case, but after migrating an app from python 3.6 to python 3.7, python frequently (but not always) segfaults when running tests for my app in code related to StopIteration (perhaps somehow related to the implementation of PEP 479?).

I'm running a self-built (from python.org sources) unpatched build of Python 3.7.5 on Ubuntu Xenial.

(The output below is edited to redact some path names.)

Core was generated by `./python'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000044cc40 in PyException_GetContext (self=self at entry=0x441cbe0)
    at Objects/exceptions.c:338
338	    Py_XINCREF(context);

(gdb) py-bt
Traceback (most recent call first):
  File "lib/requests/models.py", line 750, in generate
    for chunk in self.raw.stream(chunk_size, decode_content=True):
  File "lib/requests/models.py", line 828, in content
    self._content = b''.join(self.iter_content(CONTENT_CHUNK_SIZE)) or b''
  File "lib/requests/sessions.py", line 686, in send
    r.content
  File "lib/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "lib/requests/sessions.py", line 546, in get
    return self.request('GET', url, **kwargs)
[trace continues with other files specific to my app]

(gdb) bt
#0  0x000000000044cc40 in PyException_GetContext (
    self=self at entry=<unknown at remote 0x441cbe0>) at Objects/exceptions.c:338
#1  0x000000000050b76d in PyErr_SetObject (
    exception=<type at remote 0x8b7c00>, value=StopIteration())
    at Python/errors.c:126
#2  0x000000000050ba17 in PyErr_SetNone (exception=<optimized out>)
    at Python/errors.c:163
#3  0x00000000005d254d in gen_send_ex (gen=0x4351b00, arg=<optimized out>, 
    exc=<optimized out>, closing=<optimized out>) at Objects/genobject.c:241
#4  0x0000000000429406 in _PyEval_EvalFrameDefault (f=<optimized out>, 
    throwflag=<optimized out>) at Python/ceval.c:2809
#5  0x00000000005d20cb in gen_send_ex (gen=0x457c1b0, arg=<optimized out>, 
    exc=<optimized out>, closing=<optimized out>) at Objects/genobject.c:221
#6  0x0000000000459679 in list_extend (self=self at entry=0x445a590, 
    iterable=iterable at entry=<generator at remote 0x457c1b0>)
    at Objects/listobject.c:897
#7  0x000000000045de55 in _PyList_Extend (self=self at entry=0x445a590, 
    iterable=iterable at entry=<generator at remote 0x457c1b0>)
    at Objects/listobject.c:937
#8  0x00000000005b76fc in PySequence_List (
    v=v at entry=<generator at remote 0x457c1b0>) at Objects/abstract.c:1905
#9  0x00000000005b867d in PySequence_Fast (v=<optimized out>, 
    m=m at entry=0x603715 "can only join an iterable") at Objects/abstract.c:1935
#10 0x0000000000438e02 in stringlib_bytes_join (sep=b'', 
    iterable=<optimized out>) at Objects/stringlib/join.h:22
#11 0x0000000000445b53 in _PyMethodDef_RawFastCallKeywords (
    method=0x8b0cc0 <bytes_methods+608>, self=self at entry=b'', 
    args=args at entry=0x4322f20, nargs=nargs at entry=1, kwnames=kwnames at entry=0x0)
    at Objects/call.c:648
#12 0x00000000005cfabf in _PyMethodDescr_FastCallKeywords (
    descrobj=<method_descriptor at remote 0x16f99f0>, 
    args=args at entry=0x4322f18, nargs=nargs at entry=2, kwnames=kwnames at entry=0x0)
    at Objects/descrobject.c:288
#13 0x000000000042df85 in call_function (kwnames=0x0, oparg=2, 
    pp_stack=<synthetic pointer>) at Python/ceval.c:4593
#14 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>)
    at Python/ceval.c:3110
#15 0x00000000004211c5 in function_code_fastcall (co=co at entry=0x3597c30, 
    args=<optimized out>, args at entry=0x3ce1f08, nargs=nargs at entry=1, 
    globals=globals at entry={'__name__': 'requests.models', '__doc__': '\nrequests.models\n~~~~~~~~~~~~~~~\n\nThis module contains the primary objects that power Requests.\n', '__package__': 'requests', '__loader__': <SourceFileLoader(name='requests.models', path='lib/requests/models.py') at remote 0x357cf70>, '__spec__': <ModuleSpec(name='requests.models', loader=<...>, origin='lib/requests/models.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='lib/requests/__pycache__/models.cpython-37.pyc', _initializing=False) at remote 0x354cd70>, '__file__': 'lib/requests/models.py', '__cached__': 'lib/requests/__pycache__/models.cpython-37.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: N...(truncated)) at Objects/call.c:283
#16 0x0000000000445180 in _PyFunction_FastCallDict (
    func=<function at remote 0x35b41c0>, args=0x3ce1f08, nargs=1, kwargs=0x0)
    at Objects/call.c:322
[remainder of trace redacted]

Sometimes the C backtrace is slightly different, but very similar:

Core was generated by `./python'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  PyErr_SetObject (exception=0x8b7c00 <_PyExc_StopIteration>, value=0x0)
    at Python/errors.c:101
101	        Py_INCREF(exc_value);

(gdb) bt
#0  PyErr_SetObject (exception=<type at remote 0x8b7c00>, value=0x0)
    at Python/errors.c:101
#1  0x000000000050ba17 in PyErr_SetNone (exception=<optimized out>)
    at Python/errors.c:163
#2  0x00000000005d254d in gen_send_ex (gen=0x3c71b10, arg=<optimized out>, 
    exc=<optimized out>, closing=<optimized out>) at Objects/genobject.c:241
[rest of trace not listed, since it appears to be the same as the previous one]

When running my app's tests, I've also seen one occurrence (possibly related to these crashes) when Python aborted because a reference count was -6.

----------
components: Interpreter Core
messages: 355274
nosy: kchen
priority: normal
severity: normal
status: open
title: Segfault with StopIteration
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct 24 02:55:32 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 24 Oct 2019 06:55:32 +0000
Subject: [New-bugs-announce] [issue38572] Misleading AttributeError
 accessing fileno attribute in tarfile
Message-ID: <1571900132.35.0.991486656774.issue38572@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

This came up during https://github.com/psf/requests/issues/5229 . While fileno returns True as an attribute the actual implementation uses self.raw.fileno where the AttributeError is raised at https://github.com/python/cpython/blob/96b06aefe23521b61e4e9cdd44f5d30b00c7eb95/Lib/_pyio.py#L878 (Python implementation) . I guess it should be raising UnsupportedOperation when self.raw has no fileno so that the callers only need to catch UnsupportedOperation. Something like below for fileno implementation that will give a better exception.

   def fileno(self):
        if hasattr(self.raw, 'fileno'):
            return self.raw.fileno()
        else:
            self._unsupported("fileno")

# tarfile_fileno.py

import tarfile
import os

for f in ["foo.txt", "foo.tar"]:
    try:
        os.unlink(f)
    except OSError:
        pass

with open("foo.txt", "w") as f:
    f.write("foo.txt")
    with tarfile.open("foo.tar", "w:gz") as tarfile_obj:
        tarfile_obj.add(f.name)

with tarfile.open("foo.tar", "r:gz") as f:
    member = f.extractfile("foo.txt")
    print(f"Has attr : {hasattr(member, 'fileno')}")
    print(member.fileno())

# Current exception

python.exe .\tarfile_fileno.py
Has attr : True
Traceback (most recent call last):
  File ".\tarfile_fileno.py", line 18, in <module>
    print(member.fileno())
AttributeError: '_FileInFile' object has no attribute 'fileno'

# Proposed exception (Patching tarfile to use _pyio and modifying fileno as above) 

python.exe .\tarfile_fileno.py
Has attr : True
Traceback (most recent call last):
  File ".\tarfile_fileno.py", line 11, in <module>
    print(member.fileno())
  File "C:\Users\kasingar\AppData\Local\Programs\Python\Python37-32\lib\_pyio.py", line 831, in fileno
    self._unsupported("fileno")
  File "C:\Users\kasingar\AppData\Local\Programs\Python\Python37-32\lib\_pyio.py", line 320, in _unsupported
    (self.__class__.__name__, name))
io.UnsupportedOperation: ExFileObject.fileno() not supported

----------
components: Library (Lib)
messages: 355283
nosy: lars.gustaebel, serhiy.storchaka, xtreak
priority: normal
severity: normal
status: open
title: Misleading AttributeError accessing fileno attribute in tarfile
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 24 03:29:59 2019
From: report at bugs.python.org (Yevgeny Pats)
Date: Thu, 24 Oct 2019 07:29:59 +0000
Subject: [New-bugs-announce] [issue38573] Not Implemented Error in stdLib
 HTMLParser
Message-ID: <1571902199.4.0.291984198853.issue38573@roundup.psfhosted.org>


New submission from Yevgeny Pats <yev.pats at gmail.com>:

Not implemented error in built-in HTMLParser

from html.parser import HTMLParser
parser = HTMLParser()
parser.feed(bytearray.fromhex('3c215b63612121').decode('ascii'))

# This will throw (found by https://github.com/fuzzitdev/pythonfuzz):
Traceback (most recent call last):
  File "/Users/yevgenyp/fuzzitdev/pythonfuzz/pythonfuzz/fuzzer.py", line 21, in worker
    target(buf)
  File "examples/htmlparser/fuzz.py", line 12, in fuzz
    pass
  File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 111, in feed
    self.goahead(0)
  File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 179, in goahead
    k = self.parse_html_declaration(i)
  File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 264, in parse_html_declaration
    return self.parse_marked_section(i)
  File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/_markupbase.py", line 159, in parse_marked_section
    self.error('unknown status keyword %r in marked section' % rawdata[i+3:j])
  File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/_markupbase.py", line 34, in error
    "subclasses of ParserBase must override error()")
NotImplementedError: subclasses of ParserBase must override error()

----------
components: Library (Lib)
messages: 355287
nosy: yevgenyp
priority: normal
severity: normal
status: open
title: Not Implemented Error in stdLib HTMLParser
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct 24 03:34:34 2019
From: report at bugs.python.org (Leon Matthews)
Date: Thu, 24 Oct 2019 07:34:34 +0000
Subject: [New-bugs-announce] [issue38574] Dataclasses documentation should
 show the necessary imports
Message-ID: <1571902474.91.0.395635401957.issue38574@roundup.psfhosted.org>


New submission from Leon Matthews <leon.matthews at gmail.com>:

In the code sample documentation for other modules we show the necessary imports, we should do the same for dataclasses.

For example, the very first example uses the `dataclass` decorator without importing it first. It should read::

    from dataclasses import dataclass

    @dataclass
    class InventoryItem:
        ...

----------
assignee: docs at python
components: Documentation
messages: 355289
nosy: Leon Matthews, docs at python
priority: normal
severity: normal
status: open
title: Dataclasses documentation should show the necessary imports
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 24 03:38:39 2019
From: report at bugs.python.org (Zhipeng Xie)
Date: Thu, 24 Oct 2019 07:38:39 +0000
Subject: [New-bugs-announce] [issue38575] Child process deadlock in
 subprocess.Popen
Message-ID: <1571902719.3.0.191965904237.issue38575@roundup.psfhosted.org>


New submission from Zhipeng Xie <775350901 at qq.com>:

Hi, we had a child process deadlock on _disabling_gc_lock in subprocess.Popen. It seems that after https://github.com/python/cpython/commit/5e8e371364ee58dadb9a4e4e51c7e9cf6bedbfae, subprocess.Popen no longer support to be called in preexec_fn.

Steps to reproduce:
[root at localhost ~]# python2 --version
Python 2.7.15
[root at localhost ~]# python2 mtfork.py 

wait for a while and the child process deadlock

Here is the gdb stack:

(gdb) py-bt
Traceback (most recent call first):
  Waiting for the GIL
  File "/usr/local/lib/python2.7/subprocess.py", line 931, in _execute_child
    with self._disabling_gc_lock:
  File "/usr/local/lib/python2.7/subprocess.py", line 394, in __init__
    errread, errwrite)
  File "mtfork.py", line 36, in run_cmd
    stderr=subprocess.PIPE)
  File "/usr/local/lib/python2.7/subprocess.py", line 989, in _execute_child
    preexec_fn()
  File "/usr/local/lib/python2.7/subprocess.py", line 394, in __init__
    errread, errwrite)
  File "mtfork.py", line 15, in run_command
    stdout=arg_stdout, stderr=arg_stderr, shell=True)
  File "mtfork.py", line 51, in _readerthread3
    status = run_command("/root/exe",preexec_fn=preexec_fn_no_args)
  File "/usr/local/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/local/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/local/lib/python2.7/threading.py", line 774, in __bootstrap
    self.__bootstrap_inner()
(gdb) py-list
 926                # The first char specifies the exception type: 0 means
 927                # OSError, 1 means some other error.
 928                errpipe_read, errpipe_write = self.pipe_cloexec()
 929                try:
 930                    try:
>931                        with self._disabling_gc_lock:
 932                            gc_was_enabled = gc.isenabled()
 933                            # Disable gc to avoid bug where gc -> file_dealloc ->
 934                            # write to stderr -> hang.
 935                            # https://bugs.python.org/issue1336
 936                            gc.disable()

----------
components: Library (Lib)
files: mtfork.py
messages: 355290
nosy: Zhipeng Xie
priority: normal
severity: normal
status: open
title: Child process deadlock in subprocess.Popen
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file48675/mtfork.py

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

From report at bugs.python.org  Thu Oct 24 03:51:18 2019
From: report at bugs.python.org (Riccardo Schirone)
Date: Thu, 24 Oct 2019 07:51:18 +0000
Subject: [New-bugs-announce] [issue38576] CVE-2019-18348 CRLF injection via
 the host part of the url passed to urlopen()
Message-ID: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>


New submission from Riccardo Schirone <rschiron at redhat.com>:

Copy-pasted from https://bugs.python.org/issue30458#msg347282

================
The commit b7378d77289c911ca6a0c0afaf513879002df7d5 is incomplete: it doesn't seem to check for control characters in the "host" part of the URL, only in the "path" part of the URL. Example:
---
try:
    from urllib import request as urllib_request
except ImportError:
    import urllib2 as urllib_request
import socket
def bug(*args):
    raise Exception(args)
# urlopen() must not call create_connection()
socket.create_connection = bug
urllib_request.urlopen('http://127.0.0.1\r\n\x20hihi\r\n :11211')
---

The URL comes from the first message of this issue:
https://bugs.python.org/issue30458#msg294360

Development branches 2.7 and master produce a similar output:
---
Traceback (most recent call last):
 ...
Exception: (('127.0.0.1\r\n hihi\r\n ', 11211), ..., None)
---

So urllib2/urllib.request actually does a real network connection (DNS query), whereas it should reject control characters in the "host" part of the URL.

***

A second problem comes into the game. Some C libraries like glibc strip the end of the hostname (strip at the first newline character) and so HTTP Header injection is still possible is this case:
https://bugzilla.redhat.com/show_bug.cgi?id=1673465

***

According to the RFC 3986, the "host" grammar doesn't allow any control character, it looks like:

   host          = IP-literal / IPv4address / reg-name

   ALPHA (letters)
   DIGIT (decimal digits)
   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
      pct-encoded = "%" HEXDIG HEXDIG
      sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="
   reg-name      = *( unreserved / pct-encoded / sub-delims )

   IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"
   IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
   IPv6address   =                            6( h16 ":" ) ls32
                 /                       "::" 5( h16 ":" ) ls32
                 / [               h16 ] "::" 4( h16 ":" ) ls32
                 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                 / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                 / [ *4( h16 ":" ) h16 ] "::"              ls32
                 / [ *5( h16 ":" ) h16 ] "::"              h16
                 / [ *6( h16 ":" ) h16 ] "::"
   h16           = 1*4HEXDIG
   ls32          = ( h16 ":" h16 ) / IPv4address
   IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet
================


CVE-2019-18348 was assigned to this flaw, which is similar to CVE-2019-9947 and CVE-2019-9740 but it is about the *host* part of a url.

----------
messages: 355294
nosy: rschiron
priority: normal
severity: normal
status: open
title: CVE-2019-18348 CRLF injection via the host part of the url passed to urlopen()
type: security

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

From report at bugs.python.org  Thu Oct 24 04:20:16 2019
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Pollex?=)
Date: Thu, 24 Oct 2019 08:20:16 +0000
Subject: [New-bugs-announce] [issue38577] OPENSSL_* flags not propagated to
 extensions during build
Message-ID: <1571905216.83.0.0723614632287.issue38577@roundup.psfhosted.org>


New submission from Bj?rn Pollex <bjoern.pollex at soundcloud.com>:

When building Python 3.7.2 using pyenv on MacOS, it will use `--with-openssl` to configure OpenSSL. With that option, the compiler options for OpenSSL will be passed via `OPENSSL_*` variables, rather than normal compiler flags (e.g. `OPENSSL_LDFLAGS` vs. `LDFLAGS`). When compiling an extension, these flags will not be propagated by `distutils`, and so an extension that depends on OpenSSL fails to compile.

I'm not sure what the expected behavior here is. Should the package handle this by querying `sysconfig` directly in `setup.py`? Or should this be handled automatically by `distutils`?

Specifically, I ran into this issue when trying to install `mysqlclient-python` (https://github.com/PyMySQL/mysqlclient-python).

----------
messages: 355299
nosy: Bj?rn Pollex
priority: normal
severity: normal
status: open
title: OPENSSL_* flags not propagated to extensions during build
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct 24 05:14:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Oct 2019 09:14:34 +0000
Subject: [New-bugs-announce] [issue38578] test_concurrent_futures failed on
 AMD64 FreeBSD Shared 3.8
Message-ID: <1571908474.05.0.296505367308.issue38578@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

On AMD64 FreeBSD Shared 3.8 which is know to be very slow, different test_concurrent_futures tests failed.

https://buildbot.python.org/all/#builders/374/builds/3

test_concurrent_futures was run twice. Once in parallel of other tests, then alone in sequence.


The first run emitted two "threading_cleanup() failed" warnings and test_idle_thread_reuse() failed:

test_idle_thread_reuse (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 1.05s Warning -- threading_cleanup() failed to cleanup 2 threads (count: 2, dangling: 3)
test_map (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 3.80s Warning -- threading_cleanup() failed to cleanup -2 threads (count: 0, dangling: 1)

FAIL: test_idle_thread_reuse (test.test_concurrent_futures.ThreadPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
? File "/usr/home/buildbot/python/3.8.koobs-freebsd-564d/build/Lib/test/test_concurrent_futures.py", line 782, in test_idle_thread_reuse
? ? self.assertEqual(len(executor._threads), 1)
AssertionError: 2 != 1

At the second run, test_free_reference() failed:

1:15:08 load avg: 9.24 Re-running test_concurrent_futures in verbose mode

FAIL: test_free_reference (test.test_concurrent_futures.ThreadPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
? File "/usr/home/buildbot/python/3.8.koobs-freebsd-564d/build/Lib/test/test_concurrent_futures.py", line 745, in test_free_reference
? ? self.assertIsNone(wr())
AssertionError: <test.test_concurrent_futures.MyObject object at 0x8031cc780> is not None

----------
components: Tests
messages: 355308
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_concurrent_futures failed on AMD64 FreeBSD Shared 3.8
versions: Python 3.8

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

From report at bugs.python.org  Thu Oct 24 06:31:24 2019
From: report at bugs.python.org (Dan Snider)
Date: Thu, 24 Oct 2019 10:31:24 +0000
Subject: [New-bugs-announce] [issue38579] 'u' formatted arrays mostly
 prevent appends of 4 byte characters
Message-ID: <1571913084.38.0.724512448926.issue38579@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

Unicode characters with code points above u+ffff can only be added to the end of an array, and only from a call to the "fromunicode" method. This is because "fromunicode" uses a different procedure to modify the array compared to __new__, __setitem__, append, and extend array methods, all of which eventually call u_setitem routine, which calls PyArg_Parse with a format spec of "u#". The error occurs in that call, from what at first glance appears to be an incorrect length determination for unicode objects of the 4 byte kind.

----------
components: Library (Lib)
messages: 355319
nosy: bup
priority: normal
severity: normal
status: open
title: 'u' formatted arrays mostly prevent appends of 4 byte characters
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Oct 24 07:08:46 2019
From: report at bugs.python.org (Jakub Stasiak)
Date: Thu, 24 Oct 2019 11:08:46 +0000
Subject: [New-bugs-announce] [issue38580] select()'s documentation claims
 only sequences are accepted, but it allows all iterables
Message-ID: <1571915326.93.0.150606644361.issue38580@roundup.psfhosted.org>


New submission from Jakub Stasiak <jakub+python.org at stasiak.at>:

Excerpt from the documentation:

"""This is a straightforward interface to the Unix select() system call. The first three arguments are sequences of ?waitable objects?: either integers representing file descriptors or objects with a parameterless method named fileno() returning such an integer:"""

In reality it accepts for example dictionary key views (that's how I discovered it) due to its internal usage of PySequence_Fast, which (from https://docs.python.org/3/c-api/sequence.html#c.PySequence_Fast):

"""Return the sequence or iterable o as an object usable by the other PySequence_Fast* family of functions. If the object is not a sequence or iterable, raises TypeError with m as the message text. Returns NULL on failure."""

I made a pull request to document this behavior in select (https://github.com/python/cpython/pull/16832) but it was recommended that I create this issue because the solution may not be obvious here.

----------
components: Library (Lib)
messages: 355325
nosy: corona10, jstasiak
priority: normal
pull_requests: 16447
severity: normal
status: open
title: select()'s documentation claims only sequences are accepted, but it allows all iterables
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/issue38580>
_______________________________________

From report at bugs.python.org  Thu Oct 24 07:20:13 2019
From: report at bugs.python.org (Lealinux)
Date: Thu, 24 Oct 2019 11:20:13 +0000
Subject: [New-bugs-announce] [issue38581] Crash on distutils/util.py when
 header variable isn't a string
Message-ID: <1571916013.0.0.277609072879.issue38581@roundup.psfhosted.org>


New submission from Lealinux <bureau at lea-linux.org>:

Hello,

With some pip3 package, distutils could crash if variable "header" isn't a real string variable :

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

$ pip3 install bzr
Collecting bzr
  Using cached https://files.pythonhosted.org/packages/62/3a/81325e34bcc78f67cc33dfac64f44e7c8329d4481dec1b789267b98644c3/bzr-2.7.0.tar.gz
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: running egg_info
    creating pip-egg-info/bzr.egg-info
    writing pip-egg-info/bzr.egg-info/PKG-INFO
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "pip-install/bzr/setup.py", line 781, in <module>
        setup(**ARGS)
      File "distutils/core.py", line 148, in setup
        dist.run_commands()
      File "distutils/dist.py", line 966, in run_commands
        self.run_command(cmd)
      File "distutils/dist.py", line 985, in run_command
        cmd_obj.run()
      File "setuptools/command/egg_info.py", line 289, in run
        writer(self, ep.name, os.path.join(self.egg_info, ep.name))
      File "setuptools/command/egg_info.py", line 621, in write_pkg_info
        metadata.write_pkg_info(cmd.egg_info)
      File "distutils/dist.py", line 1117, in write_pkg_info
        self.write_pkg_file(pkg_info)
      File "setuptools/dist.py", line 165, in write_pkg_file
        long_desc = rfc822_escape(self.get_long_description())
      File "distutils/util.py", line 470, in rfc822_escape
        lines = header.split('\n')
    TypeError: a bytes-like object is required, not 'str'

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

On this case (bzr), "header" is a bytes-like object.

On attachment, a patch proposal to have a (possible) solution


PS: newbie on python-core-patching and python-bug-report, sorry if we have missed something

----------
components: Library (Lib)
files: distutils_rfc822_escape.patch
keywords: patch
messages: 355326
nosy: Lealinux
priority: normal
severity: normal
status: open
title: Crash on distutils/util.py when header variable isn't a string
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file48676/distutils_rfc822_escape.patch

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

From report at bugs.python.org  Thu Oct 24 08:01:00 2019
From: report at bugs.python.org (veaba)
Date: Thu, 24 Oct 2019 12:01:00 +0000
Subject: [New-bugs-announce] [issue38582] Regular match overflow
Message-ID: <1571918460.23.0.951384683462.issue38582@roundup.psfhosted.org>


New submission from veaba <908662421 at qq.com>:

Regular match overflow
code:
```python
import re
# list => str
def list_to_str(str_list, code=""):
    if isinstance(str_list, list):
        return code.join(str_list)
    else:
        return ''
def fn_parse_code(list_str, text):
    code_text_str=''
    code_text_str = list_to_str(list_str, '|')  # => xxx|oo
    reg_list = ['+', '.', '[', ']','((','))']
    for reg in reg_list:
        code_text_str_temp = code_text_str.replace(reg, "\\" + reg).replace('((','(\\(').replace('))','))')
        code_text_str=code_text_str_temp

    # compile
    pattern_str = re.compile(code_text_str )

    #list_str=>\\1\\2\\...

    flag_str = ''

    for item in enumerate(list_str):
        flag_str = flag_str + "\\" + str(item[0] + 1)

    print("1:",pattern_str)
    print("2:",flag_str)
    print("3:",text)
    reg_text = re.sub(r''+code_text_str+'', "`" + flag_str + "`", text)
    return reg_text

# a list
strs=['(tf.batch_gather)', '(None)', '(tf.bitwise.bitwise_and)', '(None)', '(tf.bitwise.bitwise_or)', '(None)', '(tf.bitwise.bitwise_xor)', '(None)', '(tf.bitwise.invert)', '(None)', '(tf.bitwise.left_shift)', '(None)', '(tf.bitwise.right_shift)', '(None)', '(tf.clip_by_value)', '(None)', '(tf.concat)', "('concat')", '(tf.debugging.check_numerics)', '(None)', '(tf.dtypes.cast)', '(None)', '(tf.dtypes.complex)', '(None)', '(tf.dtypes.saturate_cast)', '(None)', '(tf.dynamic_partition)', '(None)', '(tf.expand_dims)', '(None)', '(None)', '(None)', '(tf.gather_nd)', '(None)', '(0)', '(tf.gather)', '(None)', '(None)', '(None)', '(0)', '(tf.identity)', '(None)', '(tf.io.decode_base64)', '(None)', '(tf.io.decode_compressed)', "('')", '(None)', '(tf.io.encode_base64)', '(False)', '(None)', '(tf.math.abs)', '(None)', '(tf.math.acos)', '(None)', '(tf.math.acosh)', '(None)', '(tf.math.add_n)', '(None)', '(tf.math.add)', '(None)', '(tf.math.angle)', '(None)', '(tf.math.asin)', '(None)', '(tf.math.asinh)', '(None)', '(tf.math.atan2)', '(None)', '(tf.math.atan)', '(None)', '(tf.math.atanh)', '(None)', '(tf.math.ceil)', '(None)', '(tf.math.conj)', '(None)', '(tf.math.cos)', '(None)', '(tf.math.cosh)', '(None)', '(tf.math.digamma)', '(None)', '(tf.math.divide_no_nan)', '(None)', '(tf.math.divide)', '(None)', '(tf.math.equal)', '(None)', '(tf.math.erf)', '(None)', '(tf.math.erfc)', '(None)', '(tf.math.exp)', '(None)', '(tf.math.expm1)', '(None)', '(tf.math.floor)', '(None)', '(tf.math.floordiv)', '(None)', '(tf.math.floormod)', '(None)', '(tf.math.greater_equal)', '(None)', '(tf.math.greater)', '(None)', '(tf.math.imag)', '(None)', '(tf.math.is_finite)', '(None)', '(tf.math.is_inf)', '(None)', '(tf.math.is_nan)', '(None)', '(tf.math.less_equal)', '(None)', '(tf.math.less)', '(None)', '(tf.math.lgamma)', '(None)', '(tf.math.log1p)', '(None)', '(tf.math.log_sigmoid)', '(None)', '(tf.math.log)', '(None)', '(tf.math.logical_and)', '(None)', '(tf.math.logical_not)', '(None)', '(tf.math.logical_or)', '(None)', '(tf.math.logical_xor)', "('LogicalXor')", '(tf.math.maximum)', '(None)', '(tf.math.minimum)', '(None)', '(tf.math.multiply)', '(None)', '(tf.math.negative)', '(None)', '(tf.math.not_equal)', '(None)', '(tf.math.pow)', '(None)', '(tf.math.real)', '(None)', '(tf.math.reciprocal)', '(None)', '(tf.math.reduce_any)', '(None)', '(False)', '(None)', '(tf.math.reduce_max)', '(None)', '(False)', '(None)', '(tf.math.reduce_mean)', '(None)', '(False)', '(None)', '(tf.math.reduce_min)', '(None)', '(False)', '(None)', '(tf.math.reduce_prod)', '(None)', '(False)', '(None)', '(tf.math.reduce_sum)', '(None)', '(False)', '(None)', '(tf.math.rint)', '(None)', '(tf.math.round)', '(None)', '(tf.math.rsqrt)', '(None)', '(tf.math.sign)', '(None)', '(tf.math.sin)', '(None)', '(tf.math.sinh)', '(None)', '(tf.math.sqrt)', '(None)', '(tf.math.square)', '(None)', '(tf.math.squared_difference)', '(None)', '(tf.math.subtract)', '(None)', '(tf.math.tan)', '(None)', '(tf.math.truediv)', '(None)', '(tf.math.unsorted_segment_max)', '(None)', '(tf.math.unsorted_segment_mean)', '(None)', '(tf.math.unsorted_segment_min)', '(None)', '(tf.math.unsorted_segment_prod)', '(None)', '(tf.math.unsorted_segment_sqrt_n)', '(None)', '(tf.math.unsorted_segment_sum)', '(None)', '(tf.ones_like)', '(None)', '(None)', '(True)', '(tf.rank)', '(None)', '(tf.realdiv)', '(None)', '(tf.reduce_all)', '(None)', '(False)', '(None)', '(tf.size)', '(None)', '(tf.int32)', '(tf.squeeze)', '(None)', '(None)', '(None)', '(tf.stack)', '(0)', "('stack')", '(tf.strings.as_string)', '(-1)', '(False)', '(False)', '(-1)', "('')", '(None)', '(tf.strings.join)', "('')", '(None)', '(tf.strings.length)', '(None)', "('BYTE')", '(tf.strings.reduce_join)', '(None)', '(False)', "('')", '(None)', '(tf.strings.regex_full_match)', '(None)', '(tf.strings.regex_replace)', '(True)', '(None)', '(tf.strings.strip)', '(None)', '(tf.strings.substr)', '(None)', "('BYTE')", '(tf.strings.to_hash_bucket_fast)', '(None)', '(tf.strings.to_hash_bucket_strong)', '(None)', '(tf.strings.to_hash_bucket)', '(None)', '(tf.strings.to_hash_bucket)', '(None)', '(tf.strings.to_number)', '(tf.float32)', '(None)', '(tf.strings.unicode_script)', '(None)', '(tf.tile)', '(None)', '(tf.truncatediv)', '(None)', '(tf.truncatemod)', '(None)', '(tf.where)', '(None)', '(None)', '(None)', '(tf.zeros_like)', '(None)', '(None)', '(True)']

codes=[]
for st in strs:
    codes.append('('+st+')')
    
for code in codes:
    x = fn_parse_code(codes, code)
    print("result",x)


# why ? (`@ABCDEFG89HIJKLMNO89PQRSTUVW89XYZ[\]^_89`abcdefg89hijklmno89pqrstuvw89xyz{|}~8901234567890123456789

# hope: (tf.batch_gather)=> `(tf.batch_gather)`

```

----------
files: QQ??20191024195805.png
hgrepos: 384
messages: 355328
nosy: veaba
priority: normal
severity: normal
status: open
title: Regular match overflow
type: security
Added file: https://bugs.python.org/file48677/QQ??20191024195805.png

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

From report at bugs.python.org  Thu Oct 24 10:32:03 2019
From: report at bugs.python.org (Mo)
Date: Thu, 24 Oct 2019 14:32:03 +0000
Subject: [New-bugs-announce] [issue38583] The activate script in Windows is
 not correct for venvs created in git-bash
Message-ID: <1571927523.33.0.935819222823.issue38583@roundup.psfhosted.org>


New submission from Mo <moabrahams at dashavoo.com>:

When creating a virtual environment on Windows from git-bash (using python -m venv), VIRTUAL_ENV in the activate script is set using a windows style path (C:\some\path) instead of the bash style (/c/some/path).

This means the system python and pip get used, despite the user thinking they are working in a venv after sourcing activate.

As activate is a bash script, the paths in it should always be in the bash style, regardless of platform.

This is described in a stack overflow issue here: https://stackoverflow.com/questions/57758841/windows-virtualenv-created-via-gitbash-using-system-python

I have confirmed the behaviour in 3.7.3, 3.7.4, 3.7.5 and 3.8.0.

----------
components: Windows
messages: 355333
nosy: Mo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: The activate script in Windows is not correct for venvs created in git-bash
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Oct 24 10:40:54 2019
From: report at bugs.python.org (Lucas Cimon)
Date: Thu, 24 Oct 2019 14:40:54 +0000
Subject: [New-bugs-announce] [issue38584] argparse: Specifying a
 whitespace-only help message to a positional arg triggers an IndexError
 when displaying --help
Message-ID: <1571928054.48.0.618310381662.issue38584@roundup.psfhosted.org>


New submission from Lucas Cimon <lucas.cimon at gmail.com>:

The test I am going to add to test_argparse.py:

    def test_whitespace_help(self):
        parser = self._get_parser()
        parser.add_argument(
            '--foo2', action='store_true', help=' ')
        parser.add_argument(
            'bar2', type=float, help=' ')
        parser.format_help()  # raises an IndexError

----------
components: Library (Lib)
messages: 355336
nosy: Lucas Cimon
priority: normal
severity: normal
status: open
title: argparse: Specifying a whitespace-only help message to a positional arg triggers an IndexError when displaying --help
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 24 10:45:42 2019
From: report at bugs.python.org (Avi Kelman)
Date: Thu, 24 Oct 2019 14:45:42 +0000
Subject: [New-bugs-announce] [issue38585] defusedexpat not supported past
 python 3.3/3.4
Message-ID: <1571928342.44.0.0364587849841.issue38585@roundup.psfhosted.org>


New submission from Avi Kelman <avikelman at d3b.center>:

https://docs.python.org/3/library/xml.html continues to recommend defusedexpat, but that package won't install for any Python versions after 3.4 because the package isn't being maintained. https://bitbucket.org/tiran/defusedexpat/src/default/ linked from https://pypi.org/project/defusedexpat/ stops at 3.3. https://github.com/tiran/defusedexpat stops at 3.4.

If the package doesn't actually work for newer Pythons, the recommendation should be removed from official documentation.

----------
assignee: docs at python
components: Documentation
messages: 355337
nosy: Avi Kelman, docs at python
priority: normal
severity: normal
status: open
title: defusedexpat not supported past python 3.3/3.4
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/issue38585>
_______________________________________

From report at bugs.python.org  Thu Oct 24 11:16:03 2019
From: report at bugs.python.org (Lucas Cimon)
Date: Thu, 24 Oct 2019 15:16:03 +0000
Subject: [New-bugs-announce] [issue38586] logging: handlers names are not
 set when using fileConfig
Message-ID: <1571930163.44.0.759260613385.issue38586@roundup.psfhosted.org>


New submission from Lucas Cimon <lucas.cimon at gmail.com>:

The logging.Handler .name property is not set when the logging configuration is loaded with logging.fileConfig

----------
components: Library (Lib)
messages: 355338
nosy: Lucas Cimon
priority: normal
severity: normal
status: open
title: logging: handlers names are not set when using fileConfig
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 24 14:26:07 2019
From: report at bugs.python.org (Mike Driscoll)
Date: Thu, 24 Oct 2019 18:26:07 +0000
Subject: [New-bugs-announce] [issue38587] __set_name__ missing from
 descriptor howto documentation
Message-ID: <1571941567.01.0.700775981923.issue38587@roundup.psfhosted.org>


New submission from Mike Driscoll <kyosohma at gmail.com>:

I noticed that __set_name__ is not mentioned in https://docs.python.org/3/howto/descriptor.html even though it was added in https://www.python.org/dev/peps/pep-0487/ and mentioned here https://docs.python.org/3/whatsnew/3.6.html#pep-487-descriptor-protocol-enhancements

----------
assignee: docs at python
components: Documentation
messages: 355345
nosy: Mike Driscoll, docs at python
priority: normal
severity: normal
status: open
title: __set_name__ missing from descriptor howto documentation
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Oct 25 09:25:50 2019
From: report at bugs.python.org (LCatro)
Date: Fri, 25 Oct 2019 13:25:50 +0000
Subject: [New-bugs-announce] [issue38588] Use-after-free in dict/list
Message-ID: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>


New submission from LCatro <m4i1f0rt3st at sina.cn>:

Code :

The varanit bval forget call Py_INCREF to add reference in dict_equal()

    b->ma_keys->dk_lookup(b, key, ep->me_hash, &bval);  <--- ...
    if (bval == NULL) {
        Py_DECREF(key);
        Py_DECREF(aval);
        if (PyErr_Occurred())
            return -1;
        return 0;
    }
    cmp = PyObject_RichCompareBool(aval, bval, Py_EQ);


PoC 1 :

class poc() :
    def __eq__(self,other) :
        dict2.clear()
        return NotImplemented

dict1 = {0:poc()}
dict2 = {0:set()}
dict1 == dict2   ##  dict_equal() -> PyObject_RichCompareBool


Crash Detail :


(gdb) run ../python_poc_info/dict_poc_1.py 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/fuzzing/Desktop/Python-3.8.0/python ../python_poc_info/dict_poc_1.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000046e445 in do_richcompare (v=v at entry=0x7ffff7e767d0, w=w at entry=0x7ffff6dd88c0, op=op at entry=2)
    at Objects/object.c:725
725	    if (!checked_reverse_op && (f = w->ob_type->tp_richcompare) != NULL) {


======

Code :

The varanit wl->ob_item[i] forget call Py_INCREF to add reference in list_richcompare()

    for (i = 0; i < Py_SIZE(vl) && i < Py_SIZE(wl); i++) {
        int k = PyObject_RichCompareBool(vl->ob_item[i],
                                         wl->ob_item[i], Py_EQ);  <---


PoC 2 :

class poc() :
    def __eq__(self,other) :
        list1.clear()
        return NotImplemented


list1 = [poc()]
list2 = [1]
list1 == list2  #  list_richcompare() -> PyObject_RichCompareBool


Crash Detail :


(gdb) run ../python_poc_info/list_poc_1.py 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/fuzzing/Desktop/Python-3.8.0/python ../python_poc_info/list_poc_1.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000044bd07 in long_richcompare (self=0x961200 <small_ints+192>, other=0x7ffff7e767d0, op=2)
    at Objects/longobject.c:3083
3083	    CHECK_BINOP(self, other);


======

Code :

The varanit PyList_GET_ITEM(a, i) forget call Py_INCREF to add reference in list_contains()

list_contains(PyListObject *a, PyObject *el)
{
    Py_ssize_t i;
    int cmp;

    for (i = 0, cmp = 0 ; cmp == 0 && i < Py_SIZE(a); ++i)
        cmp = PyObject_RichCompareBool(el, PyList_GET_ITEM(a, i),
                                           Py_EQ);   <----


PoC 3 :

class poc() :
    def __eq__(self,other) :
        list1.clear()
        return NotImplemented

list1 = [ set() ]
poc() in list1  #  list_contains() -> PyObject_RichCompareBool


Crash Detail :


(gdb) run ../python_poc_info/list_poc_2.py 
Starting program: /home/fuzzing/Desktop/Python-3.8.0/python ../python_poc_info/list_poc_2.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000046e445 in do_richcompare (v=v at entry=0x7ffff7e766e0, w=w at entry=0x7ffff6dd88c0, op=op at entry=2)
    at Objects/object.c:725
725	    if (!checked_reverse_op && (f = w->ob_type->tp_richcompare) != NULL) {

----------
messages: 355366
nosy: LCatro, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use-after-free in dict/list
type: security
versions: Python 3.8

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

From report at bugs.python.org  Fri Oct 25 09:36:19 2019
From: report at bugs.python.org (Y3Kv Bv)
Date: Fri, 25 Oct 2019 13:36:19 +0000
Subject: [New-bugs-announce] [issue38589] Bad target address assigned in
 Python Manuals shortcut on Python installation
Message-ID: <1572010579.06.0.155387350533.issue38589@roundup.psfhosted.org>


New submission from Y3Kv Bv <yk3b.bw.ggxwkimobz at gmail.com>:

Since Python 3.7 I'm getting broken shortcut to Python 3.x Manuals:
the installer doesn't seem to check for correct path to hh.exe; sets "C" as drive letter. (Yet path to python3xx.chm starts with correct drive letter.)

----------
messages: 355369
nosy: Y3Kv Bv
priority: normal
severity: normal
status: open
title: Bad target address assigned in Python Manuals shortcut on Python installation
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Oct 25 14:13:04 2019
From: report at bugs.python.org (Tim Sanders)
Date: Fri, 25 Oct 2019 18:13:04 +0000
Subject: [New-bugs-announce] [issue38590] argparse unexpected behavior with
 argument group inside mutually exclusive group
Message-ID: <1572027184.79.0.23480523249.issue38590@roundup.psfhosted.org>


New submission from Tim Sanders <gollum9999 at gmail.com>:

argparse allows adding argument_groups inside of mutually_exclusive_groups, but the behavior is unintuitive and a bit buggy.

Demo:


import argparse

parser = argparse.ArgumentParser()
single_group = parser.add_argument_group(title='single_group')
single_group.add_argument('--a', action='store_true')

mutex_group = parser.add_mutually_exclusive_group()
mutex_group.add_argument('--b', action='store_true')

nested_group = mutex_group.add_argument_group(title='nested_group')
nested_group.add_argument('--c', action='store_true')
nested_group.add_argument('--d', action='store_true')

parser.print_help()
print(parser.parse_args())


Example output:


$ ~/test_args.py --a --b --c --d
usage: test_args.py [-h] [--a] [--b] [--c] [--d]

optional arguments:
  -h, --help  show this help message and exit
  --b

single_group:
  --a
Namespace(a=True, b=True, c=True, d=True)



Two issues I've noticed with this:
 - Arguments in the nested group show up in the usage string, but not in the help text.  The nested arguments are still parsed and available in the result, as normal.
 - Arguments in the nested group are not mutually exclusive with any arguments in the containing mutually_exclusive_group.  
   - I would expect:
       --b          ok
       --c          ok
       --d          ok
       --b --c      error
       --b --d      error
       --c --d      error*
       --b --c --d  error

*From a design perspective, it seems like argument_groups are meant to control display, and mutually_exclusive_groups are meant to control logic, so I think "error" makes sense here.  I personally would like the ability to allow "--c --d", but I think that's a separate discussion and probably a new type of group.

----------
components: Library (Lib)
messages: 355370
nosy: Tim Sanders
priority: normal
severity: normal
status: open
title: argparse unexpected behavior with argument group inside mutually exclusive group
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/issue38590>
_______________________________________

From report at bugs.python.org  Fri Oct 25 15:23:29 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 25 Oct 2019 19:23:29 +0000
Subject: [New-bugs-announce] [issue38591] Deprecating MultiLoopChildWatcher
Message-ID: <1572031409.68.0.540120244927.issue38591@roundup.psfhosted.org>


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

Proposal: 
Deprecate the alternative process watcher implementation to ThreadedChildWatcher, MultiLoopChildWatcher.

Motivation:
The idea for this proposal came from a comment from Andrew Svetlov in GH-16552:
"I believe after polishing ThreadedChildWatcher we can start deprecation of watchers subsystem at all, it generates more problems than solves."

Although Andrew suggested the idea of deprecating the process watchers subsystem entirely, I think that it would be adequate to start with just deprecating MultiLoopChildWatcher and proceeding from there. This is because the other three watcher implementations are significantly more stable in comparison (based on number of issues), have less complex implementations, and have far more widespread usage across public repositories. I would not be opposed to deprecating the other alternative watchers as well, but MultiLoopChildWatcher likely has the most justification for removal.

Details:
The class MultiLoopChildWatcher has a fairly complex implementation, causes a number of issues, is fairly unstable, is rarely utilized in comparison with the rest of the watchers API. It seems to have become a significant burden on maintenance for asyncio development without providing a significant benefit to the vast majority of users. 

Current unresolved MultiLoopChildWatcher issues:
https://bugs.python.org/issue38323
https://bugs.python.org/issue38182
https://bugs.python.org/issue37573

(3 out of the 5 open process watcher issues are caused by MultiLoopChildWatcher)

GitHub code usage comparison:
MultiLoopChildWatcher: https://github.com/search?l=Python&q=MultiLoopChildWatcher&type=Code (20 results)
ThreadedChildWatcher: https://github.com/search?l=Python&q=ThreadedChildWatcher&type=Code (77 results) 
FastChildWatcher: https://github.com/search?l=Python&q=FastChildWatcher&type=Code (4,426 results)
SafeChildWatcher: https://github.com/search?l=Python&q=SafeChildWatcher&type=Code (7,007 results)
All of asyncio usage: https://github.com/search?l=Python&q=asyncio&type=Code (599,131 results)

Note that for the above results, it also includes matches in the CPython repository and for repositories that have exact copies of Lib/asyncio/unix_events.py. Also, ThreadedChildWatcher likely has significantly less results since it's already the default watcher returned by asyncio.get_child_watcher(), so there's less need to explicitly declare it compared to the others. There are of course private repositories and non-GitHub repositories this doesn't include, but it should provide a general idea of overall usage.

My experience in interacting with asyncio users is similar to the results. The process watchers subsystem seems to be minimally used compared to the rest of asyncio, with ThreadedChildWatcher likely being the most used as the default returned from `asyncio.get_child_watcher()`. I have not personally seen a realistic example of usage of MultiLoopChildWatcher outside of python/cpython, and all of the results returned on GitHub were copies of Lib/asyncio/unix_events.py or Lib/test/test_asyncio/test_subprocess.py.

I would be interested in working on this issue if it is approved, as I think it would provide a significant long term reduction in maintenance for asyncio; allowing us to focus on the improvement and development of other features that benefit a far larger audience.

----------
components: asyncio
messages: 355372
nosy: aeros, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecating MultiLoopChildWatcher
versions: Python 3.9

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

From report at bugs.python.org  Fri Oct 25 16:18:20 2019
From: report at bugs.python.org (Marco Rougeth)
Date: Fri, 25 Oct 2019 20:18:20 +0000
Subject: [New-bugs-announce] [issue38592] Add pt-br to the language switcher
 at the Python docs website
Message-ID: <1572034700.82.0.68590075216.issue38592@roundup.psfhosted.org>


New submission from Marco Rougeth <marco at rougeth.com>:

The translation of the Python docs for Brazilian Portuguese is at around 20%. The Brazilian community have been working hard on it for the past 2 years, and as discussed with Julien, we believe this is a good moment to add the pt-br language switcher.

----------
messages: 355384
nosy: rougeth
priority: normal
severity: normal
status: open
title: Add pt-br to the language switcher at the Python docs website

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

From report at bugs.python.org  Fri Oct 25 17:51:08 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Fri, 25 Oct 2019 21:51:08 +0000
Subject: [New-bugs-announce] [issue38593] Python 3.7 does not catch infinite
 recursion for some values of sys.getrecursionlimit()
Message-ID: <1572040268.11.0.31838216135.issue38593@roundup.psfhosted.org>


New submission from Valentyn Tymofieiev <valentyn at google.com>:

While investigating an issue[1] in Apache Beam, we observed that Python 3.7 does not catch an infinite recursion for some values of sys.getrecursionlimit().

Repro steps:

docker run -it --entrypoint=/bin/bash python:3.7-stretch
git clone https://github.com/tvalentyn/beam.git
cd beam
git checkout origin/reproduce_uncaught_recursion_error
cd sdks/python
pip install nose
pip install -e .[gcp,test]
python ./setup.py nosetests --nocapture --tests 'apache_beam/runners/dataflow/dataflow_runner_test.py:DataflowRunnerTest.test_remote_runner_display_data'

On Python 3.7, the test output is:

==========
Recursion limit set to: 1002
Caught maximum recursion depth exceeded while calling a Python object. Current recursionlimit is 1002
Recursion limit set to: 1003
Caught maximum recursion depth exceeded. Current recursionlimit is 1003
Recursion limit set to: 1004
Caught maximum recursion depth exceeded while calling a Python object. Current recursionlimit is 1004
Recursion limit set to: 1005
Caught maximum recursion depth exceeded while calling a Python object. Current recursionlimit is 1005
Recursion limit set to: 1006
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00007fd9f28a5700 (most recent call first):
  File "/usr/local/lib/python3.7/site-packages/dill/_dill.py", line 424 in get
...
==========

So, if we set recursion limit to 1006 in [2], Python 3.7 interpreter does not throw/catch RecursionError in [3]. On Python 3.5, 3.6 the same code successfully catches RecursionError.  
 
[1] https://issues.apache.org/jira/browse/BEAM-8397 
[2] https://github.com/tvalentyn/beam/blob/158cc9006fef74fc17d52a4220172758f7a82820/sdks/python/apache_beam/runners/dataflow/dataflow_runner_test.py#L235 
[3] https://github.com/tvalentyn/beam/blob/158cc9006fef74fc17d52a4220172758f7a82820/sdks/python/apache_beam/pipeline.py#L599

----------
components: Interpreter Core
messages: 355389
nosy: Valentyn Tymofieiev
priority: normal
severity: normal
status: open
title: Python 3.7 does not catch infinite recursion for some values of sys.getrecursionlimit()
versions: Python 3.7

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

From report at bugs.python.org  Fri Oct 25 23:24:54 2019
From: report at bugs.python.org (Gregory Szorc)
Date: Sat, 26 Oct 2019 03:24:54 +0000
Subject: [New-bugs-announce] [issue38594] importlib.metadata documentation
 deficiencies
Message-ID: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>


New submission from Gregory Szorc <gregory.szorc at gmail.com>:

As I was attempting to implement the find_distributions() interface for PyOxidizer, I got confused by importlib.metadata's documentation.

The documentation for this module states:

```
What this means in practice is that to support finding distribution package
metadata in locations other than the file system, you should derive from
``Distribution`` and implement the ``load_metadata()`` method. Then from
your finder, return instances of this derived ``Distribution`` in the
``find_distributions()`` method.
```

The reference to `load_metadata()` is the only occurrence of the string `load_metadata` in the CPython and importlib_metadata code bases. I therefore believe the documentation in both CPython and the importlib_metadata standalone package are wrong because they are referring to a method that is never implemented nor called.

Looking at the documentation and source code for importlib.metadata, I'm also a bit confused about how exactly I'm supposed to implement a custom Distribution which isn't based on filesystems. For example, I see that certain APIs return Path-like objects (which I will need to implement). But it isn't clear exactly which attributes are mandated to exist! Am I expected to implement the full pathlib.Path interface or just a subset?

Regarding how find_distributions() is called, I also don't understand why the Context is optional and how Context could be used in some situations. For example, the implementation of discover() can construct Context instances with no arguments, which is then fed into find_distributions(). So I guess context=None or context.name=None implies "return Distribution's for every known package?" If so, this behavior is undocumented.

I'm also not sure what Context.path is for. I /think/ it is only used for the path-based finder/distribution. But the way it is documented implies it should always exist, which doesn't seem appropriate for cases like PyOxidizer which will retrieve metadata from in-memory without filesystem I/O.

I think what I'm trying to say is that the existing documentation for importlib.metadata is not sufficient to robustly implement a custom find_distributions() + Distribution type. I would kindly request that a domain expert revise the documentation such that a 3rd party can implement a custom solution. My preferred solution would be for there to be formal interfaces in importlib.abc like there are for everything else in the importlib realm. (The interfaces for finders and loaders are super useful when implementing a finder/loader from scratch.)

FWIW I think I like the new metadata API and I think it is flexible enough to allow tools like PyOxidizer to do crazy things like divorce resources from the filesystem! But it is hard to say for sure since the interfaces aren't clearly defined at present.

----------
assignee: docs at python
components: Documentation
messages: 355402
nosy: barry, docs at python, indygreg, jaraco
priority: normal
severity: normal
status: open
title: importlib.metadata documentation deficiencies
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Oct 26 01:19:33 2019
From: report at bugs.python.org (Ryan Govostes)
Date: Sat, 26 Oct 2019 05:19:33 +0000
Subject: [New-bugs-announce] [issue38595] io.BufferedRWPair doc warning may
 need clarification
Message-ID: <1572067173.75.0.622729203693.issue38595@roundup.psfhosted.org>


New submission from Ryan Govostes <rgovostes at gmail.com>:

The documentation for the io.BufferedRWPair class gives this warning:

> BufferedRWPair does not attempt to synchronize accesses to its underlying raw streams. You should not pass it the same object as reader and writer; use BufferedRandom instead.

I have a hard time understanding what this warning is trying to tell me.

1. What does it mean to "synchronize accesses"?

2. Why can't I pass the same object as reader and writer? The docstring in _pyio.py says, "This is typically used with a socket or two-way pipe."

3. How does BufferedRandom, which adds the seek() and tell() interfaces, address the issue of "synchroniz[ing] accesses"? Is synchronization automatic? What does this do for sockets or pipes which cannot seek?

----------
assignee: docs at python
components: Documentation
messages: 355404
nosy: docs at python, rgov
priority: normal
severity: normal
status: open
title: io.BufferedRWPair doc warning may need clarification
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat Oct 26 04:45:04 2019
From: report at bugs.python.org (=?utf-8?b?RmXImXRpbMSDIEdlb3JnZSBDxIN0xINsaW4=?=)
Date: Sat, 26 Oct 2019 08:45:04 +0000
Subject: [New-bugs-announce] [issue38596] simple example give a Linux core
 dumped with atk-bridge
Message-ID: <1572079504.05.0.0514921170938.issue38596@roundup.psfhosted.org>


New submission from Fe?til? George C?t?lin <catalinfest at gmail.com>:

My simple notepad code with QtWidgets.QPlainTextEdit() give me a crash dump on Linux Fedora 30 with python3

Python 3.7.4 (default, Jul  9 2019, 16:32:37) 
[GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] on linux

[mythcat at desk pyqt5_examples]$ uname -a
Linux desk 5.3.7-200.fc30.x86_64 #1 SMP Fri Oct 18 20:13:59 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[mythcat at desk pyqt5_examples]$ python3 notepad.py 

** (python3:3077): WARNING **: 11:26:06.007: AT-SPI: Could not obtain desktop path or name


** (python3:3077): WARNING **: 11:26:06.029: atk-bridge: GetRegisteredEvents returned message with unknown signature

** (python3:3077): WARNING **: 11:26:06.029: atk-bridge: get_device_events_reply: unknown signature

** (python3:3077): WARNING **: 11:26:06.029: atk-bridge: get_device_events_reply: unknown signature
Traceback (most recent call last):
  File "notepad.py", line 222, in assign_syntax_py
    self.syntax = mytext(self.text_widget.document())
NameError: name 'mytext' is not defined
Traceback (most recent call last):
  File "notepad.py", line 222, in assign_syntax_py
    self.syntax = mytext(self.text_widget.document())
NameError: name 'mytext' is not defined
Aborted (core dumped)

The code is self.syntax = my_notepad.mytext(self.text_widget.document())

----------
components: Interpreter Core
messages: 355408
nosy: catafest
priority: normal
severity: normal
status: open
title: simple example give a Linux core dumped with atk-bridge
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Sat Oct 26 15:48:20 2019
From: report at bugs.python.org (Kevin Schlossser)
Date: Sat, 26 Oct 2019 19:48:20 +0000
Subject: [New-bugs-announce] [issue38597] C Extension import limit
Message-ID: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>


New submission from Kevin Schlossser <kevin.g.schlosser at gmail.com>:

System
Windows 7 x64 SP2
Ram 16GB
6 Core AMD @ 3.2ghz

CPython 3.7.2


C Extension (pyd) import cap.

There seems to be a cap on the number of extensions that a package is able to contain. I am able to import 123 extension modules that my package has but when i go to import number 124 i get the following traceback

ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed.

these extension modules are part of my package, importing an extension module from another package does not change this behavior. it is only when I import the 124th extension that is in my package does it occur. 

When I change the order of the imports the error does not follow the import. I end up getting the same error when the 124th extension gets loaded doesn't matter what extension it is. 

I have tried to see if maybe it was a module limit and I spread the imports across multiple files and it still fails when the 124th gets loaded. I also tried imp.load_dynamic and importlib.import_module and the same error occurs.

If there is a way to work around this limitation it would be very helpful.

----------
components: Extension Modules
messages: 355425
nosy: Kevin Schlossser
priority: normal
severity: normal
status: open
title: C Extension import limit
type: resource usage
versions: Python 3.7

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

From report at bugs.python.org  Sat Oct 26 17:03:56 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Oct 2019 21:03:56 +0000
Subject: [New-bugs-announce] [issue38598] IDLE: Disable F5, etc, in Shell,
 even after saving
Message-ID: <1572123836.51.0.5425055858.issue38598@roundup.psfhosted.org>


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

When the Shell is active, the Run menu is disabled, but its shortcuts are not.  These are F5 Run Module, Shift-F5 Run ... Custom, and Alt-X Check Module.  If Shell has not been saved, the shortcuts do nothing, but once Shell has been saved, they try to compile the entire shell session.

The result is that the '3' in 'Python 3.8 ...' on the first line is highlighted as an error and the SyntaxError box pops up.  When the box is dismissed, the cursor is placed after the '3'.

Instead of calling compile, IDLE should beep and continue.

----------
assignee: terry.reedy
components: IDLE
messages: 355432
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: Disable F5, etc, in Shell, even after saving
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Oct 27 03:08:05 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 27 Oct 2019 07:08:05 +0000
Subject: [New-bugs-announce] [issue38599] Deprecate creation of asyncio
 object when the loop is not running
Message-ID: <1572160085.79.0.39835517746.issue38599@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Consider the following code:

import asyncio

q = asyncio.Queue()

async def main():
    await asyncio.gather(q.put(1), q.get(1))

asyncio.run(main())


This code just hangs since run() creates a loop but queue is bound with another (default) event loop.

The error is confusing and hard-to-debug.

We should raise a warning at least for the case; start from DeprecationWarning and make the system stricter later.

asyncio/locks.py is also affected since it has first-class classes (classes that instantiated by a user directly without factories).

----------
components: asyncio
messages: 355449
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate creation of asyncio object when the loop is not running
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 27 04:16:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Oct 2019 08:16:09 +0000
Subject: [New-bugs-announce] [issue38600] Change the mark up of NULL
Message-ID: <1572164169.73.0.860465695362.issue38600@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently NULL is mostly marked up as *NULL* in the C API documentation (although it is marked up as ``NULL`` outside of the C API documentation). It is rendered with italic font as function parameters and contradicts with formatting other macros and constants with monospace font.

The proposed PR replaces all *NULL* with ``NULL``.

----------
assignee: docs at python
components: Documentation
messages: 355452
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Change the mark up of NULL
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Oct 27 08:09:24 2019
From: report at bugs.python.org (Kiran Kumar Kotari)
Date: Sun, 27 Oct 2019 12:09:24 +0000
Subject: [New-bugs-announce] [issue38601] Couldn't able to install multiple
 python minor version in windows
Message-ID: <1572178164.18.0.338058343246.issue38601@roundup.psfhosted.org>


New submission from Kiran Kumar Kotari <kirankotari at live.com>:

Today, Python 2.x/3.x Windows installation script is check for any python minor versions installed from the same train and updating it. This creates a problem of checking the project features. We solved multi-trains like 3.5 and 3.6 installation using pyenv-win but the minor version was a problem due to EXE file validation before installation and if any it updates the same. 

Can you please help us on updating the EXE script to with 
 - validate the minor versions by default
 - off the validate the minor version on installation

This feature helps us with minor version validation.

----------
components: Installation
messages: 355463
nosy: kkotari
priority: normal
severity: normal
status: open
title: Couldn't able to install multiple python minor version in windows
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/issue38601>
_______________________________________

From report at bugs.python.org  Sun Oct 27 09:27:03 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 27 Oct 2019 13:27:03 +0000
Subject: [New-bugs-announce] [issue38602] Add fcntl.F_OFD_XXXX constant
Message-ID: <1572182823.74.0.700361916573.issue38602@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

Since Linux 3.15 is released.
fcntl.F_OFD_XXXX is used for python code.
It can be found on GitHub.
(https://github.com/ceph/ceph/blob/41d3fdc554ce920a631c7c6699a383134173fcff/qa/workunits/fs/misc/filelock_interrupt.py#L13)

I am working on this issue.

----------
components: Library (Lib)
messages: 355466
nosy: corona10, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add fcntl.F_OFD_XXXX constant
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 27 11:24:34 2019
From: report at bugs.python.org (Antony Lee)
Date: Sun, 27 Oct 2019 15:24:34 +0000
Subject: [New-bugs-announce] [issue38603] inspect.getdoc could examine the
 __class__ cell for dynamically generated subclasses
Message-ID: <1572189874.33.0.728183278975.issue38603@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

Currently, `inspect.getdoc()` fails to inherit docstrings in dynamically generated subclasses, such as
```
class Base:
    def method(self): "some docstring"

def make_subclass():
    class subclass(Base):
        def method(self): return super().method()
    return subclass

subclass = make_subclass()
inspect.getdoc(subclass.method)  # => returns None
```
because `inspect._findclass()` tries to find the base class by parsing `subclass.method.__qualname__` which is `"make_subclass.<locals>.subclass.method"` and chokes over `.<locals>.`.

In the case where the method does rely on `super()`, there is another way we can go back to the "owning" class of the method: by looking up the contents of the `__class__` cell (which is set up to make 0-arg super()).

Perhaps a `__class__` cell could even be set up for *all* methods defined in dynamically created subclasses (i.e. whose `__qualname__` includes `.<locals>.`), to help with introspection?

----------
components: Library (Lib)
messages: 355472
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: inspect.getdoc could examine the __class__ cell for dynamically generated subclasses
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 27 12:02:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Oct 2019 16:02:05 +0000
Subject: [New-bugs-announce] [issue38604] Schedule Py_UNICODE API removal
Message-ID: <1572192125.35.0.636716899488.issue38604@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Python 3.3 deprecated the C API functions using Py_UNICODE type. Examples in the doc:

* https://docs.python.org/dev/c-api/unicode.html#c.Py_UNICODE
* https://docs.python.org/dev/c-api/unicode.html#deprecated-py-unicode-apis

Currently, functions removal is scheduled for Python 4.0 but I would prefer that Python 4.0 doesn't have a long list of removed features, but no more than usual. So I'm trying to remove a few functions from Python 3.9, and try to prepare removal for others.

Py_UNICODE C API was mostly kept for backward compatibility with Python 2. Since Python 2 support ends at the end of the year, can we start to organize Py_UNICODE C API removal?

There are multiple questions:

* Should we drop the whole API at once? Or can we/should we start by removing a few functions, and then the others?
* Deprecation warnings are emitted at compilation. But I'm not aware of DeprecationWarning emited at runtime. IMHO we should emit DesprecationWarning at runtime during at least one release, so most developers ignore compilation warnings.

I propose to:

* (Right now) write an exhaustive list of all deprecated APIs: functions, constants, types, etc.
* Modify C code to emit DeprecationWarning at runtime in Python 3.9
* Experiment a modified Python without these APIs and test how many projects are broken by this removal: see PEP 608
* Schedule the actual removal of all these APIS from Python 3.10

Honestly, if the removal is causing too much issues, I'm fine to make slowdown the removal. It's just a matter of clearly communicating our intent.

Maybe we should also announce the scheduled removal in What's in Python 3.9 and in the capi-sig mailing list.

----------
components: Library (Lib)
messages: 355475
nosy: vstinner
priority: normal
severity: normal
status: open
title: Schedule Py_UNICODE API removal
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 27 12:07:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Oct 2019 16:07:10 +0000
Subject: [New-bugs-announce] [issue38605] [typing] PEP 563: Postponed
 evaluation of annotations: enable it by default before Python 4.0
Message-ID: <1572192430.43.0.755831692199.issue38605@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The PEP 563: Postponed evaluation of annotations was introduced an opt-in feature using "from __future__ import annotations". It is scheduled to become the default in Python 4.0.

I would prefer to limit the number of incompatible changes in Python 4.0: it should just a "regular" release, with a regular number of incompatible changes. The version number change is going to cause enough troubles...

Would it be possible possible to enable postponed evaluation of annotations either before or after Python 4.0? For example, can we imagine to enable it by default in Python 3.9? If not, what about Python 3.10?

See also the PEP 608 (Coordinated Python release) and bpo-38604 (Schedule Py_UNICODE API removal).

----------
components: Library (Lib)
messages: 355476
nosy: lukasz.langa, vstinner
priority: normal
severity: normal
status: open
title: [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0
versions: Python 3.9

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

From report at bugs.python.org  Sun Oct 27 14:17:55 2019
From: report at bugs.python.org (ishan gambhir)
Date: Sun, 27 Oct 2019 18:17:55 +0000
Subject: [New-bugs-announce] [issue38606] Function to count total number of
 common divisors of two numbers
Message-ID: <1572200275.66.0.453308218443.issue38606@roundup.psfhosted.org>


New submission from ishan gambhir <ishugambhir2001 at gmail.com>:

The function given in attached file can be added in math module

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 355490
nosy: ishan gambhir
priority: normal
severity: normal
status: open
title: Function to count total number of common divisors of two numbers
type: enhancement
Added file: https://bugs.python.org/file48680/cd_count.py

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

From report at bugs.python.org  Sun Oct 27 14:18:43 2019
From: report at bugs.python.org (Ben Spiller)
Date: Sun, 27 Oct 2019 18:18:43 +0000
Subject: [New-bugs-announce] [issue38607] Document that cprofile/profile
 only profile the main thread
Message-ID: <1572200323.18.0.841143569385.issue38607@roundup.psfhosted.org>


New submission from Ben Spiller <spiller.ben at gmail.com>:

The built-in profiling modules only provide information about the main thread (at least when invoked as documented). 

To avoid user confusion we should state this in the documentation at https://docs.python.org/3/library/profile.html. 

Potentially we could also suggest mitigations such as manually creating a Profile instance in the user's thread code, but the most important thing is to make clear what the module does/does not do out of the box. 

(see also https://bugs.python.org/issue9609 which discusses a possible non-doc change to help with multi-threading, but looks like that's stalled, so best to push ahead with doc'ng this.

----------
assignee: docs at python
components: Documentation
messages: 355492
nosy: benspiller, docs at python
priority: normal
severity: normal
status: open
title: Document that cprofile/profile only profile the main thread
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Oct 27 21:50:13 2019
From: report at bugs.python.org (Wei-Cheng Pan)
Date: Mon, 28 Oct 2019 01:50:13 +0000
Subject: [New-bugs-announce] [issue38608] Undocumented behavior that
 IsolatedAsyncioTestCase would enable event loop debug mode
Message-ID: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>


New submission from Wei-Cheng Pan <legnaleurc at gmail.com>:

In bpo-32972 we enabled debug mode in IsolatedAsyncioTestCase._setupAsyncioLoop, which may print some warnings that are not that important to tests.
(e.g. Executing <Future ...> took 0.110 seconds)

I personally don't really like it being turn on by default, but if it needs to be so, maybe include it in document would be a good idea.

Add Andrew to nosy list because he was the author.

----------
components: Tests
messages: 355509
nosy: asvetlov, legnaleurc
priority: normal
severity: normal
status: open
title: Undocumented behavior that IsolatedAsyncioTestCase would enable event loop debug mode
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Oct 27 22:44:52 2019
From: report at bugs.python.org (ysnt27)
Date: Mon, 28 Oct 2019 02:44:52 +0000
Subject: [New-bugs-announce] [issue38609] Trashcan mechanism segfault during
 interpreter finalization in Python 3.7.5
Message-ID: <1572230692.1.0.462220822628.issue38609@roundup.psfhosted.org>


New submission from ysnt27 <yoshint2012 at gmail.com>:

My original issue was reported to Boost.Python,
https://github.com/boostorg/python/issues/248
And I found similar issue
https://bugs.python.org/issue17703

It seems root cause exists in Python not Boost.Python.
As the issue #17703 is already closed, I want to open a new issue.

I attached a sample source code, "sample1.cc".
With the code, I can reproduce segmantation fault, like this.

% gdb /usr/local/python375/bin/python3.7dm
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-115.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/python375/bin/python3.7dm...done.
(gdb) run
Starting program: /usr/local/python375/bin/python3.7dm 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Python 3.7.5 (default, Oct 25 2019, 16:11:10) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sample1
something called
>>> sample1.dummy()
[1]
>>> exit()
~something called

Program received signal SIGSEGV, Segmentation fault.
0x000000000044602a in list_dealloc (op=op at entry=0x7ffff7f4b360)
    at ../Objects/listobject.c:316
316	    Py_TRASHCAN_SAFE_BEGIN(op)
(gdb) p _PyRuntime.gilstate.tstate_current
$1 = {_value = 0}
(gdb) where
#0  0x000000000044602a in list_dealloc (op=op at entry=0x7ffff7f4b360)
    at ../Objects/listobject.c:316
#1  0x0000000000466452 in _Py_Dealloc (op=0x7ffff7f4b360)
    at ../Objects/object.c:1971
#2  0x00007ffff051cc28 in something::~something (this=0x7ffff071e140 <obj>, 
    __in_chrg=<optimized out>) at sample1.cc:26
#3  0x00007ffff6eeac99 in __run_exit_handlers (status=status at entry=0, 
    listp=0x7ffff72786c8 <__exit_funcs>, 
    run_list_atexit=run_list_atexit at entry=true) at exit.c:77
#4  0x00007ffff6eeace7 in __GI_exit (status=status at entry=0) at exit.c:99
#5  0x00000000005178e4 in Py_Exit (sts=sts at entry=0)
    at ../Python/pylifecycle.c:2292
#6  0x000000000051faf4 in handle_system_exit () at ../Python/pythonrun.c:636
#7  0x0000000000520d88 in PyErr_PrintEx (
    set_sys_last_vars=set_sys_last_vars at entry=1) at ../Python/pythonrun.c:646
#8  0x000000000052115f in PyErr_Print () at ../Python/pythonrun.c:542
#9  0x0000000000521d1a in PyRun_InteractiveLoopFlags (
    fp=fp at entry=0x7ffff7279640 <_IO_2_1_stdin_>, 
    filename_str=filename_str at entry=0x5e55b2 "<stdin>", 
    flags=flags at entry=0x7fffffffe2f0) at ../Python/pythonrun.c:134
#10 0x00000000005223d8 in PyRun_AnyFileExFlags (
    fp=fp at entry=0x7ffff7279640 <_IO_2_1_stdin_>, filename=0x5e55b2 "<stdin>", 
    closeit=closeit at entry=0, flags=flags at entry=0x7fffffffe2f0)
---Type <return> to continue, or q <return> to quit---
    at ../Python/pythonrun.c:78
#11 0x0000000000422023 in pymain_run_file (fp=0x7ffff7279640 <_IO_2_1_stdin_>, 
    filename=0x0, p_cf=p_cf at entry=0x7fffffffe2f0) at ../Modules/main.c:427
#12 0x00000000004220e5 in pymain_run_filename (
    pymain=pymain at entry=0x7fffffffe320, cf=cf at entry=0x7fffffffe2f0)
    at ../Modules/main.c:1606
#13 0x00000000004221d8 in pymain_run_python (pymain=pymain at entry=0x7fffffffe320)
    at ../Modules/main.c:2867
#14 0x000000000042550f in pymain_main (pymain=pymain at entry=0x7fffffffe320)
    at ../Modules/main.c:3028
#15 0x0000000000425589 in _Py_UnixMain (argc=<optimized out>, 
    argv=<optimized out>) at ../Modules/main.c:3063
#16 0x000000000041f116 in main (argc=<optimized out>, argv=<optimized out>)
    at ../Programs/python.c:15
(gdb) l
311	static void
312	list_dealloc(PyListObject *op)
313	{
314	    Py_ssize_t i;
315	    PyObject_GC_UnTrack(op);
316	    Py_TRASHCAN_SAFE_BEGIN(op)
317	    if (op->ob_item != NULL) {
318	        /* Do it backwards, for Christian Tismer.
319	           There's a simple test case where somehow this reduces
320	           thrashing when a *very* large list is created and
(gdb)

----------
components: Interpreter Core
files: sample1.cc
messages: 355510
nosy: ysnt27
priority: normal
severity: normal
status: open
title: Trashcan mechanism segfault during interpreter finalization in Python 3.7.5
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48681/sample1.cc

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

From report at bugs.python.org  Mon Oct 28 01:49:18 2019
From: report at bugs.python.org (LCatro)
Date: Mon, 28 Oct 2019 05:49:18 +0000
Subject: [New-bugs-announce] [issue38610] use-after-free in list object
 function
Message-ID: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>


New submission from LCatro <m4i1f0rt3st at sina.cn>:

Code 1 :

static PyObject *
list_index_impl(PyListObject *self, PyObject *value, Py_ssize_t start,
                Py_ssize_t stop)
// ...
    for (i = start; i < stop && i < Py_SIZE(self); i++) {
        int cmp = PyObject_RichCompareBool(self->ob_item[i], value, Py_EQ);  <=  self->ob_item[i] can uaf ..


PoC :

class rewrite_list_eq(list) :
    def __eq__(self,other) :
        str(other)   #  <== that will call the object recall function tp_repr and call it ..
        return NotImplemented

class poc() :
    def __eq__(self,other) :
        list1.clear()
        return NotImplemented

list1 = [ poc() ]
list1.index(list1)   #  list_index_impl() -> PyObject_RichCompareBool()


Crash Report :

(gdb) run ../py_poc/list_poc_3.py
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tangjitao/Python-3.8.0/python ../py_poc/list_poc_3.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
PyObject_Str (v=0x7ffff6e82d20) at Objects/object.c:573
573         if (Py_TYPE(v)->tp_str == NULL)

===== 

Code 2 :

static PyObject *
list_count(PyListObject *self, PyObject *value)
{
    Py_ssize_t count = 0;
    Py_ssize_t i;

    for (i = 0; i < Py_SIZE(self); i++) {
        int cmp = PyObject_RichCompareBool(self->ob_item[i], value, Py_EQ);  //  <=


PoC :

class rewrite_list_eq(list) :
    def __eq__(self,other) :
        str(other)
        return NotImplemented

class poc() :
    def __eq__(self,other) :
        list1.clear()
        return NotImplemented

list1 = rewrite_list_eq([ poc() ])
list1.count(list1)   #  list_count() -> PyObject_RichCompareBool()


Crash Report :

(gdb) run ../py_poc/list_poc_4.py
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tangjitao/Python-3.8.0/python ../py_poc/list_poc_4.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
PyObject_Str (v=0x7ffff6e82d20) at Objects/object.c:573
573         if (Py_TYPE(v)->tp_str == NULL)


===

Code 3 :

static PyObject *
list_remove(PyListObject *self, PyObject *value)
/*[clinic end generated code: output=f087e1951a5e30d1 input=2dc2ba5bb2fb1f82]*/
{
    Py_ssize_t i;

    for (i = 0; i < Py_SIZE(self); i++) {
		Py_INCREF(self->ob_item[i]);
        int cmp = PyObject_RichCompareBool(self->ob_item[i], value, Py_EQ);


PoC :

class rewrite_list_eq(list) :
    def __eq__(self,other) :
        str(other)
        return NotImplemented

class poc() :
    def __eq__(self,other) :
        list1.clear()
        return NotImplemented

list1 = rewrite_list_eq([ poc() ])
list1.remove(list1)   #  list_count() -> PyObject_RichCompareBool()


Crash Report :

(gdb) run ../py_poc/list_poc_5.py
Starting program: /tangjitao/Python-3.8.0/python ../py_poc/list_poc_5.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
PyObject_Str (v=0x7ffff6e82d20) at Objects/object.c:573
573         if (Py_TYPE(v)->tp_str == NULL)

----------
components: Interpreter Core
messages: 355513
nosy: LCatro, serhiy.storchaka
priority: normal
severity: normal
status: open
title: use-after-free in list object function
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 28 05:11:15 2019
From: report at bugs.python.org (Jim Carroll)
Date: Mon, 28 Oct 2019 09:11:15 +0000
Subject: [New-bugs-announce] [issue38611] Bug in traceback.py
Message-ID: <1572253875.02.0.816082787085.issue38611@roundup.psfhosted.org>


New submission from Jim Carroll <jim at carroll.com>:

_elementtree.c defines a custom exception 'xml.etree.ElementTree.ParseError' that inherits from SyntaxError. According to the docs https://docs.python.org/3/library/exceptions.html#SyntaxError

``Instances of this class have attributes filename, lineno, offset and text for easier access to the details.``

The ElementTree.Parser does not provide these extra attributes. While unittesting a badly formatted string passed to ET.fromstring(), the unittests/results.py module passes the exception to traceback.py, which attempts to extract the members causing it to raise a new exception.

Either ElementTree.Parser should be raising something other than SyntaxErrors, or it should be providing the required attributes, or traceback.py needs to be more flexible and test for the extra attributes before accessing.

I'm willing to submit a patch, but before diving in, wasn't sure which path people would prefer to see fixed?

The code in traceback.py is from lines 516 - 521.

----------
components: Library (Lib)
messages: 355518
nosy: jamercee
priority: normal
severity: normal
status: open
title: Bug in traceback.py
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 28 07:08:00 2019
From: report at bugs.python.org (Richard Pausch)
Date: Mon, 28 Oct 2019 11:08:00 +0000
Subject: [New-bugs-announce] [issue38612] some non-ascii charcters link to
 same identifier/data
Message-ID: <1572260880.13.0.309355653543.issue38612@roundup.psfhosted.org>


New submission from Richard Pausch <r.pausch at hzdr.de>:

The issue was first reported in https://github.com/ipython/ipython/issues/11918. 

Some non-ascii characters like ? (\u03c6) and ? (\u03d5) map/link to the same data/identifier. 

```python
? = 1
? = 2
print(?) # results in 2 - should be 1
print(?) # results in 2
```

It has so far been shown to occur both in python 3.6 and 3.7.

----------
messages: 355525
nosy: PrometheusPi
priority: normal
severity: normal
status: open
title: some non-ascii charcters link to same identifier/data
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct 28 07:55:45 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 28 Oct 2019 11:55:45 +0000
Subject: [New-bugs-announce] [issue38613] Optimize some set operations in
 dictkeys object
Message-ID: <1572263745.15.0.0692968844895.issue38613@roundup.psfhosted.org>


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

-, |, and ^ of dictkeys are implemented as:

PyObject *result = PySet_New(self);
// Call set.difference_update, set.update, set.symmetric_difference_update with other.

PySet_New(iterable) has optimized step for iterable is dict.
But since iterable is dictkeys, PyIter_Next() is called for all elements in the dict.

We can pass dict instead of dictkey object to PySet_New.

  $ ./python -m pyperf timeit -o patched.json -s 'k = dict.fromkeys("abcdefghijklmnopqrstuvwxyz").keys(); s={1,2,3}' -- 'k | {1,2,3}'
  $ ./python -m pyperf compare_to master.json patched.json
  Mean +- std dev: [master] 778 ns +- 17 ns -> [patched] 550 ns +- 24 ns: 1.42x faster (-29%)

----------
components: Interpreter Core
messages: 355536
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Optimize some set operations in dictkeys object
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 28 08:18:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Oct 2019 12:18:15 +0000
Subject: [New-bugs-announce] [issue38614] test_asyncio: test_communicate()
 failed on AMD64 FreeBSD Shared 3.8
Message-ID: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 FreeBSD Shared 3.8:
https://buildbot.python.org/all/#builders/374/builds/10

This buildbot worker is known to be very slow. It became even slower recently.


ERROR: test_communicate (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-564d/build/Lib/test/test_asyncio/test_subprocess.py", line 147, in test_communicate
    exitcode, stdout = self.loop.run_until_complete(task)
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-564d/build/Lib/asyncio/base_events.py", line 608, in run_until_complete
    return future.result()
  File "/usr/home/buildbot/python/3.8.koobs-freebsd-564d/build/Lib/asyncio/tasks.py", line 490, in wait_for
    raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

Extract of the test:

    def test_communicate(self):
        args = PROGRAM_CAT

        async def run(data):
            proc = await asyncio.create_subprocess_exec(
                *args,
                stdin=subprocess.PIPE,
                stdout=subprocess.PIPE,
            )
            stdout, stderr = await proc.communicate(data)
            return proc.returncode, stdout

        task = run(b'some data')
        task = asyncio.wait_for(task, 60.0)
        exitcode, stdout = self.loop.run_until_complete(task)    # <==== HERE
        self.assertEqual(exitcode, 0)
        self.assertEqual(stdout, b'some data')

It seems like the test has an hardcoded timeout of 1 minute. The first thing that we can do is to increase this timeout to 5 minutes.

----------
components: Tests
messages: 355537
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_communicate() failed on AMD64 FreeBSD Shared 3.8
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 28 09:58:01 2019
From: report at bugs.python.org (Jairo Llopis)
Date: Mon, 28 Oct 2019 13:58:01 +0000
Subject: [New-bugs-announce] [issue38615] imaplib has no timeout setting
Message-ID: <1572271081.51.0.380114547236.issue38615@roundup.psfhosted.org>


New submission from Jairo Llopis <yajo.sk8 at gmail.com>:

No way to pass a timeout to imaplib.IMAP4 or imaplib.IMAP4_SSL.

When opening the connection, the only way is to use socket.settimeout(), which affects the global execution environment.

It's interesting that poplib includes the needed timeout parameter instead... weird. I think it was forgotten for imaplib.

----------
components: Library (Lib)
messages: 355542
nosy: Jairo Llopis
priority: normal
severity: normal
status: open
title: imaplib has no timeout setting
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/issue38615>
_______________________________________

From report at bugs.python.org  Mon Oct 28 10:41:07 2019
From: report at bugs.python.org (hai shi)
Date: Mon, 28 Oct 2019 14:41:07 +0000
Subject: [New-bugs-announce] [issue38616] Using Py_XDECREF to replace
 Py_DECREF in PyAST_FromNodeObject()
Message-ID: <1572273667.46.0.78113656156.issue38616@roundup.psfhosted.org>


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

`if (c.c_normalize) {
     Py_DECREF(c.c_normalize);
}` 
--> 
`Py_XDECREF(c.c_normalize);`

----------
components: Interpreter Core
messages: 355545
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Using Py_XDECREF to replace Py_DECREF in PyAST_FromNodeObject()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 28 10:56:23 2019
From: report at bugs.python.org (hai shi)
Date: Mon, 28 Oct 2019 14:56:23 +0000
Subject: [New-bugs-announce] [issue38617] Using Py_XINCREF to replace
 Py_INCREF in PyAST_CompileObject
Message-ID: <1572274583.69.0.135811249474.issue38617@roundup.psfhosted.org>


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

1) param is unpredictable;
2) the compiler_free() use Py_XDECREF(c->c_filename) in PyAST_CompileObject();

----------
components: Interpreter Core
messages: 355547
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Using Py_XINCREF to replace Py_INCREF in PyAST_CompileObject
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 28 11:08:30 2019
From: report at bugs.python.org (hai shi)
Date: Mon, 28 Oct 2019 15:08:30 +0000
Subject: [New-bugs-announce] [issue38618] Why not use refcount of
 c.c_filename in PyAST_FromNodeObject()
Message-ID: <1572275310.19.0.141379413528.issue38618@roundup.psfhosted.org>


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

I don't know why don't use refcount
`
/* borrowed reference */
c.c_filename = filename;
`
in https://github.com/python/cpython/blob/master/Python/ast.c#L786-L787

like
`
Py_INCREF(filename);
c.c_filename = filename;
`
in https://github.com/python/cpython/blob/master/Python/compile.c#L333

----------
components: Interpreter Core
messages: 355548
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Why not use refcount of c.c_filename in PyAST_FromNodeObject()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 28 11:50:18 2019
From: report at bugs.python.org (Felipe)
Date: Mon, 28 Oct 2019 15:50:18 +0000
Subject: [New-bugs-announce] [issue38619] [Doc] UUID.hex is lowercase
Message-ID: <1572277818.51.0.346216542748.issue38619@roundup.psfhosted.org>


New submission from Felipe <felipe.nospam.ochoa at gmail.com>:

The hex property of `UUID` is implemented as `'%032x' % self.int`

Is it specified that this will always be lowercase? If so, can we add a note to the documentation indicating so?

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 355553
nosy: docs at python, fov
priority: normal
severity: normal
status: open
title: [Doc] UUID.hex is lowercase
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 28 12:17:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Oct 2019 16:17:26 +0000
Subject: [New-bugs-announce] [issue38620] Shell python-config --includes
 returns the same path twice
Message-ID: <1572279446.17.0.15456686003.issue38620@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

When the shell script implementation of python-config was introduced, $PLATINCDIR variable was added:

commit 874211978c8097b8e747c90fa3ff41aacabe340f
Author: doko at python.org <doko at python.org>
Date:   Sat Jan 26 11:39:31 2013 +0100

    - Issue #16235: Implement python-config as a shell script.

...
+INCDIR="-I$includedir/python${VERSION}${ABIFLAGS}"
+PLATINCDIR="-I$includedir/python${VERSION}${ABIFLAGS}"
...
+        --includes)
+            echo "$INCDIR $PLATINCDIR"
+        ;;
+        --cflags)
+            echo "$INCDIR $PLATINCDIR $BASECFLAGS $CFLAGS $OPT"
+        ;;
...

But this variable is always equal to $INCDIR: it doesn't seem possible to change its value.

What is the purpose of emitting the same path twice?

Example on Fedora 30:

$ file /usr/bin/python3.8-x86_64-config 
/usr/bin/python3.8-x86_64-config: a /usr/bin/sh script, ..

$ /usr/bin/python3.8-x86_64-config --includes
-I/usr/include/python3.8 -I/usr/include/python3.8

=> /usr/include/python3.8 is giving twice

----------
components: Build
messages: 355561
nosy: doko, vstinner
priority: normal
severity: normal
status: open
title: Shell python-config --includes returns the same path twice
versions: Python 3.9

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

From report at bugs.python.org  Mon Oct 28 12:47:43 2019
From: report at bugs.python.org (Fred Drake)
Date: Mon, 28 Oct 2019 16:47:43 +0000
Subject: [New-bugs-announce] [issue38621] Bad decoding of encoded-words in
 unstructured email headers
Message-ID: <1572281263.86.0.289924184677.issue38621@roundup.psfhosted.org>


New submission from Fred Drake <fdrake at gmail.com>:

I've encountered a problem parsing an email with this Subject: header:

Subject: Be sure to redeem your =?utf-8?Q?$?=201.71 credit card reward
 certificate by the end of the year

email._header_value_parser.get_unstructured defers to get_encoded_word, passing the argument

  '=?utf-8?Q?$?=201.71 credit card reward certificate by the end of the year'

get_encoded_word eventually calls email._encoded_words.decode with the argument

  '=?utf-8?Q?$?=201.71 credit card reward certificate by the end of the year?='

This doesn't seem right, but I'm unsure of the syntactic priority of =XX and ?= in this case.

The policy for this is email.policy.SMTP + email.policy.strict (not sure if that's ideal; I'm retrieving messages from mbox files and over IMAP).

----------
assignee: r.david.murray
messages: 355564
nosy: barry, fdrake, r.david.murray
priority: normal
severity: normal
status: open
title: Bad decoding of encoded-words in unstructured email headers

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

From report at bugs.python.org  Mon Oct 28 14:18:57 2019
From: report at bugs.python.org (tholl)
Date: Mon, 28 Oct 2019 18:18:57 +0000
Subject: [New-bugs-announce] [issue38622] _ctypes.dlsym (py_dl_sym) does not
 trigger audit hooks
Message-ID: <1572286737.48.0.245277798688.issue38622@roundup.psfhosted.org>


New submission from tholl <py at any.tholl.xyz>:

The dlsym operation generally (e.g. when done through a ctypes.CDLL object) triggers the "ctypes.dlsym" audit event. However, using _ctypes.dlsym directly does not trigger this event. This appears to be an oversight, given that _ctypes.dlopen *does* trigger the "ctypes.dlopen" audit event.

A (very minimal) patch is attached.

I was not entirely sure what format the DLL handle should take when it is passed to the audit function, so for now it just turns it back into a number via PyLong_FromVoidPtr (i.e. into the same format in which it is passed into _ctypes.dlsym in the first place).

----------
components: Extension Modules
files: audit.patch
keywords: patch
messages: 355583
nosy: tholl
priority: normal
severity: normal
status: open
title: _ctypes.dlsym (py_dl_sym) does not trigger audit hooks
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48684/audit.patch

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

From report at bugs.python.org  Mon Oct 28 18:39:25 2019
From: report at bugs.python.org (Peter Bittner)
Date: Mon, 28 Oct 2019 22:39:25 +0000
Subject: [New-bugs-announce] [issue38623] Python documentation should
 mention how to find site-packages
Message-ID: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>


New submission from Peter Bittner <peter.bittner at gmx.net>:

A popular question on StackOverflow is, "How do I find the location of my Python site-packages directory?" [1]

While this may hint at a deeper problem that needs to be solved, a user suggested [2] the accepted answer to be added to Python's official documentation.

The most appropriate place I could find to add related information is ``Doc/tutorial/modules.rst``.

[1] https://stackoverflow.com/questions/122327/how-do-i-find-the-location-of-my-python-site-packages-directory/46071447
[2] https://stackoverflow.com/questions/122327/how-do-i-find-the-location-of-my-python-site-packages-directory/46071447#comment103247041_46071447

----------
assignee: docs at python
components: Documentation
messages: 355599
nosy: bittner, docs at python
priority: normal
severity: normal
status: open
title: Python documentation should mention how to find site-packages
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/issue38623>
_______________________________________

From report at bugs.python.org  Mon Oct 28 18:54:26 2019
From: report at bugs.python.org (Inyeol Lee)
Date: Mon, 28 Oct 2019 22:54:26 +0000
Subject: [New-bugs-announce] [issue38624] pathlib .suffix, .suffixes,
 .stem unexpected behavior for pathname with trailing dot
Message-ID: <1572303266.25.0.298826612475.issue38624@roundup.psfhosted.org>


New submission from Inyeol Lee <inyeol.lee at gmail.com>:

Python3.8 pathlib treats dot between path stem and suffix as part of suffix in general:

>>> a = pathlib.Path('foo.txt')
>>> a.stem, a.suffix
('foo', '.txt')
>>> a.with_suffix('')
PosixPath('foo')

However, if pathname ends with dot, it treats the trailing dot as part of stem, not part of suffix:

>>> b = pathlib.Path('bar.')
>>> b.stem, b.suffix
('bar.', '')

This looks like a bug. It should return ('bar', '.').
There are couple of unexpected behavior related to this:

>>> pathlib.Path('foo.txt').with_suffix('.')
...
ValueError: Invalid suffix '.' <== Why not PosixPath('foo.') ?
>>> c = pathlib.Path('foo..')
>>> c.stem, c.suffix, c.suffixes
('foo..', '', [])

I think above should return ('foo.', '.', ['.', '.'])

Tested with macOS 10.15 and Python3.8. Python3.7 behaves the same.

----------
components: Library (Lib)
messages: 355600
nosy: inyeollee
priority: normal
severity: normal
status: open
title: pathlib .suffix, .suffixes, .stem unexpected behavior for pathname with trailing dot
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Oct 28 19:25:13 2019
From: report at bugs.python.org (Graham Coster)
Date: Mon, 28 Oct 2019 23:25:13 +0000
Subject: [New-bugs-announce] [issue38625] SpooledTemporaryFile does not seek
 correctly after being rolled over
Message-ID: <1572305113.57.0.424265086892.issue38625@roundup.psfhosted.org>


Change by Graham Coster <graham_coster999 at yahoo.co.uk>:


----------
components: Library (Lib)
files: spooled-temp-file-does-not-seek-correctly-after-being-rolled.py
nosy: Gary Fernie, James Hennessy, graham.coster, inada.naoki, martin.panter, nubirstein, r.david.murray, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile does not seek correctly after being rolled over
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48685/spooled-temp-file-does-not-seek-correctly-after-being-rolled.py

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

From report at bugs.python.org  Mon Oct 28 23:03:16 2019
From: report at bugs.python.org (Windson Yang)
Date: Tue, 29 Oct 2019 03:03:16 +0000
Subject: [New-bugs-announce] [issue38626] small change at bisect_left
 function for easy understanding
Message-ID: <1572318196.84.0.0964323507502.issue38626@roundup.psfhosted.org>


New submission from Windson Yang <wiwindson at outlook.com>:

bisect_left should be similar to bisect_right. However, the current implement didn't reflect it. A little bit update for the bisect_left function could make the user easy to understand their relation.

def bisect_left(a, x, lo=0, hi=None):
    if lo < 0:
        raise ValueError('lo must be non-negative')
    if hi is None:
        hi = len(a)
    while lo < hi:
        mid = (lo+hi)//2
        # <= should be the only difference between bisect_left and bisect_right
        if x <= a[mid]: hi = mid
        else: lo = mid+1
    return lo

----------
components: Library (Lib)
messages: 355606
nosy: Windson Yang
priority: normal
severity: normal
status: open
title: small change at bisect_left function for easy understanding
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 29 01:55:17 2019
From: report at bugs.python.org (Sebastian Linke)
Date: Tue, 29 Oct 2019 05:55:17 +0000
Subject: [New-bugs-announce] [issue38627] Add copy() method to pathlib
Message-ID: <1572328517.33.0.0527318368455.issue38627@roundup.psfhosted.org>


New submission from Sebastian Linke <Seb_Linke at arcor.de>:

pathlib.Path() could wrap shutil.copy() with something like this:

def copy(self, target):
    if not self.is_file():
        # No support for directories here
        raise ValueError("Path must point to a regular file")
    # copy() appends filename when Path is copied to a directory
    # see shutil.copy() docstring and source for details
    target = shutil.copy(self, target)
    return self.__class__(target)

----------
components: Library (Lib)
messages: 355616
nosy: seblin
priority: normal
severity: normal
status: open
title: Add copy() method to pathlib
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 29 05:17:23 2019
From: report at bugs.python.org (Ayappan)
Date: Tue, 29 Oct 2019 09:17:23 +0000
Subject: [New-bugs-announce] [issue38628] Issue with ctypes in AIX
Message-ID: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>


New submission from Ayappan <ayappanec at gmail.com>:

There seems to be a behavioral issue with ctypes in AIX. 
The specific symptom is that passing structures containing arrays to a C function by value appears to be broken.
Consider the below program.,

#!/usr/bin/env python3

from ctypes import *

libc = CDLL('libc.a(shr_64.o)')


class MemchrArgsHack(Structure):
    _fields_ = [("s", c_char_p), ("c", c_ulong), ("n", c_ulong)]


memchr_args_hack = MemchrArgsHack()
memchr_args_hack.s = b"abcdef"
memchr_args_hack.c = ord('d')
memchr_args_hack.n = 7


class MemchrArgsHack2(Structure):
    _fields_ = [("s", c_char_p), ("c_n", c_ulong * 2)]


memchr_args_hack2 = MemchrArgsHack2()
memchr_args_hack2.s = b"abcdef"
memchr_args_hack2.c_n[0] = ord('d')
memchr_args_hack2.c_n[1] = 7

print(
    CFUNCTYPE(c_char_p, c_char_p, c_uint, c_ulong,
              c_void_p)(('memchr', libc))(b"abcdef", c_uint(ord('d')),
                                          c_ulong(7), None))
print(
    CFUNCTYPE(c_char_p, MemchrArgsHack,
              c_void_p)(('memchr', libc))(memchr_args_hack, None))
print(
    CFUNCTYPE(c_char_p, MemchrArgsHack2,
              c_void_p)(('memchr', libc))(memchr_args_hack2, None))

This one uses memchr from the C library and passing it structures that would map to the registers that correspond to the arguments of memchr. This works for the first structure type in the reproducer; however, using the second structure type (which should be treated the same way) does not work.

In the failing case, the last register that should be used for the structure is not populated from the structure. The reproducer passes an extra argument so that the register is instead populated from that argument for the failing case (instead of working because the register still contains the correct value from a previous call).

The output should be the same for all three calls, but we get:
b'def'
b'def'
None

The last line is None, because memchr got 0 (the None passed on the call) for its length argument.

----------
components: ctypes
messages: 355632
nosy: Ayappan
priority: normal
severity: normal
status: open
title: Issue with ctypes in AIX
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Oct 29 06:18:17 2019
From: report at bugs.python.org (Ran Benita)
Date: Tue, 29 Oct 2019 10:18:17 +0000
Subject: [New-bugs-announce] [issue38629] float is missing __ceil__() and
 __floor__(), required by numbers.Real
Message-ID: <1572344297.94.0.916739375163.issue38629@roundup.psfhosted.org>


New submission from Ran Benita <ran at unusedvar.com>:

The numbers.Real ABC requires the __ceil__ and __floor__ methods (https://github.com/python/cpython/blob/v3.8.0/Lib/numbers.py#L178-L186), however, the float type does not have them.

In regular Python, this is not a problem, because math.ceil() and math.floor() special-case float and work on it directly, and numbers.Real is implemented on float by explicitly registering it (so it's not checked that all required methods are implemented).

Where it becomes a (minor) problem is in typeshed, where the type checker *does* check that all abstract methods are implemented. So, because float is missing these two, typeshed cannot have float implement numbers.Real.

Refs: https://github.com/python/typeshed/issues/3195

----------
components: Interpreter Core, Library (Lib)
messages: 355642
nosy: bluetech
priority: normal
severity: normal
status: open
title: float is missing __ceil__() and __floor__(), required by numbers.Real
type: behavior

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

From report at bugs.python.org  Tue Oct 29 07:18:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Oct 2019 11:18:26 +0000
Subject: [New-bugs-announce] [issue38630] subprocess.Popen.send_signal()
 should poll the process
Message-ID: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

subprocess.Popen.send_signal() doesn't check if the process exited since the poll() method has been called for the last time. If the process exit just before os.kill() is called, the signal can be sent to the wrong process if the process identified is recycled.

Attached PR simply calls poll() once to reduce the time window when this race condition can occur, but it doesn't fully kill the race condition.

--

See also the new "pidfd" API which only landed very recently in the Linux kernel to prevent this issue:

* https://lwn.net/Articles/773459/
  "Toward race-free process signaling" (this articles describes this issue)
* https://lwn.net/Articles/789023/ 
  "New system calls: pidfd_open() and close_range()"
* https://kernel-recipes.org/en/2019/talks/pidfds-process-file-descriptors-on-linux/
  "pidfds: Process file descriptors on Linux" by Chrisitan Brauner

Illumos, OpenBSD, NetBSD and FreeBSD have similar concepts.

I don't propose to use pidfd here, but it's just to highlight that it's a real issue and that kernels are evolving to provide more reliable solutions against the kill(pid, sig) race condition ;-)

----------
components: Library (Lib)
messages: 355645
nosy: vstinner
priority: normal
severity: normal
status: open
title: subprocess.Popen.send_signal() should poll the process
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 29 08:38:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Oct 2019 12:38:55 +0000
Subject: [New-bugs-announce] [issue38631] Replace Py_FatalError() with
 regular Python exceptions
Message-ID: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

I replaced dozens of Py_FatalError() calls with better error reporting, but there are still many places calling Py_FatalError().

The problem of Py_FatalError() is when Python is embedded into an application: Python must not kill the whole process.

Well, even in the "regular" Python (/usr/bin/python3), Python should not exit immediately on an error.

For example, the readline module calls Py_FatalError() on memory allocation failure, whereas PyErr_NoMemory() could be used: PyErr_NoMemory() should work since it should not allocate memory.

----------
components: Interpreter Core
messages: 355651
nosy: vstinner
priority: normal
severity: normal
status: open
title: Replace Py_FatalError() with regular Python exceptions
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 29 09:03:17 2019
From: report at bugs.python.org (Zack Weinberg)
Date: Tue, 29 Oct 2019 13:03:17 +0000
Subject: [New-bugs-announce] [issue38632] setup.py sdist should honor
 SOURCE_DATE_EPOCH
Message-ID: <1572354197.87.0.67466678891.issue38632@roundup.psfhosted.org>


New submission from Zack Weinberg <zackw at panix.com>:

Reproducibility has so far been concerned primarily with binary packages, but it's also desirable for source tarballs to be reproducible starting from a version-control checkout.  This is particularly important for Python, where 'setup.py sdist' can run arbitrary code and generated files (e.g. Cython-generated C) are often included in sdists.

As a small step toward this goal, please add support for the SOURCE_DATE_EPOCH environment variable to distutils.command.sdist.  The most natural way to implement this would be with an additional user option, perhaps called 'timestamp_limit', which takes a date and time argument.  File modification timestamps in the generated tarball or zipfile will be adjusted to be no later than that time.  If 'timestamp_limit' is not set, it defaults to the value of os.environ['SOURCE_DATE_EPOCH'].

The specification for SOURCE_DATE_EPOCH may be found at https://reproducible-builds.org/specs/source-date-epoch/ .

----------
components: Distutils
messages: 355652
nosy: dstufft, eric.araujo, zwol
priority: normal
severity: normal
status: open
title: setup.py sdist should honor SOURCE_DATE_EPOCH

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

From report at bugs.python.org  Tue Oct 29 10:34:38 2019
From: report at bugs.python.org (Peter)
Date: Tue, 29 Oct 2019 14:34:38 +0000
Subject: [New-bugs-announce] [issue38633] shutil.copystat fails with
 PermissionError in WSL
Message-ID: <1572359678.82.0.846153471805.issue38633@roundup.psfhosted.org>


New submission from Peter <peter.schmidb at gmail.com>:

Using shutil.copystat (and therefore also shutil.copytree) in WSL on any directories from a mounted Windows drive (i.e. /mnt/c/...) raises an shutil.Error "[Errno 13] Permission denied". 

It seems to fail when copying the extended filesystem attribute "system.wsl_case_sensitive" using os.setxattr() here: 
https://github.com/python/cpython/blob/da6ce58dd5ac109485af45878fca6bfd265b43e9/Lib/shutil.py#L322

Note that this only happens when both src and dst are on the mounted drive. If only one is on the drive and the other is e.g. in the home directory /home/username/, it will not raise an error. 

Quick way to test: 

cd /mnt/c/ && mkdir test1 && mkdir test2 && python -c "import shutil; shutil.copystat('test1', 'test2')"

----------
components: Library (Lib), Windows
messages: 355655
nosy: paul.moore, pspeter, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: shutil.copystat fails with PermissionError in WSL
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Oct 29 11:17:05 2019
From: report at bugs.python.org (serge-sans-paille)
Date: Tue, 29 Oct 2019 15:17:05 +0000
Subject: [New-bugs-announce] [issue38634] Symbol resolution conflict when
 embeding python in an application using libedit
Message-ID: <1572362225.21.0.644355885677.issue38634@roundup.psfhosted.org>


New submission from serge-sans-paille <serge.guelton at telecom-bretagne.eu>:

See https://bugs.llvm.org/show_bug.cgi?id=43830, but basically the follwing code:

```
// a.c
#include <Python.h>

int main() {
  Py_Initialize();
  PyRun_SimpleString("import readline; print(readline.__doc__)");
  return 0;
}
```

compiled like this:

```
% gcc a.c `./install/bin/python3-config --cflags --ldflags --libs` -lpython3.9
```

runs fine:

```
% ./a.out                                          
Importing this module enables command line editing using GNU readline.
```

However the following:

```
% gcc a.c `./install/bin/python3-config --cflags --ldflags --libs` -ledit -lpython3.9
```

compiles but segfaults at runtime.

----------
messages: 355656
nosy: serge-sans-paille
priority: normal
severity: normal
status: open
title: Symbol resolution conflict when embeding python in an application using libedit
type: crash

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

From report at bugs.python.org  Tue Oct 29 16:35:00 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Oct 2019 20:35:00 +0000
Subject: [New-bugs-announce] [issue38635] Simplify decoding the ZIP64 extra
 field and make it tolerant to extra data
Message-ID: <1572381300.43.0.604148893279.issue38635@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The decoding code can be much shorter and efficient.

Also, the Info-ZIP unzip utility is tolerant to extra bytes. We can be too.

----------
components: Library (Lib)
messages: 355676
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Simplify decoding the ZIP64 extra field and make it tolerant to extra data
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Oct 29 17:14:08 2019
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Tue, 29 Oct 2019 21:14:08 +0000
Subject: [New-bugs-announce] [issue38636] "Alt + T" and "Alt + U" Broken in
 IDLE on Windows
Message-ID: <1572383648.52.0.228001978432.issue38636@roundup.psfhosted.org>


New submission from Stephen Paul Chappell <Noctis.Skytower at gmail.com>:

In the latest Python 3.8.0 installation when running IDLE on Windows, pressing "Alt + T" generates the following error:

    Exception in Tkinter callback
    Traceback (most recent call last):
      File "C:\Program Files\Python38\Lib\tkinter\__init__.py", line 1883, in __call__
        return self.func(*args)
      File "C:\Program Files\Python38\Lib\idlelib\multicall.py", line 176, in handler
        r = l[i](event)
    TypeError: toggle_tabs_event() missing 1 required positional argument: 'event'

Similarly, pressing "Alt + U" will generate a very similar error:

    Exception in Tkinter callback
    Traceback (most recent call last):
      File "C:\Program Files\Python38\Lib\tkinter\__init__.py", line 1883, in __call__
        return self.func(*args)
      File "C:\Program Files\Python38\Lib\idlelib\multicall.py", line 176, in handler
        r = l[i](event)
    TypeError: change_indentwidth_event() missing 1 required positional argument: 'event'

----------
assignee: terry.reedy
components: IDLE, Windows
messages: 355678
nosy: Zero, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: "Alt + T" and "Alt + U" Broken in IDLE on Windows
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Oct 29 22:05:46 2019
From: report at bugs.python.org (toywei)
Date: Wed, 30 Oct 2019 02:05:46 +0000
Subject: [New-bugs-announce] [issue38637] fix GROWTH_RATE comments bug
Message-ID: <1572401146.1.0.358314054297.issue38637@roundup.psfhosted.org>


New submission from toywei <g1e2t3 at foxmail.com>:

It also exists in 3.7/3.6/3.3.

----------
assignee: docs at python
components: Documentation
messages: 355688
nosy: docs at python, toywei
priority: normal
pull_requests: 16516
severity: normal
status: open
title: fix GROWTH_RATE comments bug
type: resource usage
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 30 05:21:06 2019
From: report at bugs.python.org (Alexander Kurakin)
Date: Wed, 30 Oct 2019 09:21:06 +0000
Subject: [New-bugs-announce] [issue38638] Backtrace of exit phase of context
 managers
Message-ID: <1572427266.54.0.98752253476.issue38638@roundup.psfhosted.org>


New submission from Alexander Kurakin <kuraga333 at mail.ru>:

class CM:

    def __init__(self):
        pass

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        raise RuntimeError()

if __name__ == '__main__':
    with CM() as cm:
        print('Hello')


$ python3 cm.py 
Hello
Traceback (most recent call last):
  File "cm.py", line 14, in <module>
    print('Hello')  # <--
  File "cm.py", line 10, in __exit__
    raise RuntimeError()
RuntimeError


Is it correct that print presents in backtrace? Well it's the last line but...

Thanks.

----------
components: Interpreter Core
messages: 355698
nosy: kuraga
priority: normal
severity: normal
status: open
title: Backtrace of exit phase of context managers
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Oct 30 05:29:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Oct 2019 09:29:36 +0000
Subject: [New-bugs-announce] [issue38639] Optimize floor() and ceil() for
 floats
Message-ID: <1572427776.81.0.21510885347.issue38639@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently math.floor(), math.ceil() and math.trunc() look up special methods __floor__, __ceil__ and __trunc__ correspondingly and execute them if found. Otherwise they execute common code for floats. There are no special slots for these methods, so looking up these names in type dicts takes some time. It is a waste of time for most common case -- float objects.

The proposed PR adds checks PyFloat_CheckExact() before looking up the special method. Some microbenchmarks:

$ ./python -m pyperf timeit -s "from math import floor" --duplicate 100 "floor(12345.6)"
Before:  Mean +- std dev: 63.2 ns +- 1.7 ns
After:   Mean +- std dev: 51.8 ns +- 1.3 ns

$ ./python -m pyperf timeit -s "from math import ceil" --duplicate 100 "ceil(12345.6)"
Before:  Mean +- std dev: 61.1 ns +- 1.5 ns
After:   Mean +- std dev: 51.9 ns +- 1.1 ns

$ ./python -m pyperf timeit -s "from math import trunc" --duplicate 100 "trunc(12345.6)"
Before:  Mean +- std dev: 72.0 ns +- 1.5 ns
After:   Mean +- std dev: 34.7 ns +- 1.4 ns

We should also check how this optimization affects other types:

$ ./python -m pyperf timeit -s "from math import floor" --duplicate 100 "floor(12345)"
Before:  Mean +- std dev: 56.3 ns +- 1.3 ns
After:   Mean +- std dev: 56.3 ns +- 1.4 ns

$ ./python -m pyperf timeit -s "from math import ceil" --duplicate 100 "ceil(12345)"
Before:  Mean +- std dev: 55.7 ns +- 1.6 ns
After:   Mean +- std dev: 56.8 ns +- 1.6 ns

$ ./python -m pyperf timeit -s "from math import trunc" --duplicate 100 "trunc(12345)"
Before:  Mean +- std dev: 54.7 ns +- 1.3 ns
After:   Mean +- std dev: 56.7 ns +- 1.5 ns

----------
components: Interpreter Core
messages: 355699
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize floor() and ceil() for floats
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 30 05:48:06 2019
From: report at bugs.python.org (Hugo Dupras)
Date: Wed, 30 Oct 2019 09:48:06 +0000
Subject: [New-bugs-announce] [issue38640] while False: break => SyntaxError:
 'break' outside loop
Message-ID: <1572428886.51.0.45563670991.issue38640@roundup.psfhosted.org>


New submission from Hugo Dupras <jabesq at gmail.com>:

In python 3.8 the following code raises an exception, which was not the case with previous python.

```
while False:
    ...
    break
```
It raises the following exception: SyntaxError: 'break' outside loop.
This `while False` loop was used to temporary disable a while loop in our code base.

Workaround to fix this:
```
enable=False
while enable:
    ...
    break
``` (or use the walrus operator)

----------
components: Interpreter Core
messages: 355700
nosy: jabesq
priority: normal
severity: normal
status: open
title: while False: break => SyntaxError: 'break' outside loop
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 30 09:19:43 2019
From: report at bugs.python.org (Vlad Emelianov)
Date: Wed, 30 Oct 2019 13:19:43 +0000
Subject: [New-bugs-announce] [issue38641] lib2to3 does not support py38
 return/yield syntax with starred expressions
Message-ID: <1572441583.83.0.896942127015.issue38641@roundup.psfhosted.org>


New submission from Vlad Emelianov <volshebnyi at gmail.com>:

Lib2to3 does not support changes made in https://bugs.python.org/issue32117

```python
def test():
    my_list = ["value2", "value3"]
    yield "value1", *my_list
    return "value1", *my_list
```

The idea is to use `testlist_star_expr` instead of `testlist`.

This is a backwards compatible change, because testlist_star_expr supports test as well like testlist does.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 355713
nosy: Vlad Emelianov
priority: normal
pull_requests: 16521
severity: normal
status: open
title: lib2to3 does not support py38 return/yield syntax with starred expressions
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 30 10:06:00 2019
From: report at bugs.python.org (Marco Ippolito)
Date: Wed, 30 Oct 2019 14:06:00 +0000
Subject: [New-bugs-announce] [issue38642] python3.7.3 seems to cause
 add-apt-repository to rejct or not find gi library
Message-ID: <1572444360.24.0.26930433052.issue38642@roundup.psfhosted.org>


New submission from Marco Ippolito <ippolito.marco at gmail.com>:

Following the indications found here: https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-repository 
I was trying to install Docker Engine in Ubuntu 18.04.02 Server Edition.

The first installation's steps went fine but I encountered this error message:

    (base) marco at pc:~$ sudo add-apt-repository \ 
    > "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    > $(lsb_release -cs) \
    > stable"
    Traceback (most recent call last):
      File "/usr/bin/add-apt-repository", line 11, in <module>
        from softwareproperties.SoftwareProperties import SoftwareProperties, 
    shortcut_handler
      File "/usr/lib/python3/dist-packages/softwareproperties
    /SoftwareProperties.py", line 67, in <module>
        from gi.repository import Gio
      File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in 
    <module>
        from . import _gi
    ImportError: cannot import name '_gi' from 'gi' (/usr/lib/python3/dist-
    packages/gi/__init__.py)

But import gi in python3 works fine:

    (base) marco at pc:~$ python3
    Python 3.7.3 (default, Mar 27 2019, 22:11:17) 
    [GCC 7.3.0] :: Anaconda, Inc. on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import gi
    >>> 


After changing the first line of /usr/bin/add-apt-repository in order to point to 3.6 version :  #!/usr/bin/python3.6 everything went fine: 

    (base) marco at pc:~$ sudo add-apt-repository \
    >    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    >    $(lsb_release -cs) \
    >    stable"
    Hit:1 http://gb.archive.ubuntu.com/ubuntu bionic InRelease
    Get:2 https://download.docker.com/linux/ubuntu bionic InRelease [64.4 kB]                                                            
    Get:3 http://gb.archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 
    kB]                                                         
    Get:4 http://gb.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6
     kB]
    Get:5 https://download.docker.com/linux/ubuntu bionic/stable amd64    
    Packages [9594 B]
    Get:6 http://gb.archive.ubuntu.com/ubuntu bionic-updates/universe i386 
    Packages [985 kB]  
    Get:7 http://gb.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
    Packages [1017 kB]
    Hit:8 http://apt.postgresql.org/pub/repos/apt bionic-pgdg InRelease                                                                                                                                        
    Hit:9 http://ppa.launchpad.net/certbot/certbot/ubuntu bionic InRelease                                                                                                                                     
    Get:10 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 
    kB]                                                                                                                               
    Fetched 2328 kB in 11s (217 kB/s)                                                                                                                                                                          
    Reading package lists... Done

    (base) marco at pc:~$ sudo apt-get update
    Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
    Hit:2 http://apt.postgresql.org/pub/repos/apt bionic-pgdg InRelease
    Hit:3 http://gb.archive.ubuntu.com/ubuntu bionic InRelease
    Hit:4 http://gb.archive.ubuntu.com/ubuntu bionic-updates InRelease               
    Hit:5 http://gb.archive.ubuntu.com/ubuntu bionic-backports InRelease             
    Hit:6 http://ppa.launchpad.net/certbot/certbot/ubuntu bionic InRelease
    Hit:7 https://download.docker.com/linux/ubuntu bionic InRelease
    Reading package lists... Done

    (base) marco at pc:~$ sudo apt-get install docker-ce docker-ce-cli 
    containerd.io
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following additional packages will be installed:
      aufs-tools cgroupfs-mount pigz
    The following NEW packages will be installed
      aufs-tools cgroupfs-mount containerd.io docker-ce docker-ce-cli pigz
    0 to upgrade, 6 to newly install, 0 to remove and 0 not to upgrade.
    Need to get 85.6 MB of archives.
    After this operation, 384 MB of additional disk space will be used.
    Do you want to continue? [Y/n] Y

So it seems that python3.7.3 has something which causes add-apt-repository to reject/not find gi library

----------
messages: 355714
nosy: Marco Ippolito
priority: normal
severity: normal
status: open
title: python3.7.3 seems to cause add-apt-repository to rejct or not find gi library
type: compile error
versions: Python 3.7

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

From report at bugs.python.org  Wed Oct 30 10:20:36 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 30 Oct 2019 14:20:36 +0000
Subject: [New-bugs-announce] [issue38643] Assertion failures when calling
 PyNumber_ToBase() with an invalid base
Message-ID: <1572445236.44.0.527192204316.issue38643@roundup.psfhosted.org>


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

If a base other than 2, 8, or 16 is passed to PyNumber_ToBase(), an assertion failure will occur. An exception should be raised instead.

This was mentioned in bpo-38249 (msg353039).

----------
components: Interpreter Core
messages: 355715
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Assertion failures when calling PyNumber_ToBase() with an invalid base
type: crash
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Oct 30 10:31:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Oct 2019 14:31:24 +0000
Subject: [New-bugs-announce] [issue38644] Pass explicitly tstate to function
 calls
Message-ID: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Follow-up of bpo-36710 for function calls.

----------
components: Interpreter Core
messages: 355716
nosy: vstinner
priority: normal
severity: normal
status: open
title: Pass explicitly tstate to function calls
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 30 11:07:25 2019
From: report at bugs.python.org (Michael Zhang)
Date: Wed, 30 Oct 2019 15:07:25 +0000
Subject: [New-bugs-announce] [issue38645] datetime.datetime.fromtimestamp(0,
 tzlocal()) throws error
Message-ID: <1572448045.56.0.183251608823.issue38645@roundup.psfhosted.org>


New submission from Michael Zhang <mzhangthirteen at gmail.com>:

Discovered this while trying to use a function in `boto3`. Seems like when tzlocal() is passed with a 0 to datetime.datetime.fromtimestamp(), it throws an "[Errno 22] Invalid argument" error. Using 3.7.4 via Anaconda on Windows 10, and tzlocal().tznames's local timezone for me is EST/EDT.

Can replicate through this:
```
import datetime
from dateutil.tz import tzlocal

print(datetime.datetime.fromtimestamp(0, tzlocal()))
```

----------
messages: 355720
nosy: mzhang13
priority: normal
severity: normal
status: open
title: datetime.datetime.fromtimestamp(0, tzlocal()) throws error
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Wed Oct 30 13:29:23 2019
From: report at bugs.python.org (Tom Lane)
Date: Wed, 30 Oct 2019 17:29:23 +0000
Subject: [New-bugs-announce] [issue38646] Invalid check on the result of
 pthread_self() leads to libpython startup failure
Message-ID: <1572456563.05.0.622338652634.issue38646@roundup.psfhosted.org>


New submission from Tom Lane <tgl at sss.pgh.pa.us>:

Assorted code in the Python core supposes that the result of pthread_self() cannot be equal to PYTHREAD_INVALID_THREAD_ID, ie (void *) -1.  If it is, you get a crash at interpreter startup.  Unfortunately, this supposition is directly contrary to the POSIX specification for pthread_self(), which defines no failure return value; and it is violated by NetBSD's implementation in some circumstances.  In particular, we (the Postgres project) are observing that libpython.so fails when dynamically loaded into a host executable that does not itself link libpthread.  NetBSD's code always returns -1 if libpthread was not present at main program start, as they do not support forking new threads in that case.  They assert (and I can't disagree) that their implementation conforms to POSIX.

A lazy man's solution might be to change PYTHREAD_INVALID_THREAD_ID to some other value like -3, but that's not fixing the core problem that you're violating POSIX by testing for any specific value at all.

Details and background info can be found in this email thread:

https://www.postgresql.org/message-id/flat/25662.1560896200%40sss.pgh.pa.us

----------
components: Interpreter Core
messages: 355723
nosy: tgl
priority: normal
severity: normal
status: open
title: Invalid check on the result of pthread_self() leads to libpython startup failure
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Wed Oct 30 13:32:47 2019
From: report at bugs.python.org (Yoshihiro Nagano)
Date: Wed, 30 Oct 2019 17:32:47 +0000
Subject: [New-bugs-announce] [issue38647] Why only the MacOSXOSAScript in
 webbrowser does not have the name property?
Message-ID: <1572456767.92.0.8897291562.issue38647@roundup.psfhosted.org>


New submission from Yoshihiro Nagano <y.nagano.92 at gmail.com>:

Hello.

I am using the webbrowser library in macOS and just found that only the MacOSXOSAScript object has `_name` property instead of `name.`
All of the other class, which is inherited from the BaseBrowser, has `name` property.
Are there any specific reasons for this API?
Or, are there any ways to access the name of the browser object independent from the browser type?

The corresponding implementation is shown below:
https://github.com/python/cpython/blob/4cb08b6c0ae6989d169dd48c2b24087941f6d0b0/Lib/webbrowser.py#L641-L643

Thank you.

----------
components: Library (Lib), macOS
messages: 355725
nosy: Yoshihiro Nagano, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Why only the MacOSXOSAScript in webbrowser does not have the name property?
type: behavior
versions: Python 2.7, Python 3.7

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

From report at bugs.python.org  Wed Oct 30 14:27:32 2019
From: report at bugs.python.org (Maxwell Bernstein)
Date: Wed, 30 Oct 2019 18:27:32 +0000
Subject: [New-bugs-announce] [issue38648] Py_tp_free is specified twice in
 Python-ast.c
Message-ID: <1572460052.6.0.456691292805.issue38648@roundup.psfhosted.org>


New submission from Maxwell Bernstein <tekk.nolagi at gmail.com>:

This looks like a typo due to copy-paste.

----------
messages: 355726
nosy: tekknolagi
priority: normal
severity: normal
status: open
title: Py_tp_free is specified twice in Python-ast.c
versions: Python 3.8

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

From report at bugs.python.org  Wed Oct 30 15:37:05 2019
From: report at bugs.python.org (David Lambert)
Date: Wed, 30 Oct 2019 19:37:05 +0000
Subject: [New-bugs-announce] [issue38649] tkinter messagebox is sloppy
Message-ID: <1572464225.7.0.112082789313.issue38649@roundup.psfhosted.org>


New submission from David Lambert <b49p23tivg at gmail.com>:

Does aksokcancel return "true" or True ?  The docstring should say True   This is pervasive throughout the module.  tkinter has such a mishmash of numbers supplied as strings, strings supplied as constants making this carelessness egregious.  On the topic of constants, the messagebox module redefines OK.  You might argue that the definition didn't change.  I suspect this issue applies to all versions of tkinter or Tkinter having the messagebox.

# types
ABORTRETRYIGNORE = "abortretryignore"
OK = "ok"
...

# replies
...
OK = "ok"



def askokcancel(title=None, message=None, **options):
    "Ask if operation should proceed; return true if the answer is ok"
    s = _show(title, message, QUESTION, OKCANCEL, **options)
    return s == OK

----------
assignee: docs at python
components: Documentation
messages: 355729
nosy: David Lambert, docs at python
priority: normal
severity: normal
status: open
title: tkinter messagebox is sloppy
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Oct 30 16:01:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Oct 2019 20:01:43 +0000
Subject: [New-bugs-announce] [issue38650] Add constantness to
 PyStructSequence_UnnamedField
Message-ID: <1572465703.12.0.701099038847.issue38650@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently the variable PyStructSequence_UnnamedField has type "char *". It is used as a special value for setting to the name field of PyStructSequence_Field. But the type of the name field is "const char *".

I propose to change the declaration of PyStructSequence_UnnamedField to "const char * const". Makes it referring to immutable character string and make it itself immutable.

It is binary compatible change, but some user code can complain at compilation time if it uses PyStructSequence_UnnamedField in unusual way (assigns to the "char *" variable, etc). It is very unlikely.

----------
components: Interpreter Core
messages: 355731
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add constantness to PyStructSequence_UnnamedField
versions: Python 3.9

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

From report at bugs.python.org  Wed Oct 30 16:39:55 2019
From: report at bugs.python.org (Daniel Johnson)
Date: Wed, 30 Oct 2019 20:39:55 +0000
Subject: [New-bugs-announce] [issue38651] Add WolfSSL support
Message-ID: <1572467995.9.0.965883938595.issue38651@roundup.psfhosted.org>


New submission from Daniel Johnson <djwirecat at gmail.com>:

WolfSSL is an SSL library targeted at embedded development that focuses on size and speed. It's also FIPS certified which is is important for anyone working with federal agencies.

WolfSSL website: https://www.wolfssl.com/
WolfSSL github: https://github.com/wolfSSL/wolfssl

I have two ideas currently on how Python could support WolfSSL:

1.) Shim WolfSSL's OpenSSL compatibility layer in. They don't provide a complete shim for OpenSSL and I'm not sure if they provide all the symbols Python would care about.
2.) Provide an optional configuration to use WolfSSL and it's API instead of OpenSSL.

Would either options be something the Python maintainers would be interested in? I'm testing the waters to see if this is something anyone is interested in.

Thank you for the time!

----------
assignee: christian.heimes
components: SSL
messages: 355733
nosy: Daniel Johnson, christian.heimes
priority: normal
severity: normal
status: open
title: Add WolfSSL support
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/issue38651>
_______________________________________

From report at bugs.python.org  Thu Oct 31 02:14:41 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 31 Oct 2019 06:14:41 +0000
Subject: [New-bugs-announce] [issue38652] Remove/update provisional note for
 asyncio.BufferedProtocol
Message-ID: <1572502481.2.0.695475270667.issue38652@roundup.psfhosted.org>


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

In the documentation (https://docs.python.org/3.9/library/asyncio-protocol.html#buffered-streaming-protocols) for asyncio.BufferedProtocol there is a provisional API note. This should be updated/removed for 3.8 and 3.9 since it became a part of the stable API in 3.8.

Current:

> New in version 3.7: Important: this has been added to asyncio in Python 3.7 on a provisional basis! This is as an experimental API that might be changed or removed completely in Python 3.8.

I would propose to changing it to:

> New in version 3.7.

----------
assignee: docs at python
components: Documentation
messages: 355739
nosy: aeros, asvetlov, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Remove/update provisional note for asyncio.BufferedProtocol
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Oct 31 07:28:28 2019
From: report at bugs.python.org (Hartmut Goebel)
Date: Thu, 31 Oct 2019 11:28:28 +0000
Subject: [New-bugs-announce] [issue38653] pkgutil.extend_path fails with
 zipped eggs if not at first place
Message-ID: <1572521308.12.0.490608170281.issue38653@roundup.psfhosted.org>


New submission from Hartmut Goebel <h.goebel at crazy-compilers.com>:

I have a test site containing nested namespace packages in zipped and unzipped eggs_

- nspkg3_aaa.egg - unzipped egg, namespaces: nspkg3
- nspkg3_bbb.egg - zipped egg  , namespaces: nspkg3, nspkg3.bbb
- nspkg3_ccc.egg - unzipped egg, namespaces: nspkg3

When using order "aaa, bbb, ccc" in PYTHONPATH, importing "nspkg3.bbb" FAILS,
whereas
when using order "bbb, aaa, ccc" in PYTHONPATH, importing "nspkg3.bbb" PASSES,

I would expect "nspk3.bbb" to ba importable 8as a namespace package) no matter which possition it has in PYTHONPATH.


How to reproduce

Preperation: get hands on the eggs in question:

$ wget https://github.com/pyinstaller/pyinstaller/archive/v3.5.zip
$ unzip v3.5.zip
$ cd pyinstaller-3.5/tests/functional/modules/nspkg3-pkg/

Order "aaa, bbb, ccc": fails

$ PYTHONPATH=nspkg3_aaa.egg:nspkg3_bbb.egg:nspkg3_ccc.egg python3.7 -c "import nspkg3.bbb.zzz"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'nspkg3.bbb'

Order "bbb, aaa, ccc": passes:

$ PYTHONPATH=nspkg3_bbb.egg:nspkg3_aaa.egg:nspkg3_ccc.egg python3.7 -c "import nspkg3.bbb.zzz"
this is module nspkg3.bbb.zzz


Further information

I did some research and found that the zipped egg (bbb) is *not added* to the package path when using order "aaa, bbb, ccc":

Order "aaa, bbb, ccc":  bbb is missing here

$ PYTHONPATH=nspkg3_aaa.egg:nspkg3_bbb.egg:nspkg3_ccc.egg \
   python3.7 -c "import nspkg3 ; print(nspkg3.__path__)"
['?/nspkg3_aaa.egg/nspkg3', '?/nspkg3_ccc.egg/nspkg3']

Order "bbb, aaa, ccc":  bbb is included

$ PYTHONPATH=nspkg3_bbb.egg:nspkg3_aaa.egg:nspkg3_ccc.egg \
   python3.7 -c "import nspkg3 ; print(nspkg3.__path__)"
['?/nspkg3_bbb.egg/nspkg3', '?/nspkg3_aaa.egg/nspkg3', '?/nspkg3_ccc.egg/nspkg3']


Also tested with Python 2.7: Same results

----------
components: Library (Lib)
messages: 355745
nosy: htgoebel
priority: normal
severity: normal
status: open
title: pkgutil.extend_path fails with zipped eggs if not at first place
type: behavior
versions: Python 2.7, Python 3.7

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

From report at bugs.python.org  Thu Oct 31 09:17:53 2019
From: report at bugs.python.org (Efanzh)
Date: Thu, 31 Oct 2019 13:17:53 +0000
Subject: [New-bugs-announce] [issue38654] `urllib.request.Request` uses
 mutable value as default value
Message-ID: <1572527873.7.0.615539123104.issue38654@roundup.psfhosted.org>


New submission from Efanzh <efanzh at gmail.com>:

The `headers` argument of the `__init__` method of `urllib.request.Request` class uses `{}` as default value, which is mutable. It is not a good idea.

----------
components: Library (Lib)
messages: 355750
nosy: EFanZh
priority: normal
pull_requests: 16537
severity: normal
status: open
title: `urllib.request.Request` uses mutable value as default value
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Oct 31 10:04:51 2019
From: report at bugs.python.org (pascalhofmann)
Date: Thu, 31 Oct 2019 14:04:51 +0000
Subject: [New-bugs-announce] [issue38655]
 ipaddress.ip_network('0.0.0.0/0').is_private == True
Message-ID: <1572530691.84.0.462430681921.issue38655@roundup.psfhosted.org>


New submission from pascalhofmann <mail at pascalhofmann.de>:

ipaddress.ip_network('0.0.0.0/0').is_private returns True, even though 0.0.0.0/0 clearly is no private network.

----------
components: Library (Lib)
messages: 355753
nosy: pascalhofmann
priority: normal
severity: normal
status: open
title: ipaddress.ip_network('0.0.0.0/0').is_private == True
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct 31 15:05:11 2019
From: report at bugs.python.org (toonn)
Date: Thu, 31 Oct 2019 19:05:11 +0000
Subject: [New-bugs-announce] [issue38656] mimetypes for python 3.7.5 fails
 to detect matroska video
Message-ID: <1572548711.23.0.824957089431.issue38656@roundup.psfhosted.org>


New submission from toonn <python at toonn.io>:

A user reported an error to us which seems to derive from the ``mimetypes`` library failing to guess the mime type for ``.mkv`` matroska video files:
https://github.com/ranger/ranger/issues/1744#issuecomment-548514373

This is a regression because the same query successfully identifies the filename as being of the ``video/x-mastroska`` mime type.

----------
components: Library (Lib)
messages: 355763
nosy: toonn
priority: normal
severity: normal
status: open
title: mimetypes for python 3.7.5 fails to detect matroska video
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Oct 31 16:36:00 2019
From: report at bugs.python.org (Pete Wicken)
Date: Thu, 31 Oct 2019 20:36:00 +0000
Subject: [New-bugs-announce] [issue38657] String format for hexadecimal
 notation breaks padding with alternative form
Message-ID: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>


New submission from Pete Wicken <petewicken at gmail.com>:

When formatting an integer as a hexadecimal value, the '#' alternate form modifier inserts a preceding '0x'. 
If this is used in combination with padding modifiers, the '0x' is counted as part of the overall width, which does not feel like the natural behaviour as extra calculation is required to get the correct post '0x' precision.

Example:

In [7]: f'{num:04x}'
Out[7]: '0800'

In [8]: f'{num:#04x}'
Out[8]: '0x800'

To get the hexadecimal representation padded to 4 digits, you have to account for the preceding 0x:

In [10]: f'{num:#06x}'
Out[10]: '0x0800'

----------
messages: 355767
nosy: Wicken
priority: normal
severity: normal
status: open
title: String format for hexadecimal notation breaks padding with alternative form
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Oct 31 17:38:53 2019
From: report at bugs.python.org (ThePokestarFan)
Date: Thu, 31 Oct 2019 21:38:53 +0000
Subject: [New-bugs-announce] [issue38658] Python Program crashes when
 running in fore and back ground
Message-ID: <1572557933.17.0.948616559199.issue38658@roundup.psfhosted.org>


New submission from ThePokestarFan <sarkaraoyan at gmail.com>:

I have a Python process that should not die that is multiprocessed. I have a queue process that feeds the queue every so often, but my program should use up queue items faster than the queue adds them. I have four worker threads that make requests to an API and update an SQL table with the results. However, if I use nohup and run it, it crashes. Even if I directly run it, it crashes. It used to run forever when I loaded it in PyCharm, but even that crashes it.

----------
components: macOS
files: crash.txt
messages: 355769
nosy: ThePokestarFan, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python Program crashes when running in fore and back ground
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file48688/crash.txt

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

From report at bugs.python.org  Thu Oct 31 21:12:48 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 Nov 2019 01:12:48 +0000
Subject: [New-bugs-announce] [issue38659] enum classes cause slow startup
 time
Message-ID: <1572570768.69.0.355804772721.issue38659@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

Creating an enum subclass (ie: defining an enum) is slow.  This dramatically impacts startup time of Python programs that import a bunch of potentially needed constant definitions at startup before any proper code executes.

How slow?  So slow that a module defining a ~300 enums takes nearly 100ms just to import from its pyc file.

Example code: https://github.com/googleads/google-ads-python/blob/96fd08bb62435f1930df4871033ba8689333b67f/google/ads/google_ads/v2/services/enums.py

We've known this, we should do something about it.  (Even if it means implementing the guts of the magic enum machinery in C.)  ie, it came up in https://bugs.python.org/issue28637 as a stdlib startup time regression and is likely to come up in similar contexts elsewhere.

----------
components: Library (Lib)
messages: 355777
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: enum classes cause slow startup time
type: performance
versions: Python 3.9

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